CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2022/01/10 00:52:52 Modified files: geo/gdal : Makefile distinfo Log message: geo/gdal: update to 3.4.1. See https://github.com/OSGeo/gdal/blob/v3.4.1/gdal/NEWS.md switch from pcre to pcre2
Re: new: inputmethods/fcitx5-chewing
On Sun, Jan 09, 2022 at 01:11:52PM +, Yifei Zhan wrote: > Hi, Hi Yifei, > Here attached is fcitx5-chewing, a chewing wrapper for fcitx5. I lightly > tested it on amd64, no problem so far, but I don't use chewing (or > bopomofo/zhuyin) often so it would be nice if someone can help me > thoroughly test it. Works for me on amd64 as well, thanks!
Re: wip/help wanted: fcitx5{,-gtk,-qt,-config-qt}
On Mon, Jan 10, 2022 at 11:08:16AM +0800, Kevin Lo wrote: > > On Thu, Jan 06, 2022 at 03:11:41AM +, Yifei Zhan wrote: > > On 21/12/31 12:16PM, Omar Polo wrote: > > > Yifei Zhan writes: > > > > > > > You can edit that file to enable and setup IME plugins you want, but > > > > it's more common to use fcitx5-config-qt for that. A typical workflow > > > > would look like this: > > > > > > > > 1. install fcitx5 fcitx5-gtk fcitx5-qt fcitx5-config-qt > > > > fcitx5-$IME_Plugin > > > >which $IME_Plugin to use depends on which language you want to type. > > > >(e.g. fcitx5-anthy for Japanese) > > > > > > i suppose all of these fcitx5-* packages are yet to be submitted ^^" > > > > They are on the way now :) > > > > Some IME plugins require more work than others as they depend on newer > > version of IME libs we don't have yet, but I'm working on a few updates > > now, should not take too long. At the moment I have attached fcitx5 > > fcitx5-gtk fcitx5-qt fcitx5-config-qt, lightly tested and working here > > on my amd64 box. > > > > fcitx5-anthy is also just around the corner, it can be used as a good > > test case. > > > > By the way, fcitx support for gnome-terminal is currently broken because > > gnome-terminal is built with gtk4 and uses GNOME's own IME integration > > system, I will dig into it later, but any other terminal emulator should > > be usable. konsole(qt)/sakura(gtk) both are fine. > > > > > > > > > 2. setup session environment variables in ~/.xsession, and start fcitx > > > > when logging in > > > > > > > > export XMODIFIERS=@im=fcitx > > > > export GTK_IM_MODULE=fcitx > > > > export QT_IM_MODULE=fcitx > > > > /usr/local/bin/fcitx5 > > > > > > Oh, I should have guessed that, it's similar to fcitx4. Maybe we can > > > adopt the same wording as in fcitx' DESCR? > > > (and similar for the gtk and qt module) > > > > > > > I prefer to maintain a single README file documenting all the setup > > instructions, just like meta/gnome/pkg/README-main. I think doing so > > makes it easier to keep instructions up to date. (I plan to write that > > once I got more IME plugins working) > > > > > > > Since fcitx5 is meant to be the successor for fcitx4 which is no > > > longer developed, it may make sense to replace fcitx4 with 5 instead > > > of keeping both in the port tree? I'm not using either, so I'm > > > probably missing something here. > > > > I agree, if Kevin is ok with that we can drop fcitx4 once fcitx5 and its > > plugins are tested and imported. > > Hmm, fcitx5 doesn't work on x11/dwm. Launching fcitx5 with "fcitx5 -d" > (gives no error), Ctrl+Space shortcut to change input method doesn't do > anything on applications (firefox, konsole, etc). > I have the following installed: > > fcitx5-5.0.11 flexible input method framework > fcitx5-chewing-5.0.8 chewing wrapper for fcitx5 > fcitx5-gtk-5.0.10 GTK IM module for fcitx5 > fcitx5-m17n-5.0.7 m17n wrapper for fcitx5 > fcitx5-qt-5.0.9 Qt library and IM module for fcitx5 > xcb-imdkit-1.0.3implementation of xim protocol in xcb > I found the problem. Because I had installed fcitx and then removed it, I need to delete fcitx config directory in $HOME/.conf. Sorry for the noise.
Re: wip/help wanted: fcitx5{,-gtk,-qt,-config-qt}
On Thu, Jan 06, 2022 at 03:11:41AM +, Yifei Zhan wrote: > On 21/12/31 12:16PM, Omar Polo wrote: > > Yifei Zhan writes: > > > > > You can edit that file to enable and setup IME plugins you want, but > > > it's more common to use fcitx5-config-qt for that. A typical workflow > > > would look like this: > > > > > > 1. install fcitx5 fcitx5-gtk fcitx5-qt fcitx5-config-qt fcitx5-$IME_Plugin > > >which $IME_Plugin to use depends on which language you want to type. > > >(e.g. fcitx5-anthy for Japanese) > > > > i suppose all of these fcitx5-* packages are yet to be submitted ^^" > > They are on the way now :) > > Some IME plugins require more work than others as they depend on newer > version of IME libs we don't have yet, but I'm working on a few updates > now, should not take too long. At the moment I have attached fcitx5 > fcitx5-gtk fcitx5-qt fcitx5-config-qt, lightly tested and working here > on my amd64 box. > > fcitx5-anthy is also just around the corner, it can be used as a good > test case. > > By the way, fcitx support for gnome-terminal is currently broken because > gnome-terminal is built with gtk4 and uses GNOME's own IME integration > system, I will dig into it later, but any other terminal emulator should > be usable. konsole(qt)/sakura(gtk) both are fine. > > > > > > 2. setup session environment variables in ~/.xsession, and start fcitx > > > when logging in > > > > > > export XMODIFIERS=@im=fcitx > > > export GTK_IM_MODULE=fcitx > > > export QT_IM_MODULE=fcitx > > > /usr/local/bin/fcitx5 > > > > Oh, I should have guessed that, it's similar to fcitx4. Maybe we can > > adopt the same wording as in fcitx' DESCR? > > (and similar for the gtk and qt module) > > > > I prefer to maintain a single README file documenting all the setup > instructions, just like meta/gnome/pkg/README-main. I think doing so > makes it easier to keep instructions up to date. (I plan to write that > once I got more IME plugins working) > > > > Since fcitx5 is meant to be the successor for fcitx4 which is no > > longer developed, it may make sense to replace fcitx4 with 5 instead > > of keeping both in the port tree? I'm not using either, so I'm > > probably missing something here. > > I agree, if Kevin is ok with that we can drop fcitx4 once fcitx5 and its > plugins are tested and imported. Hmm, fcitx5 doesn't work on x11/dwm. Launching fcitx5 with "fcitx5 -d" (gives no error), Ctrl+Space shortcut to change input method doesn't do anything on applications (firefox, konsole, etc). I have the following installed: fcitx5-5.0.11 flexible input method framework fcitx5-chewing-5.0.8 chewing wrapper for fcitx5 fcitx5-gtk-5.0.10 GTK IM module for fcitx5 fcitx5-m17n-5.0.7 m17n wrapper for fcitx5 fcitx5-qt-5.0.9 Qt library and IM module for fcitx5 xcb-imdkit-1.0.3implementation of xim protocol in xcb
[UPDATE] lang/node to 16.13.1
The attached archive contains my first attempt at updating lang/node to the currently active LTS version of NodeJS. Support for NodeJS 12.x will end in April 2022. I changed the port from the bundled versions of libuv, c-ares, nghttp2, zlib, brotli, icu and openssl to the versions in ports. To build v8, I adapted the v8 patches I needed to make the build work from www/chromium to the v8 version bundled with node ... robert@, could you maybe have a look if those make sense? The port builds an runs fine for me on amd64, but unfortunately I don't have access to another platform to run the build on. Could anyone please review? Thanks! cu, Volker node16-port.tar.gz Description: application/gzip
Re: ports fallout in upcoming libcrypto bump
> On Jan 9, 2022, at 4:37 PM, Theo Buehler wrote: > > With the upcoming libcrypto bump the following ports will no longer > build: > > databases/pgadmin3 > Embeds an old libssh2. Some details are here: > https://marc.info/?l=openbsd-ports=164175518805993=2 > > security/ikeman > Reaches into various structs that will become opaque. The patches > needed for this port are getting big and it would be nice if they > could be incorporated upstream. I have a diff that fixes the build but > I need to look over it once more before sending it out. This will > likely be the last time I fix the build of this port. > > security/pivy > Embeds code from an old version of OpenSSH from before the conversion > to the OpenSSL 1.1 API. I will see with upstream if it is possible to > update that code. I have not yet had the time to start looking into > this seriously. I'll follow up with some details soon. > > security/ssh-ldap-helper > I sent out a diff a while back but got no test reports. Someone told > me they'll try to test it, but it seems they got busy. I suggest > I commit that update but would like to have at least one ok. > https://marc.info/?l=openbsd-ports=163776037016642=2 > > security/tarsnap > I notified upstream about this and the master branch is fixed, but > there is no new release. The fix is trivial, but we must not patch it. > https://github.com/Tarsnap/tarsnap/issues/319 We could build from master tho I suppose… > > security/tcltls > The version in ports is quite outdated. An update should be easy but > apparently one or two of the three dependent ports will stop working. > When I tried to update the port, there were numerous test failures. > This has to be looked into by someone who cares about this. > > There are a few more non-trivial fixes that I need to land. I'll contact > the relevant maintainers and/or the list.
ports fallout in upcoming libcrypto bump
With the upcoming libcrypto bump the following ports will no longer build: databases/pgadmin3 Embeds an old libssh2. Some details are here: https://marc.info/?l=openbsd-ports=164175518805993=2 security/ikeman Reaches into various structs that will become opaque. The patches needed for this port are getting big and it would be nice if they could be incorporated upstream. I have a diff that fixes the build but I need to look over it once more before sending it out. This will likely be the last time I fix the build of this port. security/pivy Embeds code from an old version of OpenSSH from before the conversion to the OpenSSL 1.1 API. I will see with upstream if it is possible to update that code. I have not yet had the time to start looking into this seriously. I'll follow up with some details soon. security/ssh-ldap-helper I sent out a diff a while back but got no test reports. Someone told me they'll try to test it, but it seems they got busy. I suggest I commit that update but would like to have at least one ok. https://marc.info/?l=openbsd-ports=163776037016642=2 security/tarsnap I notified upstream about this and the master branch is fixed, but there is no new release. The fix is trivial, but we must not patch it. https://github.com/Tarsnap/tarsnap/issues/319 security/tcltls The version in ports is quite outdated. An update should be easy but apparently one or two of the three dependent ports will stop working. When I tried to update the port, there were numerous test failures. This has to be looked into by someone who cares about this. There are a few more non-trivial fixes that I need to land. I'll contact the relevant maintainers and/or the list.
Re: [UPDATE] games/blockgame 0.6.14 (previously games/multimc)
Hi Yuki, I am testing this, and setting the path to the Java binary is not working. I get this error: 2060.095 D "Running java checker: /usr/local/jdk-17/bin/java-jar /usr/local/bin/jars/JavaCheck.jar" 2060.103 D STDOUT "" 2060.103 W STDERR "Error: Unable to access jarfile /usr/local/bin/jars/JavaCheck.jar\n" 2060.103 D Java checker finished with status QProcess::NormalExit exit code 1 I see the jar file in question in /usr/local/share/bgl/jars, but the application is searching in the wrong location. Is there a way to configure this path, or is this something that needs to be changed in code? Thanks for your work on this! Steve On Sat, Jan 8, 2022, at 9:36 AM, Muhammad Kaisar Arkhan (Yuki) wrote: > Hi ports@, > > Attached in this email is the tarball for games/blockgame 0.6.14. > > The name is changed from games/multimc to games/blockgame due to > MultiMC's new guidelines for unofficial builds[1]. > > This new version introduces the long awaited support for Microsoft/Xbox > accounts. I have tested it with both my Xbox account which has Xbox Game > Pass membership and my unmigrated Mojang account. > > The Java version is now changed from Java 11 to Java 17 due to the > strict version requirements introduced by Minecraft 1.17. The README > contains information on how to play older versions which may not work > with Java 17 and Blockgame now has proper Java installation detection > for OpenBSD to make the process much easier. > > Lastly, due to the name change, a manual migration step is needed after > installation which is detailed in the README. > > OK? > > Thanks, > Yuki > > [1]: > https://github.com/MultiMC/Launcher#forkingredistributingcustom-builds-policy > Attachments: > * blockgame-0.6.14.tgz
[update] sysutils/telegraf 1.21.2
Hi, attached is an update for sysutils/telegraf to 1.21.2: - (re)enable i386 support (runtime tested - wireguard/wgctrl gained i386 support) - (re)enable nats support (only build tested - PR https://github.com/influxdata/telegraf/issues/10035) arm64 (see bulk builds) and modbus support are fixed upstream but did not make this release. Pushing this for review and feedback now, expect to see another update with support for arm64 and modbus once released. -m Index: Makefile === RCS file: /cvs/ports/sysutils/telegraf/Makefile,v retrieving revision 1.14 diff -u -p -u -p -r1.14 Makefile --- Makefile3 Nov 2021 07:54:45 - 1.14 +++ Makefile9 Jan 2022 18:35:28 - @@ -2,11 +2,9 @@ COMMENT = plugin-driven server agent for collecting metrics -BROKEN-i386 = build fails, no error message BROKEN-arm = build fails, no error message -MODGO_VERSION= v1.20.3 -REVISION = 0 +MODGO_VERSION= v1.21.2 MODGO_MODNAME= github.com/influxdata/telegraf GH_ACCOUNT = influxdata GH_PROJECT = telegraf Index: distinfo === RCS file: /cvs/ports/sysutils/telegraf/distinfo,v retrieving revision 1.4 diff -u -p -u -p -r1.4 distinfo --- distinfo1 Nov 2021 12:51:11 - 1.4 +++ distinfo9 Jan 2022 18:35:30 - @@ -76,7 +76,8 @@ SHA256 (go_modules/gioui.org/@v/v0.0.0-2 SHA256 (go_modules/github.com/!andreas!briese/bbloom/@v/v0.0.0-20190825152654-46b345b51c96.mod) = +1EvcgKcPaIhIpojGp3yEHWiJTNq3xEe9zkhlWAVDes= SHA256 (go_modules/github.com/!andreas!briese/bbloom/@v/v0.0.0-20190825152654-46b345b51c96.zip) = i4wBbgQVktTKjL0qjGjg3Quht6j5b6t0Isjjc7GDWi0= SHA256 (go_modules/github.com/!azure/azure-amqp-common-go/v3/@v/v3.0.1.mod) = cwzFDnbkijMmydi1zDzuyeuRNdFTJHk6hOIFm7VlFps= -SHA256 (go_modules/github.com/!azure/azure-amqp-common-go/v3/@v/v3.0.1.zip) = lm3z4M38PgYI+HxumgqQWqpmNB7dX0kh7pgkSAB8Ft4= +SHA256 (go_modules/github.com/!azure/azure-amqp-common-go/v3/@v/v3.1.0.mod) = cwzFDnbkijMmydi1zDzuyeuRNdFTJHk6hOIFm7VlFps= +SHA256 (go_modules/github.com/!azure/azure-amqp-common-go/v3/@v/v3.1.0.zip) = sg4q5M8nHaWVNyWWhgVBbmuJmGLvS/A/8lvsg2CpYw0= SHA256 (go_modules/github.com/!azure/azure-event-hubs-go/v3/@v/v3.3.13.mod) = i/0XNG6EH3JJqZB7+CqZbduTIbfo7/2YORlBOv4bO9Y= SHA256 (go_modules/github.com/!azure/azure-event-hubs-go/v3/@v/v3.3.13.zip) = l7kcSHw7wgh1OKuTX4V9wL2g89Jvu38PULyDcFVD9yg= SHA256 (go_modules/github.com/!azure/azure-kusto-go/@v/v0.4.0.mod) = 3nogpnY89rQSOyb81PyL1thfWxnR55h+tWyQThGvwEM= @@ -90,7 +91,8 @@ SHA256 (go_modules/github.com/!azure/azu SHA256 (go_modules/github.com/!azure/azure-sdk-for-go/@v/v44.1.0+incompatible.mod) = p418v2ktHa6ZkXkOAgKNxJhmFO2ZJ+szFD9AJ4a4odM= SHA256 (go_modules/github.com/!azure/azure-sdk-for-go/@v/v51.1.0+incompatible.mod) = p418v2ktHa6ZkXkOAgKNxJhmFO2ZJ+szFD9AJ4a4odM= SHA256 (go_modules/github.com/!azure/azure-sdk-for-go/@v/v52.5.0+incompatible.mod) = p418v2ktHa6ZkXkOAgKNxJhmFO2ZJ+szFD9AJ4a4odM= -SHA256 (go_modules/github.com/!azure/azure-sdk-for-go/@v/v52.5.0+incompatible.zip) = AWkWLGRow3b/yc+nVVh+zNao3WJ5zoqKVuZL5IBWEAk= +SHA256 (go_modules/github.com/!azure/azure-sdk-for-go/@v/v55.0.0+incompatible.mod) = p418v2ktHa6ZkXkOAgKNxJhmFO2ZJ+szFD9AJ4a4odM= +SHA256 (go_modules/github.com/!azure/azure-sdk-for-go/@v/v55.0.0+incompatible.zip) = BXvT4D2KFpSVPmf/CHsq68Bs+gik6r2n1BTxvmXBxaY= SHA256 (go_modules/github.com/!azure/azure-storage-blob-go/@v/v0.14.0.mod) = Ha9D0kY/ruvVWYuZSjyBaONUHFdxEdQ8bArpELU8Ksw= SHA256 (go_modules/github.com/!azure/azure-storage-blob-go/@v/v0.14.0.zip) = syfwSUku+/v4EXMUjNlrkAncvBpb/OSMLRhsd70pY5c= SHA256 (go_modules/github.com/!azure/azure-storage-blob-go/@v/v0.6.0.mod) = LAMA+ni7LxOwb8h2NT0Z3XGFPnDEIy0Cl70fT84NjDY= @@ -151,8 +153,11 @@ SHA256 (go_modules/github.com/!azure/go- SHA256 (go_modules/github.com/!azure/go-autorest/tracing/@v/v0.5.0.mod) = uEx0ub3rViIXiBUpMvfFVHlur6bzk1Vu5d0J8bsHDkI= SHA256 (go_modules/github.com/!azure/go-autorest/tracing/@v/v0.6.0.mod) = dM56ibpkfEExSV6pJwVTbyukh3QW9WEy8kUL1qFRbsA= SHA256 (go_modules/github.com/!azure/go-autorest/tracing/@v/v0.6.0.zip) = tylrpk7K5nyDrhyJ2kfG9lwv8IBwJ+MB2syrMmc5FLM= +SHA256 (go_modules/github.com/!azure/go-ntlmssp/@v/v0.0.0-20200615164410-66371956d46c.mod) = r7eFUbVmFd4AgIT1n8DUixCBZjyogRZWJ0TlwgWrZFk= +SHA256 (go_modules/github.com/!azure/go-ntlmssp/@v/v0.0.0-20200615164410-66371956d46c.zip) = N5Zk6ctXHxGe5TNXbbshFvSH1tpI3pU1YO5odfCnmwo= SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.mod) = KAIbQYClnDmTYHqVsY4jDdC8a+pSQv/o6ou/tPT3tNc= -SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.zip) = gVxuWUdF8tiEL/mksFacZpXmzf1eB+Wz2Y0GtyykHjw= +SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.4.1.mod) = JnfIL+dPIDdyiJpagBr7Mp2VF1UId92ssXIZFpurPt0= +SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.4.1.zip) = PyzyMozfrDnbWuachCAflhtQ0VeS933gq+hwiYNqkyw= SHA256
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/01/09 13:46:32 Modified files: graphics/qr-code-generator: Makefile Log message: Remove unused variable, slipped through previous commit
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/01/09 13:45:27 Modified files: graphics/qr-code-generator: Makefile Log message: Use -fPIC for C code as well to fix build on i386 Noted by sthen, tested by me.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2022/01/09 12:29:01 Modified files: net/ldns : Makefile Added files: net/ldns/patches: patch-dnssec_c patch-host2str_c patch-keys_c Log message: ldns: Prepare for upcoming libcrypto bump by using the OpenSSL 1.1 code path.
Re: CVS: cvs.openbsd.org: ports
On 2021/12/23 02:01, Klemens Nanni wrote: > CVSROOT: /cvs > Module name: ports > Changes by: k...@cvs.openbsd.org2021/12/23 02:01:11 > > Log message: > Import graphics/qr-code-generator 1.7.0 > > Input OK op > --- > High-quality QR Code generator library in Java, TypeScript/JavaScript, > Python, Rust, C++, C. > > This project aims to be the best, clearest QR Code generator library in > multiple languages. The primary goals are flexible options and absolute > correctness. Secondary goals are compact implementation size and good > documentation comments. > > This package only contains libraries for C++ and C. > > Status: > > Vendor Tag: kn > Release Tags: kn_20211223 > > N ports/graphics/qr-code-generator/Makefile > N ports/graphics/qr-code-generator/distinfo > N ports/graphics/qr-code-generator/pkg/DESCR > N ports/graphics/qr-code-generator/pkg/PLIST > > No conflicts created by this import > Broken on i386: ===> Building for qr-code-generator-1.7.0p0 cd /pobj/qr-code-generator-1.7.0/QR-Code-generator-1.7.0/c && PATH=/pobj/qr-code-generator-1.7.0/bin:/usr/bin:/bin:/ usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin cc -O2 -pipe -shared -Wl,-soname,libqrcodegen.so.0.0 -o /pobj/qr- code-generator-1.7.0/build-i386/libqrcodegen.so.0.0 qrcodegen.c ld: error: relocation R_386_PC32 cannot be used against symbol qrcodegen_encodeSegmentsAdvanced; recompile with -fPIC >>> defined in /tmp/qrcodegen-790e70.o >>> referenced by qrcodegen.c >>> /tmp/qrcodegen-790e70.o:(qrcodegen_encodeText) ld: error: relocation R_386_PC32 cannot be used against symbol qrcodegen_makeNumeric; recompile with -fPIC >>> defined in /tmp/qrcodegen-790e70.o >>> referenced by qrcodegen.c >>> /tmp/qrcodegen-790e70.o:(qrcodegen_encodeText) ld: error: relocation R_386_PC32 cannot be used against symbol qrcodegen_makeAlphanumeric; recompile with -fPIC >>> defined in /tmp/qrcodegen-790e70.o >>> referenced by qrcodegen.c >>> /tmp/qrcodegen-790e70.o:(qrcodegen_encodeText) (etc.etc.)
pgadmin3: build "fix" for upcoming libcrypto bump
pgadmin3 is one of the ports that I did not manage to fix for the upcoming libcrypto bump. The problem is that it embeds a version of libssh2 old enough that it wasn't converted to the OpenSSL 1.1 API. Patching this version is a fool's errand. The diff below disables use of libcrypto and libssl. I don't know if it makes sense to ship pgadmin3 without this, but given that configure is prepared for it, it might. Someone motivated enough might manage to update that embedded libssh2. I tried but I quickly gave up. Index: Makefile === RCS file: /cvs/ports/databases/pgadmin3/Makefile,v retrieving revision 1.46 diff -u -p -r1.46 Makefile --- Makefile6 Jul 2021 16:55:32 - 1.46 +++ Makefile9 Jan 2022 18:57:27 - @@ -5,7 +5,7 @@ COMMENT=administration and development V= 1.22.1 DISTNAME= pgadmin3-$V CATEGORIES=databases devel -REVISION= 6 +REVISION= 7 HOMEPAGE= https://www.pgadmin.org/ @@ -14,7 +14,7 @@ MAINTAINER= Pierre-Emmanuel Andre
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2022/01/09 11:50:07 Modified files: net/libunbound : Makefile Added files: net/libunbound/patches: patch-sldns_keyraw_c Log message: libunbound: Fix build with opaque RSA and DSA in LibreSSL 3.5. Same diff was just committed to base.
Re: [update] net/usockets-0.8.1, www/uwebsockets-20.8.0, www/purritobin-0.6.7
On Sun, Jan 09, 2022 at 11:55:14AM -0500, Aisha Tammy wrote:
> Ping for update.
Hi Aisha,
Sorry, don't want to give you the runaround, but could you send a fresh
unquoted diff? I tried to applied the one from your email after
sed -E 's/^..//g', but the resulting patch doesn't apply for half of
the files. The most recent one I found is from about October, but there
uwebsockets is for version 20.6; not 20.8.
Thanks!
>
> Aisha
>
> On 12/29/21 13:18, aisha wrote:
> > Thanks for the comments!
> >
> > I've attached the updated patch.
> >
> > Cheers,
> > Aisha
> >
> > diff --git a/net/usockets/Makefile b/net/usockets/Makefile
> > index a484c23f93a..03c93b13ed2 100644
> > --- a/net/usockets/Makefile
> > +++ b/net/usockets/Makefile
> > @@ -3,38 +3,31 @@
> > COMMENT = eventing, networking & crypto for async applications
> > CATEGORIES = net
> > -VERSION = 0.6.0
> > -REVISION = 1
> > -
> > -DISTNAME = usockets-${VERSION}
> > -PKGNAME = ${DISTNAME:L}
> > -
> > -SHARED_LIBS = usockets 1.0
> > +SHARED_LIBS = usockets 2.0
> > GH_ACCOUNT = uNetworking
> > GH_PROJECT = uSockets
> > -#GH_TAGNAME = v0.6.0
> > -# cstdlib include error
> > -GH_COMMIT =7683672d87067cd75b854f4e36b9820f4809a4be
> > -
> > +GH_TAGNAME = v0.8.1
> > +PKGNAME = ${DISTNAME:L}
> > MAINTAINER = Aisha Tammy
> > # Apache 2.0
> > PERMIT_PACKAGE = Yes
> > -WANTLIB += ${COMPILER_LIBCXX} crypto ssl uv
> > +WANTLIB += ${COMPILER_LIBCXX} crypto m ssl uv
> > # C11 C++17
> > COMPILER =base-clang ports-gcc
> > LIB_DEPENDS = devel/libuv
> > -USE_GMAKE =Yes
> > -MAKE_FLAGS = CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \
> > - CC="${CC}" CXX="${CXX}" \
> > - LIBusockets_VERSION="${LIBusockets_VERSION}"
> > +MAKE_ENV = LIBusockets_VERSION="${LIBusockets_VERSION}"
> > +
> > +post-extract:
> > + cp ${FILESDIR}/{Makefile,libusockets.pc.in,localhost.conf} \
> > + ${WRKSRC}
> > -NO_TEST = Yes
> > +# tests need A LOT of file descriptors ~5000-6000
> > .include
> > diff --git a/net/usockets/distinfo b/net/usockets/distinfo
> > index 964ba508e9e..a437989a34e 100644
> > --- a/net/usockets/distinfo
> > +++ b/net/usockets/distinfo
> > @@ -1,2 +1,2 @@
> > -SHA256 (usockets-0.6.0-7683672d.tar.gz) =
> > 0OooGCHD8ezNIcaB1zDPK6RQLGGYGZJb24Vemjlat7c=
> > -SIZE (usockets-0.6.0-7683672d.tar.gz) = 57634
> > +SHA256 (uSockets-0.8.1.tar.gz) =
> > OzO1kkqSV3hU4jJrPi05OEnsAL64ZaEnG/JMDyEMwdY=
> > +SIZE (uSockets-0.8.1.tar.gz) = 65470
> > diff --git a/net/usockets/files/Makefile b/net/usockets/files/Makefile
> > new file mode 100644
> > index 000..aedf5ac6d0a
> > --- /dev/null
> > +++ b/net/usockets/files/Makefile
> > @@ -0,0 +1,36 @@
> > +PREFIX ?= /usr/local
> > +LIBDIR ?= "$(PREFIX)/lib"
> > +INCLUDEDIR ?= "$(PREFIX)/include"
> > +
> > +PKG_CONFIG ?= pkg-config
> > +
> > +LIBTARGET =libusockets.so.$(LIBusockets_VERSION)
> > +
> > +REQUIRES = libcrypto libssl libuv
> > +COMMON_FLAGS = -Isrc -DLIBUS_USE_OPENSSL -DLIBUS_USE_LIBUV
> > `$(PKG_CONFIG) --cflags $(REQUIRES)`
> > +
> > +CFLAGS += -std=c11 -fPIC $(COMMON_FLAGS)
> > +CXXFLAGS +=-std=c++17 -fPIC $(COMMON_FLAGS)
> > +LDFLAGS += `$(PKG_CONFIG) --libs $(REQUIRES)`
> > +
> > +all:
> > + $(CC) $(CFLAGS) -c src/*.c src/eventing/*.c src/crypto/*.c
> > + $(CXX) $(CXXFLAGS) -c src/crypto/*.cpp
> > + $(AR) rvs libusockets.a *.o
> > + $(CXX) $(CXXFLAGS) -shared -o $(LIBTARGET) *.o -Wl,-soname,$(LIBTARGET)
> > $(LDFLAGS)
> > + sed -e "s:@PREFIX@:$(PREFIX):" -e "s:@VERSION@:$(LIBusockets_VERSION):"
> > libusockets.pc.in > libusockets.pc
> > +
> > +install:
> > + install -d "$(LIBDIR)/pkgconfig" "$(INCLUDEDIR)"
> > + install -m 644 src/libusockets.h "$(INCLUDEDIR)/"
> > + install -m 644 $(LIBTARGET) "$(LIBDIR)/"
> > + install -m 644 libusockets.a "$(LIBDIR)/"
> > + install -m 644 libusockets.pc "$(LIBDIR)/pkgconfig/"
> > +
> > +test:
> > + rm -f localhost.pem localhost.crt
> > + openssl req -x509 -out localhost.crt -keyout localhost.pem -newkey
> > rsa:2048 -nodes -sha256 -subj '/CN=localhost' -extensions EXT -config
> > localhost.conf
> > + $(CXX) $(CXXFLAGS) libusockets.a examples/hammer_test.c -o hammer_test
> > $(LDFLAGS)
> > + ./hammer_test
> > +
> > +.PHONY: all install test
> > diff --git a/net/usockets/files/libusockets.pc.in
> > b/net/usockets/files/libusockets.pc.in
> > new file mode 100644
> > index 000..8dc88682736
> > --- /dev/null
> > +++ b/net/usockets/files/libusockets.pc.in
> > @@ -0,0 +1,13 @@
> > +prefix=@PREFIX@
> > +libdir=${prefix}/lib
> > +includedir=${prefix}/include
> > +
> > +Name: uSockets
> > +Version: @VERSION@
> > +Description: eventing, networking and crypto for async applications.
> > +URL: https://github.com/uNetworking/uSockets
> > +
> > +Cflags: -I${includedir}
> > +Libs: -L${libdir} -lusockets
> > +Libs.private: -lcrypto -lssl
> > +Requires.private: libuv
> > diff --git
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: an...@cvs.openbsd.org 2022/01/09 10:58:37 Modified files: mail/mdsort: Makefile distinfo Log message: update to mdsort-11.2.0 - add command matcher, evalutes to true if command exits zero.
Re: Port: gkrellmreminder-2.0.0p10
Hi,
The fix you made works for me (more below).
Thanks
On Sat, Jan 08, 2022 at 10:12:47AM +0100, Omar Polo wrote:
John McCue writes:
Hi
I installed port gkrellmreminder-2.0.0p10 and it causes
gkrellm to core dump.
I took the reminder package from
http://gkrellm.srcbox.net/Plugins.html and fixed it.
I had to add include "#include "
and add " || defined(OpenBSD)" to the checks of the two
define lines in "reminder.c". Since that change reminder
plugin is working fine on my system (see below).
My changes are in this source package, I used RCS to keep
track of the changes made.
https://jmcunx.com/data/gkrellm-reminder-2.0.2-jmc.tar.gz
https://jmcunx.com/data/gkrellm-reminder-2.0.2-jmc.sha256
Hello,
When reporting bugs please include a recipe to reproduce the issue. In
this case, for me is installing grkellm and grkellmreminder, launching
gkrellm, enabling the plugin (left click on the bar, then plugins),
click on the reminder widget, schedule an event and press "Add" and then
"Apply".
Made a note if this plus other suggestions.
Since it's a crash due to a SIGSEGV a backtrace would be useful. It
doesn't generate a coredump thought, and the program doesn't contain
debug symbols so even if ran inside egdb (pkg_add gdb) there aren't much
info.
I've added DEBUG_PACKAGES=${BUILD_PACKAGES} to the plugin' Makefile and
re-built the port, which generates a debug- package with the info.
Armed with that, the bug was easy to spot:
reminder.c:1259 strftime( ..., localtime (>end ) );
(gdb) p event->end
$1 = -231488553457544
(gdb) p/x event->end
$2 = 0xdfdfdfdf
localtime returns NULL and then it crashes in strftime (_fmt to be precise.)
at first I thought of a possible use-after-free, given the 0xdf pattern,
but the rest of the struct seems fine:
(gdb) p *event
$3 = {name = 0xe7905a9cd10 "foo", id = 1641634627, days = 1, occurs = 0,
start = 281476618345276, end = -231488553457544,
last_displayed = 15908559728384, next = 0x0}
However, the compiler complains loudly because the program loves to
fscanf with %d into time_t. Fixing those seems to fix the crash too,
but it's just a minimal diff, the code is very fragile.
Regarding your fix for the 2038-year, I'm not sure what the consequences
of this are.
- adj_year = gtk_adjustment_new( 0, 1971, 2037, 1, 10, 0 );
+ adj_year = gtk_adjustment_new( 0, 1971, , 1, 10, 0 );
I completely forgot I added this :)
But what you did is fine by me.
so i've left it out. I've not studied in much detail the plugin, but it
seems to "just" create a bunch of time_t using the gtk form and
serialize/deserialize those to a text file. Hopefully it doesn't need
any further special treatment. (The other changes were superfluous
because you added `|| defined(__OpenBSD)' to lines that already had that
check.)
I don't really use gkrellm (just discovered it today!), so please test
the following diff and see if it fixes the problem for you too. I've
left the DEBUG_PACKAGES in case it still crashes.
As noted above, the fix works for me (OpenBSD 7, amd64).
As a final note, if you want to share a diff please use cvs or git/got.
Posting a diff is not required when reported bugs, but if you worked on
one at least make it easier for who'll look at it by generating it
against the port tree. You can fetch the port tree using cvs[0] or with
git using the github mirror[1].
Sure thing
[0]: https://www.openbsd.org/anoncvs.html
[1]: https://github.com/openbsd/ports
Index: Makefile
===
RCS file: /home/cvs/ports/sysutils/gkrellm/plugins/reminder/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile15 Sep 2017 15:37:18 - 1.23
+++ Makefile8 Jan 2022 10:00:02 -
@@ -5,7 +5,7 @@ COMMENT=GKrellM2 will remind you to do
V= 2.0.0
DISTNAME= gkrellm-reminder-${V}
PKGNAME=gkrellmreminder-${V}
-REVISION= 10
+REVISION= 11
CATEGORIES= misc
HOMEPAGE=
http://members.dslextreme.com/users/billw/gkrellm/Plugins.html\#REMINDER
@@ -15,5 +15,7 @@ MASTER_SITES= http://members.dslextreme.
EXTRA_WANTLIB= gthread-2.0
PLUGIN= ${WRKSRC}/reminder.so
+
+DEBUG_PACKAGES=${BUILD_PACKAGES}
.include
Index: patches/patch-reminder_c
===
RCS file:
/home/cvs/ports/sysutils/gkrellm/plugins/reminder/patches/patch-reminder_c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-reminder_c
--- patches/patch-reminder_c3 Nov 2003 20:34:18 - 1.1.1.1
+++ patches/patch-reminder_c8 Jan 2022 10:01:06 -
@@ -1,6 +1,7 @@
$OpenBSD: patch-reminder_c,v 1.1.1.1 2003/11/03 20:34:18 sturm Exp $
reminder.c.orig2002-12-04 06:29:09.0 +0100
-+++ reminder.c 2003-11-02 16:42:30.0 +0100
+Index: reminder.c
+--- reminder.c.orig
reminder.c
@@ -87,7 +87,7 @@ static struct reminder_config {
struct event_stored {
@@
Re: MPV, graphics driver, or AUDIO driver??
On Sun, Jan 09, 2022 at 10:49:55AM -0500, fo...@dnmx.org wrote: > So, because of that I went from TTY5 (home/xendom or at least > CTRL+ALT+Function5) to TTY1 to log-in and see if that changed anything I think this is a known bug that was introduced between 6.9-release and 7.0-release. Can you reproduce it on the same hardware with 6.9-release?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2022/01/09 07:32:39 Modified files: www/chromium/patches: patch-build_config_compiler_BUILD_gn Log message: unbreak on arm64
Re: replace graphics/comix with graphics/mcomix
> On Jan 9, 2022, at 5:58 AM, Antoine Jacoutot wrote: > On Sun, Jan 09, 2022 at 01:41:22AM -0500, Daniel Dickman wrote: >> I'd like to replace graphics/comix with the mcomix fork which is >> slightly less dead than comix. >> >> mcomix is still python2, but after this is imported, the next step >> will be to switch to the mcomix3 project, which ported the codebase to >> python3 (https://github.com/multiSnow/mcomix3) among various other >> changes over the past 6 years. >> >> ok to import mcomix as a first step? > > Hi. > > I don't understand the requirement of such a transition. > I am probably missing something but why not go directly to mcomix3? > No requirement but I found the mcomix3 port after finishing the mcomix update. I don’t have the time to look at the next piece yet. In the meantime anyone using the port may benefit from the improvements. > -- > Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2022/01/09 05:29:02 Modified files: sysutils/broot : Makefile crates.inc distinfo Log message: Update broot to 1.9.1 OK bket@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2022/01/09 05:28:03 Modified files: sysutils/bat : Makefile crates.inc distinfo Removed files: sysutils/bat/patches: patch-modcargo-crates_sys-info-0_9_0_lib_rs Log message: Update bat to 0.19.0 OK bket@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/09 05:12:42 Modified files: www/xapian-omega: Makefile distinfo Log message: update to xapian-omega-1.4.19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/09 05:12:40 Modified files: databases/xapian-bindings: Makefile distinfo databases/xapian-bindings/patches: patch-configure_ac Log message: update to xapian-bindings-perl-1.4.19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/09 05:12:37 Modified files: databases/xapian-core: Makefile distinfo Removed files: databases/xapian-core/patches: patch-cmake_xapian-config_cmake_in Log message: update to xapian-core-1.4.19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/09 05:11:17 Modified files: www/c-icap/c-icap: Makefile distinfo www/c-icap/c-icap/patches: patch-commands_c Log message: update to c-icap-0.5.9
Re: devel/ninja: Fix shell completion
On Sat, Jan 08, 2022 at 01:32:12PM -0600, Matthew Martin wrote:
> Install the zsh completion function to site-functions. From other ports
> share/bash-completion/completions seems to be the right location, but
> someone should double check me on that.
That is correct:
$ pkg-config --variable=completionsdir bash-completion
/usr/local/share/bash-completion/completions
Committed, thanks.
>
> diff --git Makefile Makefile
> index 7c5972e0079..527dc13ef33 100644
> --- Makefile
> +++ Makefile
> @@ -10,7 +10,7 @@ COMMENT = small build system with a focus on speed
> GH_ACCOUNT = ninja-build
> GH_PROJECT = ninja
> GH_TAGNAME = v1.10.2
> -REVISION = 0
> +REVISION = 1
>
> CATEGORIES = devel
>
> @@ -48,13 +48,15 @@ do-install:
> ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/ninja
> ${INSTALL_DATA} ${WRKSRC}/doc/manual.asciidoc ${PREFIX}/share/doc/ninja
> ${INSTALL_DATA_DIR} ${PREFIX}/share/ninja
> - ${INSTALL_DATA} ${WRKSRC}/misc/bash-completion ${PREFIX}/share/ninja
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions
> + ${INSTALL_DATA} ${WRKSRC}/misc/bash-completion
> ${PREFIX}/share/bash-completion/completions/ninja
> ${INSTALL_DATA} ${WRKSRC}/misc/ninja-mode.el ${PREFIX}/share/ninja
> ${INSTALL_DATA} ${WRKSRC}/misc/ninja.vim ${PREFIX}/share/ninja
> ${INSTALL_DATA} ${WRKSRC}/misc/ninja_syntax.py ${PREFIX}/share/ninja
> ${INSTALL_DATA} ${WRKSRC}/misc/write_fake_manifests.py
> ${PREFIX}/share/ninja
> ${INSTALL_DATA} ${WRKSRC}/misc/measure.py ${PREFIX}/share/ninja
> - ${INSTALL_DATA} ${WRKSRC}/misc/zsh-completion ${PREFIX}/share/ninja
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/zsh/site-functions
> + ${INSTALL_DATA} ${WRKSRC}/misc/zsh-completion
> ${PREFIX}/share/zsh/site-functions/_ninja
>
> do-test:
> @cd ${WRKSRC} && ${SETENV} ${ALL_TEST_ENV} ./ninja ninja_test \
> diff --git pkg/PLIST pkg/PLIST
> index a51ca80a2cd..ffa4fa99ff3 100644
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -1,12 +1,16 @@
> @comment $OpenBSD: PLIST,v 1.3 2017/09/20 07:30:19 giovanni Exp $
> @bin bin/ninja
> +share/bash-completion/
> +share/bash-completion/completions/
> +share/bash-completion/completions/ninja
> share/doc/ninja/
> share/doc/ninja/manual.asciidoc
> share/ninja/
> -share/ninja/bash-completion
> share/ninja/measure.py
> share/ninja/ninja-mode.el
> share/ninja/ninja.vim
> share/ninja/ninja_syntax.py
> share/ninja/write_fake_manifests.py
> -share/ninja/zsh-completion
> +share/zsh/
> +share/zsh/site-functions/
> +share/zsh/site-functions/_ninja
>
--
Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/01/09 04:39:14 Modified files: devel/ninja: Makefile devel/ninja/pkg: PLIST Log message: Install shell completion scripts into their proper location. from Matthew Martin
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/01/09 04:25:52 Modified files: sysutils/google-cloud-sdk: Makefile sysutils/google-cloud-sdk/pkg: PLIST Added files: sysutils/google-cloud-sdk/pkg: README Log message: The command completion scripts aren't standard; so install them in a non default location and add a README about how to include them in the shell profile.
Re: replace graphics/comix with graphics/mcomix
On Sun, Jan 09, 2022 at 01:41:22AM -0500, Daniel Dickman wrote: > I'd like to replace graphics/comix with the mcomix fork which is > slightly less dead than comix. > > mcomix is still python2, but after this is imported, the next step > will be to switch to the mcomix3 project, which ported the codebase to > python3 (https://github.com/multiSnow/mcomix3) among various other > changes over the past 6 years. > > ok to import mcomix as a first step? Hi. I don't understand the requirement of such a transition. I am probably missing something but why not go directly to mcomix3? -- Antoine
Re: [Fwd: Re: MPV, graphics driver, or AUDIO driver??]
On Sun, Jan 09, 2022 at 11:01:26AM +0100, Stefan Hagen wrote: > Theo de Raadt wrote: > > Stefan Hagen wrote: > > > > > Crystal Kolipe wrote: > > > > On Sat, Jan 08, 2022 at 08:15:43PM +0100, Stefan Hagen wrote: > > > > > Start X via xenodm and not via startx. Then it runs through > > > > > /etc/X11/xenodm/GiveConsole, which contains: > > > > > > > > > > if [ -c /dev/dri/card0 ]; then > > > > > chown $USER /dev/dri/card0 > > > > > fi > > > > > > > > > > Alternatively add the chown command above to your .xinitrc > > > > > > > > WHAT!? > > > > > > > > /dev/dri/card0 will be automatically chown'ed to the user logged in on > > > > ttyC0 unless you've changed /etc/fbtab from the default. > > > > > > > > Additionally, /etc/X11/xinit is run as the calling user, not as root. > > > > So how on earth would the chown command succeed, called from xinit? > > > > > > doas(1) helps. But the whole suggestion was a bandaid. I should not have > > > given it. > > > > What unbelievable terrible advice, to encourage people to make their > > accounts root-equivelant. > > > > Just wow. > > My morning brain agrees that doas and chown should not be mentioned in > one sentence. But there's no paddling back from this on a mailing list... > > So: DON'T DO THAT! As theo said, then every file could be chowned to > your user and altered and chowned back. It's basically root for > everything. Except the files that the knowledgeable sysadmin has flagged with schg. Those should be immune. Well, unless a malicious user uses the exploit you would have introduced to actually get real root access, then they can potentially remove the schg flag by directly accesing the raw disk device. Which in turn could be avoided by running in securelevel 2. > We should really hunt down why the device owner is not set properly with > the mechanism in place. Exactly. This is generally a very good idea. The mechanisms in place have hopefully been well thought out, and tested, and shouldn't allow unexpected or unintended behaviour.
Re: Monero port?
Hmm, I have it running, for a while, just to maintain my wallet. Didn't care about mining. Only thing I remember tweaking was some OpenSSL -> LibreSSL stuff, which I put on GitHub. Maybe it's fixed upstream in some other way now. https://github.com/niklasha/monero I have not looked at it for many months, I see it is 160 commits behind :-) Anyways, do with it what you please... On 2022-01-09 00:07, fo...@dnmx.org wrote: Hello there. I am new to OpenBSD so sorry for not doing this myself, I got a mountain to learn. Can I ask someone why hasn't anyone ported monero dameon and the monero wallet client (CLI or GUI)? Does it even need porting? The list says that the CLI wallet supports FreeBSD. I am sorry that I ask for things instead of trying out things myself first, but this is only because of security. I cannot trust myself to make a good security audit of the situation, let alone the code, at least not yet. You might wonder why is this important. It's important if you value anonymity, privacy and decentralization. Yes, it is a cryptocurrency, but if I were to be mining it again, I'd mine it, like I was before, for privacy, anonymity and independence, and not for profit. Also when we're at it, one of decent miners is xmrig https://getmonero.org/ https://github.com/xmrig/xmrig Please, best regards, fossy
Re: Monero port?
On Sat, Jan 08, 2022 at 06:07:27PM -0500, fo...@dnmx.org wrote: > Can I ask someone why hasn't anyone ported monero dameon and the monero > wallet client (CLI or GUI)? > Does it even need porting? The list says that the CLI wallet supports > FreeBSD. https://github.com/monero-project/monero should build without issues on OpenBSD, so a port is not needed; read through the `On OpenBSD:' build instructions. However you may or may not experience performance issues.
