CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: phess...@cvs.openbsd.org2023/02/23 00:37:52 Modified files: devel/p5-YAML-XS: distinfo Log message: use the same version as the Makefile
Re: [update] coeurl, mtxclient & nheko
On Wed, Feb 22, 2023 at 07:40:36PM +, Klemens Nanni wrote:
> This version (maybe 0.11.1 as well, did not try) builds and starts, but
> makes my system lag so much, that I have to switch to another tty to
> kill the process... while waiting a good minute for everything to react.
>
> Old nheko configures but fails to build with newer mtxclient, so unlike
> coeurl, those two need to be worked on in sync.
>
> I'll probably just report this upstream rather than spending more of my
> time on it.
New versions fsync db files too much, there is an issue upstream.
Reverting the commit to 0.10.2 (current port) behaviour fixes it.
> In the process, I've also sent our local patches upstream.
> 0.11.2 required more patches to build.
0.11.3 fixed some emoji stuff -- I don't use them, so I don't know.
This works for me on amd64. patches/ only contains the one backout and
upstreamed OpenBSD support bits.
Feedback? OK?
Index: devel/mtxclient/Makefile
===
RCS file: /cvs/ports/devel/mtxclient/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- devel/mtxclient/Makefile22 Feb 2023 03:01:58 - 1.4
+++ devel/mtxclient/Makefile23 Feb 2023 03:59:43 -
@@ -1,27 +1,28 @@
COMMENT = client API for Matrix, built on libcurl
CATEGORIES = devel
-SHARED_LIBS += matrix_client 1.0
+SHARED_LIBS += matrix_client 2.0
GH_ACCOUNT = Nheko-Reborn
GH_PROJECT = mtxclient
-GH_TAGNAME = v0.8.2
+GH_TAGNAME = v0.9.2
# MIT
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX} coeurl crypto m olm ssl
+WANTLIB += ${COMPILER_LIBCXX} coeurl crypto m olm re2 spdlog ssl
MODULES = devel/cmake
BUILD_DEPENDS = devel/libevent2 \
- devel/spdlog \
textproc/nlohmann-json
-LIB_DEPENDS = devel/coeurl \
- devel/olm>=3.2.7
+LIB_DEPENDS = devel/coeurl>=0.3.0 \
+ devel/olm>=3.2.7 \
+ devel/spdlog \
+ textproc/re2
-# C++17
+# C++20
COMPILER = base-clang ports-gcc
CONFIGURE_ARGS += -DBUILD_LIB_EXAMPLES=OFF
Index: devel/mtxclient/distinfo
===
RCS file: /cvs/ports/devel/mtxclient/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- devel/mtxclient/distinfo10 Sep 2022 16:24:48 - 1.2
+++ devel/mtxclient/distinfo22 Feb 2023 17:57:25 -
@@ -1,2 +1,2 @@
-SHA256 (mtxclient-0.8.2.tar.gz) = TKoS3flUuUktHsm2yjLvD8ZHhVXyKdsHTUO8XMKanIk=
-SIZE (mtxclient-0.8.2.tar.gz) = 609627
+SHA256 (mtxclient-0.9.2.tar.gz) = 9Vgn/boibG/ECc8ADHKxPMbQaewTACg6cjmqGckMX1Y=
+SIZE (mtxclient-0.9.2.tar.gz) = 623481
Index: devel/mtxclient/pkg/PLIST
===
RCS file: /cvs/ports/devel/mtxclient/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- devel/mtxclient/pkg/PLIST 10 Sep 2022 16:24:48 - 1.2
+++ devel/mtxclient/pkg/PLIST 22 Feb 2023 17:57:26 -
@@ -25,6 +25,7 @@ include/mtx/events/join_rules.hpp
include/mtx/events/member.hpp
include/mtx/events/messages/
include/mtx/events/messages/audio.hpp
+include/mtx/events/messages/confetti.hpp
include/mtx/events/messages/emote.hpp
include/mtx/events/messages/file.hpp
include/mtx/events/messages/image.hpp
@@ -74,6 +75,7 @@ include/mtx/responses/public_rooms.hpp
include/mtx/responses/register.hpp
include/mtx/responses/sync.hpp
include/mtx/responses/turn_server.hpp
+include/mtx/responses/users.hpp
include/mtx/responses/version.hpp
include/mtx/responses/well-known.hpp
include/mtx/secret_storage.hpp
Index: net/nheko/Makefile
===
RCS file: /cvs/ports/net/nheko/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- net/nheko/Makefile 22 Feb 2023 03:35:02 - 1.7
+++ net/nheko/Makefile 23 Feb 2023 04:57:16 -
@@ -1,8 +1,8 @@
-COMMENT = desktop client for Matrix using Qt and C++17
+COMMENT = desktop client for Matrix using Qt and C++20
GH_ACCOUNT = Nheko-Reborn
GH_PROJECT = nheko
-GH_TAGNAME = v0.10.2
+GH_TAGNAME = v0.11.3
CATEGORIES=net
@@ -19,7 +19,7 @@ WANTLIB += matrix_client olm qt5keychain
MODULES = devel/cmake \
x11/qt5
-# C++17
+# C++20
COMPILER = base-clang ports-gcc
RUN_DEPENDS = devel/desktop-file-utils \
@@ -33,8 +33,8 @@ BUILD_DEPENDS = databases/lmdbxx \
x11/qt5/qtbase
LIB_DEPENDS = databases/lmdb \
- devel/coeurl \
- devel/mtxclient \
+ devel/coeurl>=0.3.0 \
+ devel/mtxclient>=0.9.2 \
devel/olm \
devel/spdlog \
multimedia/gstreamer1/core \
Index: net/nheko/distinfo
===
RCS file: /cvs/ports/net/nheko/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- net/nheko/distinfo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 21:47:02 Modified files: graphics/p5-Color-Calc: Makefile Log message: Add missing TEST_DEPENDS to graphics/p5-Color-Calc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 21:45:59 Modified files: www/p5-CGI : Makefile distinfo Log message: Update www/p5-CGI to 4.55
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 21:36:18 Modified files: devel/p5-Clone : Makefile distinfo Log message: Update devel/p5-Clone to 0.46
Re: lang/ghc: new bootstrap
Matthias Kilian writes:
> Use a new bootstrap (still 8.10.7, but built on current from
> 2023-02-18). Attached is some kind of "port" I fiddled together
> from what's in CVS and some newer stuff, only used for "make
> bootstrap".
Nice! I belive we should keep a variation of this in the tree and
rebuild bootstrap periodically. There's a bit of intentional duplication
and some detritus we could clean up, but we can do it in the tree just
fine.
Some suggestion before committing this would be to stub it somehow such
that nobody mistakes this for a real package directory. Maybe remove
PLIST/PFRAG* and report an error from do-build: target? Also update the
COMMENT to something like:
bootstrap generator for lang/ghc while it can't be self-hosted
Thanks
Greg
>
> ghc-9.2.6 builds fine with this for me.
>
> Ciao,
> Kili
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ghc/Makefile,v
> retrieving revision 1.208
> diff -u -p -r1.208 Makefile
> --- Makefile 21 Feb 2023 23:06:55 - 1.208
> +++ Makefile 22 Feb 2023 22:50:42 -
> @@ -12,13 +12,13 @@ NO_CCACHE = Yes
> USE_NOEXECONLY = Yes
>
> GHC_VERSION =9.2.6
> -REVISION = 1
> +REVISION = 2
> DISTNAME = ghc-${GHC_VERSION}
> CATEGORIES = lang devel
> HOMEPAGE = https://www.haskell.org/ghc/
>
> # Version of the precompiled binaries
> -BIN_VER =8.10.7.20220904
> +BIN_VER =8.10.7.20230222
>
> # lang/python needed for regression tests.
> MODULES =lang/python
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/ghc/distinfo,v
> retrieving revision 1.65
> diff -u -p -r1.65 distinfo
> --- distinfo 20 Feb 2023 00:02:34 - 1.65
> +++ distinfo 22 Feb 2023 22:50:42 -
> @@ -1,8 +1,8 @@
> -SHA256 (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) =
> bH1nISV38j0ogaqDQuRycw55YaE031EEe6XR4vyw+1Q=
> -SHA256 (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) =
> icwBqEzjeDiW42tw/9kTHC7/Hso9+fjjZaBJ5DF9chY=
> +SHA256 (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) =
> JJ/ulkxy4Kl7a6PTTNZndE2e41EdQlyJe9POBrPnGL0=
> +SHA256 (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) =
> hMSc09Rklbwvj0lUwRp0qPXW90cwwnBW4kqfVn6oqEY=
> SHA256 (ghc/ghc-9.2.6-src.tar.xz) =
> elTPA5itSItO0hnhXR0eZMC2h2xDoFZFUN0R8FQNcwU=
> SHA256 (ghc/ghc-9.2.6-testsuite.tar.xz) =
> YQsidzuDfndyrjAfoGZfpiCt+9KEF4AhjmZvclrWNjk=
> -SIZE (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = 35756988
> -SIZE (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = 3686128
> +SIZE (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) = 48924640
> +SIZE (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) = 2929544
> SIZE (ghc/ghc-9.2.6-src.tar.xz) = 24638236
> SIZE (ghc/ghc-9.2.6-testsuite.tar.xz) = 3202896
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:51:33 Modified files: devel/p5-Params-Validate: Makefile distinfo devel/p5-Params-Validate/pkg: PLIST Log message: Update devel/p5-Params-Validate to 1.31
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:46:44 Modified files: devel/p5-Test-Warn: Makefile distinfo Log message: Update devel/p5-Test-Warn to 0.37
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:39:35 Modified files: textproc/p5-Text-CSV: Makefile distinfo Log message: Update textproc/p5-Text-CSV to 2.02
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:39:06 Modified files: textproc/p5-Text-CSV_XS: Makefile distinfo Log message: Update textproc/p5-Text-CSV_XS to 1.49
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:13:58 Modified files: devel/p5-MRO-Compat: Makefile distinfo Log message: Update devel/p5-MRO-Compat to 0.15
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:10:52 Modified files: devel/p5-Package-Stash: Makefile distinfo Log message: Update devel/p5-Package-Stash to 0.40
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:10:13 Modified files: devel/p5-Package-Stash-XS: Makefile distinfo devel/p5-Package-Stash-XS/pkg: PLIST Log message: Update devel/p5-Package-Stash-XS to 0.30
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2023/02/22 20:04:58 Modified files: devel/p5-YAML-XS: Makefile distinfo Log message: Update p5-YAML-XS to 0.86
lang/ghc: new bootstrap
Hi,
Use a new bootstrap (still 8.10.7, but built on current from
2023-02-18). Attached is some kind of "port" I fiddled together
from what's in CVS and some newer stuff, only used for "make
bootstrap".
ghc-9.2.6 builds fine with this for me.
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.208
diff -u -p -r1.208 Makefile
--- Makefile21 Feb 2023 23:06:55 - 1.208
+++ Makefile22 Feb 2023 22:50:42 -
@@ -12,13 +12,13 @@ NO_CCACHE = Yes
USE_NOEXECONLY = Yes
GHC_VERSION = 9.2.6
-REVISION = 1
+REVISION = 2
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
# Version of the precompiled binaries
-BIN_VER = 8.10.7.20220904
+BIN_VER = 8.10.7.20230222
# lang/python needed for regression tests.
MODULES = lang/python
Index: distinfo
===
RCS file: /cvs/ports/lang/ghc/distinfo,v
retrieving revision 1.65
diff -u -p -r1.65 distinfo
--- distinfo20 Feb 2023 00:02:34 - 1.65
+++ distinfo22 Feb 2023 22:50:42 -
@@ -1,8 +1,8 @@
-SHA256 (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) =
bH1nISV38j0ogaqDQuRycw55YaE031EEe6XR4vyw+1Q=
-SHA256 (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) =
icwBqEzjeDiW42tw/9kTHC7/Hso9+fjjZaBJ5DF9chY=
+SHA256 (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) =
JJ/ulkxy4Kl7a6PTTNZndE2e41EdQlyJe9POBrPnGL0=
+SHA256 (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) =
hMSc09Rklbwvj0lUwRp0qPXW90cwwnBW4kqfVn6oqEY=
SHA256 (ghc/ghc-9.2.6-src.tar.xz) =
elTPA5itSItO0hnhXR0eZMC2h2xDoFZFUN0R8FQNcwU=
SHA256 (ghc/ghc-9.2.6-testsuite.tar.xz) =
YQsidzuDfndyrjAfoGZfpiCt+9KEF4AhjmZvclrWNjk=
-SIZE (ghc/ghc-8.10.7.20220904-amd64-unknown-openbsd.tar.xz) = 35756988
-SIZE (ghc/ghc-8.10.7.20220904-shlibs-amd64.tar.gz) = 3686128
+SIZE (ghc/ghc-8.10.7.20230222-amd64-unknown-openbsd.tar.xz) = 48924640
+SIZE (ghc/ghc-8.10.7.20230222-shlibs-amd64.tar.gz) = 2929544
SIZE (ghc/ghc-9.2.6-src.tar.xz) = 24638236
SIZE (ghc/ghc-9.2.6-testsuite.tar.xz) = 3202896
ghc-8.10.7.tgz
Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2023/02/22 15:33:32 Modified files: devel/got : Makefile distinfo Log message: update to got 0.84 too many changes to list all here; see git repository history for more; and see git repository history for per-change authorship information - add 'got histedit -d' flag to drop all commits - show worktree UUID in backout/cherrypick -l output - several changes in preparation for eventual SHA256 object ID support - make 'got rebase' work when the to-be-rebased branch has no parent commit - fix bad line-wrapping in tog ref and tree views - add horizontal scrolling support to tog ref and tree views - create .pack and .idx files with filemode 0444, like Git does - make 'got fetch' fetch the work tree's current branch as an implicit fallback - improve 'got fetch' behaviour when work tree's branch is not on server - gotwebd: fix briefs/tags navigation overlap - drop double process name from some gotd logs - tog: fix high CPU usage issue after starting search (reported by Mikhail) - fix gotd exiting with abnormal error during client connection teardown - fix gotd segfault in libevent while disconnecting clients - tweak 'got commit' log-message validation: now checks timestamp and size > 0 - gotwebd: abort blame if the client disconnects midway through - make 'got fetch -b branch' only fetch the named branch - got/tog/gotadmin: call pledge(2) earlier where possible - no longer error out if redundant "got commit -A $GOT_AUTHOR" option is used - add 'gotadmin pack' -D flag to force generation of ref-deltas in pack files - make 'got fetch' update cached HEAD symref if it has changed in remote repo - add commit/histedit/merge/rebase -C option to commit unresolved conflicts - make 'got status' check for merge conflict markers on newly added lines only - fix read/write out of bounds in gitconfig file parser (reported by James Cook) - fix "got fetch" hanging if remote repo is out-of-date (reported by James Cook) - ignore patterns with trailing "/" now match directories (suggested by Lucas) - make 'got merge' honour author setting in gitconfig (reported by James Cook) - sync default values shown in gotwebd.conf(5) EXAMPLES section - fix parsing of indented comments in gitconfig file (reported by James Cook) - fix tog diff between arbitrary commits; regression from 0.80
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2023/02/22 15:20:15 Modified files: net/curl : Tag: OPENBSD_7_2 Makefile distinfo Log message: net/curl: update to 7.88.1 for HTTP/2 data corruption fix
Re: update: net/swirc 3.4.1 -> 3.4.2 (bug fix)
On Wed, Feb 22, 2023 at 07:07:43PM +, Markus Uhlin wrote: > Swirc 3.4.2 out. A small bug fix release. > I think only Windows was affected but I post it anyway. Committed, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2023/02/22 15:05:00 Modified files: net/swirc : Makefile distinfo Log message: Update swirc to 3.4.2. >From maintainer Markus Uhlin, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2023/02/22 14:55:04 Modified files: net/curl : Makefile distinfo Log message: net/curl: update to 7.88.1 for HTTP/2 data corruption fix
riscv64 bulk build report
Bulk build on riscv64.ports.openbsd.org Started : Sun Feb 5 16:20:24 MST 2023 Finished: Mon Feb 20 02:12:35 MST 2023 Duration: 14 Days 9 hours 52 minutes Built using OpenBSD 7.2-current (GENERIC.MP) #278: Sat Feb 4 17:45:40 MST 2023 Built 10248 packages Number of packages built each day: Feb 5: 87 Feb 8: 4 Feb 9: 1766 Feb 10: 1185 Feb 11: 784 Feb 12: 484 Feb 13: 307 Feb 14: 302 Feb 15: 250 Feb 16: 499 Feb 17: 1137 Feb 18: 737 Feb 19: 2704 Feb 20: 2 Critical path missing pkgs: http://build-failures.rhaalovely.net/riscv64/2023-02-05/summary.log Build failures: 77 http://build-failures.rhaalovely.net/riscv64/2023-02-05/audio/navidrome.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/databases/influxdb.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/devel/coccigrep.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/devel/github-cli.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/devel/promu.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/devel/reposurgeon.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/devel/shfmt.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/editors/micro.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/emulators/citra.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/games/clidle.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/games/zelda3-data.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/games/zelda3-rom.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/mail/aerc.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/mail/opensmtpd-filters/rspamd.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/amfora.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/coredns.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/dnscontrol.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/dt.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/eduvpn/vpn-daemon.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/go-ipfs.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/irtt.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/mattermost-server.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/minio/client.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/minio/server.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/snowflake_proxy.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/stayrtr.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/syncthing.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/termshark.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/net/yggdrasil-go.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/security/cfssl.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/security/lego.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/security/ogvt.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/security/sops.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/security/step-cli.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/security/vault.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/shells/elvish.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/alertmanager.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/amazon-ecs-cli.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/beats/filebeat.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/beats/heartbeat.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/beats/metricbeat.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/beats/packetbeat.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/blackbox_exporter.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/chezmoi.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/dep.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/direnv.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/docker-cli.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/duf.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/envconsul.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/exoscale-cli.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/fzf.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/gitlab-cli.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/gitlab-runner.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/gke-gcloud-auth-plugin.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/hcloud.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/kopia.log http://build-failures.rhaalovely.net/riscv64/2023-02-05/sysutils/lf.log
Re: keepassxc will not run under OpenBSD 7.2-current (GENERIC.MP)#1059
On Tue, 21 Feb 2023 21:42:39 -0600 Abel Abraham Camarillo Ojeda wrote: > I think esc7.net is known to have issues, at least I filed a report > months ago > > On Tue, Feb 21, 2023 at 5:31 PM Ed Ahlsen-Girard > wrote: > > [...] > [...] > [...] > [...] > [...] I've tried several other mirrors, and the amd64 packages are all dated 19 Feb (which is not solving the problem). -- Edward Ahlsen-Girard Ft Walton Beach, FL
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/22 12:51:12 Modified files: www/chromium : Makefile distinfo www/chromium/patches: patch-chrome_browser_ui_views_frame_browser_view_cc patch-chrome_test_BUILD_gn patch-media_gpu_vaapi_vaapi_video_decoder_cc Log message: update to 110.0.5481.177
Re: [update] coeurl, mtxclient & nheko
22.02.2023 03:37, Klemens Nanni пишет: > 0.11.2 came out, will build and retest with that one soon. This version (maybe 0.11.1 as well, did not try) builds and starts, but makes my system lag so much, that I have to switch to another tty to kill the process... while waiting a good minute for everything to react. Old nheko configures but fails to build with newer mtxclient, so unlike coeurl, those two need to be worked on in sync. I'll probably just report this upstream rather than spending more of my time on it. In the process, I've also sent our local patches upstream. 0.11.2 required more patches to build.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/22 12:33:24 Modified files: security/rust-openssl-tests: Makefile distinfo Log message: Update to rust-openssl-tests 20230222
update: net/swirc 3.4.1 -> 3.4.2 (bug fix)
Hi ports@, Swirc 3.4.2 out. A small bug fix release. I think only Windows was affected but I post it anyway. >From the changelog: ## [3.4.2] - 2023-02-22 ## - **Added** usage of typedefs (`STRING`, `CSTRING`, `errno_t`, ...) - **Fixed** printtext() bugs due to not checking if the wide character passed to `wcrtomb_s()` or `wcrtomb()` is a null character. I attach a diff. Kind regards Markus Index: Makefile === RCS file: /cvs/ports/net/swirc/Makefile,v retrieving revision 1.24 diff -u -p -r1.24 Makefile --- Makefile19 Feb 2023 12:04:54 - 1.24 +++ Makefile22 Feb 2023 19:00:16 - @@ -1,5 +1,5 @@ COMMENT = curses icb and irc client -DISTNAME = swirc-3.4.1 +DISTNAME = swirc-3.4.2 CATEGORIES = net HOMEPAGE = https://www.nifty-networks.net/swirc/ Index: distinfo === RCS file: /cvs/ports/net/swirc/distinfo,v retrieving revision 1.21 diff -u -p -r1.21 distinfo --- distinfo19 Feb 2023 12:04:54 - 1.21 +++ distinfo22 Feb 2023 19:00:16 - @@ -1,2 +1,2 @@ -SHA256 (swirc-3.4.1.tgz) = 2nbhy8sGu6su+K7VwFqqYKmvwRrhoaYzkGzD8B52w74= -SIZE (swirc-3.4.1.tgz) = 302612 +SHA256 (swirc-3.4.2.tgz) = zf5NfVh5tAeR91n+lKldxrMQxUocaFeQ/I0kR7ov3Jc= +SIZE (swirc-3.4.2.tgz) = 302886
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2023/02/22 11:04:28 Modified files: net/openvpn: Makefile net/openvpn/pkg: README Log message: Add hint about compression disabled by default with OpenVPN 2.6 Found out by landry@ connecting to a server with compression enabled.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/22 10:27:16 Modified files: graphics/tiff : Makefile Added files: graphics/tiff/patches: patch-libtiff_tif_close_c patch-tools_tiffcrop_c Log message: backport upstream fixes for CVE-2022-48281 CVE-2023-0795 CVE-2023-0796 CVE-2023-0797 CVE-2023-0798 CVE-2023-0799 CVE-2023-0800 CVE-2023-0801 CVE-2023-0802 CVE-2023-0803 CVE-2023-0804 and a null pointer dereference ok landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/02/22 10:17:19 Modified files: devel/coeurl : Makefile Log message: mention missing doctest port for future test enablers
Re: maintainer update, www/ephemetoot 3.1.3 --> 3.1.4
Ping ?
diff /usr/ports
commit - 59eec5c604409c9cf68d099a5e5dc095ea712868
path + /usr/ports
blob - d2bb1777c418f0f6eb04ad2b543041041d597688
file + www/ephemetoot/Makefile
--- www/ephemetoot/Makefile
+++ www/ephemetoot/Makefile
@@ -1,8 +1,7 @@
COMMENT = tool for deleting old Mastodon toots
-MODPY_EGG_VERSION =3.1.3
+MODPY_EGG_VERSION =3.1.4
DISTNAME = ephemetoot-${MODPY_EGG_VERSION}
-REVISION = 4
CATEGORIES = www
@@ -16,8 +15,7 @@ RUN_DEPENDS = devel/py-setuptools${MODPY_FLAVOR} \
MODPY_PI = Yes
MODPY_PYBUILD =poetry-core
-RUN_DEPENDS = devel/py-setuptools${MODPY_FLAVOR} \
- textproc/py-yaml${MODPY_FLAVOR}>=5.0 \
+RUN_DEPENDS = textproc/py-yaml${MODPY_FLAVOR}>=5.0 \
www/py-mastodon.py${MODPY_FLAVOR} \
www/py-requests${MODPY_FLAVOR}
blob - ec49e3523431779272c17cb143e2599a5915bdc0
file + www/ephemetoot/distinfo
--- www/ephemetoot/distinfo
+++ www/ephemetoot/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ephemetoot-3.1.3.tar.gz) = 6c5G9hGcwjE0tJEQhzmH66ORTM74gewrcfNVFMnHuG8=
-SIZE (ephemetoot-3.1.3.tar.gz) = 59144
+SHA256 (ephemetoot-3.1.4.tar.gz) = egR430Pks04cOSrvK3f3vjxoul22WUleGHyn9HYrzbI=
+SIZE (ephemetoot-3.1.4.tar.gz) = 59110
On Wed, 15 Feb 2023, Paco Esteban wrote:
> Hi ports@,
>
> This is an update of www/ephemetoot to its latest version 3.1.4
> The changes on the software are:
>
> * removal of unnecessary setuptools dependency found by florian@ here:
> https://marc.info/?l=openbsd-ports=167325446116128=2
> which upstream integrated.
> * version number displayed is now accurate for latest version
> * minimum Python version is now 3.8
>
> The port only bumps version and drops setuptools as a RUN_DEPENDS.
>
> Tested in my basic use case on amd64.
>
> ok to commit ?
>
> diff /usr/ports
> commit - 59eec5c604409c9cf68d099a5e5dc095ea712868
> path + /usr/ports
> blob - d2bb1777c418f0f6eb04ad2b543041041d597688
> file + www/ephemetoot/Makefile
> --- www/ephemetoot/Makefile
> +++ www/ephemetoot/Makefile
> @@ -1,8 +1,7 @@
> COMMENT =tool for deleting old Mastodon toots
>
> -MODPY_EGG_VERSION = 3.1.3
> +MODPY_EGG_VERSION = 3.1.4
> DISTNAME = ephemetoot-${MODPY_EGG_VERSION}
> -REVISION = 4
>
> CATEGORIES = www
>
> @@ -16,8 +15,7 @@ RUN_DEPENDS =
> devel/py-setuptools${MODPY_FLAVOR} \
> MODPY_PI = Yes
> MODPY_PYBUILD = poetry-core
>
> -RUN_DEPENDS =devel/py-setuptools${MODPY_FLAVOR} \
> - textproc/py-yaml${MODPY_FLAVOR}>=5.0 \
> +RUN_DEPENDS =textproc/py-yaml${MODPY_FLAVOR}>=5.0 \
> www/py-mastodon.py${MODPY_FLAVOR} \
> www/py-requests${MODPY_FLAVOR}
>
> blob - ec49e3523431779272c17cb143e2599a5915bdc0
> file + www/ephemetoot/distinfo
> --- www/ephemetoot/distinfo
> +++ www/ephemetoot/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (ephemetoot-3.1.3.tar.gz) =
> 6c5G9hGcwjE0tJEQhzmH66ORTM74gewrcfNVFMnHuG8=
> -SIZE (ephemetoot-3.1.3.tar.gz) = 59144
> +SHA256 (ephemetoot-3.1.4.tar.gz) =
> egR430Pks04cOSrvK3f3vjxoul22WUleGHyn9HYrzbI=
> +SIZE (ephemetoot-3.1.4.tar.gz) = 59110
--
Paco Esteban.
0x5818130B8A6DBC03
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/22 09:27:38 Modified files: audio/sox : Makefile Log message: audio/sox: unbreak; I committed from the wrong tree...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/02/22 09:18:35 Modified files: devel/coeurl : Makefile distinfo Log message: devel/coeurl: update to 0.3.0. see https://nheko.im/nheko-reborn/coeurl/-/tags/v0.3.0 tested by kn@ with both nheko 0.10.2 & 0.11.1. ok kn@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2023/02/22 09:04:53 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: register comms/wammu removal
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2023/02/22 08:56:27 Modified files: comms : Makefile Removed files: comms/wammu: Makefile distinfo comms/wammu/patches: patch-setup_py comms/wammu/pkg: DESCR PLIST Log message: Remove wammu as it is broken with new wxWidgets and has no upstream maintainer to fix this.
[update] libusb1-1.0.26
Hi.
This diff updates libusb to the latest available release.
I would appreciate some testing :-)
Thanks!
Index: Makefile
===
RCS file: /cvs/ports/devel/libusb1/Makefile,v
retrieving revision 1.36
diff -u -p -r1.36 Makefile
--- Makefile20 Feb 2023 08:47:39 - 1.36
+++ Makefile22 Feb 2023 15:29:06 -
@@ -1,11 +1,10 @@
COMMENT = library for USB device access from userspace
-VERSION = 1.0.23
+VERSION = 1.0.26
DISTNAME = libusb-${VERSION}
PKGNAME = libusb1-${VERSION}
-REVISION = 3
-SHARED_LIBS += usb-1.0 1.2 # 2.0
+SHARED_LIBS += usb-1.0 2.0 # 3.0
CATEGORIES = devel
Index: distinfo
===
RCS file: /cvs/ports/devel/libusb1/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo27 Nov 2019 20:15:17 - 1.6
+++ distinfo22 Feb 2023 15:29:06 -
@@ -1,2 +1,2 @@
-SHA256 (libusb-1.0.23.tar.bz2) = 2xHAbpWKgtrFLPPGXLTdLD8znIqYhmURDg0k0ZMSrY0=
-SIZE (libusb-1.0.23.tar.bz2) = 602860
+SHA256 (libusb-1.0.26.tar.bz2) = Es56YfyYVNHSof/glfe1+sGd26CVwlnmBnpGUAOBtaU=
+SIZE (libusb-1.0.26.tar.bz2) = 620534
Index: patches/patch-libusb_core_c
===
RCS file: patches/patch-libusb_core_c
diff -N patches/patch-libusb_core_c
--- patches/patch-libusb_core_c 11 Mar 2022 18:50:41 - 1.7
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-On OpenBSD USB controllers are shown as normal devices, making the
-itinial limit too small. On a recent machine this value is almost
-always exceeded, so bump it.
-
-Index: libusb/core.c
libusb/core.c.orig
-+++ libusb/core.c
-@@ -612,7 +612,7 @@ libusb_free_device_list(list, 1);
- * which grows when required. it can be freed once discovery has completed,
- * eliminating the need for a list node in the libusb_device structure
- * itself. */
--#define DISCOVERED_DEVICES_SIZE_STEP 8
-+#define DISCOVERED_DEVICES_SIZE_STEP 16
-
- static struct discovered_devs *discovered_devs_alloc(void)
- {
Index: patches/patch-libusb_libusb_h
===
RCS file: /cvs/ports/devel/libusb1/patches/patch-libusb_libusb_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-libusb_libusb_h
--- patches/patch-libusb_libusb_h 11 Mar 2022 18:50:41 - 1.2
+++ patches/patch-libusb_libusb_h 22 Feb 2023 15:29:06 -
@@ -1,10 +1,11 @@
libusb/libusb.h.orig Sat Sep 10 11:00:40 2016
-+++ libusb/libusb.hSat Sep 10 11:00:56 2016
-@@ -58,6 +58,7 @@ typedef unsigned __int32 uint32_t;
+Index: libusb/libusb.h
+--- libusb/libusb.h.orig
libusb/libusb.h
+@@ -47,6 +47,7 @@ typedef SSIZE_T ssize_t;
+ #if !defined(_MSC_VER)
#include
#endif
-
+#include /* timeval */
#include
- #include
+ #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
Index: patches/patch-libusb_os_openbsd_usb_c
===
RCS file: patches/patch-libusb_os_openbsd_usb_c
diff -N patches/patch-libusb_os_openbsd_usb_c
--- patches/patch-libusb_os_openbsd_usb_c 11 Mar 2022 18:50:41 -
1.11
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,39 +0,0 @@
-Export port number, fix github #314.
-https://github.com/libusb/libusb/pull/764
-
-Fix an OpenBSD backend bug where an existing open file descriptor is
-overwritten if a libusb user attempts to open the same ugen(4) device
-multiple times. This was observed with sane-backends and broke scanning.
-https://github.com/libusb/libusb/pull/763
-
-Index: libusb/os/openbsd_usb.c
libusb/os/openbsd_usb.c.orig
-+++ libusb/os/openbsd_usb.c
-@@ -183,6 +183,7 @@ obsd_get_device_list(struct libusb_context * ctx,
- dev->bus_number = di.udi_bus;
- dev->device_address = di.udi_addr;
- dev->speed = di.udi_speed;
-+ dev->port_number = di.udi_port;
-
- dpriv = (struct device_priv *)dev->os_priv;
- dpriv->fd = -1;
-@@ -232,15 +233,17 @@ obsd_open(struct libusb_device_handle *handle)
- char devnode[16];
-
- if (dpriv->devname) {
-+ int fd;
- /*
-* Only open ugen(4) attached devices read-write, all
-* read-only operations are done through the bus node.
-*/
- snprintf(devnode, sizeof(devnode), DEVPATH "%s.00",
- dpriv->devname);
-- dpriv->fd = open(devnode, O_RDWR);
-- if (dpriv->fd < 0)
-+ fd = open(devnode, O_RDWR);
-+ if (fd < 0)
- return _errno_to_libusb(errno);
-+ dpriv->fd =
Re: [maintainer] bug in www/gotosocial 0.7.0
Le 2023-02-22 13:33, Stuart Henderson a écrit : > Problem is that we don't know if other codepaths also result in using > old system calls - this avoids one known case but there may still be > others. Crashing at start is possibly not so bad; starting up ok and > crashing later could do much more damage. Especially in an area around > database files I'm getting a bit twitchy. There are a lot of syscalls > showing up in > go/pkg/mod/modernc.org/sqlite@v1.20.4/lib/sqlite_openbsd_*.go and IIUC > any using off_t will be in the set which was changed. > > Really my best suggestion at the moment is to run on 7.2 or a kernel > with those syscalls reinstated, but calling syscalls directly at all > is at odds with some of the possible future directions to avoid #3 in > https://marc.info/?l=openbsd-tech=167702364728145=2 (though quite > common in some ecosystems - in particular on Linux glibc has sometimes > been slow to add wrappers for syscalls in new kernels which downstream > software wishes to use, so not really surprising that people who have > learnt to code that way also do so when dealing with other OS). > Ok, I see. Thank you. Regards, H. > > -- > Sent from a phone, apologies for poor formatting. > > On 22 February 2023 11:47:36 Hukadan wrote: > >> Le 2023-02-22 09:49, Stuart Henderson a écrit : >>> On 2023/02/21 23:24, Hukadan wrote: After some investigations, it appears to be related to a change in the latest version of gotosocial where WAL[1] is now enabled by default. gotosocial works fine when the setting is switched back to DELETE. >>> >>> Sorry this isn't going to be very directly helpful in terms of fixing, >>> but I can explain what's going on and why you're running into it now. >>> >>> The go ecosystem largely expects OS to carry backwards compatibility >>> for long periods of time and OpenBSD does not want to do that. >>> >>> This is exacerbated by the static linking of libraries everywhere, so >>> when changes are made to the OS, all software using them needs to be >>> updated. It's not even just a simple rebuild, like it is with most C >>> software, because of the way dependencies work in most go software. >>> >>> The crash is due to some legacy system calls that have been removed >>> in -current, they were replaced with versions with a different call >>> conventiom (removing "pad" parameters) 2021/12/23 leaving the old >>> ones around for compatibility because some software (mostly go) still >>> used them. The compatibility ones were removed 2022/07/20 and readded >>> 2022/08/01 because too much software was still using them, then removed >>> again 2023/02/11. >>> >>> In particular one of the affected syscalls (SYS_MMAP) is one which is >>> often called directly even in software which normally tries to use the >>> libc syscall wrappers. >>> >>> Various go libraries still use the old ones even in their latest upstream >>> versions. >>> >>> Specifically in this crash, >>> https://gitlab.com/cznic/libc/-/blob/master/libc_openbsd.go#L1470 >>> uses the SYS_MMAP constant from >>> https://go.googlesource.com/sys/+/refs/heads/master/unix/zsysnum_openbsd_amd64.go#156 >>> which is the old pad syscall which was removed. Despite some suggestions >>> to the contrary this has *not* yet been updated upstream in >>> golang.org/x/sys. >>> >>> It is possible that, while disabling WAL fixes this particular crash, >>> there might be other code still using those syscalls under certain >>> conditions. >>> >>> Unfortunately for the current go build system we can't patch modules >>> which are used as part of building other software, the build system >>> expects a zip file (IIUC with a valid hash) rather than just source >>> code. So to fix this there are two methods >>> >>> 1: >>> >>> a) the libraries upstream need to adapt to follow the changes in OpenBSD >>> (in this case it might need changes in both golang.org/x/sys and >>> modernc.org/libc), >>> >>> b) there need to be new upstream releases of those libraries, >>> >>> c) the software using those libraries (e.g. gotosocial) needs a release >>> specifying the new version of that library, or there is a dirty method >>> we can use to patch the version numbers of libraries specified in the >>> build. >>> >>> or 2: >>> >>> If upstreams don't adapt we can ignore the unflexible go modbuild stuff >>> and produce an old-style vendored tarball which we can patch in ports. >>> I have one report that the same version of gotosocial works just fine on -STABLE with WAL enabled. >>> >>> This is a change in OpenBSD rather than in gotosocial, -stable working >>> ok is expected. Same for -current before this commit: >>> https://github.com/openbsd/src/commit/454ecbe3fc36ac622b906f0c934efee67d137b8e >>> >>> -- >> Thank you so much for the time you put on explaining me all this. >> You made it crystal clear despite my lack of knowledge. >> >> At the moment, I think we can deal with it by switching back to >> "DELETE" until upstream cacthes
[new] devel/p5-ExtUtils-LibBuilder
Hi, Please consider merging in the new port devel/p5-ExtUtils-LibBuilder. It is a build-dependency for biber [0], a BibTeX replacement for BibLaTeX. You may fetch the port at: https://rak.ac/~tmp/06fba8f759d9f06fde5d6fcf4ce5b358.devel.p5-ExtUtils-LibBuilder.tar.gz It contains: devel/p5-ExtUtils-LibBuilder devel/p5-ExtUtils-LibBuilder/Makefile devel/p5-ExtUtils-LibBuilder/distinfo devel/p5-ExtUtils-LibBuilder/pkg devel/p5-ExtUtils-LibBuilder/pkg/DESCR devel/p5-ExtUtils-LibBuilder/pkg/PLIST Information for file:/usr/ports/packages/amd64/all/p5-ExtUtils-LibBuilder-0.08p0.tgz Comment: tool to build C libraries Description: Some Perl modules need to ship C libraries together with their Perl code. Although there are mechanisms to compile and link (or glue) C code in your Perl programs, there isn't a clear method to compile standard, self-contained C libraries. This module's main goal is to help in that task. Maintainer: The OpenBSD ports mailing-list WWW: https://metacpan.org/release/ExtUtils-LibBuilder Thank you, Ryan [0] https://biblatex-biber.sourceforge.net/ -- |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2023/02/22 08:20:37 Modified files: devel/p5-Data-Alias: Makefile distinfo Log message: Update to p5-Data-Alias-1.28.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/22 08:11:35 Modified files: audio/audacity : Makefile distinfo audio/audacity/patches: patch-lib-src_libnyquist_nyquist_xlisp_xlisp_h patch-src_AboutDialog_cpp patch-src_AudacityApp_cpp audio/audacity/pkg: PLIST Added files: audio/audacity/patches: patch-lib-src_libnyquist_nyquist_sys_unix_switches_h patch-lib-src_libnyquist_nyquist_xlisp_path_c patch-libraries_lib-basic-ui_BasicUI_cpp patch-linux_findlib_c patch-src_MIDIPlay_cpp Removed files: audio/audacity/patches: patch-cmake-proxies_CMakeLists_txt patch-lib-src_libnyquist_nyquist_cmt_cext_h patch-src_AudioIOBase_h patch-src_AudioIO_cpp patch-src_FFmpeg_h patch-src_MixerBoard_cpp Log message: Update to audacity-3.2.4.
Re: audio/sox port: unfixed vulns
> Can we have those patches in the port please? Committed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/22 08:03:03 Modified files: audio/sox : Makefile audio/sox/patches: patch-src_formats_c Added files: audio/sox/patches: patch-src_aiff_c patch-src_formats_i_c patch-src_hcom_c patch-src_sphere_c patch-src_voc_c patch-src_wav_c Log message: audio/sox: apply patches by Helmut Grohne as ported to the version in our ports tree by the Steffen "Kragenbaer" Nurpmeso. ok maintainer
Re: audio/sox port: unfixed vulns
On Feb 13 13:50:43, h...@stare.cz wrote:
> On Feb 07 15:09:39, t...@theobuehler.org wrote:
> > On Tue, Feb 07, 2023 at 02:48:25PM +0100, Jan Stary wrote:
> > > On Feb 06 22:56:02, t...@theobuehler.org wrote:
> > > > There is an ongoing discussion on audio/sox on oss-security:
> > > >
> > > > https://marc.info/?l=oss-security=167546008232629=2
> > > >
> > > > Steffen Nurpmeso ported the patches to apply against the commit
> > > > we also use in our ports, that's what's included in the diff below.
> > > >
> > > > The patches look sensible to me although I haven't reviewed them
> > > > thoroughly.
> > > >
> > > > It's probably a good idea to keep an eye on this discussion both for
> > > > reviews of the patches and for possible developments of a new upstream
> > > > repo containing them.
> > >
> > > I just asked upstream - let's wait a on whether the upstream maintainer
> > > decides to include these in the upstream git (SF) that we build from;
> > > I would prefer that to maintaining the patches (thank you Steffen!)
> >
> > For reference:
> >
> > https://marc.info/?l=sox-devel=167577672104072=2
> >
> > The patches were sent to oss-security *because* upstream failed to react:
> >
> >I am working on fixing known vulnerabilities in sox and since upstream
> >seems mostly dead (no commits in more than a year, no replies to bug
> >reports)
> >
> > Given this, waiting until upstream decides to unhibernate makes little
> > sense to me.
>
> After talkig to both Helmut and upstream,
> I am convinced there is no point waiting
> till upstream acts on this (or anything, really).
Can we have those patches in the port please?
Jan
> I have created merge requests upstream
> for each of the patches individually.
> Let's see ahat happens.
>
> Going through the individual patches:
> it seems SOX_EOF is the universal indicator of a returned error,
> even though the err msgs use SOX_EHDR or SOX_EFMT.
> But it seems the rest of the code doesn't really
> distinguish the kind of returned error ...
>
> Comments inline.
>
> Jan
>
>
> > diff --git a/src/aiff.c b/src/aiff.c
> > index 3a152c588c..6de94f3276 100644
> > --- a/src/aiff.c
> > +++ b/src/aiff.c
> > @@ -619,6 +619,11 @@ int lsx_aiffstartwrite(sox_format_t * ft)
> > At 48 kHz, 16 bits stereo, this gives ~3 hours of audio.
> > Sorry, the AIFF format does not provide for an indefinite
> > number of samples. */
> > +if (ft->signal.channels >= (0x7f00 /
> > (ft->encoding.bits_per_sample >> 3)))
> > +{
> > +lsx_fail_errno(ft, SOX_EOF, "too many channels for AIFF
> > header");
> > +return SOX_EOF;
> > +}
> > return(aiffwriteheader(ft, (uint64_t) 0x7f00 /
> > ((ft->encoding.bits_per_sample>>3)*ft->signal.channels)));
> > }
>
> This prevents sox from _writing_ an aiff file
> with an absurd number of channels; the bug
> https://sourceforge.net/p/sox/bugs/360/
> seems related: should we also refuse to _read_
> audio files with 1073807359 channels and the like?
>
> >
> > diff --git a/src/formats.c b/src/formats.c
> > index 3fcf4382b6..5eda5e3612 100644
> > --- a/src/formats.c
> > +++ b/src/formats.c
> > @@ -627,6 +627,7 @@ error:
> >free(ft->priv);
> >free(ft->filename);
> >free(ft->filetype);
> > + sox_delete_comments(>oob.comments);
> >free(ft);
> >return NULL;
> > }
>
>
> This is in a failed open_read();
> the same imho applies to a failed open_write();
> updated patch attached.
>
> However, once SoX fails an open_{read,write},
> it exits soon afterwards anyway.
>
>
> > diff --git a/src/formats_i.c b/src/formats_i.c
> > index 7048040d1c..5f5ef979d4 100644
> > --- a/src/formats_i.c
> > +++ b/src/formats_i.c
> > @@ -19,6 +19,7 @@
> > */
> >
> > #include "sox_i.h"
> > +#include
> > #include
> > #include
> > #include
> > @@ -60,13 +61,24 @@ int lsx_check_read_params(sox_format_t * ft, unsigned
> > channels,
> >if (ft->seekable)
> > ft->data_start = lsx_tell(ft);
> >
> > - if (channels && ft->signal.channels && ft->signal.channels != channels)
> > + if (channels && ft->signal.channels && ft->signal.channels != channels) {
> > lsx_warn("`%s': overriding number of channels", ft->filename);
> > - else ft->signal.channels = channels;
> > + } else if (channels > SHRT_MAX) {
> > +lsx_fail_errno(ft, EINVAL, "implausibly large number of channels");
> > +return SOX_EOF;
> > + } else {
> > +ft->signal.channels = channels;
> > + }
>
> Ah, this is what correctly rejects the files at
> https://sourceforge.net/p/sox/bugs/360/
>
> > - if (rate && ft->signal.rate && ft->signal.rate != rate)
> > + if (rate && ft->signal.rate && ft->signal.rate != rate) {
> > lsx_warn("`%s': overriding sample rate", ft->filename);
> > - else ft->signal.rate = rate;
> > + /* Since NaN comparisons yield false, the negation rejects them. */
> > + } else if (!(rate > 0)) {
> > +
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/22 06:56:09 Modified files: mail : Makefile Log message: +grommunio
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/22 06:55:11 Added files: mail/grommunio/mapi-header-php/patches: patch-class_baserecurrence_php patch-mapidefs_php Log message: CAL_DEFAULT has been defined as 1 since the dawn of outlook and php made the stupid decision in the calendar extension to ignore this fact and #undef it to "unbreak" build on windows and creating a conflict because that extension sets it to 0, so rename our variable for now
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/22 06:53:49 ports/mail/grommunio/mapi-header-php/patches Update of /cvs/ports/mail/grommunio/mapi-header-php/patches In directory cvs.openbsd.org:/tmp/cvs-serv69609/patches Log Message: Directory /cvs/ports/mail/grommunio/mapi-header-php/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/22 06:53:40 Modified files: mail/grommunio/gromox: Makefile distinfo Log message: sync to upstream git head
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/02/22 06:53:11 Modified files: mail/grommunio/dav/patches: patch-lib_GLogger_php Log message: set a default value for the errcontext parameter for the error handler callback to support php8+ properly
Re: gtk+4 slow application startup
Le Tue, 21 Feb 2023 12:15:31 +0100, Antoine Jacoutot a écrit : > On Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray wrote: > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote: > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > > > > Hi. > > > > > > > > > > There seems to be a regression with mesa that makes gtk+4 application > > > > > very slow > > > > > to start. > > > > > By default the GSK renderer uses OpenGL. > > > > > As a workaround, you can temporarily use this to go back to the cairo > > > > > renderer > > > > > which makes gtk+4 applications fast again: > > > > > > > > > > export GSK_RENDERER=cairo > > > > > > > > What hardware is this on? Is there a Mesa or gtk bug for it? > > > > > > See dmesg below. > > > > > > > When did this behaviour start? Before the gtk update that recently > > > > went in? Does it occur with GSK_RENDERER=vulkan? > > > > GSK_RENDERER described in > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer > > > > > > It did not happen on my previous amd ryzen. > > > As soon as I switched to the new intel laptop, I was that bug (exact same > > > installation, I rsync'd everything). > > > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy > > > (not > > > built by default) and segfaults on a regular basis. > > > > > > > There is > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > > > > which briefly touches on shader cache. We disable the shader > > > > cache to be able to uses pledge(2). > > > > > > Yes, that is the bug I was looking into. > > > > Here is a xenocara diff to enable the shader cache. > > It is created in ~/.cache/mesa_shader_cache/ > > > > On an Intel system (x250 with Broadwell) launching gtk4-demo results in > > a 1.6M cache. The time to a window appearing is noticeably shorter > > running it again after that. > > > > The various firefox and chromium ports will need to change > > unveil/pledge policies to use it. Chromium at least still runs but > > there are multiple warnings that directories can't be created. > > Wow, that makes a crazy improvement! > Running a full blown GNOME right now and I can definitely tell the difference. > Thanks :-) > > > > Index: lib/mesa/src/util/disk_cache.c > > === > > RCS file: /cvs/xenocara/lib/mesa/src/util/disk_cache.c,v > > retrieving revision 1.13 > > diff -u -p -r1.13 disk_cache.c > > --- lib/mesa/src/util/disk_cache.c 28 Jan 2023 08:56:53 - 1.13 > > +++ lib/mesa/src/util/disk_cache.c 20 Feb 2023 12:42:45 - > > @@ -80,11 +80,6 @@ disk_cache_create(const char *gpu_name, > > uint8_t cache_version = CACHE_VERSION; > > size_t cv_size = sizeof(cache_version); > > > > -#ifdef __OpenBSD__ > > - /* default to no disk shader cache to avoid pledge violations in > > chromium */ > > - return NULL; > > -#endif > > - > > if (!disk_cache_enabled()) > >return NULL; > > > > > +1, with this diff, it's day and night when using GNOME
Re: [maintainer] bug in www/gotosocial 0.7.0
Problem is that we don't know if other codepaths also result in using old system calls - this avoids one known case but there may still be others. Crashing at start is possibly not so bad; starting up ok and crashing later could do much more damage. Especially in an area around database files I'm getting a bit twitchy. There are a lot of syscalls showing up in go/pkg/mod/modernc.org/sqlite@v1.20.4/lib/sqlite_openbsd_*.go and IIUC any using off_t will be in the set which was changed. Really my best suggestion at the moment is to run on 7.2 or a kernel with those syscalls reinstated, but calling syscalls directly at all is at odds with some of the possible future directions to avoid #3 in https://marc.info/?l=openbsd-tech=167702364728145=2 (though quite common in some ecosystems - in particular on Linux glibc has sometimes been slow to add wrappers for syscalls in new kernels which downstream software wishes to use, so not really surprising that people who have learnt to code that way also do so when dealing with other OS). -- Sent from a phone, apologies for poor formatting. On 22 February 2023 11:47:36 Hukadan wrote: Le 2023-02-22 09:49, Stuart Henderson a écrit : On 2023/02/21 23:24, Hukadan wrote: After some investigations, it appears to be related to a change in the latest version of gotosocial where WAL[1] is now enabled by default. gotosocial works fine when the setting is switched back to DELETE. Sorry this isn't going to be very directly helpful in terms of fixing, but I can explain what's going on and why you're running into it now. The go ecosystem largely expects OS to carry backwards compatibility for long periods of time and OpenBSD does not want to do that. This is exacerbated by the static linking of libraries everywhere, so when changes are made to the OS, all software using them needs to be updated. It's not even just a simple rebuild, like it is with most C software, because of the way dependencies work in most go software. The crash is due to some legacy system calls that have been removed in -current, they were replaced with versions with a different call conventiom (removing "pad" parameters) 2021/12/23 leaving the old ones around for compatibility because some software (mostly go) still used them. The compatibility ones were removed 2022/07/20 and readded 2022/08/01 because too much software was still using them, then removed again 2023/02/11. In particular one of the affected syscalls (SYS_MMAP) is one which is often called directly even in software which normally tries to use the libc syscall wrappers. Various go libraries still use the old ones even in their latest upstream versions. Specifically in this crash, https://gitlab.com/cznic/libc/-/blob/master/libc_openbsd.go#L1470 uses the SYS_MMAP constant from https://go.googlesource.com/sys/+/refs/heads/master/unix/zsysnum_openbsd_amd64.go#156 which is the old pad syscall which was removed. Despite some suggestions to the contrary this has *not* yet been updated upstream in golang.org/x/sys. It is possible that, while disabling WAL fixes this particular crash, there might be other code still using those syscalls under certain conditions. Unfortunately for the current go build system we can't patch modules which are used as part of building other software, the build system expects a zip file (IIUC with a valid hash) rather than just source code. So to fix this there are two methods 1: a) the libraries upstream need to adapt to follow the changes in OpenBSD (in this case it might need changes in both golang.org/x/sys and modernc.org/libc), b) there need to be new upstream releases of those libraries, c) the software using those libraries (e.g. gotosocial) needs a release specifying the new version of that library, or there is a dirty method we can use to patch the version numbers of libraries specified in the build. or 2: If upstreams don't adapt we can ignore the unflexible go modbuild stuff and produce an old-style vendored tarball which we can patch in ports. I have one report that the same version of gotosocial works just fine on -STABLE with WAL enabled. This is a change in OpenBSD rather than in gotosocial, -stable working ok is expected. Same for -current before this commit: https://github.com/openbsd/src/commit/454ecbe3fc36ac622b906f0c934efee67d137b8e -- Thank you so much for the time you put on explaining me all this. You made it crystal clear despite my lack of knowledge. At the moment, I think we can deal with it by switching back to "DELETE" until upstream cacthes up. I would like to avoid as much as possible the vendored tarball road. I will modify the patch of the configuration file to make this switch. But I probably won't have time to do it before this week-end. I guess some lines could be dropped somewhere (FAQ about following -current?) to warn people about the needed change. This could be something along the lines: ``` Starting v0.7.0, GoToSocial uses WAL for sqlite
Re: [maintainer] bug in www/gotosocial 0.7.0
Le 2023-02-22 09:49, Stuart Henderson a écrit : > On 2023/02/21 23:24, Hukadan wrote: >> After some investigations, it appears to be related to >> a change in the latest version of gotosocial where WAL[1] >> is now enabled by default. gotosocial works fine when >> the setting is switched back to DELETE. > > Sorry this isn't going to be very directly helpful in terms of fixing, > but I can explain what's going on and why you're running into it now. > > The go ecosystem largely expects OS to carry backwards compatibility > for long periods of time and OpenBSD does not want to do that. > > This is exacerbated by the static linking of libraries everywhere, so > when changes are made to the OS, all software using them needs to be > updated. It's not even just a simple rebuild, like it is with most C > software, because of the way dependencies work in most go software. > > The crash is due to some legacy system calls that have been removed > in -current, they were replaced with versions with a different call > conventiom (removing "pad" parameters) 2021/12/23 leaving the old > ones around for compatibility because some software (mostly go) still > used them. The compatibility ones were removed 2022/07/20 and readded > 2022/08/01 because too much software was still using them, then removed > again 2023/02/11. > > In particular one of the affected syscalls (SYS_MMAP) is one which is > often called directly even in software which normally tries to use the > libc syscall wrappers. > > Various go libraries still use the old ones even in their latest upstream > versions. > > Specifically in this crash, > https://gitlab.com/cznic/libc/-/blob/master/libc_openbsd.go#L1470 > uses the SYS_MMAP constant from > https://go.googlesource.com/sys/+/refs/heads/master/unix/zsysnum_openbsd_amd64.go#156 > which is the old pad syscall which was removed. Despite some suggestions > to the contrary this has *not* yet been updated upstream in golang.org/x/sys. > > It is possible that, while disabling WAL fixes this particular crash, > there might be other code still using those syscalls under certain > conditions. > > Unfortunately for the current go build system we can't patch modules > which are used as part of building other software, the build system > expects a zip file (IIUC with a valid hash) rather than just source > code. So to fix this there are two methods > > 1: > > a) the libraries upstream need to adapt to follow the changes in OpenBSD > (in this case it might need changes in both golang.org/x/sys and > modernc.org/libc), > > b) there need to be new upstream releases of those libraries, > > c) the software using those libraries (e.g. gotosocial) needs a release > specifying the new version of that library, or there is a dirty method > we can use to patch the version numbers of libraries specified in the > build. > > or 2: > > If upstreams don't adapt we can ignore the unflexible go modbuild stuff > and produce an old-style vendored tarball which we can patch in ports. > >> I have one report that the same version of gotosocial >> works just fine on -STABLE with WAL enabled. > > This is a change in OpenBSD rather than in gotosocial, -stable working > ok is expected. Same for -current before this commit: > https://github.com/openbsd/src/commit/454ecbe3fc36ac622b906f0c934efee67d137b8e > > -- > Thank you so much for the time you put on explaining me all this. You made it crystal clear despite my lack of knowledge. At the moment, I think we can deal with it by switching back to "DELETE" until upstream cacthes up. I would like to avoid as much as possible the vendored tarball road. I will modify the patch of the configuration file to make this switch. But I probably won't have time to do it before this week-end. I guess some lines could be dropped somewhere (FAQ about following -current?) to warn people about the needed change. This could be something along the lines: ``` Starting v0.7.0, GoToSocial uses WAL for sqlite database by default. Unforunately, the go libraries involved use an old syscall making GoToSocial crash at start. Therefore, before starting GoToSocial, make sure `journal-mode` for sqlite does not switch to WAL by adding or setting the db-sqlite-journal-mode to an empty string or DELETE in the GoToSocial config file, e.g.: `db-sqlite-journal-mode: ""` If you forgot and started GoToSocial anyway, there is an easy way out: 1- **back-up** the 3 files of your db (sqlite, shm and wal) ; 2- connect to the database using sqlite3 3- once connected, issue the following command: `PRAGMA journal_mode=DELETE;` After that you should be back with just one db file. 4- add (or set if it exists) the following line in your config file: db-sqlite-journal-mode: "" 5- start GoToSocial ``` Again, thank you! Regards, H. >> gotosocial[93313]: timestamp="21/02/2023 23:03:56.767" >> func=bundb.sqlitePragmas level=INFO msg="sqlite pragma cache_size set to >> -8192" >> gotosocial[93313]:
Re: WIP protobuf 22.0 (was Re: RFC: merge py-protobuf into protobuf)
I am going to abandon this update for now. This is going to need quite a bit more work and thought. One issue is that abseil-cpp forces us to use a specific c++ version with which not all consumers are prepared to cope. Hopefully the more important consumers will adapt some time down the road. Here's the deceptively short list of ports that break. libphonenumber is pretty important in the gnome ecosystem and takes out a good chunk of the tree. audio/clementine devel/protobuf-c games/goldberg_emulator games/pokerth! geo/qgis net/barrier net/mosh productivity/libphonenumber x11/kde-applications/marble x11/vlc, Some details: audio/clementine /usr/local/include/absl/types/internal/span.h:133:27: error: no template named 'enable_if_t' in namespace 'std'; did you mean simply 'enable_if_t'? using EnableIfNotIsView = std::enable_if_t::value, int>; ^~~~ enable_if_t devel/protobuf-c configure: error: required protobuf header file not found games/goldberg_emulator In file included from /usr/local/include/absl/container/internal/compressed_tuple.h:40: /usr/local/include/absl/utility/utility.h:164:12: error: no member named 'in_place_t' in namespace 'std' using std::in_place_t; ~^ games/pokerth! /usr/local/include/google/protobuf/port_def.inc:200:1: error: static assertion failed due to requirement '201103L >= 201402L': Protobuf only supports C++14 and newer. static_assert(PROTOBUF_CPLUSPLUS_MIN(201402L), "Protobuf only supports C++14 and newer."); ^ ~~~ geo/qgis ld.lld: error: undefined reference due to --no-allow-shlib-undefined: __emutls_v._ZN6google8protobuf 8internal15ThreadSafeArena13thread_cache_E net/barrier ld: error: undefined symbol: testing::Mock::AllowUninterestingCalls(void const*) net/mosh /usr/local/include/absl/container/internal/compressed_tuple.h:155:48: error: no type named 'in_place_t' in namespace 'absl' explicit constexpr CompressedTupleImpl(absl::in_place_t, Vs&&... args) ~~^ productivity/libphonenumber ld: error: undefined symbol: __emutls_v._ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E x11/kde-applications/marble /usr/local/include/absl/types/internal/span.h:130:24: error: no template named 'enable_if_t' in namespace 'std'; did you mean simply 'enable_if_t'? using EnableIfIsView = std::enable_if_t::value, int>; ^~~~ enable_if_t x11/vlc, /usr/local/include/absl/utility/utility.h:164:12: error: no member named 'in_place_t' in namespace ' std' using std::in_place_t; ~^
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/02/22 04:20:27 Modified files: www/mozilla-firefox: Makefile www/mozilla-firefox/files: unveil.content unveil.main Log message: www/mozilla-firefox: fixup previous and use $XDG_CACHE_HOME Mesa respects XDG_CACHE_HOME in line 860 of lib/mesa/src/util/disk_cache_os.c noted by tb@, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/22 04:19:42 Modified files: net/bro: Tag: OPENBSD_7_2 Makefile distinfo Log message: SECURITY update to zeek-5.0.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/02/22 04:19:27 Modified files: www/firefox-esr: Makefile www/firefox-esr/files: unveil.content unveil.main Log message: www/firefox-esr: fixup previous and use $XDG_CACHE_HOME Mesa respects XDG_CACHE_HOME in line 860 of lib/mesa/src/util/disk_cache_os.c noted by tb@, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mb...@cvs.openbsd.org 2023/02/22 03:37:55 Modified files: devel/codechecker: distinfo Makefile Log message: Update to Release 6.21.0. ok rsadowski
[Update] devel/codechecker to 6.21.0
Dear ports@, This updates devel/codechecker to the newest release. It still works for my use case. OK? Feedback? mbuhl Index: Makefile === RCS file: /cvs/ports/devel/codechecker/Makefile,v retrieving revision 1.4 diff -u -p -r1.4 Makefile --- Makefile27 Nov 2022 14:33:09 - 1.4 +++ Makefile3 Feb 2023 14:22:17 - @@ -2,8 +2,7 @@ COMMENT = clang static code analyzer GH_ACCOUNT = Ericsson GH_PROJECT = codechecker -GH_TAGNAME = v6.20.0 -REVISION = 0 +GH_TAGNAME = v6.21.0 CATEGORIES = devel Index: distinfo === RCS file: /cvs/ports/devel/codechecker/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo9 Nov 2022 15:46:07 - 1.1.1.1 +++ distinfo3 Feb 2023 14:22:17 - @@ -1,10 +1,10 @@ -SHA256 (codechecker-v6.20.0/clike.min.js) = lJbma7uCu604soGpj5LJO4RxDMWUige1afF5veoZxz4= -SHA256 (codechecker-v6.20.0/codechecker-6.20.0.tar.gz) = 7g+YhNMguRzHhzQM2CsvXA+pBcHV5t3fYEGwpJsKOpI= -SHA256 (codechecker-v6.20.0/codemirror.LICENSE) = o/L+Ksa0caqAxzfF0oPdBJvckDpzg17m1NLKwC/dU78= -SHA256 (codechecker-v6.20.0/codemirror.min.css) = wluO/w4cnorJpS0JmcdTSYzwdb5E6u045qa4Ervfb1k= -SHA256 (codechecker-v6.20.0/codemirror.min.js) = AqnMwc9Kk6sJShDo5QGwu2Ea9MzSR+iSWy4nJV+gRRU= -SIZE (codechecker-v6.20.0/clike.min.js) = 18240 -SIZE (codechecker-v6.20.0/codechecker-6.20.0.tar.gz) = 10909440 -SIZE (codechecker-v6.20.0/codemirror.LICENSE) = 1107 -SIZE (codechecker-v6.20.0/codemirror.min.css) = 5731 -SIZE (codechecker-v6.20.0/codemirror.min.js) = 166305 +SHA256 (codechecker-v6.21.0/clike.min.js) = lJbma7uCu604soGpj5LJO4RxDMWUige1afF5veoZxz4= +SHA256 (codechecker-v6.21.0/codechecker-6.21.0.tar.gz) = PDrOFSddrLgdP9fwBKlufiMP/eS/oSWnxPdpfSs2DDQ= +SHA256 (codechecker-v6.21.0/codemirror.LICENSE) = o/L+Ksa0caqAxzfF0oPdBJvckDpzg17m1NLKwC/dU78= +SHA256 (codechecker-v6.21.0/codemirror.min.css) = wluO/w4cnorJpS0JmcdTSYzwdb5E6u045qa4Ervfb1k= +SHA256 (codechecker-v6.21.0/codemirror.min.js) = AqnMwc9Kk6sJShDo5QGwu2Ea9MzSR+iSWy4nJV+gRRU= +SIZE (codechecker-v6.21.0/clike.min.js) = 18240 +SIZE (codechecker-v6.21.0/codechecker-6.21.0.tar.gz) = 11029302 +SIZE (codechecker-v6.21.0/codemirror.LICENSE) = 1107 +SIZE (codechecker-v6.21.0/codemirror.min.css) = 5731 +SIZE (codechecker-v6.21.0/codemirror.min.js) = 166305
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/22 02:46:53 Modified files: net/bro: Makefile distinfo Log message: SECURITY update to zeek-5.0.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/22 02:35:01 Modified files: sysutils/cloud-sql-proxy: Makefile distinfo Log message: Update to cloud-sql-proxy-2.1.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/22 02:26:48 Modified files: sysutils/go-cs : Makefile distinfo Log message: Update to go-cs-1.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/22 02:23:24 Modified files: graphics/webp-pixbuf-loader: Makefile distinfo Log message: Update to webp-pixbuf-loader-0.1.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/22 02:22:53 Modified files: sysutils/borgbackup/2.0: Makefile Log message: borgbackup/2.0: bump after change in openssl/1.1 (static linking)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/22 02:22:15 Modified files: security/sslscan: Makefile Log message: sslscan: bump after change in openssl/1.1 (static linking)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/02/22 02:21:35 Modified files: security/openssl/1.1: Makefile Added files: security/openssl/1.1/patches: patch-crypto_rc4_asm_rc4-x86_64_pl Log message: openssl/1.1: mixed xonly fix for RC4. Visible via eopenssl11 version -a or eopenssl11 speed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/02/22 02:02:34 Added files: x11/gnome/photos/patches: patch-meson_build Log message: Accept both babl and babl-0.1 (from upstream).
Re: [maintainer] bug in www/gotosocial 0.7.0
On 2023/02/21 23:24, Hukadan wrote: > After some investigations, it appears to be related to > a change in the latest version of gotosocial where WAL[1] > is now enabled by default. gotosocial works fine when > the setting is switched back to DELETE. Sorry this isn't going to be very directly helpful in terms of fixing, but I can explain what's going on and why you're running into it now. The go ecosystem largely expects OS to carry backwards compatibility for long periods of time and OpenBSD does not want to do that. This is exacerbated by the static linking of libraries everywhere, so when changes are made to the OS, all software using them needs to be updated. It's not even just a simple rebuild, like it is with most C software, because of the way dependencies work in most go software. The crash is due to some legacy system calls that have been removed in -current, they were replaced with versions with a different call conventiom (removing "pad" parameters) 2021/12/23 leaving the old ones around for compatibility because some software (mostly go) still used them. The compatibility ones were removed 2022/07/20 and readded 2022/08/01 because too much software was still using them, then removed again 2023/02/11. In particular one of the affected syscalls (SYS_MMAP) is one which is often called directly even in software which normally tries to use the libc syscall wrappers. Various go libraries still use the old ones even in their latest upstream versions. Specifically in this crash, https://gitlab.com/cznic/libc/-/blob/master/libc_openbsd.go#L1470 uses the SYS_MMAP constant from https://go.googlesource.com/sys/+/refs/heads/master/unix/zsysnum_openbsd_amd64.go#156 which is the old pad syscall which was removed. Despite some suggestions to the contrary this has *not* yet been updated upstream in golang.org/x/sys. It is possible that, while disabling WAL fixes this particular crash, there might be other code still using those syscalls under certain conditions. Unfortunately for the current go build system we can't patch modules which are used as part of building other software, the build system expects a zip file (IIUC with a valid hash) rather than just source code. So to fix this there are two methods 1: a) the libraries upstream need to adapt to follow the changes in OpenBSD (in this case it might need changes in both golang.org/x/sys and modernc.org/libc), b) there need to be new upstream releases of those libraries, c) the software using those libraries (e.g. gotosocial) needs a release specifying the new version of that library, or there is a dirty method we can use to patch the version numbers of libraries specified in the build. or 2: If upstreams don't adapt we can ignore the unflexible go modbuild stuff and produce an old-style vendored tarball which we can patch in ports. > I have one report that the same version of gotosocial > works just fine on -STABLE with WAL enabled. This is a change in OpenBSD rather than in gotosocial, -stable working ok is expected. Same for -current before this commit: https://github.com/openbsd/src/commit/454ecbe3fc36ac622b906f0c934efee67d137b8e -- > gotosocial[93313]: timestamp="21/02/2023 23:03:56.767" > func=bundb.sqlitePragmas level=INFO msg="sqlite pragma cache_size set to > -8192" > gotosocial[93313]: timestamp="21/02/2023 23:03:56.767" > func=bundb.sqlitePragmas level=INFO msg="sqlite pragma busy_timeout set to > 30" > gotosocial[93313]: SIGSYS: bad system call > gotosocial[93313]: PC=0x2dfa02617 m=8 sigcode=0 > gotosocial[93313]: > gotosocial[93313]: goroutine 0 [idle]: > gotosocial[93313]: syscall.syscall10X(0x4c0c40, 0xc5, 0x0, 0x8000, 0x3, 0x1, > 0x8, 0x0, 0x0, 0x0, ...) > gotosocial[93313]:runtime/sys_openbsd3.go:79 +0x45 fp=0xc00081e0d8 > sp=0xc00081e0b8 pc=0x465045 > gotosocial[93313]: syscall.syscall10X(0x197874b?, 0x46ae46?, 0xc00081e158?, > 0xc00081e1d8?, 0x19786dd?, 0xc0004be070?, 0x8?, 0xc00081e1c0?, 0x1ab7aa9?, > 0x0, ...) > gotosocial[93313]::1 +0x59 fp=0xc00081e158 sp=0xc00081e0d8 > pc=0x46aff9 > gotosocial[93313]: syscall.syscall6Internal(0x1978720?, 0xc0004be070?, > 0xc00081e1c0?, 0xc00081e228?, 0x1978f65?, 0xc0004be070?, 0x8?) > gotosocial[93313]:syscall/syscall_openbsd_libc.go:26 +0x45 > fp=0xc00081e1c0 sp=0xc00081e158 pc=0x4bb0a5 > gotosocial[93313]: syscall.syscall6Internal(0xc5, 0x0, 0x8000, 0x3, 0x1, 0x8, > 0x0) > gotosocial[93313]::1 +0x45 fp=0xc00081e208 sp=0xc00081e1c0 > pc=0x4c1645 > gotosocial[93313]: modernc.org/libc.Xmmap(0xc0004be070?, 0x24b7004c8?, > 0xc8?, 0x4b7004c0?, 0x2?, 0x1?, 0x24b700540?) > gotosocial[93313]:modernc.org/libc@v1.22.2/libc_openbsd.go:1472 +0x51 > fp=0xc00081e270 sp=0xc00081e208 pc=0x196dc51 > gotosocial[93313]: modernc.org/sqlite/lib.unixShmMap(0xc0004be070, > 0x258c005a8, 0x0, 0x8000, 0x1, 0x2c8b004e8) > gotosocial[93313]: > modernc.org/sqlite@v1.20.4/lib/sqlite_openbsd_amd64.go:16097 +0x427 > fp=0xc00081e308 sp=0xc00081e270
