OpenBSD Mail Box: October 2022

Monday, October 31, 2022

Re: [new] databases/rocksdb

On 10/31/2022 2:15 PM, Landry Breuil wrote:
> Hi,
>
> here's a port of facebook's rocksdb (http://rocksdb.org/), a fork of
> google's leveldb. I've enabled all the archivers deps because
> stalwart-jmap apparently uses snappy compress via rocksdb-rs for its index
> storage. with the shipped ldb binary, i'm able to play/inspect with the
> internal index, eventually backuping it (cf
> https://github.com/facebook/rocksdb/wiki/Administration-and-Data-Access-Tool).
>
> =========
> RocksDB is an embeddable persistent key-value store for fast storage.
> It can also be the foundation for a client-server database but the
> current focus is on embedded workloads.
> =========
>
> feedback welcome. I dont really know if this can get picked up by some
> other ports, from my understanding mariadb can/might use it ?

MariaDB uses it's own embedded copy of RocksDB for the DB engine.

Looking at what supports RocksDB so far, it's bindings that do not
typically come
out of the box with the respective languages and we do not have them in
the ports
tree. So I don't think that's much of an issue.

https://github.com/facebook/rocksdb/blob/main/LANGUAGE-BINDINGS.md

I pushed a patch to improve arm64 support.

https://github.com/facebook/rocksdb/commit/0311956fa44265db45641df94544df72bfc7782f.patch

Re: [new] math/ministat: small statistic utility

On Tue, Nov 01, 2022 at 12:14:34AM +0100, Jeremie Courreges-Anglas wrote:

> tl;dr : the pledge(2) promises looks reasonable to me. While
> I initially found that three pledge(2) was too much, I must admit
> that all of them tighten the program execution before looking at
> untrusted data. For the first call pledge(2), one could argue that the
> program environment is hardly untrusted data, but past problems like
> shellshock have proved this assumption wrong. The second pledge(2) call
> is the least useful IMO, since it only drops "tty" before reading data
> from files. But I feel strongly about dropping it.

> As suspected ministat fails to build on sparc64 (base-gcc) because it
> uses math.h functions but doesn't link against libm. Thanks kmos@ for
> confirming, suggesting the fix and testing it!

> This looks ready to import. ok?

ok kmos to import

--Kurt

[update] devel/luaposix: update to 35.1

Attached an update for luaposix to 35.1. Change in the build system to the new one. Tests can no longer be run as deps are not in tree. I tried out a few examples from upstream, they seemed to work.

cc'd awolk@ as lsyncd is the only revdep, don't anticipate any breakage.

ok?

diff --git a/devel/luaposix/Makefile b/devel/luaposix/Makefile
index 81f39c35924..2ca369aa79b 100644
--- a/devel/luaposix/Makefile
+++ b/devel/luaposix/Makefile
@@ -1,8 +1,7 @@
COMMENT= posix library for the lua language
-V= 33.4.0
+V= 35.1
DISTNAME= luaposix-${V}
EPOCH= 0
-REVISION= 1
CATEGORIES= devel

GH_ACCOUNT= luaposix
@@ -22,11 +21,28 @@ FLAVOR?=
RUN_DEPENDS= devel/lua-bit32
.endif

-CONFIGURE_STYLE= gnu
-
-CONFIGURE_ENV+= LUA=${MODLUA_BIN}
-
-post-install:
- mv ${PREFIX}/share/doc/luaposix ${MODLUA_DOCDIR}
+# needs deps not in tree
+NO_TEST= Yes
+
+post-patch:
+ sed -e "s|/usr/bin/env lua|${MODLUA_BIN}|" -i ${WRKSRC}/build-aux/luke
+
+do-build:
+ cd ${WRKSRC} && \
+ ./build-aux/luke --verbose package=luaposix version=${V} \
+ LDOC=true \
+ PREFIX=${PREFIX} \
+ INST_LIBDIR=${MODLUA_LIBDIR} \
+ INST_LUADIR=${MODLUA_DATADIR} \
+ LUA_INCDIR=${MODLUA_INCL_DIR} \
+ CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" CC="${CC}"
+
+do-install:
+ cd ${WRKSRC} && \
+ ./build-aux/luke --verbose install \
+ LDOC=true \
+ PREFIX=${PREFIX} \
+ INST_LIBDIR=${MODLUA_LIBDIR} \
+ INST_LUADIR=${MODLUA_DATADIR} \

.include <bsd.port.mk>
diff --git a/devel/luaposix/distinfo b/devel/luaposix/distinfo
index b733de45364..a256d2f22b5 100644
--- a/devel/luaposix/distinfo
+++ b/devel/luaposix/distinfo
@@ -1,2 +1,2 @@
-SHA256 (luaposix-33.4.0.tar.gz) = 5mJi9bf+HDLGXxel71/7McTRh3AZtIcKXTc+KrZSaiE=
-SIZE (luaposix-33.4.0.tar.gz) = 643523
+SHA256 (luaposix-35.1.tar.gz) = TEceApyMSvn3NiINzCyK/BIujNt+poBr5NiJo51QEw4=
+SIZE (luaposix-35.1.tar.gz) = 180023
diff --git a/devel/luaposix/pkg/PLIST b/devel/luaposix/pkg/PLIST
index 134090e4fef..70c32b13c18 100644
--- a/devel/luaposix/pkg/PLIST
+++ b/devel/luaposix/pkg/PLIST
@@ -1,58 +1,40 @@
-lib/lua/${MODLUA_VERSION}/posix.a
-lib/lua/${MODLUA_VERSION}/posix.so
-share/doc/${FULLPKGNAME}/
-share/doc/${FULLPKGNAME}/examples/
-share/doc/${FULLPKGNAME}/examples/dir.lua.html
-share/doc/${FULLPKGNAME}/examples/fork.lua.html
-share/doc/${FULLPKGNAME}/examples/fork2.lua.html
-share/doc/${FULLPKGNAME}/examples/getopt.lua.html
-share/doc/${FULLPKGNAME}/examples/glob.lua.html
-share/doc/${FULLPKGNAME}/examples/limit.lua.html
-share/doc/${FULLPKGNAME}/examples/lock.lua.html
-share/doc/${FULLPKGNAME}/examples/netlink-uevent.lua.html
-share/doc/${FULLPKGNAME}/examples/ping.lua.html
-share/doc/${FULLPKGNAME}/examples/poll.lua.html
-share/doc/${FULLPKGNAME}/examples/signal.lua.html
-share/doc/${FULLPKGNAME}/examples/socket.lua.html
-share/doc/${FULLPKGNAME}/examples/termios.lua.html
-share/doc/${FULLPKGNAME}/examples/tree.lua.html
-share/doc/${FULLPKGNAME}/index.html
-share/doc/${FULLPKGNAME}/ldoc.css
-share/doc/${FULLPKGNAME}/modules/
-share/doc/${FULLPKGNAME}/modules/posix.ctype.html
-share/doc/${FULLPKGNAME}/modules/posix.dirent.html
-share/doc/${FULLPKGNAME}/modules/posix.errno.html
-share/doc/${FULLPKGNAME}/modules/posix.fcntl.html
-share/doc/${FULLPKGNAME}/modules/posix.fnmatch.html
-share/doc/${FULLPKGNAME}/modules/posix.getopt.html
-share/doc/${FULLPKGNAME}/modules/posix.glob.html
-share/doc/${FULLPKGNAME}/modules/posix.grp.html
-share/doc/${FULLPKGNAME}/modules/posix.html
-share/doc/${FULLPKGNAME}/modules/posix.libgen.html
-share/doc/${FULLPKGNAME}/modules/posix.poll.html
-share/doc/${FULLPKGNAME}/modules/posix.pwd.html
-share/doc/${FULLPKGNAME}/modules/posix.sched.html
-share/doc/${FULLPKGNAME}/modules/posix.signal.html
-share/doc/${FULLPKGNAME}/modules/posix.stdio.html
-share/doc/${FULLPKGNAME}/modules/posix.stdlib.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.msg.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.resource.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.socket.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.stat.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.statvfs.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.time.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.times.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.utsname.html
-share/doc/${FULLPKGNAME}/modules/posix.sys.wait.html
-share/doc/${FULLPKGNAME}/modules/posix.syslog.html
-share/doc/${FULLPKGNAME}/modules/posix.termio.html
-share/doc/${FULLPKGNAME}/modules/posix.time.html
-share/doc/${FULLPKGNAME}/modules/posix.unistd.html
-share/doc/${FULLPKGNAME}/modules/posix.utime.html
+lib/lua/${MODLUA_VERSION}/posix/
+@so lib/lua/${MODLUA_VERSION}/posix/ctype.so
+@so lib/lua/${MODLUA_VERSION}/posix/dirent.so
+@so lib/lua/${MODLUA_VERSION}/posix/errno.so
+@so lib/lua/${MODLUA_VERSION}/posix/fcntl.so
+@so lib/lua/${MODLUA_VERSION}/posix/fnmatch.so
+@so lib/lua/${MODLUA_VERSION}/posix/glob.so
+@so lib/lua/${MODLUA_VERSION}/posix/grp.so
+@so lib/lua/${MODLUA_VERSION}/posix/libgen.so
+@so lib/lua/${MODLUA_VERSION}/posix/poll.so
+@so lib/lua/${MODLUA_VERSION}/posix/pwd.so
+@so lib/lua/${MODLUA_VERSION}/posix/sched.so
+@so lib/lua/${MODLUA_VERSION}/posix/signal.so
+@so lib/lua/${MODLUA_VERSION}/posix/stdio.so
+@so lib/lua/${MODLUA_VERSION}/posix/stdlib.so
+lib/lua/${MODLUA_VERSION}/posix/sys/
+@so lib/lua/${MODLUA_VERSION}/posix/sys/msg.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/resource.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/socket.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/stat.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/statvfs.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/time.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/times.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/utsname.so
+@so lib/lua/${MODLUA_VERSION}/posix/sys/wait.so
+@so lib/lua/${MODLUA_VERSION}/posix/syslog.so
+@so lib/lua/${MODLUA_VERSION}/posix/termio.so
+@so lib/lua/${MODLUA_VERSION}/posix/time.so
+@so lib/lua/${MODLUA_VERSION}/posix/unistd.so
+@so lib/lua/${MODLUA_VERSION}/posix/utime.so
share/lua/${MODLUA_VERSION}/posix/
-share/lua/${MODLUA_VERSION}/posix/_argcheck.lua
+share/lua/${MODLUA_VERSION}/posix/_base.lua
+share/lua/${MODLUA_VERSION}/posix/_bitwise.lua
+share/lua/${MODLUA_VERSION}/posix/_strict.lua
share/lua/${MODLUA_VERSION}/posix/compat.lua
share/lua/${MODLUA_VERSION}/posix/deprecated.lua
share/lua/${MODLUA_VERSION}/posix/init.lua
share/lua/${MODLUA_VERSION}/posix/sys.lua
share/lua/${MODLUA_VERSION}/posix/util.lua
+share/lua/${MODLUA_VERSION}/posix/version.lua

Re: irssi-1.4.3 released

Lauri Tirkkonen writes:

> Hi, I've been informed that irssi-1.4.3 was just released. It builds fine with
> just a mechanical update, but since you got into the whole Meson update thing
> last time around, perhaps I should leave it to you? :)
>

Here is an update to net/irssi submitted by Lauri Tirkkonen and released
on October 31, 2022.

changelog: https://irssi.org/NEWS/#news-v1-4-3

Main changes in irssi are fixes to freezes and adding help documentation
about -nocap, which caused some issues with icbirc as found by stsp@.

I successfully tested all consumers:
twirssi
irssi-otr
irssi-icb
irssi-xmpp: continues to be BROKEN
icbirc

Tests are welcome. OK?

diff --git a/net/irssi/Makefile b/net/irssi/Makefile
index d78d29a064a..e8cd89e3505 100644
--- a/net/irssi/Makefile
+++ b/net/irssi/Makefile
@@ -6,7 +6,7 @@ MULTI_PACKAGES = -main -otr
COMMENT-main = modular IRC client with many features
COMMENT-otr = OTR (off-the-record) plugin for irssi

-V = 1.4.2
+V = 1.4.3
DISTNAME = irssi-$V
PKGSPEC-main = irssi-=$V
PKGNAME-main = irssi-$V
diff --git a/net/irssi/distinfo b/net/irssi/distinfo
index 67e40a694fb..e5effe4a558 100644
--- a/net/irssi/distinfo
+++ b/net/irssi/distinfo
@@ -1,2 +1,2 @@
-SHA256 (irssi-1.4.2.tar.gz) = LXLJoXi/XL5N+rSZgYAFq7hfeTdkdvkk/AnJacschBk=
-SIZE (irssi-1.4.2.tar.gz) = 1924981
+SHA256 (irssi-1.4.3.tar.gz) = LLrKST1MNtPxpqKgaA69/jvavCAtm4uZ5J9Mg7cCFZE=
+SIZE (irssi-1.4.3.tar.gz) = 1926409

Re: [new] math/ministat: small statistic utility

On Sat, Oct 29 2022, Mikhail <mp39590@gmail.com> wrote:
> On Sat, Oct 29, 2022 at 09:43:28AM +0100, Stuart Henderson wrote:
>> On 2022/10/29 11:02, Mikhail wrote:
>> > On Sat, Oct 29, 2022 at 09:37:08AM +0200, Omar Polo wrote:
>> > >
>> > > Port-wise, the only thing that needs to be adjusted is CFLAGS, as
>> > > it uses the hardcoded ones '-O2 -pipe -Werror' and not the ones
>> > > provided by the port infrastructure; it's very easy to fix:
>> >
>> > Fixed, new archive attached, also the diff between vanilla and this
>> > ministat.c:
>>
>> imho it would be better for the distfile to be exactly the standard
>> FreeBSD version, then apply any changes by patching it in the port
>
> Such way it looks cleaner indeed. Distfile updated, new archive
> attached.

tl;dr : the pledge(2) promises looks reasonable to me. While
I initially found that three pledge(2) was too much, I must admit
that all of them tighten the program execution before looking at
untrusted data. For the first call pledge(2), one could argue that the
program environment is hardly untrusted data, but past problems like
shellshock have proved this assumption wrong. The second pledge(2) call
is the least useful IMO, since it only drops "tty" before reading data
from files. But I feel strongly about dropping it.

As suspected ministat fails to build on sparc64 (base-gcc) because it
uses math.h functions but doesn't link against libm. Thanks kmos@ for
confirming, suggesting the fix and testing it!

This looks ready to import. ok?

Re: [new] stalwart-jmap & stalwart-imap: JMAP server written in rust

Le Sun, Oct 30, 2022 at 06:43:30PM +0100, Landry Breuil a écrit :
> Le Fri, Oct 07, 2022 at 04:44:05PM +0200, Landry Breuil a écrit :
> > hi,
> >
> > here's two new wip ports for https://jmap.stalw.art/ and its counterpart
> > https://imap.stalw.art/ which serves as an IMAP proxy in front of the
> > JMAP server.
> >
> > cf https://jmap.io/software.html for more details about JMAP.
> >
> > i've had quite a struggle with some rust bits but in the end it builds,
> > packages and starts fine. Not properly tested yet, as its mandatory to
> > setup TLS certs for it.
> >
> > it cant work yet with the mail/meli submission i've sent but it's being worked
> > on upstream.
> >
> > as for the uids ive reused the ones from prelude/pfflowd:
> >
> > 561 _rbldns _rbldns net/rbldnsd
> > 562 _smokeping _smokeping net/smokeping
> > 563 _postgrey _postgrey mail/postgrey
> > -#564 _prelude _prelude security/prelude
> > -#565 _pfflowd _pfflowd net/pfflowd
> > +564 _stalwart-jmap _stalwart-jmap mail/stalwart-jmap
> > +565 _stalwart-imap _stalwart-imap mail/stalwart-imap
> > 566 _tor _tor net/tor
> > #567 _dk-milter _dk-milter mail/dk-milter
> > 568 _milter-greylist mail/milter-greylist
>
> New version of the port:
> - used subdirs to factorize most bits in Makefile.inc
> - also includes stalwart-cli port to manage the jmap server
> - tweaked the rc script to log to syslog, a bit ugly with control chars..
> - tweaked the default conf for stalwart-imap, since it runs as an
> unprivileged user it cant bind to 143/993
> - tweaked the conf to disable most certs as they're a pain to deal with
> when one wants to quickly prototype, and TLS should be handled by a
> reverse proxy anyway
> - written a README with all the bits & tweaks i've found so far to have
> something running
> - tested:
> - created domain/account, imported mbox
> - mutt against stalwart-imap -> works, shows mails
> - thunderbird against stalwart-imap -> lists mails, doesnt show mail
> content
> - toyed with curl to query jmap server, works
> - meli over jmap chokes, reported upstream at
> https://git.meli.delivery/meli/meli/issues/162
> - wrangled with https://cypht.org JMAP support, being debugged in
> https://github.com/jasonmunro/cypht/issues/180
>

new version of the ports updated for the recent 0.2.0 releases, which
adds sieve/manage support.
cf https://github.com/stalwartlabs/imap-server/releases/tag/v0.2.0 &
https://github.com/stalwartlabs/jmap-server/releases/tag/v0.2.0

quite some wrangling with rust crates dependencies...

Landry

Python 3.10+ readline issue (was Re: [New(ish)] Python 3.11.0)

On Mon, Oct 31, 2022 at 10:04:30PM +0000, Stuart Henderson wrote:

> If anyone has an idea what's up with readline, I'd love to hear it,
> it's a bit of a blocker for switching to 3.10 by default and I don't find
> the build system particularly easy to work with.

> There's one fairly obvious issue (tb and I both found this one), the
> newer build system wants a libreadline.so symlink; putting that in place
> temporarily in /usr/lib works around that but doesn't fix the problem.

Further details:

Up until Python 3.8.x the readline module built just fine. Starting with
3.9, it complained about the readline module not working, but a working
module _does_ get built anyway. So looking into what changed between 3.8,
3.9, and 3.10 for the build system may yield something.

--Kurt

Re: [New(ish)] Python 3.11.0

On 2022/10/31 17:28, Kurt Mosiejczuk wrote:
> Here's the initial port for Python 3.11.0
>
> I've tested on amd64 and sparc64.
>
> Python upstream switched a number of autoconf things from command line
> switches to environment variables. We may see it show up in later releases
> of the other 3.x versions, but for now we'll just set what we need in the
> 3.11 Makefile.
>
> This still suffers from the same problem 3.10 does where the readline module
> does not build properly. (3.9 makes the same complaint, but somehow a
> working version of the module gets built).
>
> ok?

ok (with my and tb's comments offlist)

If anyone has an idea what's up with readline, I'd love to hear it,
it's a bit of a blocker for switching to 3.10 by default and I don't find
the build system particularly easy to work with.

There's one fairly obvious issue (tb and I both found this one), the
newer build system wants a libreadline.so symlink; putting that in place
temporarily in /usr/lib works around that but doesn't fix the problem.

Re: [new] math/ministat: small statistic utility

On Mon, Oct 31, 2022 at 05:52:27PM +0100, Omar Polo wrote:

> forgot to reply to this, sorry. Agree with sthen@ suggestion and your
> latest tarball it's ok for me to import

It should have 'm' in WANTLIB and also add '-lm' to CFLAGS. That makes it
build on sparc64.

With those two changes, ok kmos to import

--Kurt

[New(ish)] Python 3.11.0

Here's the initial port for Python 3.11.0

I've tested on amd64 and sparc64.

Python upstream switched a number of autoconf things from command line
switches to environment variables. We may see it show up in later releases
of the other 3.x versions, but for now we'll just set what we need in the
3.11 Makefile.

This still suffers from the same problem 3.10 does where the readline module
does not build properly. (3.9 makes the same complaint, but somehow a
working version of the module gets built).

ok?

--Kurt

Index: python.port.mk
===================================================================
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.169
diff -u -p -r1.169 python.port.mk
--- python.port.mk 23 Oct 2022 10:14:04 -0000 1.169
+++ python.port.mk 31 Oct 2022 21:22:01 -0000
@@ -74,7 +74,8 @@ MODPY_VERSION ?= ${MODPY_DEFAULT_VERSION
# verify if MODPY_VERSION found is correct
.if ${MODPY_VERSION} != "2.7" && \
${MODPY_VERSION} != "3.9" && \
- ${MODPY_VERSION} != "3.10"
+ ${MODPY_VERSION} != "3.10" && \
+ ${MODPY_VERSION} != "3.11"
ERRORS += "Fatal: unknown or unsupported MODPY_VERSION: ${MODPY_VERSION}"
.endif

Index: Makefile
===================================================================
RCS file: /cvs/ports/lang/python/Makefile,v
retrieving revision 1.77
diff -u -p -r1.77 Makefile
--- Makefile 11 Aug 2022 02:15:02 -0000 1.77
+++ Makefile 31 Oct 2022 21:22:01 -0000
@@ -2,5 +2,6 @@ SUBDIR =
SUBDIR += 2.7
SUBDIR += 3.9
SUBDIR += 3.10
+SUBDIR += 3.11

.include <bsd.port.subdir.mk>

Re: [new] editors/helix version 22.08.1

Le Mon, 31 Oct 2022 10:07:04 +0100,
Laurent Cheylus <foxy@free.fr> a écrit :

> Hi,
>
> this is a port for Helix (text editor) https://helix-editor.com
>
> Features:
> - Vim-like modal editing
> - Multiple selections
> - Built-in language server support
> - Smart, incremental syntax highlighting and code editing via
> tree-sitter
>
> It's my first port for a Rust tool. Tested on amd64, works fine.
>
> - Makefile defines MASTER_SITES to download helix-22.08.1-source.tar.xz
> : full sources (Helix + TreeSitter grammars)
> - Special case with EXTRACT_CASES to decompress sources in WRKDIST
>
> - Patches (derived from those of the FreeBSD port
> https://github.com/freebsd/freebsd-ports/tree/main/editors/helix/)
> * patch-helix-term_build_rs: remove Git hash in internal version
> * patch-helix-loader_src_lib_rs: define path for data directory
> (${PREFIX}/share/helix)
> * patch-helix-loader_src_grammar_rs: disable internal command 'hx
> --grammar fetch' to fetch TreeSitter grammar with Git
>
> - Install tutor.txt, themes, queries and grammars (.so files built from
> TreeSitter sources) in ${PREFIX}/share/helix/runtime
>
>
> Port also available on GH openbsd-wip
> https://github.com/jasperla/openbsd-wip/tree/master/editors/helix
>
>
> comments welcome, Laurent

the ports looks in good shape and works fine, including LSP support
which I tested with gopls and clangd.

in pkg/DESCR, delete "written in Rust" because this brings
nothing useful, and wrap the long line

remove "post-modern" in the COMMENT, that's not useful

please add ${WRKSRC}/languages.toml into ${PREFIX}/share/helix,
regenerate PLIST after this. this file is useful to use it as a
reference for local tweaks.

with theses changes, it's ok solene@ for import

devel/cargo: MODCARGO_WANTLIB introduction

Hi,

I intent to add MODCARGO_WANTLIB variable in devel/cargo module to help a bit
for WANTLIB.

Any Rust programs using the Rust std library are linked with: c, pthread and
c++abi/libgcc.

As c++abi/libgcc is a bit particular (only sparc64 link to libgcc statically,
others archs are using c++abi dynamically), it is regular source of questions
regarding WANTLIB and COMPILER_LIBCXX (as c++abi usually comes from here).

It was done this way, as sparc64 is using estdc++ for C++ stuff, and so linking
with c++abi could be problematic when C++ is also involved.

WANTLIB variable isn't modified automatically.

port modification to use MODCARGO_WANTLIB could be done smoothly on port update.
a direct modification requires a bump, as WANTLIB value will change on sparc64.

Comments or OK ?
--
Sebastien Marie

diff /data/semarie/repos/openbsd/ports
commit - ec68a50a503667234d64a20f8fdd92b06f887b74
path + /data/semarie/repos/openbsd/ports
blob - 843c9e9a8bd2f5dd2296eedc636a4c521e30a294
file + devel/cargo/cargo.port.mk
--- devel/cargo/cargo.port.mk
+++ devel/cargo/cargo.port.mk
@@ -23,6 +23,19 @@ MODCARGO_CARGOTOML ?= ${WRKSRC}/Cargo.toml
# Default path for cargo manifest.
MODCARGO_CARGOTOML ?= ${WRKSRC}/Cargo.toml

+# WANTLIB for Rust compiled code
+# it should be kept in sync with lang/rust code
+# - c/pthread : all syscalls
+# - c++abi / libgcc.a : unwind
+MODCARGO_WANTLIB = c pthread
+
+.if "${MARCHINE_ARCH}" != "sparc64"
+MODCARGO_WANTLIB += c++abi
+.else
+# libgcc.a is static
+MODCARGO_WANTLIB +=
+.endif
+
# Define MASTER_SITES_CRATESIO for crates.io
MASTER_SITES_CRATESIO = https://crates.io/api/v1/crates/

cpu frequency sensors

> > > o Added CPU frequency sensors for each core on CPUs that have
> > > MPERF/APERF support.

This is current/amd64 on an APU2 (dmesg below).
The cpu line says PERF - does that imply MPERF/APEEF support?
The sensors seem enabled:

hw.sensors.cpu0.frequency0=950000000.00 Hz
hw.sensors.cpu1.frequency0=950000000.00 Hz
hw.sensors.cpu2.frequency0=950000000.00 Hz
hw.sensors.cpu3.frequency0=950000000.00 Hz

while apm says

Performance adjustment mode: auto (1000 MHz)

In fact, dmesg says

cpu0: 998 MHz: speeds: 1000 800 600 MHz

Is the 950 expected, and in fact more true than dmesg's 1000?
Or is that a bug in the sensors code? How can I debug this?

Jan

OpenBSD 7.2-current (GENERIC.MP) #822: Fri Oct 28 21:59:48 MDT 2022
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2112425984 (2014MB)
avail mem = 2031046656 (1936MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7ee92040 (13 entries)
bios0: vendor coreboot version "v4.17.0.2" date 07/28/2022
bios0: PC Engines apu2
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST IVRS SSDT SSDT DRTM HPET
acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf8000000, bus 0-63
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.19 MHz, 16-30-01
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.24 MHz, 16-30-01
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec00000, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec20000, version 21, 32 pins
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PBR4)
acpiprt2 at acpi0: bus 1 (PBR5)
acpiprt3 at acpi0: bus -1 (PBR6)
acpiprt4 at acpi0: bus 2 (PBR7)
acpiprt5 at acpi0: bus -1 (PBR8)
acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu4 at acpi0: no cpu matching ACPI ID 4
acpicpu5 at acpi0: no cpu matching ACPI ID 5
acpicpu6 at acpi0: no cpu matching ACPI ID 6
acpicpu7 at acpi0: no cpu matching ACPI ID 7
acpipci0 at acpi0 PCI0: 0x00000000 0x00000011 0x00000001
acpicmos0 at acpi0
com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at acpi0 COM2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"BOOT0000" at acpi0 not configured
acpitz0 at acpi0: critical temperature is 115 degC
cpu0: 998 MHz: speeds: 1000 800 600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD 16h Root Complex" rev 0x00
vendor "AMD", unknown product 0x1567 (class system subclass IOMMU, rev 0x00) at pci0 dev 0 function 2 not configured
pchb1 at pci0 dev 2 function 0 "AMD 16h Host" rev 0x00
ppb0 at pci0 dev 2 function 2 "AMD 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03: msi, address 00:0d:b9:5e:24:00
ppb1 at pci0 dev 2 function 4 "AMD 16h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 "Intel I211" rev 0x03: msi, address 00:0d:b9:5e:24:01
ccp0 at pci0 dev 8 function 0 "AMD 16h Crypto" rev 0x00
xhci0 at pci0 dev 16 function 0 "AMD Bolton xHCI" rev 0x11: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1
ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: apic 4 int 19, AHCI 1.3
ahci0: port 0: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, YMTC JGS, U033> t10.ATA_YMTC_JGS_2201060101982_
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
ehci0 at pci0 dev 19 function 0 "AMD Hudson-2 USB2" rev 0x39: apic 4 int 18
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 "AMD Hudson-2 SMBus" rev 0x42: SMI
iic0 at piixpm0
iic1 at piixpm0
iic1: addr 0x4c 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words 00=ffff 01=ffff 02=ffff 03=ffff 04=ffff 05=ffff 06=ffff 07=ffff
pcib0 at pci0 dev 20 function 3 "AMD Hudson-2 LPC" rev 0x11
sdhc0 at pci0 dev 20 function 7 "AMD Bolton SD/MMC" rev 0x01: apic 4 int 16
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma
pchb2 at pci0 dev 24 function 0 "AMD 16h Link Cfg" rev 0x00
pchb3 at pci0 dev 24 function 1 "AMD 16h Address Map" rev 0x00
pchb4 at pci0 dev 24 function 2 "AMD 16h DRAM Cfg" rev 0x00
km0 at pci0 dev 24 function 3 "AMD 16h Misc Cfg" rev 0x00
pchb5 at pci0 dev 24 function 4 "AMD 16h CPU Power" rev 0x00
pchb6 at pci0 dev 24 function 5 "AMD 16h Misc Cfg" rev 0x00
isa0 at pcib0
isadma0 at isa0
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
intr_establish: pic ioapic0 pin 7: can't share type 3 with 2
wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x53
vmm0 at mainbus0: SVM/RVI
scsibus2 at sdmmc0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <SD/MMC, SD32G, 0061> removable
sd1: 29512MB, 512 bytes/sector, 60440576 sectors
uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices Hub" rev 2.00/0.18 addr 2
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd1a (935d4b4c539cee8a.a) swap on sd1b dump on sd1b

Re: NEW: net/accounts-sso/{gsignond,signond,libaccounts-glib,libaccounts-qt}

On Mon Oct 31, 2022 at 02:36:32PM +0000, Stuart Henderson wrote:
> On 2022/10/30 17:30, Rafael Sadowski wrote:
> > I add a conflict between gsignond and signond becouse both install
> > share/dbus-1/services/com.google.code.AccountsSSO.SingleSignOn.service
>
> This is going to make things difficult for anything depending on them..
>

Fixed by removing com.google.code.AccountsSSO.SingleSignOn.service from
gsignond because it ships with com.google.code.AccountsSSO.gSingleSignOn.service.
^
Now signond comes with com.google.code.AccountsSSO.SingleSignOn.service and gsignond
with com.google.code.AccountsSSO.gSingleSignOn.service.

New tarball attached

[new] databases/rocksdb

Hi,

here's a port of facebook's rocksdb (http://rocksdb.org/), a fork of
google's leveldb. I've enabled all the archivers deps because
stalwart-jmap apparently uses snappy compress via rocksdb-rs for its index
storage. with the shipped ldb binary, i'm able to play/inspect with the
internal index, eventually backuping it (cf
https://github.com/facebook/rocksdb/wiki/Administration-and-Data-Access-Tool).

=========
RocksDB is an embeddable persistent key-value store for fast storage.
It can also be the foundation for a client-server database but the
current focus is on embedded workloads.
=========

feedback welcome. I dont really know if this can get picked up by some
other ports, from my understanding mariadb can/might use it ?

Landry

update sysutils/obsdfreqd

I made a new release of obsdfreqd. The temperature mode is now trying
to detect a CPU temperature sensor instead of using the first sensor
found, or you can give it a specific temperature sensor to use.

Improvement by Vlad Meşco

diff --git a/sysutils/obsdfreqd/Makefile b/sysutils/obsdfreqd/Makefile
index 9c1de2641d2..4d823cb6632 100644
--- a/sysutils/obsdfreqd/Makefile
+++ b/sysutils/obsdfreqd/Makefile
@@ -1,7 +1,6 @@
COMMENT = userland daemon to manage CPU frequency
-V = 1.0.3
+V = 1.1.0
DISTNAME = obsdfreqd-${V}
-REVISION = 0

CATEGORIES = sysutils

diff --git a/sysutils/obsdfreqd/distinfo b/sysutils/obsdfreqd/distinfo
index 73e89d4b8ba..e77741dba2f 100644
--- a/sysutils/obsdfreqd/distinfo
+++ b/sysutils/obsdfreqd/distinfo
@@ -1,2 +1,2 @@
-SHA256 (obsdfreqd-1.0.3.tar.gz) = la7GN2AE2ZRZXdWLBOf7f4VXlljJze6mPQULfJEOW+M=
-SIZE (obsdfreqd-1.0.3.tar.gz) = 6338
+SHA256 (obsdfreqd-1.1.0.tar.gz) = GueIAUG4GnBT22X5St6v0yKJ1ow5G5crLyPYEw77sFA=
+SIZE (obsdfreqd-1.1.0.tar.gz) = 8745

Re: postfix-pgsql postmap failures after upgrade

On Sun, 30 Oct 2022 09:16:39 -0700
Tim Howe <tim.h@bendtel.com> wrote:

> On Sun, 30 Oct 2022 09:13:19 +0000
> Stuart Henderson <stu@spacehopper.org> wrote:
>
> > If you have the ports tree on your machine you can unpack the attached
> > file under /usr/ports/mail/postfix, pkg_delete postfix, and build a 3.5
> > version from /usr/ports/mail/postfix/stable35 with "FLAVOR=pgsql make
> > install".
>
> Thank you for your help and response.
>
> I was building your stable35 but it failed at sqlite3, which I do have
> installed (found /usr/local/include/sqlite3.h on my system, anyway).
> I wasn't sure if I should play with -I or not.
>
> full error:
>
> dict_sqlite.c:74:10: fatal error: 'sqlite3.h' file not found
> #include <sqlite3.h>
> [...]

I started it over and it seemed to build second time around,
go figure.

--TimH

Re: unexpected behavior from neofetch in snapshots

On Mon, Oct 31, 2022 at 05:28:08PM +0100, Omar Polo wrote:
> On 2022/10/31 11:54:10 -0400, Norvell Spearman <norvell.spearman@gmail.com> wrote:
> > There seems to be a problem between neofetch and bash in snapshots.
> > neofetch displays the ASCII logo for the OS and most of the expected
> > information about the system it's running on, but stops then shows the
> > next command prompt in the middle of the logo, leaving out the usual
> > colored blocks. With 7.2-release and earlier I got behavior as seen in
> > expected.png. With 7.2-current I get behavior as seen in current.png.
> > Running "neofetch -v" shows the following error:
> >
> > /usr/local/bin/neofetch: line 3802: bad substitution: no closing `}' in ${block_spaces// /${blocks}nl}
> >
> > 7.2-release uses bash-5.1.16 while -current uses bash-5.2.2 (with the
> > same version of neofetch in both), so I'm guessing that something
> > changed with bash between the two versions. I don't know much about
> > shell scripting, so all apologies for not being more helpful.
> >
> > To show the expected behavior, I downloaded the -release version of bash
> > (5.1.16), renamed its binary, and told a copy of -current's neofetch to
> > use the renamed bash for execution.
> >
> > Let me know if you need more information. I did check marc.info to see
> > whether anybody else had already reported this, so apologies in advance
> > if I missed something.
>
> There's an issue about this opened on github:
> https://github.com/dylanaraps/neofetch/issues/2209
>
> This is a bit out of my comfort zone, I don't really know what the
> bash // parameter substitution does, but as was hinted by a user in
> that issue escaping the [ fixes it, at least in my brief testing.
>
> (no idea how the raw escape in the diff will end up in the mail)
>
> Index: Makefile
> ===================================================================
> RCS file: /home/cvs/ports/sysutils/neofetch/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- Makefile 11 Mar 2022 19:57:43 -0000 1.11
> +++ Makefile 31 Oct 2022 16:21:37 -0000
> @@ -4,7 +4,7 @@ CATEGORIES = sysutils misc
> GH_ACCOUNT = dylanaraps
> GH_PROJECT = neofetch
> GH_TAGNAME = 7.1.0
> -REVISION = 0
> +REVISION = 1
>
> # MIT
> PERMIT_PACKAGE = Yes
> Index: patches/patch-neofetch
> ===================================================================
> RCS file: /home/cvs/ports/sysutils/neofetch/patches/patch-neofetch,v
> retrieving revision 1.8
> diff -u -p -r1.8 patch-neofetch
> --- patches/patch-neofetch 11 Mar 2022 19:57:43 -0000 1.8
> +++ patches/patch-neofetch 31 Oct 2022 16:21:31 -0000
> @@ -1,4 +1,5 @@
> From https://github.com/dylanaraps/neofetch/pull/1494
> +and add needed escape to please bash.
>
> Index: neofetch
> --- neofetch.orig
> @@ -22,3 +23,14 @@ Index: neofetch
> gpu="${gpu/OpenGL renderer string: }"
> ;;
> esac
> +@@ -3800,8 +3799,8 @@ get_cols() {
> + printf -v block_spaces "%${block_height}s"
> +
> + # Convert the spaces into rows of blocks.
> +- [[ "$blocks" ]] && cols+="${block_spaces// /${blocks}[mnl}"
> +- [[ "$blocks2" ]] && cols+="${block_spaces// /${blocks2}[mnl}"
> ++ [[ "$blocks" ]] && cols+="${block_spaces// /${blocks}\[mnl}"
> ++ [[ "$blocks2" ]] && cols+="${block_spaces// /${blocks2}\[mnl}"
> +
> + # Add newlines to the string.
> + cols=${cols%%nl}
>

That fixed it. Thanks very much.

--
Norvell Spearman

Re: xpdf segs fault

On Oct 31 2022, Theo Buehler wrote:
> > Well, I followed the instructions Stuart gave me, if I did it well
> > the patches in the link above make no difference. His xpopple fork
> > may have other modifications.
>
> Is this with or without my patch? I.e., with motif-2.3.8 or motif-2.3.8p0?

Yeah, I took this in care :-). I tried with and without your patch.
Without your motif patch xpdf always crashes.

I hope I did it well. The patches in the web didn't work as is, I
had to make the modifications manually. Then I ran:

make update-patches
make
make install

The following are the patches generated by update-patches under
patches/ directory after I edited the files:

Index: xpdf/PDFCore.cc
--- xpdf/PDFCore.cc.orig
+++ xpdf/PDFCore.cc
@@ -13,6 +13,7 @@

Re: [new] math/ministat: small statistic utility

On 2022/10/29 12:39:27 +0300, Mikhail <mp39590@gmail.com> wrote:
> On Sat, Oct 29, 2022 at 09:43:28AM +0100, Stuart Henderson wrote:
> > On 2022/10/29 11:02, Mikhail wrote:
> > > On Sat, Oct 29, 2022 at 09:37:08AM +0200, Omar Polo wrote:
> > > >
> > > > Port-wise, the only thing that needs to be adjusted is CFLAGS, as
> > > > it uses the hardcoded ones '-O2 -pipe -Werror' and not the ones
> > > > provided by the port infrastructure; it's very easy to fix:
> > >
> > > Fixed, new archive attached, also the diff between vanilla and this
> > > ministat.c:
> >
> > imho it would be better for the distfile to be exactly the standard
> > FreeBSD version, then apply any changes by patching it in the port
>
> Such way it looks cleaner indeed. Distfile updated, new archive
> attached.

forgot to reply to this, sorry. Agree with sthen@ suggestion and your
latest tarball it's ok for me to import

thanks!

Re: [wip] devel/swig 4.1.0

Index: patches/patch-pcbnew_CMakeLists_txt
===================================================================
RCS file: /cvs/ports/cad/kicad/patches/patch-pcbnew_CMakeLists_txt,v
retrieving revision 1.8
diff -u -r1.8 patch-pcbnew_CMakeLists_txt
--- patches/patch-pcbnew_CMakeLists_txt 29 Aug 2022 16:50:34 -0000 1.8
+++ patches/patch-pcbnew_CMakeLists_txt 30 Oct 2022 17:46:08 -0000
@@ -1,7 +1,18 @@
+chunk 1: remove unneeded bits to fix build with swig 4.1
+from https://gitlab.com/kicad/code/kicad/-/issues/12414
+
Index: pcbnew/CMakeLists.txt
--- pcbnew/CMakeLists.txt.orig
+++ pcbnew/CMakeLists.txt
-@@ -495,7 +495,7 @@ add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}
+@@ -487,15 +487,11 @@ add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND ${SWIG_EXECUTABLE}
+ ${SWIG_OPTS} -o ${CMAKE_CURRENT_BINARY_DIR}/pcbnew_wrap.cxx ${CMAKE_SOURCE_DIR}/pcbnew/python/swig/pcbnew.i
+
+- COMMAND ${PYTHON_EXECUTABLE}
+- ${CMAKE_SOURCE_DIR}/scripting/build_tools/fix_swig_imports.py
+- ${CMAKE_CURRENT_BINARY_DIR}/pcbnew.py
+-
+ WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)

if( UNIX AND NOT APPLE )
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/llvm/Makefile,v
retrieving revision 1.293
diff -u -r1.293 Makefile
--- Makefile 21 Jul 2022 13:04:32 -0000 1.293
+++ Makefile 29 Oct 2022 15:39:25 -0000
@@ -16,6 +16,7 @@
PKGNAME-python = py3-llvm-${LLVM_V}
PKGNAME-lldb = lldb-${LLVM_V}
REVISION-main = 3
+REVISION-lldb = 0

CATEGORIES = devel

Index: patches/patch-tools_lldb_bindings_CMakeLists_txt
===================================================================
RCS file: patches/patch-tools_lldb_bindings_CMakeLists_txt
diff -N patches/patch-tools_lldb_bindings_CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-tools_lldb_bindings_CMakeLists_txt 29 Oct 2022 15:39:25 -0000
@@ -0,0 +1,15 @@
+Fix build with swig 4.1.0
+cf https://reviews.llvm.org/D134877
+cf https://bugzilla.redhat.com/show_bug.cgi?id=2128646
+Index: tools/lldb/bindings/CMakeLists.txt
+--- tools/lldb/bindings/CMakeLists.txt.orig
++++ tools/lldb/bindings/CMakeLists.txt
+@@ -26,8 +26,6 @@ set(SWIG_COMMON_FLAGS
+ -features autodoc
+ -I${LLDB_SOURCE_DIR}/include
+ -I${CMAKE_CURRENT_SOURCE_DIR}
+- -D__STDC_LIMIT_MACROS
+- -D__STDC_CONSTANT_MACROS
+ ${DARWIN_EXTRAS}
+ )
+
Index: patches/patch-tools_lldb_bindings_interfaces_swig
===================================================================
RCS file: patches/patch-tools_lldb_bindings_interfaces_swig
diff -N patches/patch-tools_lldb_bindings_interfaces_swig
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-tools_lldb_bindings_interfaces_swig 29 Oct 2022 15:39:25 -0000
@@ -0,0 +1,15 @@
+Fix build with swig 4.1.0
+cf https://reviews.llvm.org/D134877
+cf https://bugzilla.redhat.com/show_bug.cgi?id=2128646
+Index: tools/lldb/bindings/interfaces.swig
+--- tools/lldb/bindings/interfaces.swig.orig
++++ tools/lldb/bindings/interfaces.swig
+@@ -1,8 +1,5 @@
+ /* Various liblldb typedefs that SWIG needs to know about. */
+ #define __extension__ /* Undefine GCC keyword to make Swig happy when processing glibc's stdint.h. */
+-/* The ISO C99 standard specifies that in C++ implementations limit macros such
+- as INT32_MAX should only be defined if __STDC_LIMIT_MACROS is. */
+-#define __STDC_LIMIT_MACROS
+ %include "stdint.i"
+
+ %include "lldb/lldb-defines.h"
Index: patches/patch-tools_lldb_bindings_python_python-typemaps_swig
===================================================================
RCS file: patches/patch-tools_lldb_bindings_python_python-typemaps_swig
diff -N patches/patch-tools_lldb_bindings_python_python-typemaps_swig
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-tools_lldb_bindings_python_python-typemaps_swig 29 Oct 2022 15:39:25 -0000
@@ -0,0 +1,15 @@
+fix build with swig 4.1.0
+https://github.com/llvm/llvm-project/commit/f0a25fe0b746f56295d5c02116ba28d2f965c175
+
+Index: tools/lldb/bindings/python/python-typemaps.swig
+--- tools/lldb/bindings/python/python-typemaps.swig.orig
++++ tools/lldb/bindings/python/python-typemaps.swig
+@@ -439,7 +439,7 @@ bool SetNumberFromPyObject<double>(double &number, PyO
+
+ %typemap(out) lldb::FileSP {
+ $result = nullptr;
+- lldb::FileSP &sp = $1;
++ const lldb::FileSP &sp = $1;
+ if (sp) {
+ PythonFile pyfile = unwrapOrSetPythonException(PythonFile::FromFile(*sp));
+ if (!pyfile.IsValid())
Le Sun, Oct 30, 2022 at 10:36:42PM +0100, Landry Breuil a écrit :
> Le Sat, Oct 29, 2022 at 06:34:21PM +0200, Landry Breuil a écrit :
> > hi,
> >
> > here's a wip update to swig 4.1.0, cf
> > https://swig.org/Release/RELEASENOTES for relnotes, mostly adding
> > support for javascript via nodejs, switch to pcre2, and integrate the
> > support for php8 i already backported for mapserver.
> >
> > almost all tests but some in guile pass, i've added nodejs & go to
> > TEST_DEPENDS to avoid kicking swig from archs that dont have them.
> >
> > tests from exotic archs much welcome (eg those not having go/node), so
> > far:
> > - tested on amd64
> > - built subversion & graphviz without issues
> > - some patches needed for lldb in devel/llvm, attached too
>
> new diff with patch-configure readded, should fix guile tests which
> otherwise fails with:
>
> ld: error: unknown argument '-I/usr/local/include'
> ld: error: unknown argument '-pthread'
> ld: error: unknown argument '-pthread'
> ld: error: unable to find library -lm
>
> known breakage in kicad & llvm have pending diffs.

Those were the only fallouts, i have diffs to fix them (attached below).

Ran swig regress tests on amd64/i386/arm64, they all need the nodejs
headers tweak but that's mostly it.

ok for swig ? or someone wants to run sparc64/macppc/riscv64 tests ?

Landry

Re: xpdf segs fault

> Well, I followed the instructions Stuart gave me, if I did it well
> the patches in the link above make no difference. His xpopple fork
> may have other modifications.

Is this with or without my patch? I.e., with motif-2.3.8 or motif-2.3.8p0?

Re: xpdf segs fault

On Oct 31 2022, Walter Alejandro Iglesias wrote:
> On Oct 31 2022, Walter Alejandro Iglesias wrote:
> > On Oct 30 2022, Theo Buehler wrote:
> > > On Sun, Oct 30, 2022 at 11:04:20PM +0100, Theo Buehler wrote:
> > > > On Sun, Oct 30, 2022 at 09:00:53PM +0100, Walter Alejandro Iglesias wrote:
> > > > > Hello,
> > > > >
> > > > > I suppose I have to report this bug here.
> > > > >
> > > > > As far as I was aware Xpdf search dialog didn't support non ascii
> > > > > characters (as it also the case with mupdf). Lately I been using the
> > > > > xpopple version under debian, and I realized it now lets you do utf8
> > > > > searches.
> > > > >
> > > > > Happy with this xpdf improvement I tried to do the same under openbsd (I
> > > > > assume openbsd xpdf port is not the xpopple version, right?), it let me
> > > > > type some utf8 characters (spanish keyboard) in its search dialog but
> > > > > when I type characters with tilde Xpdf segs fault.
> > > >
> > > > It's a pretty bad out-of-bounds access in motif.
> >
> > I understand. I've been investigating how motif handles utf8, it seems
> > to be really entangled.
> >
> > > > The diff below makes
> > > > things work for me. Searching for spanish words with accents in xpdf
> > > > works for me with this diff.
> >
> > Your patch solves the segfault, and now I can type characters with tilde.
> > But keyboard input doesn't let me enter three bytes utf8 characters, like
> > mdash, quotes, ellipsis or euro sign. Is that blocked for some reason?
>
> The issue is explained here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946270
>
> It seems motif asumes you're entering latin-1 characters even when they
> are utf-8. How do you generate patches for ports? Is there a cvs
> command to download the port's sources?

Well, I followed the instructions Stuart gave me, if I did it well
the patches in the link above make no difference. His xpopple fork
may have other modifications.

>
>
> >
> >
> > >
> > > Forgot one last tweak (<= vs <). This is better:
> > >
> > > Index: Makefile
> > > ===================================================================
> > > RCS file: /cvs/ports/x11/motif/Makefile,v
> > > retrieving revision 1.8
> > > diff -u -p -r1.8 Makefile
> > > --- Makefile 11 Mar 2022 20:16:47 -0000 1.8
> > > +++ Makefile 30 Oct 2022 22:00:43 -0000
> > > @@ -1,6 +1,7 @@
> > > COMMENT= Motif toolkit
> > >
> > > DISTNAME= motif-2.3.8
> > > +REVISION= 0
> > >
> > > SHARED_LIBS += Xm 6.1 # 4.4
> > > SHARED_LIBS += Mrm 4.1 # 4.4
> > > Index: patches/patch-lib_Xm_VirtKeys_c
> > > ===================================================================
> > > RCS file: patches/patch-lib_Xm_VirtKeys_c
> > > diff -N patches/patch-lib_Xm_VirtKeys_c
> > > --- /dev/null 1 Jan 1970 00:00:00 -0000
> > > +++ patches/patch-lib_Xm_VirtKeys_c 30 Oct 2022 22:05:54 -0000
> > > @@ -0,0 +1,24 @@
> > > +Check bounds before accessing the keycaps table.
> > > +
> > > +Index: lib/Xm/VirtKeys.c
> > > +--- lib/Xm/VirtKeys.c.orig
> > > ++++ lib/Xm/VirtKeys.c
> > > +@@ -558,10 +558,16 @@ FindVirtKey(Display *dpy,
> > > + XmDisplay xmDisplay = (XmDisplay) XmGetXmDisplay( dpy);
> > > + XmVKeyBinding keyBindings = xmDisplay->display.bindings;
> > > + KeyCode min_kcode;
> > > +- int ks_per_kc;
> > > ++ int min_kc, max_kc, ks_per_kc;
> > > + KeySym *ks_table = XtGetKeysymTable( dpy, &min_kcode, &ks_per_kc);
> > > + KeySym *kc_map = &ks_table[(keycode - min_kcode) * ks_per_kc];
> > > +- Modifiers EffectiveSMMask = EffectiveStdModMask( dpy, kc_map, ks_per_kc);
> > > ++ Modifiers EffectiveSMMask;
> > > ++
> > > ++ XDisplayKeycodes(dpy, &min_kc, &max_kc);
> > > ++ if (keycode < min_kcode || (keycode - min_kcode) * ks_per_kc >= max_kc)
> > > ++ return;
> > > ++
> > > ++ EffectiveSMMask = EffectiveStdModMask( dpy, kc_map, ks_per_kc);
> > > +
> > > + /* Get the modifiers from the actual event */
> > > + Modifiers VirtualStdMods = 0;
> >
> > --
> > Walter
>
> --
> Walter

--
Walter

Re: unexpected behavior from neofetch in snapshots

On 2022/10/31 11:54:10 -0400, Norvell Spearman <norvell.spearman@gmail.com> wrote:
> There seems to be a problem between neofetch and bash in snapshots.
> neofetch displays the ASCII logo for the OS and most of the expected
> information about the system it's running on, but stops then shows the
> next command prompt in the middle of the logo, leaving out the usual
> colored blocks. With 7.2-release and earlier I got behavior as seen in
> expected.png. With 7.2-current I get behavior as seen in current.png.
> Running "neofetch -v" shows the following error:
>
> /usr/local/bin/neofetch: line 3802: bad substitution: no closing `}' in ${block_spaces// /${blocks}nl}
>
> 7.2-release uses bash-5.1.16 while -current uses bash-5.2.2 (with the
> same version of neofetch in both), so I'm guessing that something
> changed with bash between the two versions. I don't know much about
> shell scripting, so all apologies for not being more helpful.
>
> To show the expected behavior, I downloaded the -release version of bash
> (5.1.16), renamed its binary, and told a copy of -current's neofetch to
> use the renamed bash for execution.
>
> Let me know if you need more information. I did check marc.info to see
> whether anybody else had already reported this, so apologies in advance
> if I missed something.

There's an issue about this opened on github:
https://github.com/dylanaraps/neofetch/issues/2209

This is a bit out of my comfort zone, I don't really know what the
bash // parameter substitution does, but as was hinted by a user in
that issue escaping the [ fixes it, at least in my brief testing.

(no idea how the raw escape in the diff will end up in the mail)

Index: Makefile
===================================================================
RCS file: /home/cvs/ports/sysutils/neofetch/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile 11 Mar 2022 19:57:43 -0000 1.11
+++ Makefile 31 Oct 2022 16:21:37 -0000
@@ -4,7 +4,7 @@ CATEGORIES = sysutils misc
GH_ACCOUNT = dylanaraps
GH_PROJECT = neofetch
GH_TAGNAME = 7.1.0
-REVISION = 0
+REVISION = 1

# MIT
PERMIT_PACKAGE = Yes
Index: patches/patch-neofetch
===================================================================
RCS file: /home/cvs/ports/sysutils/neofetch/patches/patch-neofetch,v
retrieving revision 1.8
diff -u -p -r1.8 patch-neofetch
--- patches/patch-neofetch 11 Mar 2022 19:57:43 -0000 1.8
+++ patches/patch-neofetch 31 Oct 2022 16:21:31 -0000
@@ -1,4 +1,5 @@
From https://github.com/dylanaraps/neofetch/pull/1494
+and add needed escape to please bash.

Index: neofetch
--- neofetch.orig
@@ -22,3 +23,14 @@ Index: neofetch
gpu="${gpu/OpenGL renderer string: }"
;;
esac
+@@ -3800,8 +3799,8 @@ get_cols() {
+ printf -v block_spaces "%${block_height}s"
+
+ # Convert the spaces into rows of blocks.
+- [[ "$blocks" ]] && cols+="${block_spaces// /${blocks}[mnl}"
+- [[ "$blocks2" ]] && cols+="${block_spaces// /${blocks2}[mnl}"
++ [[ "$blocks" ]] && cols+="${block_spaces// /${blocks}\[mnl}"
++ [[ "$blocks2" ]] && cols+="${block_spaces// /${blocks2}\[mnl}"
+
+ # Add newlines to the string.
+ cols=${cols%%nl}

Re: Makefile: line continuation before empty line?

On Mon, Oct 31, 2022 at 03:25:00PM +0000, Stuart Henderson wrote:
> On 2022/10/31 16:18, Christian Weisgerber wrote:
> > There are 76 or so port Makefiles that have a trailing backslash
> > for line continuation before an empty line, e.g. like this in
> > cmake/Makefile:
> >
> > 77 perl -e 's,/usr/include,${LOCALBASE}/include,' \
> > 78 ${WRKSRC}/Modules/FindDCMTK.cmake \
> > 79
> >
> > Now, this _is_ harmless. The parser will just gobble up the next line
> > and since that one's empty, there's no effect.
> >
> > That said, I think they are accidental leftovers when subsequent
> > content lines were deleted and somebody forgot to remove that
> > trailing backslash on the new last line of an assignment.
> >
> > Should I remove them? Should I not bother?
> > Does anybody actually use this style intentionally?
> >
> >
> > (I have already grepped for instances where the next line is not
> > empty and repaired those that were in error.)
>
> I would be happy to remove them

Same here \

--
Antoine

Re: [update] security/vaultwarden to 1.25.2 and www/vaultwarden-web to 2022.9.0

On Mon, Oct 31, 2022, at 9:27 AM, Aaron Bieber wrote:
> On Thu, 15 Sep 2022 at 11:13:04 +0200, Denis Fondras wrote:
>> Le Wed, Sep 14, 2022 at 07:31:38PM -0400, aisha a écrit :
>> > On 22/09/14 07:40PM, Denis Fondras wrote:
>> > > Le Tue, Sep 13, 2022 at 07:44:35PM -0400, aisha a ?crit :
>> > > > On 22/09/05 05:50PM, Denis Fondras wrote:
>> > > > > Le Mon, Sep 05, 2022 at 11:21:57AM -0400, aisha a ?crit :
>> > > > > > On 22/08/20 10:06PM, aisha wrote:
>> > > > > > > On 22/08/11 05:29PM, aisha wrote:
>> > > > > > > > attached updates
>> > > > > > > > - security/vaultwarden 1.25.0 to 1.25.2
>> > > > > > > > no major changes between these two versions, 1.25.1 had a bug with mobile uploads but we are not affected in ports
>> > > > > > > > port side change - drop vendored distfile
>> > > > > > > >
>> > > > > > > > - www/vaultwarden-web 2.28.1 to 2022.6.2
>> > > > > > > > version scheme changed but am not updating epoch as its still larger than current one
>> > > > > > > > no other major changes
>> > > > > > > >
>> > > >
>> > > > ping
>> > > > updated vaultwarden-web to 2022.9.0
>> > > >
>> > >
>> > > Have you been able to create an organization ?
>> > > It worked with the previous port.
>> > >
>> > > Denis
>> > >
>> >
>> > attached with patch for the org creation fix
>> >
>>
>> OK for me, tested on amd64.
>>
>> I will commit tonight if nobody speak up against.
>> Thank you.
>>
>
> Looks like the diff is missing the REVISION bump. Also aisha can now commit
> herself :D

Woops - I was looking at the wrong diff \o/

unexpected behavior from neofetch in snapshots

There seems to be a problem between neofetch and bash in snapshots.
neofetch displays the ASCII logo for the OS and most of the expected
information about the system it's running on, but stops then shows the
next command prompt in the middle of the logo, leaving out the usual
colored blocks. With 7.2-release and earlier I got behavior as seen in
expected.png. With 7.2-current I get behavior as seen in current.png.
Running "neofetch -v" shows the following error:

/usr/local/bin/neofetch: line 3802: bad substitution: no closing `}' in ${block_spaces// /${blocks}nl}

7.2-release uses bash-5.1.16 while -current uses bash-5.2.2 (with the
same version of neofetch in both), so I'm guessing that something
changed with bash between the two versions. I don't know much about
shell scripting, so all apologies for not being more helpful.

To show the expected behavior, I downloaded the -release version of bash
(5.1.16), renamed its binary, and told a copy of -current's neofetch to
use the renamed bash for execution.

Let me know if you need more information. I did check marc.info to see
whether anybody else had already reported this, so apologies in advance
if I missed something.

--
Norvell Spearman

Re: [update] security/vaultwarden to 1.25.2 and www/vaultwarden-web to 2022.9.0

On Thu, 15 Sep 2022 at 11:13:04 +0200, Denis Fondras wrote:
> Le Wed, Sep 14, 2022 at 07:31:38PM -0400, aisha a écrit :
> > On 22/09/14 07:40PM, Denis Fondras wrote:
> > > Le Tue, Sep 13, 2022 at 07:44:35PM -0400, aisha a ?crit :
> > > > On 22/09/05 05:50PM, Denis Fondras wrote:
> > > > > Le Mon, Sep 05, 2022 at 11:21:57AM -0400, aisha a ?crit :
> > > > > > On 22/08/20 10:06PM, aisha wrote:
> > > > > > > On 22/08/11 05:29PM, aisha wrote:
> > > > > > > > attached updates
> > > > > > > > - security/vaultwarden 1.25.0 to 1.25.2
> > > > > > > > no major changes between these two versions, 1.25.1 had a bug with mobile uploads but we are not affected in ports
> > > > > > > > port side change - drop vendored distfile
> > > > > > > >
> > > > > > > > - www/vaultwarden-web 2.28.1 to 2022.6.2
> > > > > > > > version scheme changed but am not updating epoch as its still larger than current one
> > > > > > > > no other major changes
> > > > > > > >
> > > >
> > > > ping
> > > > updated vaultwarden-web to 2022.9.0
> > > >
> > >
> > > Have you been able to create an organization ?
> > > It worked with the previous port.
> > >
> > > Denis
> > >
> >
> > attached with patch for the org creation fix
> >
>
> OK for me, tested on amd64.
>
> I will commit tonight if nobody speak up against.
> Thank you.
>

Looks like the diff is missing the REVISION bump. Also aisha can now commit
herself :D

Re: Makefile: line continuation before empty line?

On 2022/10/31 16:18, Christian Weisgerber wrote:
> There are 76 or so port Makefiles that have a trailing backslash
> for line continuation before an empty line, e.g. like this in
> cmake/Makefile:
>
> 77 perl -e 's,/usr/include,${LOCALBASE}/include,' \
> 78 ${WRKSRC}/Modules/FindDCMTK.cmake \
> 79
>
> Now, this _is_ harmless. The parser will just gobble up the next line
> and since that one's empty, there's no effect.
>
> That said, I think they are accidental leftovers when subsequent
> content lines were deleted and somebody forgot to remove that
> trailing backslash on the new last line of an assignment.
>
> Should I remove them? Should I not bother?
> Does anybody actually use this style intentionally?
>
>
> (I have already grepped for instances where the next line is not
> empty and repaired those that were in error.)

I would be happy to remove them

Makefile: line continuation before empty line?

There are 76 or so port Makefiles that have a trailing backslash
for line continuation before an empty line, e.g. like this in
cmake/Makefile:

77 perl -e 's,/usr/include,${LOCALBASE}/include,' \
78 ${WRKSRC}/Modules/FindDCMTK.cmake \
79

Now, this _is_ harmless. The parser will just gobble up the next line
and since that one's empty, there's no effect.

That said, I think they are accidental leftovers when subsequent
content lines were deleted and somebody forgot to remove that
trailing backslash on the new last line of an assignment.

Should I remove them? Should I not bother?
Does anybody actually use this style intentionally?

(I have already grepped for instances where the next line is not
empty and repaired those that were in error.)

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Re: NEW: net/accounts-sso/{gsignond,signond,libaccounts-glib,libaccounts-qt}

On 2022/10/30 17:30, Rafael Sadowski wrote:
> I add a conflict between gsignond and signond becouse both install
> share/dbus-1/services/com.google.code.AccountsSSO.SingleSignOn.service

This is going to make things difficult for anything depending on them..

Re: NEW: VHS-0.1.0

Let's move it to v0.1.1

On Mon, 31 Oct 2022 at 11:00:29 +0100, Gonzalo L. Rodriguez wrote:
> Hi,
>
> I made a port for VHS:
>
> https://github.com/charmbracelet/vhs
>
> Unfortunately we have to update libwebsockets (diff attached, and I emailed
> awolk@) and ttyd (someone wants to do it?:).
>
> Cheers.-
>
> --
>
> %gonzalo

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/www/libwebsockets/Makefile,v
> retrieving revision 1.19
> diff -u -p -r1.19 Makefile
> --- Makefile 11 Mar 2022 20:10:03 -0000 1.19
> +++ Makefile 28 Oct 2022 11:52:14 -0000
> @@ -2,8 +2,7 @@ COMMENT = lightweight C library for fas
>
> GH_ACCOUNT = warmcat
> GH_PROJECT = libwebsockets
> -GH_TAGNAME = v2.4.2
> -REVISION = 0
> +GH_TAGNAME = v4.3.2
>
> SHARED_LIBS = websockets 9.0 # 12
>
> @@ -16,7 +15,7 @@ MAINTAINER = Adam Wolk <awolk@openbsd.o
> # LGPL2 + static link exception
> PERMIT_PACKAGE = Yes
>
> -WANTLIB += crypto m ssl z
> +WANTLIB += crypto m pthread ssl z
>
> MODULES = devel/cmake
>
> @@ -24,8 +23,5 @@ CONFIGURE_ARGS += -DLWS_WITHOUT_TESTAPPS
> -DLWS_WITHOUT_TEST_SERVER=ON
>
> NO_TEST = Yes
> -
> -post-install:
> - @rm -r ${WRKINST}/usr/local/share/libwebsockets-test-server
>
> .include <bsd.port.mk>
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/www/libwebsockets/distinfo,v
> retrieving revision 1.14
> diff -u -p -r1.14 distinfo
> --- distinfo 26 Apr 2018 20:19:58 -0000 1.14
> +++ distinfo 28 Oct 2022 11:52:14 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (libwebsockets-2.4.2.tar.gz) = cwEtf89Cje3MyBboOmOgFGLieBnVU3uODQxyZL+s+tY=
> -SIZE (libwebsockets-2.4.2.tar.gz) = 3777160
> +SHA256 (libwebsockets-4.3.2.tar.gz) = aoWhvM8lrMfo5Tg+STTJsyoQKIDR5MN8cLJ64qQkBuE=
> +SIZE (libwebsockets-4.3.2.tar.gz) = 15616264
> Index: patches/patch-lib_misc_base64-decode_c
> ===================================================================
> RCS file: patches/patch-lib_misc_base64-decode_c
> diff -N patches/patch-lib_misc_base64-decode_c
> --- patches/patch-lib_misc_base64-decode_c 11 Mar 2022 20:10:04 -0000 1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -0000
> @@ -1,22 +0,0 @@
> -Fix the build with Clang 13.
> -
> -Upstream commit 0bfd39135e970ed1273f2f935c581f213543c7ef.
> -
> -Index: lib/misc/base64-decode.c
> ---- lib/misc/base64-decode.c.orig
> -+++ lib/misc/base64-decode.c
> -@@ -53,7 +53,6 @@ lws_b64_encode_string(const char *in, int in_len, char
> - unsigned char triple[3];
> - int i;
> - int len;
> -- int line = 0;
> - int done = 0;
> -
> - while (in_len) {
> -@@ -78,7 +77,6 @@ lws_b64_encode_string(const char *in, int in_len, char
> - *out++ = (len > 2 ? encode[triple[2] & 0x3f] : '=');
> -
> - done += 4;
> -- line += 4;
> - }
> -
> Index: pkg/PLIST
> ===================================================================
> RCS file: /cvs/ports/www/libwebsockets/pkg/PLIST,v
> retrieving revision 1.4
> diff -u -p -r1.4 PLIST
> --- pkg/PLIST 11 Mar 2022 20:10:04 -0000 1.4
> +++ pkg/PLIST 28 Oct 2022 11:52:14 -0000
> @@ -1,13 +1,100 @@
> +include/libwebsockets/
> include/libwebsockets.h
> -include/lws-plugin-ssh.h
> +include/libwebsockets/abstract/
> +include/libwebsockets/abstract/abstract.h
> +include/libwebsockets/abstract/protocols/
> +include/libwebsockets/abstract/protocols.h
> +include/libwebsockets/abstract/protocols/smtp.h
> +include/libwebsockets/abstract/transports/
> +include/libwebsockets/abstract/transports.h
> +include/libwebsockets/abstract/transports/raw-skt.h
> +include/libwebsockets/abstract/transports/unit-test.h
> +include/libwebsockets/lws-adopt.h
> +include/libwebsockets/lws-async-dns.h
> +include/libwebsockets/lws-bb-i2c.h
> +include/libwebsockets/lws-bb-spi.h
> +include/libwebsockets/lws-button.h
> +include/libwebsockets/lws-cache-ttl.h
> +include/libwebsockets/lws-callbacks.h
> +include/libwebsockets/lws-cgi.h
> +include/libwebsockets/lws-client.h
> +include/libwebsockets/lws-conmon.h
> +include/libwebsockets/lws-context-vhost.h
> +include/libwebsockets/lws-cose.h
> +include/libwebsockets/lws-dbus.h
> +include/libwebsockets/lws-diskcache.h
> +include/libwebsockets/lws-display.h
> +include/libwebsockets/lws-dll2.h
> +include/libwebsockets/lws-dsh.h
> +include/libwebsockets/lws-eventlib-exports.h
> +include/libwebsockets/lws-fault-injection.h
> +include/libwebsockets/lws-freertos.h
> +include/libwebsockets/lws-fts.h
> +include/libwebsockets/lws-genaes.h
> +include/libwebsockets/lws-gencrypto.h
> +include/libwebsockets/lws-genec.h
> +include/libwebsockets/lws-genhash.h
> +include/libwebsockets/lws-genrsa.h
> +include/libwebsockets/lws-gpio.h
> +include/libwebsockets/lws-http.h
> +include/libwebsockets/lws-i2c.h
> +include/libwebsockets/lws-ili9341-spi.h
> +include/libwebsockets/lws-jose.h
> +include/libwebsockets/lws-jwe.h
> +include/libwebsockets/lws-jwk.h
> +include/libwebsockets/lws-jws.h
> +include/libwebsockets/lws-lecp.h
> +include/libwebsockets/lws-led.h
> +include/libwebsockets/lws-lejp.h
> +include/libwebsockets/lws-logs.h
> +include/libwebsockets/lws-lwsac.h
> +include/libwebsockets/lws-map.h
> +include/libwebsockets/lws-metrics.h
> +include/libwebsockets/lws-misc.h
> +include/libwebsockets/lws-mqtt.h
> +include/libwebsockets/lws-netdev.h
> +include/libwebsockets/lws-network-helper.h
> +include/libwebsockets/lws-optee.h
> +include/libwebsockets/lws-protocols-plugins.h
> +include/libwebsockets/lws-purify.h
> +include/libwebsockets/lws-pwm.h
> +include/libwebsockets/lws-retry.h
> +include/libwebsockets/lws-ring.h
> +include/libwebsockets/lws-secure-streams-client.h
> +include/libwebsockets/lws-secure-streams-policy.h
> +include/libwebsockets/lws-secure-streams.h
> +include/libwebsockets/lws-sequencer.h
> +include/libwebsockets/lws-service.h
> +include/libwebsockets/lws-settings.h
> +include/libwebsockets/lws-sha1-base64.h
> +include/libwebsockets/lws-smd.h
> +include/libwebsockets/lws-spa.h
> +include/libwebsockets/lws-spi.h
> +include/libwebsockets/lws-ssd1306-i2c.h
> +include/libwebsockets/lws-state.h
> +include/libwebsockets/lws-struct.h
> +include/libwebsockets/lws-system.h
> +include/libwebsockets/lws-test-sequencer.h
> +include/libwebsockets/lws-threadpool.h
> +include/libwebsockets/lws-timeout-timer.h
> +include/libwebsockets/lws-tls-sessions.h
> +include/libwebsockets/lws-tokenize.h
> +include/libwebsockets/lws-vfs.h
> +include/libwebsockets/lws-write.h
> +include/libwebsockets/lws-writeable.h
> +include/libwebsockets/lws-ws-close.h
> +include/libwebsockets/lws-ws-ext.h
> +include/libwebsockets/lws-ws-state.h
> +include/libwebsockets/lws-x509.h
> include/lws_config.h
> lib/cmake/
> lib/cmake/libwebsockets/
> -lib/cmake/libwebsockets/LibwebsocketsConfig.cmake
> -lib/cmake/libwebsockets/LibwebsocketsConfigVersion.cmake
> lib/cmake/libwebsockets/LibwebsocketsTargets${MODCMAKE_BUILD_SUFFIX}
> lib/cmake/libwebsockets/LibwebsocketsTargets.cmake
> -lib/libwebsockets.a
> +lib/cmake/libwebsockets/LwsCheckRequirements.cmake
> +lib/cmake/libwebsockets/libwebsockets-config-version.cmake
> +lib/cmake/libwebsockets/libwebsockets-config.cmake
> +@static-lib lib/libwebsockets.a
> @lib lib/libwebsockets.so.${LIBwebsockets_VERSION}
> lib/pkgconfig/libwebsockets.pc
> lib/pkgconfig/libwebsockets_static.pc

--

%gonzalo

Re: xpdf segs fault

On 2022/10/31 14:52, Walter Alejandro Iglesias wrote:
> On Oct 31 2022, Walter Alejandro Iglesias wrote:
> > On Oct 30 2022, Theo Buehler wrote:
> > > On Sun, Oct 30, 2022 at 11:04:20PM +0100, Theo Buehler wrote:
> > > > On Sun, Oct 30, 2022 at 09:00:53PM +0100, Walter Alejandro Iglesias wrote:
> > > > > Hello,
> > > > >
> > > > > I suppose I have to report this bug here.
> > > > >
> > > > > As far as I was aware Xpdf search dialog didn't support non ascii
> > > > > characters (as it also the case with mupdf). Lately I been using the
> > > > > xpopple version under debian, and I realized it now lets you do utf8
> > > > > searches.
> > > > >
> > > > > Happy with this xpdf improvement I tried to do the same under openbsd (I
> > > > > assume openbsd xpdf port is not the xpopple version, right?), it let me
> > > > > type some utf8 characters (spanish keyboard) in its search dialog but
> > > > > when I type characters with tilde Xpdf segs fault.
> > > >
> > > > It's a pretty bad out-of-bounds access in motif.
> >
> > I understand. I've been investigating how motif handles utf8, it seems
> > to be really entangled.
> >
> > > > The diff below makes
> > > > things work for me. Searching for spanish words with accents in xpdf
> > > > works for me with this diff.
> >
> > Your patch solves the segfault, and now I can type characters with tilde.
> > But keyboard input doesn't let me enter three bytes utf8 characters, like
> > mdash, quotes, ellipsis or euro sign. Is that blocked for some reason?
>
> The issue is explained here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946270
>
> It seems motif asumes you're entering latin-1 characters even when they
> are utf-8. How do you generate patches for ports? Is there a cvs
> command to download the port's sources?

If you have the ports tree on your system, the steps are basically along
these lines:

make patch
cd `make show=WRKSRC`
cp foo.c foo.c.orig
vi foo.c
cd -
make update-patches

iff there is an existing patches/ directory then you can do this to
add a file (or similar if you want to remove a patch with 'cvs rm')

cd patches
cvs add patch-foo_c
cd -
cvs diff -uNp

If there is no existing patches/ directory there is also a way but
it's more awkward to do with anoncvs mirrors, so in that case for
people without a cvs account the easiest way is probably to send
a tar

Re: xpdf segs fault

On Oct 31 2022, Walter Alejandro Iglesias wrote:
> On Oct 30 2022, Theo Buehler wrote:
> > On Sun, Oct 30, 2022 at 11:04:20PM +0100, Theo Buehler wrote:
> > > On Sun, Oct 30, 2022 at 09:00:53PM +0100, Walter Alejandro Iglesias wrote:
> > > > Hello,
> > > >
> > > > I suppose I have to report this bug here.
> > > >
> > > > As far as I was aware Xpdf search dialog didn't support non ascii
> > > > characters (as it also the case with mupdf). Lately I been using the
> > > > xpopple version under debian, and I realized it now lets you do utf8
> > > > searches.
> > > >
> > > > Happy with this xpdf improvement I tried to do the same under openbsd (I
> > > > assume openbsd xpdf port is not the xpopple version, right?), it let me
> > > > type some utf8 characters (spanish keyboard) in its search dialog but
> > > > when I type characters with tilde Xpdf segs fault.
> > >
> > > It's a pretty bad out-of-bounds access in motif.
>
> I understand. I've been investigating how motif handles utf8, it seems
> to be really entangled.
>
> > > The diff below makes
> > > things work for me. Searching for spanish words with accents in xpdf
> > > works for me with this diff.
>
> Your patch solves the segfault, and now I can type characters with tilde.
> But keyboard input doesn't let me enter three bytes utf8 characters, like
> mdash, quotes, ellipsis or euro sign. Is that blocked for some reason?

The issue is explained here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946270

It seems motif asumes you're entering latin-1 characters even when they
are utf-8. How do you generate patches for ports? Is there a cvs
command to download the port's sources?

>
>
> >
> > Forgot one last tweak (<= vs <). This is better:
> >
> > Index: Makefile
> > ===================================================================
> > RCS file: /cvs/ports/x11/motif/Makefile,v
> > retrieving revision 1.8
> > diff -u -p -r1.8 Makefile
> > --- Makefile 11 Mar 2022 20:16:47 -0000 1.8
> > +++ Makefile 30 Oct 2022 22:00:43 -0000
> > @@ -1,6 +1,7 @@
> > COMMENT= Motif toolkit
> >
> > DISTNAME= motif-2.3.8
> > +REVISION= 0
> >
> > SHARED_LIBS += Xm 6.1 # 4.4
> > SHARED_LIBS += Mrm 4.1 # 4.4
> > Index: patches/patch-lib_Xm_VirtKeys_c
> > ===================================================================
> > RCS file: patches/patch-lib_Xm_VirtKeys_c
> > diff -N patches/patch-lib_Xm_VirtKeys_c
> > --- /dev/null 1 Jan 1970 00:00:00 -0000
> > +++ patches/patch-lib_Xm_VirtKeys_c 30 Oct 2022 22:05:54 -0000
> > @@ -0,0 +1,24 @@
> > +Check bounds before accessing the keycaps table.
> > +
> > +Index: lib/Xm/VirtKeys.c
> > +--- lib/Xm/VirtKeys.c.orig
> > ++++ lib/Xm/VirtKeys.c
> > +@@ -558,10 +558,16 @@ FindVirtKey(Display *dpy,
> > + XmDisplay xmDisplay = (XmDisplay) XmGetXmDisplay( dpy);
> > + XmVKeyBinding keyBindings = xmDisplay->display.bindings;
> > + KeyCode min_kcode;
> > +- int ks_per_kc;
> > ++ int min_kc, max_kc, ks_per_kc;
> > + KeySym *ks_table = XtGetKeysymTable( dpy, &min_kcode, &ks_per_kc);
> > + KeySym *kc_map = &ks_table[(keycode - min_kcode) * ks_per_kc];
> > +- Modifiers EffectiveSMMask = EffectiveStdModMask( dpy, kc_map, ks_per_kc);
> > ++ Modifiers EffectiveSMMask;
> > ++
> > ++ XDisplayKeycodes(dpy, &min_kc, &max_kc);
> > ++ if (keycode < min_kcode || (keycode - min_kcode) * ks_per_kc >= max_kc)
> > ++ return;
> > ++
> > ++ EffectiveSMMask = EffectiveStdModMask( dpy, kc_map, ks_per_kc);
> > +
> > + /* Get the modifiers from the actual event */
> > + Modifiers VirtualStdMods = 0;
>
> --
> Walter

--
Walter

riscv64 bulk build report