Re: new: textproc/fswatch 1.17.1
Stuart Henderson writes: > On 2024/10/03 15:18, Sebastien Marie wrote: >> Hi, >> >> I would like to import textproc/fswatch (instead of having it in >> mystuff), a program and library to monitor file changes in >> cross-platform way (it is using kqueue on OpenBSD). > > textproc doesn't feel quite right - what do you think about sysutils > (where it will be alongside sysutils/entr which does a similar thing)? yes, sysutils make more sense. >> I am using it with a build system (dune, for ocaml) which could using it >> for monitor and rebuild files (I am using dune directly from opam and >> not from devel/dune). >> >> >> $ cat pkg/DESCR >> fswatch main features are: > > Maybe start with a tiny description like > > fswatch monitora files and directory trees for changes. Main features are: fine too. > otherwise ok with me. thanks. -- Sebastien Marie
new: textproc/fswatch 1.17.1
Hi, I would like to import textproc/fswatch (instead of having it in mystuff), a program and library to monitor file changes in cross-platform way (it is using kqueue on OpenBSD). I am using it with a build system (dune, for ocaml) which could using it for monitor and rebuild files (I am using dune directly from opam and not from devel/dune). $ cat pkg/DESCR fswatch main features are: - Support for many OS-specific APIs such as kevent, inotify, and FSEvents. - Recursive directory monitoring. - Path filtering using including and excluding regular expressions. - Customizable record format. - Support for periodic idle events. Limitations: The kqueue monitor, available on any *BSD system featuring kqueue, requires a file descriptor to be opened for every file being watched. As a result, this monitor scales badly with the number of files being observed, and may begin to misbehave as soon as the fswatch process runs out of file descriptors. In this case, fswatch dumps one error on standard error for every file that cannot be opened. Comments or OK to import ? -- Sebastien Marie fswatch.tgz Description: Binary data
Re: sysutils/sccache: ship docs, zap obsolete makefile stuff
Klemens Nanni writes:
> Usage is the only offline help you get and I don't like browsing github
> to find out how to use the tool.
>
> A few docs don't apply to us, but it's not worth filtering them, imho.
>
> While here, I noticed that it packages fine without the chmod hack;
> DISTFILES contains the tarball twice, so fix that as well.
>
> Feedback? OK?
it makes sense. ok semarie@ if it is fine for maintainer too.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/sccache/Makefile,v
> diff -u -p -r1.11 Makefile
> --- Makefile 19 Jun 2024 15:16:36 - 1.11
> +++ Makefile 12 Sep 2024 14:54:25 -
> @@ -6,13 +6,12 @@ COMMENT = compiler cache for C/C++/Rust
> GH_ACCOUNT = mozilla
> GH_PROJECT = sccache
> GH_TAGNAME = v0.8.1
> +REVISION = 0
>
> CATEGORIES = devel
>
> MAINTAINER = Caspar Schutijser
>
> -FIX_EXTRACT_PERMISSIONS = Yes
> -
> # Apache 2.0
> PERMIT_PACKAGE = Yes
>
> @@ -27,8 +26,11 @@ CONFIGURE_STYLE = cargo
> LIB_DEPENDS += archivers/zstd
> MODCARGO_RUSTFLAGS +=-L${LOCALBASE}/lib
>
> -# as devel/cargo MODULES adds DISTFILES, GH_* didn't
> -DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
> +DOCDIR = ${PREFIX}/share/doc/sccache
> +
> +post-install:
> + ${INSTALL_DATA_DIR} ${DOCDIR}
> + ${INSTALL_DATA} ${WRKSRC}/docs/*.md ${DOCDIR}/
>
> .include "crates.inc"
>
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/sccache/pkg/PLIST,v
> diff -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 8 Nov 2023 18:20:53 - 1.1.1.1
> +++ pkg/PLIST 12 Sep 2024 14:23:50 -
> @@ -1 +1,21 @@
> @bin bin/sccache
> +share/doc/sccache/
> +share/doc/sccache/Architecture.md
> +share/doc/sccache/Azure.md
> +share/doc/sccache/Caching.md
> +share/doc/sccache/Configuration.md
> +share/doc/sccache/Distributed.md
> +share/doc/sccache/DistributedFreeBSD.md
> +share/doc/sccache/DistributedQuickstart.md
> +share/doc/sccache/GHA.md
> +share/doc/sccache/Gcs.md
> +share/doc/sccache/Jenkins.md
> +share/doc/sccache/Local.md
> +share/doc/sccache/Memcached.md
> +share/doc/sccache/OSS.md
> +share/doc/sccache/Redis.md
> +share/doc/sccache/Releasing.md
> +share/doc/sccache/ResponseFiles.md
> +share/doc/sccache/Rust.md
> +share/doc/sccache/S3.md
> +share/doc/sccache/Webdav.md
>
--
Sebastien Marie
Re: Help needed on porting ripgrep-all
A Tammy writes: > Try by adding something like > > MODCARGO_CRATES_KEEP =libsqlite3-sys The purpose of MODCARGO_CRATES_KEEP is "I know what I am doing, I want to compile and use the embedded libsqlite3 version". It is expected to be an opt-in choice to avoid the use of ports tree version. So please don't advice to use it without checking why the embedded version would be required instead of the ports tree version. Thanks. -- Sebastien Marie
Re: rust-{clippy,rustfmt} missing dependency on rust
Matthew Martin writes:
> I'm on a monthish old snapshot. While there's been a bump to libcrypto
> and libssl in the meantime, pkg_add -u usually doesn't break anything.
> On a recent pkg_add -u,
>
>
> Can't install rust-1.81.0 because of libraries
> Direct dependencies for rust-1.80.1->1.81.0 resolve to libssh2-1.11.0
> curl-8.9.1p0
> Full dependency tree is curl-8.9.1p0 libssh2-1.11.0 ngtcp2-1.7.0
> nghttp2-1.63.0 nghttp3-1.5.0
> rust-clippy-1.80.1p0->1.81.0: ok
> rust-rustfmt-1.80.1p0->1.81.0: ok
>
>
> However when attempting to run clippy or rustfmt,
>
>
> ~% /usr/local/bin/clippy-driver
> ld.so: clippy-driver: can't load library 'libstd-02e247769dc17415.so'
> zsh: killed /usr/local/bin/clippy-driver
> ~% /usr/local/bin/rustfmt
> ld.so: rustfmt: can't load library 'librustc_driver-02e247769dc17411.so'
> zsh: killed /usr/local/bin/rustfmt
>
>
> I think this means rust-clippy and rust-rustfmt are missing a dependency
> on rust-main.
Thanks for the report. There is already a dependency but it isn't enough
constrained (it is a dependency on lang/rust,-main and not on the exact
version).
The following diff should fix that.
diff /home/semarie/repos/openbsd/ports/mystuff/lang/rust
commit - ab1a6945b5c16b0b34c1f64b0b0b10b7226f33ed
path + /home/semarie/repos/openbsd/ports/mystuff/lang/rust
blob - 0bdeb56edbb274d02a471b63e1a88fb4171f5e1f
file + Makefile
--- Makefile
+++ Makefile
@@ -17,6 +17,10 @@ COMMENT-src =Rust source component
V =1.81.0
DISTNAME = rustc-${V}-src
+REVISION-gdb = 0
+REVISION-clippy = 0
+REVISION-rustfmt = 0
+REVISION-src = 0
# rustc bootstrap version
BV-aarch64 = 1.80.1
@@ -155,15 +159,15 @@ LIB_DEPENDS-main += ${LIB_DEPENDS} \
net/curl \
security/libssh2
-RUN_DEPENDS-gdb += lang/rust,-main \
+RUN_DEPENDS-gdb += ${FULLPKGNAME-main}:${FULLPKGPATH-main} \
devel/gdb
# BUILD_LLDB is defined by /usr/share/mk/bsd.own.mk
.if ${BUILD_LLDB:L} == yes
RUN_DEPENDS-gdb += devel/llvm/17,-lldb
.endif
-RUN_DEPENDS-clippy += lang/rust,-main
-RUN_DEPENDS-rustfmt += lang/rust,-main
-RUN_DEPENDS-src += lang/rust,-main
+RUN_DEPENDS-clippy += ${FULLPKGNAME-main}:${FULLPKGPATH-main}
+RUN_DEPENDS-rustfmt += ${FULLPKGNAME-main}:${FULLPKGPATH-main}
+RUN_DEPENDS-src += ${FULLPKGNAME-main}:${FULLPKGPATH-main}
PKG_ARCH-src = *
Comments or OK ?
--
Sebastien Marie
new: editors/jmigpin-editor
Hi, I would like to import the attached port to editors/jmigpin-editor. The project (and the binary) is just 'editor' by it seems a bit too generic for the ports tree. So the PKGNAME is set to jmigpin-editor. I kept 'editor' for the binary as there is no conflict. https://github.com/jmigpin/editor jmigpin-editor is a graphical source code editor in pure Go, inspired by acme (from plan9). >From pkg/DESCR: This is a simple but advanced source code editor As the editor is being developed, the rules of how the UI interacts will become more well defined. - Auto-indentation of wrapped lines. - No code coloring (except comments and strings). - Many TextArea utilities: undo/redo, replace, comment, ... - Handles big files. - Start external processes from the toolbar with a click, capturing the output to a row. - Drag and drop files/directories to the editor. - Detects if files opened are changed outside the editor. - Plugin support - examples such as `gotodefinition` and `autocomplete`. - Golang specific: - Calls goimports if available when saving a .go file. - Clicking on `.go` files identifiers will jump to the identifier definition (needs `gopls`). - Debug utility for go programs (`GoDebug` cmd). - allows to go back and forth in time to consult code values. - Language Server Protocol (LSP) (code analysis): - `-lsproto` cmd line option - basic support for gotodefinition and completion - mostly being tested with `clangd` and `gopls` - Inline complete - code completion by hitting the `tab` key (uses LSP). Comments or OK ? -- Sebastien Marie jmigpin-editor.tgz Description: Binary data
new: www/caddy
Hi, The attached tarball contains a port for caddy server (https://caddyserver.com/). Caddy is most often used as an HTTPS server, but it is suitable for any long-running Go program. First and foremost, it is a platform to run Go applications. Caddy "apps" are just Go programs that are implemented as Caddy modules. Two apps -- tls and http -- ship standard with Caddy. Caddy apps instantly benefit from automated documentation, graceful on-line config changes via API, and unification with other Caddy apps. Although JSON is Caddy's native config language, Caddy can accept input from config adapters which can essentially convert any config format of your choice into JSON: Caddyfile, JSON 5, YAML, TOML, NGINX config, and more. The primary way to configure Caddy is through its API, but if you prefer config files, the command-line interface supports those too. Caddy exposes an unprecedented level of control compared to any web server in existence. In Caddy, you are usually setting the actual values of the initialized types in memory that power everything from your HTTP handlers and TLS handshakes to your storage medium. Caddy is also ridiculously extensible, with a powerful plugin system that makes vast improvements over other web servers. To wield the power of this design, you need to know how the config document is structured. Please see our documentation site for details about Caddy's config structure. Nearly all of Caddy's configuration is contained in a single config document, rather than being scattered across CLI flags and env variables and a configuration file as with other web servers. This makes managing your server config more straightforward and reduces hidden variables/factors. It reuses uid/gid 524 (from 2016). diff /home/semarie/repos/openbsd/ports commit - a4d48766a296eeb3f8ed9992966d7d7a1fd4612e path + /home/semarie/repos/openbsd/ports blob - 5104415dc091f405d9c26b9c73d49c1d2e7be77e file + infrastructure/db/user.list --- infrastructure/db/user.list +++ infrastructure/db/user.list @@ -32,7 +32,7 @@ id user group port 521 _exim _exim mail/exim 522 _unboundexporter sysutils/unbound_exporter 523 _ffproxy _ffproxywww/ffproxy -#524 _mail mail/openwebmail +524 _caddy _caddy www/caddy 525 _quagga_quagga net/quagga 526 _tomcat_tomcat www/tomcat 527 _milter-regex _milter-regex mail/milter-regex Comments or OK to import ? -- Sebastien Marie caddy.tgz Description: Binary data
Re: [new] sysutils/unbound_exporter
Pascal Stumpf writes: > This simple Prometheus metrics exporter for the Unbound DNS resolver > connects to Unbound's TLS control socket and sends the stats_noreset > command, causing Unbound to return metrics as key-value pairs. The > metrics exporter converts Unbound metric names to Prometheus metric > names and labels by using a set of regular expressions. > > This reuses UID 522 from comms/xcept and needs to be run as group > _unbound for access to the control socket. You will want to set > 'extended-statistics: yes' in unbound.conf. > > ok? The port looks good to me. I would just add a note in the port itself about 'extended-statistics: yes' (pkg-readme or maybe simply in DESCR telling it is supported). My build machine is still working, I will provide feedback a bit later. Thanks. -- Sebastien Marie
Re: (maintainer update) lang/ecl-24.5.10
Hi,
Just some comments.
Timo Myyrä writes:
> Hi,
>
> Here's a bit long overdue update for the ECL port.
> Lightly tested on amd64.
>
> timo
>
> diff /usr/ports
> commit - 91c62197c95d894e5fecbb4866735eb37d9ec02a
> path + /usr/ports
> blob - 5d1ff4982781db1ed5fc9dfa5c1fb5c2680b06af
> file + lang/ecl/Makefile
> --- lang/ecl/Makefile
> +++ lang/ecl/Makefile
> @@ -1,9 +1,9 @@
> COMMENT =embeddable common-lisp
> CATEGORIES = lang
>
> -V = 21.2.1
> +V = 24.5.10
> DISTNAME = ecl-$V
> -SHARED_LIBS += ecl 8.0
> +SHARED_LIBS += ecl 9.0
>
> REVISION = 0
REVISION should be removed
And the regress doesn't work anymore: ecl use explicitly /bin/bash for
testing.
So I also have:
-TEST_DEPENDS = ${BASE_PKGPATH}
+TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH} \
+ shells/bash
And a patch for src/tests/Makefile.in
blob - /dev/null
file + lang/ecl/patches/patch-src_tests_Makefile_in (mode 644)
--- /dev/null
+++ lang/ecl/patches/patch-src_tests_Makefile_in
@@ -0,0 +1,12 @@
+Index: src/tests/Makefile.in
+--- src/tests/Makefile.in.orig
src/tests/Makefile.in
+@@ -2,7 +2,7 @@
+ # vim: set filetype=makefile tabstop=8 shiftwidth=4 expandtab:
+
+ ECL=@prefix@/@bindir@/ecl@EXEEXT@
+-SHELL=/bin/bash -o pipefail
++SHELL=bash -o pipefail
+
+ .PHONY: all check ansi-test
+
Thanks.
--
Sebastien Marie
Re: BROKEN: x11/stumpwm XLIB Meta_L breakage. (fails to start session)
izzy Meyer writes: > On Tue, 30 Jul 2024 18:16:23 +0200 > Matthieu Herrb wrote: > >> >> Hi, >> >> Do you know the date / version of your previous (working) snapshot? >> > > Not entirely sure on date/version, but I know I ran last a sysupgrade > two days ago. Things were fine then. No major breakage. Normally, you have it in /var/log/messages (or /var/log/messages.0.gz) $ grep sysupgrade /var/log/messages Jul 29 16:17:33 quade sysupgrade: installed new /bsd.upgrade. Old kernel version: OpenBSD 7.5-current (GENERIC.MP) #202: Sat Jul 20 13:30:37 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I would be interested to know your current version of stumpwm: $ pkg_info -q | grep stumpwm and if it was another version previously: $ grep 'pkg_add:.*stumpwm' /var/log/messages $ zgrep 'pkg_add:.*stumpwm' /var/log/messages.0.gz sbcl was updated recently (and so stumpwm too). Thanks. -- Sebastien Marie
textproc/delta: time crate update for upcoming lang/rust
Hi,
The following diff updates time crate to 0.3.36 (and dependencies). It
is required for lang/rust 1.80.0
Comments or OK ?
--
Sebastien Marie
Index: Makefile
===
RCS file: /cvs/ports/textproc/delta/Makefile,v
diff -u -p -r1.18 Makefile
--- Makefile4 May 2024 09:26:32 - 1.18
+++ Makefile28 Jul 2024 12:25:49 -
@@ -3,7 +3,7 @@ COMMENT = viewer for git and diff outpu
GH_ACCOUNT = dandavison
GH_PROJECT = delta
GH_TAGNAME = 0.17.0
-REVISION = 0
+REVISION = 1
CATEGORIES = textproc
@@ -18,6 +18,11 @@ COMPILER = base-clang ports-gcc
WANTLIB += ${MODCARGO_WANTLIB} m git2 onig
MODULES = devel/cargo
+
+MODCARGO_CRATES_UPDATE += time
+MODCARGO_CRATES += time0.3.36
+MODCARGO_CRATES += time-macros 0.2.18
+MODCARGO_CRATES += num-conv0.1.0
LIB_DEPENDS += devel/libgit2/libgit2 \
textproc/oniguruma
Index: distinfo
===
RCS file: /cvs/ports/textproc/delta/distinfo,v
diff -u -p -r1.12 distinfo
--- distinfo29 Apr 2024 17:10:28 - 1.12
+++ distinfo28 Jul 2024 12:25:49 -
@@ -83,6 +83,7 @@ SHA256 (cargo/mio-0.8.11.tar.gz) = pKZQV
SHA256 (cargo/nix-0.27.1.tar.gz) = LrBOnGiO/xyJ1ytAfxaM95u56Gep0zI+1sAVGeucwFM=
SHA256 (cargo/ntapi-0.4.1.tar.gz) =
6KOJXGORw51/5+vERKh+spkbKgvHGP2r0HHuxhf8aOQ=
SHA256 (cargo/nu-ansi-term-0.49.0.tar.gz) =
wHPTwZMNB1F3Ss9J5mZTrOy0FsOlTG7AlamxHK3bWmg=
+SHA256 (cargo/num-conv-0.1.0.tar.gz) =
UdUV0y+xgu43zaLM3LkpUNajwok6ooDlQGccLNDzsdk=
SHA256 (cargo/num-traits-0.2.17.tar.gz) =
OeMgBBPyN/QasRrW0WG8cjnITctjF3PM1949/ktcJnw=
SHA256 (cargo/once_cell-1.19.0.tar.gz) =
P9sSskdrWV+TWMUWGqRnwkOIWcqhNt7IbCb90u/he5I=
SHA256 (cargo/onig-6.4.0.tar.gz) = jEsxyHIq2RccbXfTVX2weMqyvVCvzJ0JyLMVxZ34yk8=
@@ -136,8 +137,10 @@ SHA256 (cargo/terminal_size-0.3.0.tar.gz
SHA256 (cargo/thiserror-1.0.56.tar.gz) =
1UN4xkVidhMkHQd6Onnbll22AogmaPkTasQq+ey3MK0=
SHA256 (cargo/thiserror-impl-1.0.56.tar.gz) =
+g+qlDtQ89swogqn4mXbxmB2mT7+2EY+jeQU5dBtNHE=
SHA256 (cargo/time-0.3.31.tar.gz) =
9le6QsP4bnaA5TyM06+Ku+VrVJF5C0biLhnA1XRjWD4=
+SHA256 (cargo/time-0.3.36.tar.gz) =
Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU=
SHA256 (cargo/time-core-0.1.2.tar.gz) =
75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M=
SHA256 (cargo/time-macros-0.2.16.tar.gz) =
Jhl+M0ICRK63DD6MeDdspGVxvE5wHkeRws2fV9yzpD8=
+SHA256 (cargo/time-macros-0.2.18.tar.gz) =
PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8=
SHA256 (cargo/tinyvec-1.6.0.tar.gz) =
h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A=
SHA256 (cargo/tinyvec_macros-0.1.1.tar.gz) =
HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA=
SHA256 (cargo/unicode-bidi-0.3.14.tar.gz) =
byUo8nqesrIeaclTGbML0O/YXQnDeXQbD3jqHYa+JBY=
@@ -277,6 +280,7 @@ SIZE (cargo/mio-0.8.11.tar.gz) = 102983
SIZE (cargo/nix-0.27.1.tar.gz) = 286494
SIZE (cargo/ntapi-0.4.1.tar.gz) = 126552
SIZE (cargo/nu-ansi-term-0.49.0.tar.gz) = 28211
+SIZE (cargo/num-conv-0.1.0.tar.gz) = 7444
SIZE (cargo/num-traits-0.2.17.tar.gz) = 50190
SIZE (cargo/once_cell-1.19.0.tar.gz) = 33046
SIZE (cargo/onig-6.4.0.tar.gz) = 32616
@@ -330,8 +334,10 @@ SIZE (cargo/terminal_size-0.3.0.tar.gz)
SIZE (cargo/thiserror-1.0.56.tar.gz) = 20592
SIZE (cargo/thiserror-impl-1.0.56.tar.gz) = 15367
SIZE (cargo/time-0.3.31.tar.gz) = 121762
+SIZE (cargo/time-0.3.36.tar.gz) = 119805
SIZE (cargo/time-core-0.1.2.tar.gz) = 7191
SIZE (cargo/time-macros-0.2.16.tar.gz) = 24356
+SIZE (cargo/time-macros-0.2.18.tar.gz) = 24361
SIZE (cargo/tinyvec-1.6.0.tar.gz) = 45991
SIZE (cargo/tinyvec_macros-0.1.1.tar.gz) = 5865
SIZE (cargo/unicode-bidi-0.3.14.tar.gz) = 56429
x11/gnome/librsvg: time crate update for upcoming lang/rust
Hi,
The following diff updates time crate to 0.3.36 (and dependencies). It
is required for lang/rust 1.80.0
Comments or OK ?
--
Sebastien Marie
Index: Makefile
===
RCS file: /cvs/ports/x11/gnome/librsvg/Makefile,v
diff -u -p -r1.227 Makefile
--- Makefile13 Jul 2024 08:06:15 - 1.227
+++ Makefile28 Jul 2024 12:18:48 -
@@ -19,6 +19,7 @@ DEBUG_PACKAGES= ${BUILD_PACKAGES}
### stable
.if ${PROPERTIES:Mrust}
+REVISION = 0
SHARED_LIBS += rsvg-2 41.0 # 52.0
GNOME_VERSION= ${STABLE_VERSION}
MODULES += devel/cargo \
@@ -32,6 +33,10 @@ PKG_ARGS=-Dold=0 -Dstable=1
MAKE_ENV +=${MODCARGO_ENV}
MAKE_FLAGS += V=1
WANTLIB += ${MODCARGO_WANTLIB} ${COMPILER_LIBCXX} Xau Xdmcp cairo-gobject jpeg
+
+MODCARGO_CRATES_UPDATE += time
+MODCARGO_CRATES += time0.3.36
+MODCARGO_CRATES += time-macros 0.2.18
.else
### old
REVISION= 6
Index: distinfo
===
RCS file: /cvs/ports/x11/gnome/librsvg/distinfo,v
diff -u -p -r1.120 distinfo
--- distinfo13 Jul 2024 08:06:15 - 1.120
+++ distinfo28 Jul 2024 12:18:49 -
@@ -223,8 +223,10 @@ SHA256 (gnome/../cargo/thiserror-1.0.56.
SHA256 (gnome/../cargo/thiserror-impl-1.0.56.tar.gz) =
+g+qlDtQ89swogqn4mXbxmB2mT7+2EY+jeQU5dBtNHE=
SHA256 (gnome/../cargo/tiff-0.9.1.tar.gz) =
uhMQ/OpUxqmk/RqteU7MAsMWgva/vs30YL8ZUz7tHj4=
SHA256 (gnome/../cargo/time-0.3.34.tar.gz) =
yCSLZSG7FLxFtAZxWbm2rXkuLW11TWxB+1Din+/jh0k=
+SHA256 (gnome/../cargo/time-0.3.36.tar.gz) =
Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU=
SHA256 (gnome/../cargo/time-core-0.1.2.tar.gz) =
75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M=
SHA256 (gnome/../cargo/time-macros-0.2.17.tar.gz) =
e6Oj70HmZyovDwATkrtdzT/wqZktYYynYaEcMSFUd3Q=
+SHA256 (gnome/../cargo/time-macros-0.2.18.tar.gz) =
PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8=
SHA256 (gnome/../cargo/tinytemplate-1.2.1.tar.gz) =
vk1rXxn/dmToyY0D4hOctRDbmwpgtV+Ohwm2idk5trw=
SHA256 (gnome/../cargo/tinyvec-1.6.0.tar.gz) =
h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A=
SHA256 (gnome/../cargo/tinyvec_macros-0.1.1.tar.gz) =
HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA=
@@ -506,8 +508,10 @@ SIZE (gnome/../cargo/thiserror-1.0.56.ta
SIZE (gnome/../cargo/thiserror-impl-1.0.56.tar.gz) = 15367
SIZE (gnome/../cargo/tiff-0.9.1.tar.gz) = 1423953
SIZE (gnome/../cargo/time-0.3.34.tar.gz) = 118430
+SIZE (gnome/../cargo/time-0.3.36.tar.gz) = 119805
SIZE (gnome/../cargo/time-core-0.1.2.tar.gz) = 7191
SIZE (gnome/../cargo/time-macros-0.2.17.tar.gz) = 24443
+SIZE (gnome/../cargo/time-macros-0.2.18.tar.gz) = 24361
SIZE (gnome/../cargo/tinytemplate-1.2.1.tar.gz) = 26490
SIZE (gnome/../cargo/tinyvec-1.6.0.tar.gz) = 45991
SIZE (gnome/../cargo/tinyvec_macros-0.1.1.tar.gz) = 5865
www/zola: time crate update for upcoming lang/rust
Hi, The following diff updates time crate to 0.3.36 (and dependencies). It is required for lang/rust 1.80.0 Comments or OK ? -- Sebastien Marie Index: Makefile === RCS file: /cvs/ports/www/zola/Makefile,v diff -u -p -r1.18 Makefile --- Makefile29 Dec 2023 16:13:59 - 1.18 +++ Makefile28 Jul 2024 12:16:42 - @@ -22,6 +22,11 @@ LIB_DEPENDS += textproc/oniguruma MODULES = devel/cargo +MODCARGO_CRATES_UPDATE += time +MODCARGO_CRATES += time0.3.36 +MODCARGO_CRATES += time-macros 0.2.18 +MODCARGO_CRATES += num-conv0.1.0 + CONFIGURE_STYLE = cargo SEPARATE_BUILD = Yes Index: distinfo === RCS file: /cvs/ports/www/zola/distinfo,v diff -u -p -r1.5 distinfo --- distinfo29 Dec 2023 16:13:59 - 1.5 +++ distinfo28 Jul 2024 12:16:43 - @@ -221,6 +221,7 @@ SHA256 (cargo/nom-tracable-0.9.0.tar.gz) SHA256 (cargo/nom-tracable-macros-0.9.0.tar.gz) = p6xoHqDD1GiwA73r46ZdFjLjQDAkUvlcP/rfUVcExI0= SHA256 (cargo/nom_locate-4.2.0.tar.gz) = HjyDwFOwcT2mDFuN5H/o5JT+Ps5SZ7LyMJCgegU7qPM= SHA256 (cargo/notify-4.0.17.tar.gz) = rgPIyFPbp7/SPlcf8M/3vJ3OtApM1oTNFoGCQYP0Ulc= +SHA256 (cargo/num-conv-0.1.0.tar.gz) = UdUV0y+xgu43zaLM3LkpUNajwok6ooDlQGccLNDzsdk= SHA256 (cargo/num-format-0.4.4.tar.gz) = plLZdxpjcR/Tw962cKz75cMKQHLmZNejv1qeEFascsM= SHA256 (cargo/num-integer-0.1.45.tar.gz) = Il0zifs1CaJMk/XCnra94lhrmNnwFmNt/1jXxvdWnNk= SHA256 (cargo/num-rational-0.4.1.tar.gz) = BjihydCjwJFBWBRbx2z/Nzp1pifm7L+3HL5vRTpaGbA= @@ -353,8 +354,10 @@ SHA256 (cargo/thiserror-1.0.51.tar.gz) = SHA256 (cargo/thiserror-impl-1.0.51.tar.gz) = AXQil3h1E7ec+OKdEFbt4TE+JCC3s7FdCnaLSSH1Sd8= SHA256 (cargo/tiff-0.9.0.tar.gz) = bRcrD00/uhe6iYEYWLnT2X+SiuzoRkdbvaB2ykZzYhE= SHA256 (cargo/time-0.3.30.tar.gz) = xKNKswDy3ublYsEKBG/AXjWLKfm/kid/MMPI2CJ19vU= +SHA256 (cargo/time-0.3.36.tar.gz) = Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU= SHA256 (cargo/time-core-0.1.2.tar.gz) = 75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M= SHA256 (cargo/time-macros-0.2.15.tar.gz) = StcNaNup4fis7aeqZxGWXf7Byshp8xGlG9CLOizLziA= +SHA256 (cargo/time-macros-0.2.18.tar.gz) = PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8= SHA256 (cargo/tinystr-0.7.5.tar.gz) = g8Ar88U4qzK6kTQIIkMjkV9O+abWHA6F1JPzVZIcDs4= SHA256 (cargo/tinyvec-1.6.0.tar.gz) = h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A= SHA256 (cargo/tinyvec_macros-0.1.1.tar.gz) = HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA= @@ -676,6 +679,7 @@ SIZE (cargo/nom-tracable-0.9.0.tar.gz) = SIZE (cargo/nom-tracable-macros-0.9.0.tar.gz) = 1544 SIZE (cargo/nom_locate-4.2.0.tar.gz) = 19013 SIZE (cargo/notify-4.0.17.tar.gz) = 54419 +SIZE (cargo/num-conv-0.1.0.tar.gz) = 7444 SIZE (cargo/num-format-0.4.4.tar.gz) = 61509 SIZE (cargo/num-integer-0.1.45.tar.gz) = 22529 SIZE (cargo/num-rational-0.4.1.tar.gz) = 27889 @@ -808,8 +812,10 @@ SIZE (cargo/thiserror-1.0.51.tar.gz) = 2 SIZE (cargo/thiserror-impl-1.0.51.tar.gz) = 15372 SIZE (cargo/tiff-0.9.0.tar.gz) = 1418215 SIZE (cargo/time-0.3.30.tar.gz) = 120289 +SIZE (cargo/time-0.3.36.tar.gz) = 119805 SIZE (cargo/time-core-0.1.2.tar.gz) = 7191 SIZE (cargo/time-macros-0.2.15.tar.gz) = 23568 +SIZE (cargo/time-macros-0.2.18.tar.gz) = 24361 SIZE (cargo/tinystr-0.7.5.tar.gz) = 16366 SIZE (cargo/tinyvec-1.6.0.tar.gz) = 45991 SIZE (cargo/tinyvec_macros-0.1.1.tar.gz) = 5865
sysutils/rustic: time crate update for upcoming lang/rust
Hi,
The following diff updates time crate to 0.3.36 (and dependencies). It
is required for lang/rust 1.80.0
Comments or OK ?
--
Sebastien Marie
diff /data/semarie/repos/openbsd/ports
commit - 50e60d3f44a62b83d566d19d5dd1424e798b73a0
path + /data/semarie/repos/openbsd/ports
blob - 33609200087578a745a8d117f00a83b5263aaebe
file + sysutils/rustic/Makefile
--- sysutils/rustic/Makefile
+++ sysutils/rustic/Makefile
@@ -4,6 +4,7 @@ NOT_FOR_ARCHS = sparc64
COMMENT = fast, encrypted, deduplicated backups
DIST_TUPLE = github rustic-rs rustic v0.7.0 .
+REVISION = 0
CATEGORIES = sysutils
@@ -17,6 +18,10 @@ WANTLIB += ${MODCARGO_WANTLIB} m zstd
MODULES = devel/cargo
MODCARGO_RUSTFLAGS = -L${PREFIX}/lib
+MODCARGO_CRATES_UPDATE += time
+MODCARGO_CRATES += time0.3.36
+MODCARGO_CRATES += time-macros 0.2.18
+
LIB_DEPENDS = archivers/zstd
CONFIGURE_STYLE = cargo
blob - 3c357fa81357a851f166310e77af094ec56e9a2b
file + sysutils/rustic/distinfo
--- sysutils/rustic/distinfo
+++ sysutils/rustic/distinfo
@@ -352,8 +352,10 @@ SHA256 (cargo/thiserror-1.0.56.tar.gz) = 1UN4xkVidhMkH
SHA256 (cargo/thiserror-impl-1.0.56.tar.gz) =
+g+qlDtQ89swogqn4mXbxmB2mT7+2EY+jeQU5dBtNHE=
SHA256 (cargo/thread_local-1.1.7.tar.gz) =
P91vBkzP8tZWetyzhzymMHAPALWtPwYMJbXc/ZpM4VI=
SHA256 (cargo/time-0.3.33.tar.gz) =
ALJLebegfxAgnxnmg8oeKJ2Asedv+owrd5cYVmoINnk=
+SHA256 (cargo/time-0.3.36.tar.gz) =
Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU=
SHA256 (cargo/time-core-0.1.2.tar.gz) =
75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M=
SHA256 (cargo/time-macros-0.2.17.tar.gz) =
e6Oj70HmZyovDwATkrtdzT/wqZktYYynYaEcMSFUd3Q=
+SHA256 (cargo/time-macros-0.2.18.tar.gz) =
PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8=
SHA256 (cargo/tiny-keccak-2.0.2.tar.gz) =
LJ03k0AKRflUxS5z0GgxbXa29ONpd+P867E6JyHoAjc=
SHA256 (cargo/tinyvec-1.6.0.tar.gz) =
h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A=
SHA256 (cargo/tinyvec_macros-0.1.1.tar.gz) =
HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA=
@@ -801,8 +803,10 @@ SIZE (cargo/thiserror-1.0.56.tar.gz) = 20592
SIZE (cargo/thiserror-impl-1.0.56.tar.gz) = 15367
SIZE (cargo/thread_local-1.1.7.tar.gz) = 13585
SIZE (cargo/time-0.3.33.tar.gz) = 118429
+SIZE (cargo/time-0.3.36.tar.gz) = 119805
SIZE (cargo/time-core-0.1.2.tar.gz) = 7191
SIZE (cargo/time-macros-0.2.17.tar.gz) = 24443
+SIZE (cargo/time-macros-0.2.18.tar.gz) = 24361
SIZE (cargo/tiny-keccak-2.0.2.tar.gz) = 20129
SIZE (cargo/tinyvec-1.6.0.tar.gz) = 45991
SIZE (cargo/tinyvec_macros-0.1.1.tar.gz) = 5865
security/sn0int: time crate update for upcoming lang/rust
Hi, The following diff updates time crate to 0.3.36 (and dependencies). It is required for lang/rust 1.80.0 Comments or OK ? -- Sebastien Marie diff /data/semarie/repos/openbsd/ports commit - 50e60d3f44a62b83d566d19d5dd1424e798b73a0 path + /data/semarie/repos/openbsd/ports blob - 9cad78815231e19ccb5d1245ba4c0934f16fef8c file + security/sn0int/Makefile --- security/sn0int/Makefile +++ security/sn0int/Makefile @@ -8,6 +8,7 @@ COMMENT = semi-automatic OSINT framework and package m GH_ACCOUNT = kpcyrd GH_PROJECT = sn0int GH_TAGNAME = v0.26.0 +REVISION = 0 CATEGORIES = security @@ -30,6 +31,14 @@ BUILD_DEPENDS = security/rust-ring \ RUN_DEPENDS = net/libmaxminddb,-asn \ net/libmaxminddb,-city +MODCARGO_CRATES_UPDATE += time@0.3.28 +MODCARGO_CRATES += time0.3.36 +MODCARGO_CRATES += time-core 0.1.2 +MODCARGO_CRATES += time-macros 0.2.18 +MODCARGO_CRATES += deranged0.3.9 +MODCARGO_CRATES += num-conv0.1.0 +MODCARGO_CRATES += powerfmt0.2.0 + .include "crates.inc" CONFIGURE_STYLE = cargo blob - 20a7604b405fa0fcc9b3f2aff2d5685b9e9382fd file + security/sn0int/distinfo --- security/sn0int/distinfo +++ security/sn0int/distinfo @@ -105,6 +105,7 @@ SHA256 (cargo/deflate-0.8.6.tar.gz) = c3cPjh/n1k3xfKZq SHA256 (cargo/der-parser-7.0.0.tar.gz) = /jmKx1BXkU19BzB79n3H8/V0omeDtPx4BaIP+p9QboI= SHA256 (cargo/der-parser-8.2.0.tar.gz) = 29Z2+7q1NxKO8CeK21V2zzY8/2qiKnsk7/6XNHz6th4= SHA256 (cargo/deranged-0.3.8.tar.gz) = 8mluipRfZY/RTcO4ckLmuAzQ82/wTqVg+jkII2iEeUY= +SHA256 (cargo/deranged-0.3.9.tar.gz) = DzLQSSLGBCfab5/vFNBC2e3d72TLnUzg1k0GhfvrH9M= SHA256 (cargo/derive_more-0.99.17.tar.gz) = T7gQ0wp8GVP5EzTeckRzH8PzwQ1/4WMzijW59kCWAyE= SHA256 (cargo/devise-0.2.1.tar.gz) = 3XFsSlB63Foqp8KjctBsdJdyfgiSskPTA2vHR4oT5SY= SHA256 (cargo/devise_codegen-0.2.1.tar.gz) = 6nuCkNEYEnwI42adogszG+1WsJ8gvllFt9psEW2Pq1M= @@ -281,6 +282,7 @@ SHA256 (cargo/notify-4.0.17.tar.gz) = rgPIyFPbp7/SPlcf SHA256 (cargo/nude-0.3.0.tar.gz) = Ypv4TzH3ZbpIBYNxxus8Xu0PzexouBTrEfb2XewK2+M= SHA256 (cargo/num-bigint-0.4.4.tar.gz) = YI52WbXD18uiYtiUgBueydAN6YnoqCvUvvkdCNpFzcA= SHA256 (cargo/num-complex-0.2.4.tar.gz) = trGUEalxnnU6/xLlGHt01g09xEnsP03CHjmJw/VUvJU= +SHA256 (cargo/num-conv-0.1.0.tar.gz) = UdUV0y+xgu43zaLM3LkpUNajwok6ooDlQGccLNDzsdk= SHA256 (cargo/num-integer-0.1.45.tar.gz) = Il0zifs1CaJMk/XCnra94lhrmNnwFmNt/1jXxvdWnNk= SHA256 (cargo/num-iter-0.1.43.tar.gz) = fQPmwCjF3Fysbi3sDv2oH8iHYFuz2IRXi7bWv3UU4lI= SHA256 (cargo/num-rational-0.3.2.tar.gz) = EqxCixyxf85vcxAB0wfTUexwptIC/C5g99TF5C2PTwc= @@ -328,6 +330,7 @@ SHA256 (cargo/pledge-0.4.2.tar.gz) = JSWZQXt9mkO3/cY91 SHA256 (cargo/plist-0.4.2.tar.gz) = XyqfB19jlBAOfBBe0a9z+xhZ1v0U5J1CkNV4EgvrFn8= SHA256 (cargo/plist-1.5.0.tar.gz) = vcAAHP6j21ei4kvA2Bjp4g5VS1+X+rubwjHcJAJprgY= SHA256 (cargo/png-0.16.8.tar.gz) = PDKHkgy4R97j3jPTAcRj+6FN2pnbJCFN35P4PTAh9MY= +SHA256 (cargo/powerfmt-0.2.0.tar.gz) = Q57jBd7xFboFk4226xZE/5QWXFq16UINHBvO27qQk5E= SHA256 (cargo/ppv-lite86-0.2.17.tar.gz) = W0CvgFsxIf6rijwp8E2K0mL6jgVhiD52U+AkrkR55t4= SHA256 (cargo/pq-sys-0.4.8.tar.gz) = McAFJCbfmXwMvTB4nrRMoJfjVBcXp7j6NrHEZO5+3r0= SHA256 (cargo/precomputed-hash-0.1.1.tar.gz) = klOD76NGcwR4+0g42+kTfSpHZ1rXicVG0VCm4d1Ksxw= @@ -476,8 +479,11 @@ SHA256 (cargo/threadpool-1.8.1.tar.gz) = 0FDmCzPUHBkQi SHA256 (cargo/tiff-0.6.1.tar.gz) = mlP0cG1lSX3wxDSSQd7d81+EzuGch+2G6oylkPRGRDc= SHA256 (cargo/time-0.1.45.tar.gz) = G3l6+tPzEtHGalbRHQMW+RY1bRG9FY+8bKY4n/a/gFo= SHA256 (cargo/time-0.3.28.tar.gz) = F/a7VX/SRcKOZBGqVrZAPGia2VBh9Q5L4WwnTnChfkg= +SHA256 (cargo/time-0.3.36.tar.gz) = Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU= SHA256 (cargo/time-core-0.1.1.tar.gz) = cwD777Ta3BryNanO83N86mkqnZfhucvNTr2ub4ho5vs= +SHA256 (cargo/time-core-0.1.2.tar.gz) = 75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M= SHA256 (cargo/time-macros-0.2.14.tar.gz) = GpQvRDOUeO9nk1qyu67C+wMiSWzzy+hLJh4GrDgUxXI= +SHA256 (cargo/time-macros-0.2.18.tar.gz) = PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8= SHA256 (cargo/tinyvec-1.6.0.tar.gz) = h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A= SHA256 (cargo/tinyvec_macros-0.1.1.tar.gz) = HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA= SHA256 (cargo/tokio-0.1.22.tar.gz) = WgnAtbtYiHKrLwmvoT7m6drBHhCg7J6OO6OaWl1TCvY= @@ -681,6 +687,7 @@ SIZE (cargo/deflate-0.8.6.tar.gz) = 62365 SIZE (cargo/der-parser-7.0.0.tar.gz) = 62990 SIZE (cargo/der-parser-8.2.0.tar.gz) = 63495 SIZE (cargo/deranged-0.3.8.tar.gz) = 15314 +SIZE (cargo/deranged-0.3.9.tar.gz) = 17080 SIZE (cargo/derive_more-0.99.17.tar.gz) = 55771 SIZE (cargo/devise-0.2.1.tar.gz) = 918 SIZE (cargo/devise_codegen-0.2.1.tar.gz) = 2339 @@ -857,6 +864,7 @@ SIZE (cargo/notify-4.0.17.tar.gz) = 54419 SIZE (cargo/nude-0.3.0.tar.gz) = 416105 SIZE (cargo/num-bigint-0.4.4.tar.gz) = 99369 SIZE (cargo/num-complex-0.2.4.tar.gz) = 24679 +SIZE (cargo/num-conv-0.1.0.tar.gz) = 7444 S
security/pizauth: time crate update for upcoming lang/rust
Hi,
The following diff updates time crate to 0.3.36 (and dependencies). It
is required for lang/rust 1.80.0
Comments or OK ?
--
Sebastien Marie
diff /data/semarie/repos/openbsd/ports
commit - 50e60d3f44a62b83d566d19d5dd1424e798b73a0
path + /data/semarie/repos/openbsd/ports
blob - 702c1b041319b182c30afc384b5a59e9c50e34ae
file + security/pizauth/Makefile
--- security/pizauth/Makefile
+++ security/pizauth/Makefile
@@ -5,6 +5,7 @@ COMMENT = OAuth2 authentication daemon
V =1.0.4
DISTNAME = pizauth-$V
+REVISION = 0
CATEGORIES = mail security
@@ -22,6 +23,11 @@ WANTLIB += ${MODCARGO_WANTLIB} m
DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
MODULES = devel/cargo
+MODCARGO_CRATES_UPDATE += time
+MODCARGO_CRATES += time0.3.36
+MODCARGO_CRATES += time-macros 0.2.18
+MODCARGO_CRATES += num-conv0.1.0
+
CONFIGURE_STYLE = cargo
SEPARATE_BUILD = Yes
blob - ae4ad6c113cba63c9452e64729c4832a265a8173
file + security/pizauth/distinfo
--- security/pizauth/distinfo
+++ security/pizauth/distinfo
@@ -61,6 +61,7 @@ SHA256 (cargo/match_cfg-0.1.0.tar.gz) = /77oY04NRdJYrL
SHA256 (cargo/memchr-2.7.1.tar.gz) =
Uj3E9RHlWrh7aU3DDQ+CDWCQbvBkE/k9TXoThVmcwUk=
SHA256 (cargo/miniz_oxide-0.7.1.tar.gz) =
54EOC+VbQoraQQQcQfMsnxpCgXkBtMz0X6PUtlYedMc=
SHA256 (cargo/nix-0.27.1.tar.gz) = LrBOnGiO/xyJ1ytAfxaM95u56Gep0zI+1sAVGeucwFM=
+SHA256 (cargo/num-conv-0.1.0.tar.gz) =
UdUV0y+xgu43zaLM3LkpUNajwok6ooDlQGccLNDzsdk=
SHA256 (cargo/num-traits-0.2.17.tar.gz) =
OeMgBBPyN/QasRrW0WG8cjnITctjF3PM1949/ktcJnw=
SHA256 (cargo/num_threads-0.1.6.tar.gz) =
KBnOBB0u4TEDb0/J1q564SWjpA6XumTQT+eZrZ2ru0Q=
SHA256 (cargo/once_cell-1.19.0.tar.gz) =
P9sSskdrWV+TWMUWGqRnwkOIWcqhNt7IbCb90u/he5I=
@@ -105,8 +106,10 @@ SHA256 (cargo/syslog-6.1.0.tar.gz) = dDTpW8zM4SFdMPS/h
SHA256 (cargo/termcolor-1.1.3.tar.gz) =
urJNMLkRsjdvOhPMLNRDFC8Mgd2gTBGGk+NbODV1d1U=
SHA256 (cargo/thread_local-1.1.7.tar.gz) =
P91vBkzP8tZWetyzhzymMHAPALWtPwYMJbXc/ZpM4VI=
SHA256 (cargo/time-0.3.31.tar.gz) =
9le6QsP4bnaA5TyM06+Ku+VrVJF5C0biLhnA1XRjWD4=
+SHA256 (cargo/time-0.3.36.tar.gz) =
Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU=
SHA256 (cargo/time-core-0.1.2.tar.gz) =
75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M=
SHA256 (cargo/time-macros-0.2.16.tar.gz) =
Jhl+M0ICRK63DD6MeDdspGVxvE5wHkeRws2fV9yzpD8=
+SHA256 (cargo/time-macros-0.2.18.tar.gz) =
PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8=
SHA256 (cargo/tinyvec-1.6.0.tar.gz) =
h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A=
SHA256 (cargo/tinyvec_macros-0.1.1.tar.gz) =
HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA=
SHA256 (cargo/typenum-1.17.0.tar.gz) =
Qv8L8MZrgjjG87V43zfQt4SOVd+Fd7P3T5KmmszuuCU=
@@ -220,6 +223,7 @@ SIZE (cargo/match_cfg-0.1.0.tar.gz) = 7153
SIZE (cargo/memchr-2.7.1.tar.gz) = 96307
SIZE (cargo/miniz_oxide-0.7.1.tar.gz) = 55194
SIZE (cargo/nix-0.27.1.tar.gz) = 286494
+SIZE (cargo/num-conv-0.1.0.tar.gz) = 7444
SIZE (cargo/num-traits-0.2.17.tar.gz) = 50190
SIZE (cargo/num_threads-0.1.6.tar.gz) = 7334
SIZE (cargo/once_cell-1.19.0.tar.gz) = 33046
@@ -264,8 +268,10 @@ SIZE (cargo/syslog-6.1.0.tar.gz) = 1
SIZE (cargo/termcolor-1.1.3.tar.gz) = 17242
SIZE (cargo/thread_local-1.1.7.tar.gz) = 13585
SIZE (cargo/time-0.3.31.tar.gz) = 121762
+SIZE (cargo/time-0.3.36.tar.gz) = 119805
SIZE (cargo/time-core-0.1.2.tar.gz) = 7191
SIZE (cargo/time-macros-0.2.16.tar.gz) = 24356
+SIZE (cargo/time-macros-0.2.18.tar.gz) = 24361
SIZE (cargo/tinyvec-1.6.0.tar.gz) = 45991
SIZE (cargo/tinyvec_macros-0.1.1.tar.gz) = 5865
SIZE (cargo/typenum-1.17.0.tar.gz) = 42849
lang/gleam: time crate update for upcoming lang/rust
Hi,
The following diff updates time crate to 0.3.36 (and dependencies). It
is required for lang/rust 1.80.0
Comments or OK ?
--
Sebastien Marie
diff /data/semarie/repos/openbsd/ports
commit - 50e60d3f44a62b83d566d19d5dd1424e798b73a0
path + /data/semarie/repos/openbsd/ports
blob - 628c88b883fef88952ce0d33d5d51a4a7df6433e
file + lang/gleam/Makefile
--- lang/gleam/Makefile
+++ lang/gleam/Makefile
@@ -6,6 +6,7 @@ NOT_FOR_ARCHS = sparc64
GH_ACCOUNT = gleam-lang
GH_PROJECT = gleam
GH_TAGNAME = v1.3.2
+REVISION = 0
HOMEPAGE = https://gleam.run
@@ -23,6 +24,10 @@ WANTLIB += ${MODCARGO_WANTLIB} m
CONFIGURE_STYLE = cargo
+MODCARGO_CRATES_UPDATE += time
+MODCARGO_CRATES += time0.3.36
+MODCARGO_CRATES += time-macros 0.2.18
+
post-patch:
${SUBST_CMD} ${WRKSRC}/compiler-core/src/build/package_compiler.rs \
${WRKSRC}/compiler-cli/src/shell.rs \
blob - 9ebf0ebc0121e7a5b1f9523169bc94f90d17118f
file + lang/gleam/distinfo
--- lang/gleam/distinfo
+++ lang/gleam/distinfo
@@ -229,8 +229,10 @@ SHA256 (cargo/thiserror-1.0.59.tar.gz) = 8BJq0Iv/efKfw
SHA256 (cargo/thiserror-impl-1.0.59.tar.gz) =
0c1BO11Vi0xb82gOMkpvpQFOe3wGelHmnb30frcUi2Y=
SHA256 (cargo/thread_local-1.1.8.tar.gz) =
i575utATraOAiFTOrHtGgSpkZbo2iFmjfiEAKD0tcZw=
SHA256 (cargo/time-0.3.34.tar.gz) =
yCSLZSG7FLxFtAZxWbm2rXkuLW11TWxB+1Din+/jh0k=
+SHA256 (cargo/time-0.3.36.tar.gz) =
Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU=
SHA256 (cargo/time-core-0.1.2.tar.gz) =
75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M=
SHA256 (cargo/time-macros-0.2.17.tar.gz) =
e6Oj70HmZyovDwATkrtdzT/wqZktYYynYaEcMSFUd3Q=
+SHA256 (cargo/time-macros-0.2.18.tar.gz) =
PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8=
SHA256 (cargo/tinyvec-1.6.0.tar.gz) =
h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A=
SHA256 (cargo/tinyvec_macros-0.1.1.tar.gz) =
HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA=
SHA256 (cargo/tokio-1.37.0.tar.gz) =
Gtvr/+ynX8/QWK+kgPtsC4HhZaAyP5ydOclpfjfEZ4c=
@@ -537,8 +539,10 @@ SIZE (cargo/thiserror-1.0.59.tar.gz) = 21040
SIZE (cargo/thiserror-impl-1.0.59.tar.gz) = 15726
SIZE (cargo/thread_local-1.1.8.tar.gz) = 13962
SIZE (cargo/time-0.3.34.tar.gz) = 118430
+SIZE (cargo/time-0.3.36.tar.gz) = 119805
SIZE (cargo/time-core-0.1.2.tar.gz) = 7191
SIZE (cargo/time-macros-0.2.17.tar.gz) = 24443
+SIZE (cargo/time-macros-0.2.18.tar.gz) = 24361
SIZE (cargo/tinyvec-1.6.0.tar.gz) = 45991
SIZE (cargo/tinyvec_macros-0.1.1.tar.gz) = 5865
SIZE (cargo/tokio-1.37.0.tar.gz) = 764297
devel/snare: time crate update for upcoming lang/rust
Hi,
The following diff updates time crate to 0.3.36 (and dependencies). It
is required for lang/rust 1.80.0
Comments or OK ?
--
Sebastien Marie
diff /data/semarie/repos/openbsd/ports
commit - 50e60d3f44a62b83d566d19d5dd1424e798b73a0
path + /data/semarie/repos/openbsd/ports
blob - 60536dd624618fafcb4ef0ee85ab39a0c8146eb4
file + devel/snare/Makefile
--- devel/snare/Makefile
+++ devel/snare/Makefile
@@ -2,6 +2,7 @@ COMMENT = GitHub webhooks runner daemon
V =0.4.11
DISTNAME = snare-$V
+REVISION = 0
CATEGORIES = devel
@@ -19,6 +20,11 @@ WANTLIB += ${MODCARGO_WANTLIB} m
DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
MODULES = devel/cargo
+MODCARGO_CRATES_UPDATE += time
+MODCARGO_CRATES += time0.3.36
+MODCARGO_CRATES += time-macros 0.2.18
+MODCARGO_CRATES += num-conv0.1.0
+
CONFIGURE_STYLE = cargo
SEPARATE_BUILD = Yes
blob - 0b1d92f1f10f6f05997eee9441ec607c4fcbbadd
file + devel/snare/distinfo
--- devel/snare/distinfo
+++ devel/snare/distinfo
@@ -47,6 +47,7 @@ SHA256 (cargo/memchr-2.6.4.tar.gz) = 9mXuQLxKPFWQr7HpZ
SHA256 (cargo/memoffset-0.7.1.tar.gz) =
XeiTwyzeXzg7qkwExdbb3XNc/Up5Sw3r2yuxtCHaX/Q=
SHA256 (cargo/memoffset-0.9.0.tar.gz) =
WmNLHGGpVYW9FWB8arDE5bIm5pX/KAC6DNzN3yCMQGw=
SHA256 (cargo/nix-0.26.4.tar.gz) = WYvq88xv3Zpd+xYwwoAMes0x33qvD1ZXlvuitTyhrxs=
+SHA256 (cargo/num-conv-0.1.0.tar.gz) =
UdUV0y+xgu43zaLM3LkpUNajwok6ooDlQGccLNDzsdk=
SHA256 (cargo/num-traits-0.2.17.tar.gz) =
OeMgBBPyN/QasRrW0WG8cjnITctjF3PM1949/ktcJnw=
SHA256 (cargo/num_cpus-1.16.0.tar.gz) =
QWH8ttYC1NIIGvfDpFhS2HWgPdM3pr/dbgZAe2E0KkM=
SHA256 (cargo/num_threads-0.1.6.tar.gz) =
KBnOBB0u4TEDb0/J1q564SWjpA6XumTQT+eZrZ2ru0Q=
@@ -87,8 +88,10 @@ SHA256 (cargo/tempfile-3.8.1.tar.gz) = fvGtrEUK1/SzwoW
SHA256 (cargo/thiserror-1.0.50.tar.gz) =
+achD1yacVa7UKo2rtTJWvtR3w3wBxOUlEjPnpfTgtI=
SHA256 (cargo/thiserror-impl-1.0.50.tar.gz) =
JmsuQLwA5abAnDWEAR4IsG8SPAA2LJK5dbqYQ6qqFLg=
SHA256 (cargo/time-0.3.30.tar.gz) =
xKNKswDy3ublYsEKBG/AXjWLKfm/kid/MMPI2CJ19vU=
+SHA256 (cargo/time-0.3.36.tar.gz) =
Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU=
SHA256 (cargo/time-core-0.1.2.tar.gz) =
75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M=
SHA256 (cargo/time-macros-0.2.15.tar.gz) =
StcNaNup4fis7aeqZxGWXf7Byshp8xGlG9CLOizLziA=
+SHA256 (cargo/time-macros-0.2.18.tar.gz) =
PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8=
SHA256 (cargo/typenum-1.17.0.tar.gz) =
Qv8L8MZrgjjG87V43zfQt4SOVd+Fd7P3T5KmmszuuCU=
SHA256 (cargo/unicode-ident-1.0.12.tar.gz) =
M1S5rD+uH/Z1XLbbU2g622YWNPZ1V5Qt6k+s6+wP7ks=
SHA256 (cargo/unicode-width-0.1.11.tar.gz) =
5Rcz8RycT3KqDBYACCRoWeNAsAgHVpoNoOehB5snuoU=
@@ -169,6 +172,7 @@ SIZE (cargo/memchr-2.6.4.tar.gz) = 94439
SIZE (cargo/memoffset-0.7.1.tar.gz) = 8556
SIZE (cargo/memoffset-0.9.0.tar.gz) = 9033
SIZE (cargo/nix-0.26.4.tar.gz) = 279099
+SIZE (cargo/num-conv-0.1.0.tar.gz) = 7444
SIZE (cargo/num-traits-0.2.17.tar.gz) = 50190
SIZE (cargo/num_cpus-1.16.0.tar.gz) = 15713
SIZE (cargo/num_threads-0.1.6.tar.gz) = 7334
@@ -209,8 +213,10 @@ SIZE (cargo/tempfile-3.8.1.tar.gz) = 32164
SIZE (cargo/thiserror-1.0.50.tar.gz) = 19414
SIZE (cargo/thiserror-impl-1.0.50.tar.gz) = 15357
SIZE (cargo/time-0.3.30.tar.gz) = 120289
+SIZE (cargo/time-0.3.36.tar.gz) = 119805
SIZE (cargo/time-core-0.1.2.tar.gz) = 7191
SIZE (cargo/time-macros-0.2.15.tar.gz) = 23568
+SIZE (cargo/time-macros-0.2.18.tar.gz) = 24361
SIZE (cargo/typenum-1.17.0.tar.gz) = 42849
SIZE (cargo/unicode-ident-1.0.12.tar.gz) = 42168
SIZE (cargo/unicode-width-0.1.11.tar.gz) = 19187
audio/spotifyd: time crate update for upcoming lang/rust
Hi,
The following diff updates time crate to 0.3.36 (and dependencies). It
is required for lang/rust 1.80.0
Comments or OK ?
--
Sebastien Marie
diff /data/semarie/repos/openbsd/ports
commit - 50e60d3f44a62b83d566d19d5dd1424e798b73a0
path + /data/semarie/repos/openbsd/ports
blob - 809b0539768b3a2fe599bc2bc6f483485de1487c
file + audio/spotifyd/Makefile
--- audio/spotifyd/Makefile
+++ audio/spotifyd/Makefile
@@ -7,6 +7,7 @@ HEAD_COMMIT = ff2f7a06e54bf05afd57a0243dc9f67abc15f04
DIST_TUPLE = github spotifydspotifyd${HEAD_COMMIT}
.
WRKDIST = ${WRKDIR}/spotifyd-${HEAD_COMMIT}
DISTNAME = spotifyd-0.3.5pl2
+REVISION = 0
CATEGORIES = audio net
MAINTAINER = Klemens Nanni
@@ -27,6 +28,14 @@ LIB_DEPENDS =audio/portaudio-svn \
CONFIGURE_STYLE = cargo
SEPARATE_BUILD = Yes
+MODCARGO_CRATES_UPDATE += time@0.3.28
+MODCARGO_CRATES += time0.3.36
+MODCARGO_CRATES += time-core 0.1.2
+MODCARGO_CRATES += time-macros 0.2.18
+MODCARGO_CRATES += deranged0.3.9
+MODCARGO_CRATES += num-conv0.1.0
+MODCARGO_CRATES += powerfmt0.2.0
+
MODCARGO_NO_DEFAULT_FEATURES = Yes
MODCARGO_FEATURES =dbus_keyring \
dbus_mpris \
blob - 5ad053c57883bb3e84789ae4a30764785d2b21d4
file + audio/spotifyd/distinfo
--- audio/spotifyd/distinfo
+++ audio/spotifyd/distinfo
@@ -72,6 +72,7 @@ SHA256 (cargo/dbus-0.9.7.tar.gz) = G7IZh7n7FhMFi6OEMSH
SHA256 (cargo/dbus-crossroads-0.5.2.tar.gz) =
OkyDQ3GHVEulFCQndGg1BhszBEbKiQLqvXDkr7j3beA=
SHA256 (cargo/dbus-tokio-0.7.6.tar.gz) =
AHaI1Fm8Z3ExwGOjp3+4mVJuF7eYDzkLaWRL28QfrRM=
SHA256 (cargo/deranged-0.3.8.tar.gz) =
8mluipRfZY/RTcO4ckLmuAzQ82/wTqVg+jkII2iEeUY=
+SHA256 (cargo/deranged-0.3.9.tar.gz) =
DzLQSSLGBCfab5/vFNBC2e3d72TLnUzg1k0GhfvrH9M=
SHA256 (cargo/derivative-2.2.0.tar.gz) =
/MPdXp6cCyldbh5NgR+28VfV/9eEuNIC/GLqyANadws=
SHA256 (cargo/digest-0.10.7.tar.gz) =
ntmigfe8m3V25hRoumFaZqXIz9/0JCCnCqgnAaOx4pI=
SHA256 (cargo/digest-0.9.0.tar.gz) =
091g0QgKV6BasDI3cEngWRQV0rMa/XAoNW2/PMbcsGY=
@@ -193,6 +194,7 @@ SHA256 (cargo/nom-7.1.3.tar.gz) = 0nOYPFplenCj6PKgEymC
SHA256 (cargo/num-0.4.1.tar.gz) = sFGA1p49oOUwuiodrlEQMX5J47fz1BviJ9xfkuSe568=
SHA256 (cargo/num-bigint-0.4.4.tar.gz) =
YI52WbXD18uiYtiUgBueydAN6YnoqCvUvvkdCNpFzcA=
SHA256 (cargo/num-complex-0.4.4.tar.gz) =
G6FXygiFQR3oXWygMLp+KoOihjYFbHxpmwfItvc4MhQ=
+SHA256 (cargo/num-conv-0.1.0.tar.gz) =
UdUV0y+xgu43zaLM3LkpUNajwok6ooDlQGccLNDzsdk=
SHA256 (cargo/num-derive-0.3.3.tar.gz) =
h2pT//mOA6k2pnSylWiw5gXwayk3LCSJ/03iPxlJdD0=
SHA256 (cargo/num-integer-0.1.45.tar.gz) =
Il0zifs1CaJMk/XCnra94lhrmNnwFmNt/1jXxvdWnNk=
SHA256 (cargo/num-iter-0.1.43.tar.gz) =
fQPmwCjF3Fysbi3sDv2oH8iHYFuz2IRXi7bWv3UU4lI=
@@ -227,6 +229,7 @@ SHA256 (cargo/pledge-0.4.2.tar.gz) = JSWZQXt9mkO3/cY91
SHA256 (cargo/polling-2.8.0.tar.gz) =
Sy0yPoynmWs+IxJlEaUj9+YpJNk+zVrnOzM4FbDrPc4=
SHA256 (cargo/portaudio-rs-0.3.2.tar.gz) =
zba17/lszJv0TTTDeasDrpREJtg9FpQ0W9+BWdVh1WI=
SHA256 (cargo/portaudio-sys-0.1.1.tar.gz) =
UZSk+pU7T/2FHDIO9vBITNcnjLcWnqnWxDPkmyP3t/U=
+SHA256 (cargo/powerfmt-0.2.0.tar.gz) =
Q57jBd7xFboFk4226xZE/5QWXFq16UINHBvO27qQk5E=
SHA256 (cargo/ppv-lite86-0.2.17.tar.gz) =
W0CvgFsxIf6rijwp8E2K0mL6jgVhiD52U+AkrkR55t4=
SHA256 (cargo/priority-queue-1.3.2.tar.gz) =
//Oe38rsDWTo0No4Vk+tGV0tUbaAlAKV/MMHNm4QHmE=
SHA256 (cargo/proc-macro-crate-1.3.1.tar.gz) =
f0wCHhCTpWYmd06BIWpM5zKnNeW61IaKA/PtZcoMORk=
@@ -310,8 +313,11 @@ SHA256 (cargo/thread-id-4.2.0.tar.gz) = eUdPVzVhzcSHGg
SHA256 (cargo/thread_local-1.1.7.tar.gz) =
P91vBkzP8tZWetyzhzymMHAPALWtPwYMJbXc/ZpM4VI=
SHA256 (cargo/time-0.1.45.tar.gz) =
G3l6+tPzEtHGalbRHQMW+RY1bRG9FY+8bKY4n/a/gFo=
SHA256 (cargo/time-0.3.28.tar.gz) =
F/a7VX/SRcKOZBGqVrZAPGia2VBh9Q5L4WwnTnChfkg=
+SHA256 (cargo/time-0.3.36.tar.gz) =
Xf2I5WNGRobJFsfkbmI+Ug3cbXn6ZkE5Dy4/qG6D6IU=
SHA256 (cargo/time-core-0.1.1.tar.gz) =
cwD777Ta3BryNanO83N86mkqnZfhucvNTr2ub4ho5vs=
+SHA256 (cargo/time-core-0.1.2.tar.gz) =
75J8p1r7gIpNZN03TwCirfjQ/P+OexhK+IbDyH7Eo/M=
SHA256 (cargo/time-macros-0.2.14.tar.gz) =
GpQvRDOUeO9nk1qyu67C+wMiSWzzy+hLJh4GrDgUxXI=
+SHA256 (cargo/time-macros-0.2.18.tar.gz) =
PyUqaFQP3jo4d67qVSuDK0CrmmnjGO/QeHdKAd3uHM8=
SHA256 (cargo/tinyvec-1.6.0.tar.gz) =
h8xc6zh1uyDCiQAFpOImpGUSZKXHXtskIbUoYaCgy1A=
SHA256 (cargo/tinyvec_macros-0.1.1.tar.gz) =
HzzLrDEf6gX4b2GQS0YrVfs9+IN6Nm38YBoBYdBTLyA=
SHA256 (cargo/tokio-1.32.0.tar.gz) =
F+1gd+1s1sdHNeIfN+sW3Dk1+Wh4sf6WEHQInMgIk/k=
@@ -455,6 +461,7 @@ SIZE (cargo/dbus-0.9.7.tar.gz) = 104206
SIZE (cargo/dbus-crossroads-0.5.2.tar.gz) = 44664
SIZE (cargo/dbus-tokio-0.7.6.tar.gz) = 17545
SIZE (cargo/deranged-0.3.8.tar.gz) = 15314
+SIZE (cargo/deranged-0.3.9.tar.gz) = 17080
SIZE (cargo/derivative-2.2.0.tar.gz) = 48076
SIZE (cargo/digest-0.10.7.tar.gz) = 19557
SIZE (cargo/digest-0.9.0.tar.gz) = 13247
@@ -576,6 +583,7 @@ SIZE (cargo/nom-7.1.3
import devel/rust-bindgen v0.69.4
Hi, I would like to import devel/rust-bindgen, a cli utility to generate Rust interface from C (or some C++) headers. It is using llvm to read/parse C files (libclang.so). The library is loaded at runtime, but the binary doesn't automatically find it (/usr/local/llvmXX/lib path isn't a standard one). So I moved the binary to libexec and created a small shell wrapper to autodetect the library path. It is still possible to manually override the library path using environment variable. I didn't set any devel/llvm version in RUN_DEPENDS as it is working with all versions (so I don't force installing a specific version). It could be done differently if requested. All tests are passing (tested on amd64). Comments or OK ? -- Sebastien Marie rust-bindgen.tgz Description: Binary data
Re: import databases/duckdb
Sebastien Marie writes: > > 3. split the port in several parts (maybe FLAVOR or separated ports): >- main part : duckdb executable + library without extensions (or > only minimal set) >- extension part : build the extensions and install *.duckdb_extension > files in a system directory I started to explore build duckdb and extensions separately, but an additional problem popup: extensions are checked for a signature (from upstream key). So port build ones doesn't have signature and are, by default, refused to be loaded (user should set `allow_unsigned_extensions` flag to permit the load). From user point of vue, building extensions separately seems to be no go. So I intent to build most extensions statically (in cli and shared library), and don't install static files. Thanks. -- Sebastien Marie
Re: import databases/duckdb
Stuart Henderson writes: > On 2024/06/01 17:02, Sebastien Marie wrote: >> Hi, >> >> I would like to import duckdb (https://duckdb.org/) port. >> >> DuckDB is a high-performance analytical database system. It is designed to >> be >> fast, reliable, portable, and easy to use. DuckDB provides a rich SQL >> dialect, >> with support far beyond basic SQL. DuckDB supports arbitrary and nested >> correlated subqueries, window functions, collations, complex types (arrays, >> structs), and more. >> >> The port installs the CLI with several extensions and the shared lib, >> but no bindings for external language. >> >> Comments or OK ? >> -- >> Sebastien Marie >> > > It would be nice to have duckdb in the tree. I think it's not quite as > fast as clickhouse-local but seems more straightforward. A few comments: > > - No need to set DISTNAME, that is the default. no problem, done locally > - Personally I would use GH_* rather than DIST_TUPLE, there's not really > an advantage to DIST_TUPLE here, and it has the downside that it doesn't > work with portroach. no problem, done locally > - I'm a bit unsure about packaging the extensions as .a files, do they > do anything useful? I would have expected to see the shared objects > (see WRKBUILD/extension/*/*.duckdb_extension after build) instead. I didn't looked at this aspect. It is the default installed files. The duckdb exectuable seems to have the extensions embedded: $ duckdb D SELECT extension_name, loaded, installed, install_mode FROM duckdb_extensions(); ┌──┬─┬───┬───┐ │ extension_name │ loaded │ installed │ install_mode│ │ varchar │ boolean │ boolean │ varchar │ ├──┼─┼───┼───┤ │ arrow│ false │ false │ │ │ autocomplete │ true│ true │ STATICALLY_LINKED │ │ aws │ false │ false │ │ │ azure│ false │ false │ │ │ excel│ false │ false │ │ │ fts │ true│ true │ STATICALLY_LINKED │ │ httpfs │ true│ true │ STATICALLY_LINKED │ │ iceberg │ false │ false │ │ │ icu │ true│ true │ STATICALLY_LINKED │ │ inet │ true│ true │ STATICALLY_LINKED │ │ jemalloc │ false │ false │ │ │ json │ true│ true │ STATICALLY_LINKED │ │ motherduck │ false │ false │ │ │ mysql_scanner│ false │ false │ │ │ parquet │ true│ true │ STATICALLY_LINKED │ │ postgres_scanner │ false │ false │ │ │ shell│ true│ true │ STATICALLY_LINKED │ │ spatial │ false │ false │ │ │ sqlite_scanner │ false │ false │ │ │ substrait│ false │ false │ │ │ tpcds│ false │ false │ │ │ tpch │ false │ false │ │ ├──┴─┴───┴───┤ │ 22 rows 4 columns │ └┘ >From a manual inspection of symbols in libduckdb.so, the extensions seems to be also present in the library and after I made a simple program using the library, I have the same output for the query: so the extensions are inside the libduckdb.so library too. For the usage of extensions as statically files, it seems be necessary if you are statically compile duckdb in an application: the fact the extensions where defined statically linked at port-compile-time seems to force them to be also used in the same way if you compile a program with duckdb library (I tried to link my test program statically, but failed to find the right files to included). So, from the previous, I think that the extensions files (*.duckdb_extension) are only needed if you are compiling a "little" libduckdb.so and you want to extend the capabilities at runtime. Please note that from documentation reading, it seems there is no default system path (only user path) where extensions are searched automatically. So user might need to load them with full path. What would be the preferred direction ? 1. keep things "as it" 2. do not install statical files at this point 3. split the port in several parts (maybe FLAVOR or separated ports): - main part : duckdb executable + library without extensions (or only minimal set) - extension part : build the extensions and install *.duckdb_extension files in a system directory Thanks. -- Sebastien Marie
import databases/duckdb
Hi, I would like to import duckdb (https://duckdb.org/) port. DuckDB is a high-performance analytical database system. It is designed to be fast, reliable, portable, and easy to use. DuckDB provides a rich SQL dialect, with support far beyond basic SQL. DuckDB supports arbitrary and nested correlated subqueries, window functions, collations, complex types (arrays, structs), and more. The port installs the CLI with several extensions and the shared lib, but no bindings for external language. Comments or OK ? -- Sebastien Marie duckdb.tgz Description: Binary data
update textproc/typst to 0.11.1
Hi,
The following diff updates textproc/typst to 0.11.1 (released today).
While here:
- take maintainership
- dynamically patch typst-dev-assets integration (instead of conflicting
at each release)
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - 7a954077803d639c4330039bcbceee8a9499d229
path + /home/semarie/repos/openbsd/ports
blob - 91bcd2f4788210ec018550dbc9274f13f3ae131c
file + textproc/typst/Makefile
--- textproc/typst/Makefile
+++ textproc/typst/Makefile
@@ -1,7 +1,7 @@
COMMENT = markup-based typesetting system
DISTNAME = typst-${V}
-V =0.11.0
+V =0.11.1
DIST_TUPLE += github typst typst v${V} .
DIST_TUPLE += github typst typst-dev-assets v${V} crates/typst-dev-assets
@@ -9,6 +9,7 @@ DIST_TUPLE += github typst typst-dev-assets v${V} crat
CATEGORIES = textproc
HOMEPAGE = https://typst.app/
+MAINTAINER = Sebastien Marie
# Apache-2.0
PERMIT_PACKAGE = Yes
@@ -23,5 +24,11 @@ MODCARGO_TEST_ARGS = --workspace
CONFIGURE_STYLE = cargo
SEPARATE_BUILD = Yes
+pre-patch:
+ sed -ie '/github.com\/typst\/typst-dev-assets\?tag=/d' \
+ ${WRKSRC}/Cargo.lock
+ sed -ie 's/typst-dev-assets = { [^}]* }/typst-dev-assets = { path =
"crates\/typst-dev-assets" }/' \
+ ${WRKSRC}/Cargo.toml
+
.include "crates.inc"
.include
blob - 0f73e247d7299d3ebf73ec93cbc7e3f1178e
file + textproc/typst/crates.inc
--- textproc/typst/crates.inc
+++ textproc/typst/crates.inc
@@ -33,7 +33,7 @@ MODCARGO_CRATES +=chrono 0.4.35 # MIT OR Apache-2.0
MODCARGO_CRATES += ciborium0.2.2 # Apache-2.0
MODCARGO_CRATES += ciborium-io 0.2.2 # Apache-2.0
MODCARGO_CRATES += ciborium-ll 0.2.2 # Apache-2.0
-MODCARGO_CRATES += citationberg0.3.0 # MIT OR Apache-2.0
+MODCARGO_CRATES += citationberg0.3.1 # MIT OR Apache-2.0
MODCARGO_CRATES += clap4.5.2 # MIT OR Apache-2.0
MODCARGO_CRATES += clap_builder4.5.2 # MIT OR Apache-2.0
MODCARGO_CRATES += clap_complete 4.5.1 # MIT OR Apache-2.0
@@ -95,7 +95,7 @@ MODCARGO_CRATES +=gif 0.13.1 # MIT/Apache-2.0
MODCARGO_CRATES += half2.4.0 # MIT OR Apache-2.0
MODCARGO_CRATES += hashbrown 0.12.3 # MIT OR Apache-2.0
MODCARGO_CRATES += hashbrown 0.14.3 # MIT OR Apache-2.0
-MODCARGO_CRATES += hayagriva 0.5.2 # MIT OR Apache-2.0
+MODCARGO_CRATES += hayagriva 0.5.3 # MIT OR Apache-2.0
MODCARGO_CRATES += heck0.4.1 # MIT OR Apache-2.0
MODCARGO_CRATES += hypher 0.1.5 # MIT OR Apache-2.0
MODCARGO_CRATES += iana-time-zone 0.1.60 # MIT OR Apache-2.0
@@ -230,6 +230,7 @@ MODCARGO_CRATES += serde_json 1.0.114 # MIT OR Apache-
MODCARGO_CRATES += serde_spanned 0.6.5 # MIT OR Apache-2.0
MODCARGO_CRATES += serde_yaml 0.8.26 # MIT OR Apache-2.0
MODCARGO_CRATES += serde_yaml 0.9.32 # MIT OR Apache-2.0
+MODCARGO_CRATES += shell-escape0.1.5 # MIT/Apache-2.0
MODCARGO_CRATES += simd-adler320.3.7 # MIT
MODCARGO_CRATES += simplecss 0.2.1 # MIT/Apache-2.0
MODCARGO_CRATES += siphasher 0.3.11 # MIT/Apache-2.0
@@ -269,7 +270,7 @@ MODCARGO_CRATES += toml_edit 0.22.6 # MIT OR
Apache-2.
MODCARGO_CRATES += ttf-parser 0.20.0 # MIT OR Apache-2.0
MODCARGO_CRATES += two-face0.3.0 # MIT OR Apache-2.0
MODCARGO_CRATES += typed-arena 2.0.2 # MIT
-MODCARGO_CRATES += typst-assets0.11.0 # Apache-2.0
+MODCARGO_CRATES += typst-assets0.11.1 # Apache-2.0
MODCARGO_CRATES += unic-langid 0.9.4 # MIT OR Apache-2.0
MODCARGO_CRATES += unic-langid-impl0.9.4 # MIT OR Apache-2.0
MODCARGO_CRATES += unicase 2.7.0 # MIT/Apache-2.0
blob - 82de451c80adabb31438ca580c40121fb6565beb
file + textproc/typst/distinfo
--- textproc/typst/distinfo
+++ textproc/typst/distinfo
@@ -33,7 +33,7 @@ SHA256 (cargo/chrono-0.4.35.tar.gz) = jq9ZA9y8CjkxL+t3
SHA256 (cargo/ciborium-0.2.2.tar.gz) =
Quaf/W8JF/XAKSVqJNAWHbF86jmX0YXbDTWSYwh3Dw4=
SHA256 (cargo/ciborium-io-0.2.2.tar.gz) =
Ba/qHgoGyb4z1Tm4dvHONpL0r+ostB90DndDIl7Rx1c=
SHA256 (cargo/ciborium-ll-0.2.2.tar.gz) =
V2Y7ZT2UijOL+z7rqbsv1fz67Lnhmeh+HtpNnoskD9k=
-SHA256 (cargo/citationberg-0.3.0.tar.gz) =
ghCPK2dslUB20uUETxmmoDiHskvUKATzIuBlDRMDWJk=
+SHA256 (cargo/citationberg-0.3.1.tar.gz) =
0ln+n9eP+gWhGVgdIP3bUL+6QoMRBXsSdB/7kBUSPQs=
SHA256 (cargo/clap-4.5.2.tar.gz) = sjCrhLD/34kNWhCr28i4OuHEkYJ12uoauIAfcVNrJlE=
SHA256 (cargo/clap_builder-4.5.2.tar.gz) =
rhKeLnZq4OwDSE5gmVQRnxI8wf5lAzfhVdA7Ai8k97Q=
SHA256 (cargo/clap_complete-4.5.1.tar.gz) =
iF5NfVr0C/uZrm+UM+KS/qyY1FLcs+w9Jd/nVSt32ow=
@@ -95,7 +95,7 @@ SHA256 (cargo/gif-0.13.1.tar.gz) = P7LWmxkhXhi7kS+jD3z
SHA256 (cargo/half-2.4.0.tar.gz) = tezqruxpZTndr3szM0DxrzWlqoeuPk8+rQUy9yr/qy4=
SHA256 (cargo/hashbrown-0.12.3.tar.gz) =
ip7
update: mail/offlineimap to latest HEAD
Hi,
With the switch to python-3.11 by default, mail/offlineimap stopped
working due to some (wrong) assertion:
AssertionError: Your sqlite is not multithreading safe.
The `sqlite3.threadsafety` changed in python-3.11, the value is set
dynamically instead of hard-coding it to 1, and offlineimap is checking
for `1`.
The current version of mail/offlineimap is the latest published release
(8.0.0 from Oct 18, 2021), but the repository is somehow active (last
commit is 5 months ago) and has proper python-3.11 support.
The following diff updates mail/offlineimap to the latest commit in
HEAD. I am using the date of the commit for the patchlevel suffix.
With it, I could use offlineimap again.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - b2c7acbc7dd918d9c73dc98acda9de3fd5f78c5e
path + /home/semarie/repos/openbsd/ports
blob - cdd013dbbb04e5ada556298ef4f4ea7763df2b16
file + mail/offlineimap/Makefile
--- mail/offlineimap/Makefile
+++ mail/offlineimap/Makefile
@@ -1,13 +1,11 @@
COMMENT= powerful IMAP/Maildir synchronization and reader support
MODPY_EGG_VERSION = 8.0.0
-#DISTNAME =offlineimap-v${MODPY_EGG_VERSION}
-PKGNAME = offlineimap-${MODPY_EGG_VERSION}
-REVISION = 3
+DISTNAME = offlineimap-${MODPY_EGG_VERSION}pl20231218
GH_ACCOUNT = OfflineIMAP
GH_PROJECT = offlineimap3
-GH_TAGNAME = v${MODPY_EGG_VERSION}
+GH_COMMIT =d29a4dc459401f8a78e347cb0f8ae7670add0975
CATEGORIES=mail
@@ -29,8 +27,6 @@ RUN_DEPENDS= devel/py-rfc6555${MODPY_FLAVOR} \
mail/py-imaplib2${MODPY_FLAVOR} \
sysutils/py-distro${MODPY_FLAVOR}
-#SITES=https://www.offlineimap.org/uploads/
-
EXAMPLESDIR= ${PREFIX}/share/examples/offlineimap
post-build:
blob - a39897fc51ba7c4a24fac245758ea2d23d84c3a7
file + mail/offlineimap/distinfo
--- mail/offlineimap/distinfo
+++ mail/offlineimap/distinfo
@@ -1,2 +1,2 @@
-SHA256 (offlineimap3-8.0.0.tar.gz) =
XUDBY8ovv4llgRbin4+nUFDQw0wpYZAZ7uGoTJD8qzI=
-SIZE (offlineimap3-8.0.0.tar.gz) = 702509
+SHA256 (offlineimap-8.0.0pl20231218-d29a4dc4.tar.gz) =
NJRQ4A2UiY3AB2R8K19iAm+febCcP5pevULwdjRG/N0=
+SIZE (offlineimap-8.0.0pl20231218-d29a4dc4.tar.gz) = 705369
blob - 8462e3a21c2783a5746e2379df97963ea74d4a1c
file + mail/offlineimap/patches/patch-offlineimap_conf
--- mail/offlineimap/patches/patch-offlineimap_conf
+++ mail/offlineimap/patches/patch-offlineimap_conf
@@ -1,7 +1,7 @@
Index: offlineimap.conf
--- offlineimap.conf.orig
+++ offlineimap.conf
-@@ -765,7 +765,7 @@ remotehost = examplehost
+@@ -768,7 +768,7 @@ remotehost = examplehost
# You can also use fingerprint verification via cert_fingerprint.
# See below for more verbose explanation.
#
update lang/sbcl to 2.4.4 (and add libsbcl.so)
Hi,
The following diff updates sbcl to 2.4.4.
It also adds libsbcl.a and libsbcl.so to the port.
Regarding libsbcl.so, the library isn't available on all platforms (some
.S files aren't PIC compatible - at least on i386), so I only added it
to tested platforms (aarch64 and amd64 at time).
Comments or OK ?
--
Sebastien Marie
Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
diff -u -p -r1.67 Makefile
--- Makefile8 Apr 2024 15:32:45 - 1.67
+++ Makefile1 May 2024 13:41:32 -
@@ -4,10 +4,12 @@ ONLY_FOR_ARCHS += aarch64 amd64 arm i386
COMMENT = high performance Common Lisp compiler
-V =2.4.3
+V =2.4.4
DISTNAME = sbcl-${V}-source
PKGNAME = sbcl-${V}
+SHARED_LIBS += sbcl0.0
+
CATEGORIES = lang
HOMEPAGE = https://www.sbcl.org/
@@ -79,17 +81,28 @@ WANTLIB += pthread
EXTRA_PARAMS +=--without-sb-thread
.endif
+# libsbcl.so is not available everywhere
+LIBSBCL-${MACHINE_ARCH} ?= No
+LIBSBCL-aarch64 = Yes
+LIBSBCL-amd64 =Yes
+
+SUBST_VARS += COMMENT_libsbcl
+
+.if ${LIBSBCL-${MACHINE_ARCH}:MYes}
+COMMENT_libsbcl = @lib
+.else
+COMMENT_libsbcl = @comment
+.endif
+
BUILD_DEPENDS += print/texinfo
LIB_DEPENDS += archivers/zstd
TEST_DEPENDS +=devel/capstone/main \
devel/gmp
-MAKE_ENV +=CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib" \
- LINKFLAGS="-L${LOCALBASE}/lib" \
+MAKE_ENV +=INFO_DIR="${PREFIX}/info/" \
+ LIBsbcl_VERSION="${LIBsbcl_VERSION}" \
MAKEINFO=${PREFIX}/bin/gmakeinfo \
MAN_DIR="${PREFIX}/man/" \
- INFO_DIR="${PREFIX}/info/" \
SBCL_MAKE_JOBS="-j${MAKE_JOBS}"
USE_GMAKE =Yes
@@ -115,7 +128,12 @@ do-build:
--xc-host="${XCHOST_CMD}" \
--with-sb-core-compression \
--with-sb-xref-for-internals \
+ --with-sb-linkable-runtime \
${EXTRA_PARAMS}
+.if ${LIBSBCL-${MACHINE_ARCH}:MYes}
+ umask 022 && cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
+ /bin/sh ./make-shared-library.sh
+.endif
umask 022 && cd ${WRKSRC}/doc/manual/ && ${SETENV} ${MAKE_ENV} \
${GMAKE} info
@@ -126,6 +144,11 @@ do-install:
post-install:
rmdir ${PREFIX}/share/doc/sbcl/html/
+.if ${LIBSBCL-${MACHINE_ARCH}:MYes}
+ # the SONAME is properly configured
+ mv ${PREFIX}/lib/libsbcl.so \
+ ${PREFIX}/lib/libsbcl.so.${LIBsbcl_VERSION}
+.endif
do-test:
cd ${WRKSRC}/tests/ && ${SETENV} ${MAKE_ENV} /bin/sh ./run-tests.sh
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
diff -u -p -r1.32 distinfo
--- distinfo8 Apr 2024 15:32:45 - 1.32
+++ distinfo1 May 2024 13:41:32 -
@@ -1,2 +1,2 @@
-SHA256 (sbcl-2.4.3-source.tar.bz2) =
icmq35K4KtPHSj1PFYoDiJPeoOTzlNyvyWNYPDC3w/I=
-SIZE (sbcl-2.4.3-source.tar.bz2) = 8126417
+SHA256 (sbcl-2.4.4-source.tar.bz2) =
ipMmJ7Px2OlhjxzcIl7csAJFaARpfiyH0UBoN2ShBtU=
+SIZE (sbcl-2.4.4-source.tar.bz2) = 8065883
Index: patches/patch-src_cold_shared_lisp
===
RCS file: patches/patch-src_cold_shared_lisp
diff -N patches/patch-src_cold_shared_lisp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_cold_shared_lisp 1 May 2024 13:41:32 -
@@ -0,0 +1,12 @@
+Index: src/cold/shared.lisp
+--- src/cold/shared.lisp.orig
src/cold/shared.lisp
+@@ -392,7 +392,7 @@
+ ("(and cons-profiling (not sb-thread))" ":CONS-PROFILING requires
:SB-THREAD")
+ ("(and sb-linkable-runtime (not (or arm arm64 x86 x86-64 ppc
ppc64)))"
+ ":SB-LINKABLE-RUNTIME not supported on selected architecture")
+- ("(and sb-linkable-runtime (not (or darwin freebsd linux win32)))"
++ ("(and sb-linkable-runtime (not (or darwin openbsd freebsd linux
win32)))"
+ ":SB-LINKABLE-RUNTIME not supported on selected operating system")
+ ("(and sb-eval sb-fasteval)"
+ ;; It sorta kinda works to have both, but there should be no need,
Index: patches/patch-src_runtime_Config_generic-openbsd
===
RCS file: patches/patch-src_runtime_Config_generic-openbsd
diff -N patches/patch-src_runtime_Config_generic-openbsd
--- /dev/null 1 Jan 1970 00:00:00 -
Re: lang/sbcl - building and installing libsbcl.so ?
Dima Pasechnik writes:
> On Fri, Apr 26, 2024 at 12:11:31AM +0200, Kirill A. Korinsky wrote:
>> On Thu, 25 Apr 2024 23:28:27 +0200,
>> Dima Pasechnik wrote:
>> >
>> > +SHARED_LIBS += sbcl 0.0
>>
>> I suggest to match library version with sbcl version to avoid nightmare, as
>> far as I recall upstream doesn't care about ABI stability between releases,
>> and, for example, .fasl should be recompiled each new release.
>
> One can't just take X.Y.Z as a version for .so, as they must have the
> form X.Y, not X.Y.Z. With this in mind, as well as due to the fact that
> the upstream hasn't versioned libsbcl.so at all, starting from 0.0
> might be OK, no? (These would be OpenBSD-specific versions, anyway).
I am unsure about X.Y vs X.Y.Z, but shared-libs on OpenBSD has X.Y and
the numbering is controlled by porters. So if SHARED_LIBS is used, it
must be 0.0 at start.
Please note that the ABI control isn't just about what upstream is doing
on their side: if changes are done on OpenBSD, the ABI might change too
(remember the time_t size change ? it was a local change in OpenBSD
which affected ABI on all ports using time_t in signatures)
Regarding the update path for the port, we have tools for helping
checking ABI changes (and it is also possible to just major bump at each
release too).
>>
>> > @info info/sbcl.info
>> > +@so lib/libsbcl.so.0.0
>>
>> Without symlink libsbcl.so -> libsbcl.so.0.0 linking agains that library
>> will be quite tricky.
>
> Not really. OpenBSD linker is clever enough to know that -lsbcl
> corresponds to the newest libsbcl.so.x.y.
I agree.
>>
>> Minor remarks:
>> - minus sign as the first character inside the patch should be ok, but may
>> be considered quite suspicious.
> That was in already present patches.
it isn't a problem.
>> - you also need to increase reviosion with that changes.
yes, it should be done (but I intent to wait for 2.4.4 in few days to
integrate your changes)
>> - I suggest to add diff.noprefix=true to port's git config to avoid prefix
>
> if your port tree is under git, you can save my diff to my_patch and do
>
>git apply my_patch :-)
>
`patch -p1` is also a possibility.
Only one thing isn't properly addressed: the SONAME of the library is
still `libsbcl.so`. This information is used by the linker at compile
time when the library is used.
$ readelf -d libsbcl.so | grep SONAME
Having SOFLAGS defined to -Wl,-soname,libsbcl.so.${LIBsbcl_VERSION}
should be enough (I have done that in
src/runtime/Config.generic-openbsd, but I did the things a bit
differently).
Thanks.
--
Sebastien Marie
Re: lang/sbcl - building and installing libsbcl.so ?
Kirill A. Korinsky writes:
> On Thu, 25 Apr 2024 14:11:32 +0200,
> Sebastien Marie wrote:
>>
>> The static-library is simple to add (with --with-sb-linkable-runtime
>> support).
>>
>
> Which requires at least this patch
yes. I already have sent to upstream the full support for
--with-sb-linkable-runtime.
> diff --git src/cold/shared.lisp src/cold/shared.lisp
> index 773d36115..a7c55ea6c 100644
> --- src/cold/shared.lisp
> +++ src/cold/shared.lisp
> @@ -392,7 +392,7 @@
> ("(and cons-profiling (not sb-thread))" ":CONS-PROFILING requires
> :SB-THREAD")
> ("(and sb-linkable-runtime (not (or arm arm64 x86 x86-64 ppc
> ppc64)))"
>":SB-LINKABLE-RUNTIME not supported on selected architecture")
> - ("(and sb-linkable-runtime (not (or darwin freebsd linux win32)))"
> + ("(and sb-linkable-runtime (not (or darwin freebsd openbsd linux
> win32)))"
>":SB-LINKABLE-RUNTIME not supported on selected operating system")
> ("(and sb-eval sb-fasteval)"
>;; It sorta kinda works to have both, but there should be no need,
>
>
> Anyway, I haven't tested it.
>
> But this discussion put in my head another idea: build libsbcl.so indeed,
> but using it also inside sbcl binary.
>
> This way allows to solve an issue with rebuild of ports which saves lisp
> image as binary.
>
> But this approach requires some work inside sbcl build system.
I thought of that too, but I am still unsure it will solves the issue
(at least directly). Yes, the stumpwm package will be update
automatically, but because of WANTLIB change.
I am unsure a binary linked with old libsbcl.so will be runable with a
newer libsbcl.so. It might be something to try...
Thanks
--
Sebastien Marie
Re: lang/sbcl - building and installing libsbcl.so ?
Dima Pasechnik writes: > Dear all, > sbcl can be packaged into a dynamic library, something one needs for > e.g. calling Lisp from C or Python, > via sbcl-librarian https://github.com/quil-lang/sbcl-librarian > A question about your use-case: would a static library (libsbcl.a) be enough for your purpose ? I am a bit reluctant to add a shared lib (with all the major/minor management its implies) for something outside the port tree. The static-library is simple to add (with --with-sb-linkable-runtime support). Else I will look to add it. Thanks. -- Sebastien Marie
new: textproc/typst 0.11.0
Hi, I would like to import textproc/typst - https://typst.app/ It is a rust based program. The website promotes the webapp (a collaborative editor on web), but the cli tool is enough for doing all the stuff. The port is slightly patched to avoid rust git dependency. I replaced it by using DIST_TUPLE. $ cat pkg/DESCR Typst is a new markup-based typesetting system that is designed to be as powerful as LaTeX while being much easier to learn and use. Typst has: - Built-in markup for the most common formatting tasks - Flexible functions for everything else - A tightly integrated scripting system - Math typesetting, bibliography management, and more - Fast compile times thanks to incremental compilation - Friendly error messages in case something goes wrong Comments or OK ? -- Sebastien Marie typst.tgz Description: Binary data
Re: compile of rhythmbox fails
jonathan soons writes: > Absolute noob on OpenBSD here. > I am using the latest ports tree on a macppc. I assume this affects everyone. > I try to compile rhythmbox and I get the error: > > Dependency librsvg-2.0 found: NO found 2.40.21 but need: '>= 2.48' > Found CMake: /usr/local/bin/cmake (3.28.3) > Run-time dependency librsvg-2.0 found: NO (tried cmake) > > ../../pobj/AppStream-1.0.2/AppStream-1.0.2/compose/meson.build:70:21: ERROR: > Dependency lookup for librsvg-2.0 with method 'pkgconfig' failed: Invalid > version, need 'librsvg-2.0' ['>= 2.48'] found '2.40.21'. > > The compile fails. > > Is this something trivial I should fix or do I need the maintainer? it seems you need to port lang/rust to macppc :) no kinding, the problem is the following: - rhythmbox wants librsvg >= 2.48 - on macppc, the latest version available is 2.40.21 (due to no rustc to compile later version 2.58.0) so the problem is not really trivial to fix. -- Sebastien Marie
Re: dpb always rebuild rust-bootstrap
Solene Rapenne writes: > hi, on a fresh current amd64 I had to set up dpb because it seems > there was a libc bump at the wrong time for me :) > > however, now I have my working dpb (easy to setup once you understand > it), I don't understand why dpb -R something_depending_on_rust > always have to recompile lang/rust, in the packages directory, only > the rust bootstrap package is changed everytime I run dpb. > > I'm not sure which logs I could provide though. This is quite > annoying because lang/rust is heavy to compile and I like to trigger > dpb every time I try a diff. > > Am I the only one with this issue? I'm interested to know if there are any problems with the way I did rust-bootstrap. Currently, it is marked with 'always-update', because the package content depend on the build host (system libraries are embedded in the package for the bootstrap purpose). I expected that if the package isn't installed (and it shouldn't in standard usage) it will not be a problem. Do you have it installed ? If it isn't the case, and dpb is rebuilding it without purpose (I assume no port depending on it), it might be a problem in dpb, or some side effect for a subpackage having 'always-update'. I could look to remove the 'always-update' option from rust-bootstrap without too much trouble. Thanks. -- Sebastien Marie
Re: Followup after update lang/sbcl
(Adding Cc to stumpwm maintainer) Kirill A. Korinsky writes: > Greetings, > > I've encountered an edge case with update of sbcl which lead to broken > stumpwm. > > My stumpwm configuration uses mpd modules which requires sb-bsd-sockets, so > after update of sbcl... it was broken. > > To overstep that issue I must rebuild stumpwm because it is saved image > which includes sbcl which was used when it was build. > > To avoid such issue in the future I suggest to add a note inside lang/sbcl > that after update x11/stumpwm should have increased revision. > > I haven't found any other port which depends on lang/sbcl. I commited a REVISION bump to x11/stumpwm (REVISION starts at 0). if I properly understand the problem, it is due that you are using both stumpwm (compiled with older sbcl compiler) and sbcl parts (for a mpd module), and the version mismatches. For now, bumping stumpwm is the simpler, but I wonder if it would be possible to use stumpwm somehow from source and let's sbcl compilation to refresh the fasl files if updated. Timo, any idea ? Thanks. -- Sebastien Marie
Re: CVS: cvs.openbsd.org: ports (textproc/ripgrep)
Theo Buehler writes:
> CVSROOT: /cvs
> Module name: ports
> Changes by: t...@cvs.openbsd.org2024/04/13 18:16:34
>
> Modified files:
> textproc/ripgrep: Makefile
>
> Log message:
> drop maintainer
is it intented ?
the commit message doesn't correspond to the patch (it could happen),
and the patch is weird (does ripgrep do not depend on c, pthread and
c++abi at all ?)
Below is the diff which was commited.
--
Sebastien Marie
===
RCS file: /cvsrepo/anoncvs/cvs/ports/textproc/ripgrep/Makefile,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- ports/textproc/ripgrep/Makefile 2024/04/14 00:14:15 1.33
+++ ports/textproc/ripgrep/Makefile 2024/04/14 00:16:34 1.34
@@ -3,14 +3,12 @@
GH_ACCOUNT = BurntSushi
GH_PROJECT = ripgrep
GH_TAGNAME = 14.1.0
-REVISION = 0
+REVISION = 1
CATEGORIES = textproc sysutils
# Unlicense/MIT
PERMIT_PACKAGE = Yes
-
-WANTLIB += ${MODCARGO_WANTLIB}
MAINTAINER = Theo Buehler
bootstrap subpackage - lang/rust prototype
Hi,
We recently discussed internally about having a subpackage that provide
a binary bootstrap (for ports needing one), in order to avoid a too big
gap between base changes and ports bootstrap regeneration.
I took lang/rust example for testing some prototype. It might cover some
aspects but not all.
I opted to generate a plain tarball located at
/usr/local/lib/rustc-bootstrap-${MACHINE_ARCH}.tar
- a tarball : instead of copying files to one directory (and have to
deal with filename changes due to MAJOR/MINOR in libraries in the
PLIST), I prefered to use a tarball.
so the PLIST-bootstrap is simple: just a unique file with stable name.
- a plain tarball : I didn't see strong need to generate a compressed
tarball here. rust boostrap is using lzma compression and it is
relatively ressource intensive. and as the package is also compressed,
I prefered to stick with plain tarball.
- tarball destination : I put the tarball under /usr/local/lib, without
specific name for the filename (I just reused the one I have for
lang/rust). If we want some uniformisation, it might be preferable to
have a commun directory (/usr/local/lib/bootstrap/ or
/usr/local/share/bootstrap/ for example), and a common pattern for the
name (lang-rust.tar ?)
- PLIST-boostrap with 'always-update' : as the content of the tarball
might change without notice, due to library bump (in base, or in a
ports dependency), I marked the package as 'always-update'. It might
be useful or not. In pratice, nobody is expected to install this
subpackage outside few porters.
- the tarball is in the format that lang/rust will expect for building
(all files under rustc-bootstrap-${MACHINE_ARCH}-${V}). It means that
minimal post-processing would be required to use it for building the
port (in fact, only lzma compression).
I intent to change slightly the extract step of the port to have a
tarball named rustc-bootstrap-${MACHINE_ARCH}-${V}-MMDD and an
extract directory named rustc-bootstrap-${MACHINE_ARCH}-${V}. The date
part would be used only to pin the right tarball.
Any comments on the principe ?
--
Sebastien Marie
Index: Makefile
===
RCS file: /cvs/ports/lang/rust/Makefile,v
diff -u -p -r1.200 Makefile
--- Makefile2 Apr 2024 12:14:19 - 1.200
+++ Makefile4 Apr 2024 06:54:01 -
@@ -12,6 +12,7 @@ COMMENT-main =compiler for Rust Langua
COMMENT-gdb = Rust debugger through gdb
COMMENT-clippy = Rust linter
COMMENT-rustfmt = Rust code formatter
+COMMENT-bootstrap =Rust binary bootstrap
COMMENT-src = Rust source component
V =1.77.1
@@ -31,9 +32,10 @@ PKGNAME-main = rust-${V}
PKGNAME-gdb = rust-gdb-${V}
PKGNAME-clippy = rust-clippy-${V}
PKGNAME-rustfmt = rust-rustfmt-${V}
+PKGNAME-bootstrap =rust-bootstrap-${V}
PKGNAME-src = rust-src-${V}
-MULTI_PACKAGES = -main -gdb -clippy -rustfmt -src
+MULTI_PACKAGES = -main -gdb -clippy -rustfmt -bootstrap -src
CATEGORIES = lang
@@ -254,7 +256,7 @@ do-build:
rust-std rustc cargo clippy rustfmt rust-src
rm -rf -- ${WRKBUILD}/build/tmp
-COMPONENTS ?= rustc-${V}-${TRIPLE_ARCH} \
+COMPONENTS = rustc-${V}-${TRIPLE_ARCH} \
rust-std-${V}-${TRIPLE_ARCH} \
cargo-${V}-${TRIPLE_ARCH} \
clippy-${V}-${TRIPLE_ARCH} \
@@ -284,6 +286,20 @@ do-install:
${TRIPLE_ARCH} \
${LIBRUST_HASH} \
${LIBRUST_REHASH}
+ # create a bootstrap tarball
+ cd ${PREFIX} && pax -w \
+ -f ${PREFIX}/lib/rustc-bootstrap-${MACHINE_ARCH}.tar \
+ -s ',^,rustc-bootstrap-${MACHINE_ARCH}-${V}/,' \
+ bin/{rustc,rustdoc,cargo} \
+ lib/lib*.so \
+ lib/rustlib/${TRIPLE_ARCH}/
+ cd ${PREFIX} && ldd bin/{rustc,rustdoc,cargo} \
+ | sed -ne 's,.* \(/.*/lib/lib.*\.so.[.0-9]*\)$$,\1,p' \
+ | sort -u \
+ | pax -w -a \
+ -f ${PREFIX}/lib/rustc-bootstrap-${MACHINE_ARCH}.tar \
+ -s ',^/usr/lib/,rustc-bootstrap-${MACHINE_ARCH}-${V}/lib/,' \
+ -s
',^/usr/local/lib/,rustc-bootstrap-${MACHINE_ARCH}-${V}/lib/,'
# replace libraries by link
for lib in ${PREFIX}/lib/lib*.* ; do \
libname=$${lib##*/} ; \
@@ -302,37 +318,5 @@ do-install:
do-test:
${TEST_BIN} test --jobs=${MAKE_JOBS} --no-fail-fast
-
-STRIP ?= strip
-# Try to avoid strip from our ancient binutils-2.17
-.if ${LINKER_VERSION} != "lld"
-STRIP =llvm-strip-${MODCLANG_VERSION}
-.endif
-
-# bootstrap target permits to regenerate the bootstrap archive
-BOOTSTRAPNAME=rustc-bootstrap-${MACHINE_ARCH}-${V}-new
-BOOTSTR
update lang/sbcl to 2.4.3 (test wanted on arm, powerpc, powerpc64)
Hi,
The following patch updates lang/sbcl to 2.4.3
I am interested to have it tested on:
- arm
- powerpc
- powerpc64
(for others archs, I have already tested it).
A build test is enough (running 'make' and see if it build successfully
or error-out).
The reason is 2.4.2 introduced some changes in the way some hashes are
generated (by using perfecthash). If it works well when using sbcl for
building itself (using FLAVOR=native_bootstrap), but it uses
pre-computed values for clisp or ecl, and fail to build if some values
are missing.
So before commiting the update, I would like to be sure to not break
arm, powerpc or powerpc64... I already added bits for i386. amd64 and
aarch64 was fine.
The Makefile also includes few changes to error-out early (and have the
error message at the end of the build, instead of several lines before).
The post-extract changes will help to get the missing bits for
perfecthash:
- if usual build failed
- install sbcl from package (pkg_add -a sbcl)
- build sbcl using sbcl (env FLAVOR=native_bootstrap make) - it is a quick
build (usually 5~10min)
- update the patches to get the new bits (env FLAVOR=native_bootstrap make
update-patches)
- build 'normally' using the changed patches (make)
Thanks.
--
Sebastien Marie
Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
diff -u -p -r1.66 Makefile
--- Makefile3 Feb 2024 07:21:34 - 1.66
+++ Makefile30 Mar 2024 10:36:06 -
@@ -4,7 +4,7 @@ ONLY_FOR_ARCHS += aarch64 amd64 arm i386
COMMENT = high performance Common Lisp compiler
-V =2.4.1
+V =2.4.3
DISTNAME = sbcl-${V}-source
PKGNAME = sbcl-${V}
@@ -55,11 +55,13 @@ XCHOST_CMD =${LOCALBASE}/bin/sbcl \
.elif ${BOOTSTRAP_METHOD:Mclisp}
BUILD_DEPENDS += lang/clisp
-XCHOST_CMD = ${LOCALBASE}/bin/clisp -q -norc
+XCHOST_CMD = ${LOCALBASE}/bin/clisp \
+ -q -norc -on-error exit
.elif ${BOOTSTRAP_METHOD:Mecl}
BUILD_DEPENDS += lang/ecl
-XCHOST_CMD = ${LOCALBASE}/bin/ecl -q --norc
+XCHOST_CMD = ${LOCALBASE}/bin/ecl \
+ -q --norc --load
${.CURDIR}/files/ecl-nodebugger.lisp
.else
ERRORS += "Fatal: unknown BOOTSTRAP_METHOD"
@@ -87,11 +89,20 @@ MAKE_ENV += CFLAGS="${CFLAGS} -I${LOCAL
LINKFLAGS="-L${LOCALBASE}/lib" \
MAKEINFO=${PREFIX}/bin/gmakeinfo \
MAN_DIR="${PREFIX}/man/" \
- INFO_DIR="${PREFIX}/info/"
+ INFO_DIR="${PREFIX}/info/" \
+ SBCL_MAKE_JOBS="-j${MAKE_JOBS}"
USE_GMAKE =Yes
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
+post-extract:
+# the build might modify some files. keep original files to help creating
patches.
+.if ${FLAVOR:Mnative_bootstrap}
+. for nn in 30 61 63
+ cp ${WRKSRC}/xperfecthash${nn}.lisp-expr{,${PATCHORIG}}
+. endfor
+.endif
do-configure:
printf '"%s.%s.%s"\n' "${V}" "openbsd" "${FULLPKGNAME}" \
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
diff -u -p -r1.31 distinfo
--- distinfo3 Feb 2024 07:21:34 - 1.31
+++ distinfo30 Mar 2024 10:36:06 -
@@ -1,2 +1,2 @@
-SHA256 (sbcl-2.4.1-source.tar.bz2) =
2k+UhvrUE9OversbCSaTJf20v/fnuI8hld3udDJjz34=
-SIZE (sbcl-2.4.1-source.tar.bz2) = 7800453
+SHA256 (sbcl-2.4.3-source.tar.bz2) =
icmq35K4KtPHSj1PFYoDiJPeoOTzlNyvyWNYPDC3w/I=
+SIZE (sbcl-2.4.3-source.tar.bz2) = 8126417
Index: files/ecl-nodebugger.lisp
===
RCS file: files/ecl-nodebugger.lisp
diff -N files/ecl-nodebugger.lisp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/ecl-nodebugger.lisp 30 Mar 2024 10:36:06 -
@@ -0,0 +1,6 @@
+;; define a debugger hook which exit early
+(setf *debugger-hook*
+ (lambda (c fun)
+(princ c)
+(si::tpl-backtrace)
+(quit 1)))
Index: patches/patch-xperfecthash30_lisp-expr
===
RCS file: patches/patch-xperfecthash30_lisp-expr
diff -N patches/patch-xperfecthash30_lisp-expr
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-xperfecthash30_lisp-expr 30 Mar 2024 10:36:06 -
@@ -0,0 +1,28 @@
+Add some missing entries for bootstrapping from no-sbcl on i386
+
+Index: xperfecthash30.lisp-expr
+--- xperfecthash30.lisp-expr.orig
xperfecthash30.lisp-expr
+@@ -2322,5 +2322,22 @@
+ (#(73FB831 85FCC7A 1025CF34 1A13A884 1CA0C5B8)
+ "(REAL FLOAT DOUBLE-FLOAT SINGLE-FLOAT RATIONAL)"
+ "( (& (+ (>> val 18) (>> val 22)) 7))")
++(#(B1B342 20
update: sysutils/sysclean to 3.8
Hi,
I would like to update sysclean to 3.8. It carries an important update
for 7.5.
Currently, /var/account/acct is created by default by the installer
(file in etc.tgz sets), and daily(8) has automatic processing of the
file for rotating it and create summary files for accounting.
All of that is done whatever is the accounting flag value in
rc.conf.local.
sysclean until 3.8, considers these files as unexpected if accounting is
disabled. In 7.5 release, it will not be the case anymore, so it will be
better if the file aren't reported as unexpected.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - 78d184603e64f0015ebe76b2db388b00c60c035e
path + /home/semarie/repos/openbsd/ports
blob - 3b1ad664d987d971192a0348dd459ff60828ac6d
file + sysutils/sysclean/Makefile
--- sysutils/sysclean/Makefile
+++ sysutils/sysclean/Makefile
@@ -1,6 +1,6 @@
COMMENT = list obsolete files between OpenBSD upgrades
-V =3.7
+V =3.8
DISTNAME = sysclean-${V}
CATEGORIES = sysutils
blob - 077c634c0e152445524e68538afdf7416b4c381d
file + sysutils/sysclean/distinfo
--- sysutils/sysclean/distinfo
+++ sysutils/sysclean/distinfo
@@ -1,2 +1,2 @@
-SHA256 (sysclean-3.7.tar.gz) = eShCxxJEs4iVe8/KlrSSK3BEGo2MxTTV7u9lY1WBCqw=
-SIZE (sysclean-3.7.tar.gz) = 7601
+SHA256 (sysclean-3.8.tar.gz) = 9D4oTi8s4gAmAe2PQnHqrzIWHQTt+2Ep3wK+oWnp13A=
+SIZE (sysclean-3.8.tar.gz) = 7593
update devel/distcc to 3.4
Hi,
The following diff updates devel/distcc to 3.4.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - 828b7c82daa9518c6957ff79fe518bd9a3809417
path + /home/semarie/repos/openbsd/ports
blob - a847351e44ca761e6167dfa7dcb549ad3d28b52b
file + devel/distcc/Makefile
--- devel/distcc/Makefile
+++ devel/distcc/Makefile
@@ -2,13 +2,11 @@ COMMENT-main =distributed builds for C, C++
and Obje
COMMENT-gtk = GTK+ monitor for distcc
COMMENT-server = distcc server
-VERSION = 3.3.5
+VERSION = 3.4
DISTNAME = distcc-${VERSION}
EPOCH =0
CATEGORIES = devel net
-REVISION = 5
-
HOMEPAGE = https://distcc.github.io/
# GPLv2
@@ -37,13 +35,12 @@ WANTLIB-server =${WANTLIB}
LIB_DEPENDS-server = ${LIB_DEPENDS}
LIB_DEPENDS-gtk = ${LIB_DEPENDS} \
- x11/gtk+2
+ x11/gtk+3
RUN_DEPENDS-gtk = devel/desktop-file-utils
-WANTLIB-gtk += ${WANTLIB} X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi
-WANTLIB-gtk += Xinerama Xrandr Xrender atk-1.0 cairo fontconfig
freetype
-WANTLIB-gtk += gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gobject-2.0
-WANTLIB-gtk += gtk-x11-2.0 harfbuzz intl pango-1.0 pangocairo-1.0
-WANTLIB-gtk += pangoft2-1.0 z
+WANTLIB-gtk += ${WANTLIB}
+WANTLIB-gtk += atk-1.0 cairo cairo-gobject gdk-3 gdk_pixbuf-2.0 gio-2.0
+WANTLIB-gtk += glib-2.0 gobject-2.0 gtk-3 harfbuzz intl pango-1.0
+WANTLIB-gtk += pangocairo-1.0
USE_GMAKE =Yes
blob - 245d7f4685575b9e8341591bbd6516b9a70c9ef8
file + devel/distcc/distinfo
--- devel/distcc/distinfo
+++ devel/distcc/distinfo
@@ -1,2 +1,2 @@
-SHA256 (distcc-3.3.5.tar.gz) = eo5Fo6JgG31YBcfVskkY462EtrXMkVMTP0Mv3Mbc5Rg=
-SIZE (distcc-3.3.5.tar.gz) = 1204580
+SHA256 (distcc-3.4.tar.gz) = K5nt2p2tnb8oOTOgLqzm3nQj/lZQ2qSnKMlQ5c03vX0=
+SIZE (distcc-3.4.tar.gz) = 1239519
Re: Remove productivity/tryton
Daniel Dickman writes:
> On Sat, 2 Mar 2024, Sebastien Marie wrote:
>
>> Please note that I am not 100% confident with the quirks part with regex
>> (it seems it is the right way, but additionnals eyes would be welcome).
>
> tryton seems like a unique enough prefix to me, what do you think about
> the below instead?
>
> + 1 => 'proteus',
> + 1 => qr{^tryton},
>
> This is similar to what was done for drupal and I think it should cover
> everything except for proteus.
>
it is similar, while we don't have a port starting with tryton in its
name. it is why a used regex only for ^trytond-module- prefix.
but it might be enough with only the ^tryton prefix. I suppose it will
be time to look that again if some hypothetic port with such name show.
--
Sebastien Marie
Re: Remove productivity/tryton
Sebastien Marie writes:
> Hi,
>
> I would like to remove productivity/tryton.
>
> The current state is the following:
> - 5.0 serie (old LTS) is EOL since november (and requires python3.7 to run)
> - 5.2 serie is EOL
>
I only received invitations to remove them, so next step.
- unhook from the build
- unreserve uid from user.list
- quirks for removal
- (and finally remove the files)
Please note that I am not 100% confident with the quirks part with regex
(it seems it is the right way, but additionnals eyes would be welcome).
Comments or OK ?
--
Sebastien Marie
Index: devel/quirks/files/Quirks.pm
===
RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
retrieving revision 1.1615
diff -u -p -r1.1615 Quirks.pm
--- devel/quirks/files/Quirks.pm2 Mar 2024 04:33:59 - 1.1615
+++ devel/quirks/files/Quirks.pm2 Mar 2024 10:38:14 -
@@ -1914,6 +1914,11 @@ setup_obsolete_reason(
3 => 'smtube',
65 => 'goldendict',
31 => 'mkplaylist',
+ 1 => 'tryton',
+ 1 => 'tryton-sao',
+ 1 => 'proteus',
+ 1 => 'trytond',
+ 1 => qr{^trytond-module-},
);
# though it's not yet used, these should be pkgnames, so that eventually
Index: infrastructure/db/user.list
===
RCS file: /cvs/ports/infrastructure/db/user.list,v
retrieving revision 1.439
diff -u -p -r1.439 user.list
--- infrastructure/db/user.list 29 Feb 2024 10:10:17 - 1.439
+++ infrastructure/db/user.list 2 Mar 2024 10:38:16 -
@@ -183,7 +183,7 @@ id usergroup port
672 _radicale _radicale productivity/radicale
673 _buildbot _buildbot devel/py-buildbot
674 _buildslave_buildslave devel/py-buildslave
-675 _trytond _trytondproductivity/tryton
+#675 _trytond _trytondproductivity/tryton
676 _gdm _gdmx11/gnome/gdm
677 _scamper _scampernet/scamper
678 _owampd_owampd net/owamp
Index: productivity/Makefile
===
RCS file: /cvs/ports/productivity/Makefile,v
retrieving revision 1.111
diff -u -p -r1.111 Makefile
--- productivity/Makefile 29 Sep 2023 18:19:01 - 1.111
+++ productivity/Makefile 2 Mar 2024 10:38:18 -
@@ -52,7 +52,6 @@
SUBDIR += teapot
SUBDIR += thinkingrock
SUBDIR += timewarrior
- SUBDIR += tryton
SUBDIR += tudu
SUBDIR += vdirsyncer
SUBDIR += vit
Re: NEW. sysutils/croc
Paco Esteban writes:
> After reading other comments, I added the README to ${PREFIX}/share/doc/croc/
> This is markdown, so not so pleasant to read from the terminal. But
> it's something.
fine with it.
>> > The software has a "relay" mode in which it acts as a daemon. I did not
>> > include startup scripts or reserve a system user, should we do that ?
>>
>> I don't have strong opinion about it. I am fine without it, but if you
>> expect users to want to setup a local relay, it might be preferable (as
>> it will be properly configured at first).
>
> I added the startup script and user in the end. I think it's better to
> have it even if the user base is small.
the @newuser is a bit odd: you have a home defined to
${LOCALSTATEDIR}/croc , but the directory isn't created by the port.
if the relay mode doesn't need an owned directory as home, just use /var/empty
for the rc script, prefer:
daemon="${TRUEPREFIX}/bin/croc relay"
daemon_flags=""
so the relay command will not be overrided by user setting.
please note that the default configuration (if the user enable the
script) makes the relay to listen to *:90{09,10,11,12,13}. It might be
preferable to listen to localhost by default (even if not really an
useful relay).
daemon_flags="--host localhost"
Thanks.
--
Sebastien Marie
Re: NEW. sysutils/croc
Paco Esteban writes: > Hi ports@, > > cat DESCR > > croc is a tool that allows any two computers to simply and securely > transfer > files and folders. > croc's features include: > > * allow any two computers to transfer data (using a relay) > * end-to-end encryption (using PAKE) > * easy cross-platform transfers (Windows, Linux, Mac) > * multiple file transfers > * resume transfers that are interrupted > * local server or port-forwarding not needed > * ipv6-first with ipv4 fallback > * can use proxy, like tor > > You'll notice than PLIST only contains the binary. The only > documentation they include in the sources is the project README file, > which I'm not sure if we should include in the package. Eventually, it could be possible add just few lines as example in DESC: $ croc send foobar Sending 'foobar' (6.6 MB) Code is: 1767-cubic-ringo-source On the other computer run croc 1767-cubic-ringo-source > The software has a "relay" mode in which it acts as a daemon. I did not > include startup scripts or reserve a system user, should we do that ? I don't have strong opinion about it. I am fine without it, but if you expect users to want to setup a local relay, it might be preferable (as it will be properly configured at first). > Comments and suggestions welcome. > > Ok to import ? There is still a commented "FIX_CLEANUP_PERMISSIONS" in the Makefile. Outside of that, I am fine with it. ok semarie@ Thanks. -- Sebastien Marie
Remove productivity/tryton
Hi, I would like to remove productivity/tryton. The current state is the following: - 5.0 serie (old LTS) is EOL since november (and requires python3.7 to run) - 5.2 serie is EOL It would be possible to invest time to update to 6.0 and/or 7.0 series (both LTS), but it is an huge number of packages to import, and I think any real work with such ERP system needs proper version pinning (in control of the user). So I would like to propose removing them with reason "no benefit to being packaged" or "removed, needs a port maintainer". If someone has interest in it, we could keep them (if updated), and I will drop maintainership of them. Any comments ? -- Sebastien Marie
Re: x11/stumpwm: update to 23.11
Timo Myyrä writes: > On Fri, Feb 16 2024, Kirill A. Korinsky wrote: > >> Greetings, >> >> This is almost clean update which requires one trivial patch which was >> backported as https://github.com/stumpwm/stumpwm/pull/1179 >> >> Tested on amd64. > > Hi, > > The diff reads ok but it should just drop the REVISION line as > the version gets updated. Tested the newer version and works for me in > basic use. > > Timo > I commited the diff (with REVISION removed). Thanks. -- Sebastien Marie
Re: net/matrirc: create port, "--offline mode" error (download crates from github.com)
Manuel Kuklinski writes:
> Hi!
>
> Please excuse my e-mail - I already searched google.com and asked on
> #openbsd at libera.chat but haven't got a satisfying answer. The problem
> is as follows:
>
> I want to create a new port, namely net/matrirc
> (https://github.com/martinetd/matrirc). It's an irc to matrix bridge,
> written in rust, that supports e2e ecnryption. I created a skeleton
> Makefile (excuse the formatting):
>
> [...]
>
> But make fails with the following error:
>
> - - - - - - - - - - %< - - - - - - - - - -
>
> ===> Building for matrirc-1.0
> error: failed to get `irc` as a dependency of package `matrirc v0.1.0
> (/usr/obj/ports/matrirc-1.0/matrirc-1.0)`
>
> Caused by:
> failed to load source for dependency `irc`
>
> Caused by:
> Unable to update
> https://github.com/aatxe/irc?rev=709151b94d9f92a79758e706e6bea219b449e56f#709151b9
>
> Caused by:
> can't checkout from 'https://github.com/aatxe/irc': you are in the offline
> mode (--offline)
>
> - - - - - - - - - - %< - - - - - - - - - -
>
> My question is as follows: how do I get cargo to download the necessary
> crates from github.com, without modifying:
>
> /usr/ports/devel/cargo/cargo.port.mk
>
the devel/cargo module doesn't support fetching crates from arbitrary
git repository. so basically, you can't.
from Cargo.toml, matrirc has two git dependencies:
- irc = { version = "0.15", git = "https://github.com/aatxe/irc";, rev =
"709151b94d9f92a79758e706e6bea219b449e56f" }
- matrix-sdk = { features = ["anyhow"], git =
"https://github.com/matrix-org/matrix-rust-sdk";, rev =
"0b9c082e11955f49f99acd21542f62b40f11c418" }
and they aren't managed by the module.
There is currently no simple way to resolve that.
--
Sebastien Marie
update: devel/distcc to 3.4
Hi,
The following diff updates devel/distcc to the last released version 3.4
(May 11, 2021).
The changelog mentions:
- distccmon-gnome ported from gtk2 to gtk3
- Remove debug lag in spawning new threads. (better multi-core performance)
- Bug fixes.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - da78110bb08bf7832f875e4b0515b72ebd33f1bb
path + /home/semarie/repos/openbsd/ports
blob - a847351e44ca761e6167dfa7dcb549ad3d28b52b
file + devel/distcc/Makefile
--- devel/distcc/Makefile
+++ devel/distcc/Makefile
@@ -2,13 +2,11 @@ COMMENT-main =distributed builds for C, C++
and Obje
COMMENT-gtk = GTK+ monitor for distcc
COMMENT-server = distcc server
-VERSION = 3.3.5
+VERSION = 3.4
DISTNAME = distcc-${VERSION}
EPOCH =0
CATEGORIES = devel net
-REVISION = 5
-
HOMEPAGE = https://distcc.github.io/
# GPLv2
@@ -37,13 +35,12 @@ WANTLIB-server =${WANTLIB}
LIB_DEPENDS-server = ${LIB_DEPENDS}
LIB_DEPENDS-gtk = ${LIB_DEPENDS} \
- x11/gtk+2
+ x11/gtk+3
RUN_DEPENDS-gtk = devel/desktop-file-utils
-WANTLIB-gtk += ${WANTLIB} X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi
-WANTLIB-gtk += Xinerama Xrandr Xrender atk-1.0 cairo fontconfig
freetype
-WANTLIB-gtk += gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gobject-2.0
-WANTLIB-gtk += gtk-x11-2.0 harfbuzz intl pango-1.0 pangocairo-1.0
-WANTLIB-gtk += pangoft2-1.0 z
+WANTLIB-gtk += ${WANTLIB}
+WANTLIB-gtk += atk-1.0 cairo cairo-gobject gdk-3 gdk_pixbuf-2.0 gio-2.0
+WANTLIB-gtk += glib-2.0 gobject-2.0 gtk-3 harfbuzz intl pango-1.0
+WANTLIB-gtk += pangocairo-1.0
USE_GMAKE =Yes
blob - 245d7f4685575b9e8341591bbd6516b9a70c9ef8
file + devel/distcc/distinfo
--- devel/distcc/distinfo
+++ devel/distcc/distinfo
@@ -1,2 +1,2 @@
-SHA256 (distcc-3.3.5.tar.gz) = eo5Fo6JgG31YBcfVskkY462EtrXMkVMTP0Mv3Mbc5Rg=
-SIZE (distcc-3.3.5.tar.gz) = 1204580
+SHA256 (distcc-3.4.tar.gz) = K5nt2p2tnb8oOTOgLqzm3nQj/lZQ2qSnKMlQ5c03vX0=
+SIZE (distcc-3.4.tar.gz) = 1239519
Re: pkg_check -F confusion
Jan Stary writes: > This is current/amd64 on a PC, > with packages freshly updated. > > pkg_check(8) says: > > Other files (option -F) > Checks that there are no other random objects under /usr/local. > > and later > > -F Check the filesystem for random objects > > without saying explictly which filesystem that is. > (/usr/local is a separate filesystem in what follows.) > > Apparently, pkg_check looks at everything from the root down: > > Checking file system ... > System libs NOT in locate dbs: > /usr/lib/libc.so.96.5 > /usr/lib/libc.so.97.0 > /usr/lib/libc.so.97.1 > > Why does pkg_check consider system libraries? > Surely these don't belong to any package. > Also, each of these _is_ in the locate db: > > $ locate libc.so > /usr/lib/libc.so.96.1 > [...] the locate dbs mentionned isn't the one at /var/db/locate.database (updated by weekly(8) and used by default by locate(1)), but the ones at /usr/lib/locate/src.db and /usr/X11R6/lib/locate/xorg.db (installed by the OS at install time). $ locate -d /usr/lib/locate/src.db:/usr/X11R6/lib/locate/xorg.db libc.so base74:/usr/lib/libc.so.98.0 base74:/usr/share/relink/usr/lib/libc.so.98.0.a > Lastly, it looks at /boot and /root/Mail > and the smtpd queue and whatnot. > Why is pkg_check looking at these? > > Unknown files: > /boot > /bsd > /bsd.booted > [...] The method used for reporting unknown files using pkg_check is relatively simple. If you want a more elaborated tool, you could use sysclean(8). The method used by sysclean(8) is explained at https://kapouay.eu.org/notes/sysclean-intro/ . Thanks. -- Sebastien Marie
Re: NEW: devel/zug devel/immer devel/lager (krita update depedencies)
Rafael Sadowski writes: > On Thu Jan 18, 2024 at 09:23:05AM +0100, Sebastien Marie wrote: >> Rafael Sadowski writes: >> >> > Hi All! >> > >> > Would someone be kind enough to review these 3 new ports? There are no >> > heavy dependencies necessary to build it. >> > >> >> Just one question, shouldn't they be using NO_BUILD = Yes ? >> >> If I properly understood, they are headers/source files only >> ports. Currently, when running the 'build' target, the output is the >> following: >> >> ===> Building for zug-0.1.1 >> Change Dir: '/data/semarie/repos/openbsd/ports/pobj/zug-0.1.1/build-amd64' >> >> Run Build Command(s): /usr/local/bin/ninja -v -j 1 >> ninja: no work to do. >> >> >> Thanks. >> -- >> Sebastien Marie >> > > Thanks Sebastien! All ports are happy with NO_BUILD = Yes. OK with this > change? hep. It is fine with me. ok semarie@ to import them. thanks. -- Sebastien Marie
Re: rust-analyzer: proc-macro support broken
Edd Barrett writes:
>
> This does not occur when using the LSP with a rustup-installed toolchain on
> Linux.
>
> I don't recall seeing this error when I was building RA from source (the magic
> command I used to use to build/install was `cargo xtask install --server`).
>
> I notice that in the source code there is a crate called `proc-macro-srv` and
> on my linux box there is a binary `rust-analyzer-proc-macro-srv`. Perhaps this
> is missing?
>
the `rust-analyzer-proc-macro-srv` binary is built with
`crates/proc-macro-srv-cli`.
> I've not had time to look deeper, but wanted to report it here in case someone
> already knows the fix.
I have the following diff for build and installing it:
diff /data/semarie/repos/openbsd/ports
commit - 6e2565794a185e8cfd1a5e1e3f80bc1884d1b0cd
path + /data/semarie/repos/openbsd/ports
blob - a56a1e753ce83d0c6527997479470230c8d4b3b4
file + devel/rust-analyzer/Makefile
--- devel/rust-analyzer/Makefile
+++ devel/rust-analyzer/Makefile
@@ -5,6 +5,8 @@ GH_ACCOUNT =rust-lang
GH_PROJECT = rust-analyzer
GH_TAGNAME = 2023-12-18
+REVISION = 0
+
DISTNAME = ${GH_PROJECT}-${GH_TAGNAME:S/-//g}
HOMEPAGE = https://rust-analyzer.github.io/
@@ -22,7 +24,9 @@ WANTLIB += ${MODCARGO_WANTLIB} m
MODULES = devel/cargo
-MODCARGO_INSTALL_TARGET_PATHS =crates/rust-analyzer
+MODCARGO_INSTALL_TARGET_PATHS =\
+ crates/rust-analyzer \
+ crates/proc-macro-srv-cli
SEPARATE_BUILD = Yes
blob - d4e086558c5f76385160a7c7e168c38ef6ddc975
file + devel/rust-analyzer/pkg/PLIST
--- devel/rust-analyzer/pkg/PLIST
+++ devel/rust-analyzer/pkg/PLIST
@@ -1,4 +1,5 @@
@bin bin/rust-analyzer
+@bin bin/rust-analyzer-proc-macro-srv
share/doc/rust-analyzer/
share/doc/rust-analyzer/manual.adoc
share/doc/rust-analyzer/manual.html
The drawback is the build target isn't enough to build all the parts,
and it is during the fake target that some parts (for
proc-macro-srv-cli) are build.
It would be interesting to know if it is enough for the user who
contacted you.
Thanks.
--
Sebastien Marie
Re: Add devel/rust-analyzer
Edd Barrett writes:
> Hi,
>
>> I am unsure to properly understand here. You need rust,-src and rustfmt
>> to build the port now ?
>
> You're right, that's bogus. Fixed.
>
>> post-build:
>> cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${LOCALBASE}/bin/asciidoctor \
>> docs/user/manual.adoc
>
> Fixed, and using -safe.
>
>> Please install both manual.html and manual.adoc. AsciiDoc format is
>> readable in a terminal.
>
> Fixed.
>
> Diff to previous. OK?
ok semarie@
Thanks.
> diff -urNa /tmp/rust-analyzer/Makefile ./Makefile
> --- /tmp/rust-analyzer/Makefile Fri Jan 19 11:16:07 2024
> +++ ./MakefileFri Jan 19 15:48:07 2024
> @@ -14,9 +14,9 @@
>
> RUN_DEPENDS =lang/rust,-src \
> lang/rust,-rustfmt
> -BUILD_DEPENDS = ${RUN_DEPENDS} \
> - textproc/ruby-rouge \
> +BUILD_DEPENDS = textproc/ruby-rouge \
> textproc/asciidoctor
> +TEST_DEPENDS = lang/rust,-rustfmt
>
> WANTLIB += ${MODCARGO_WANTLIB} m
>
> @@ -34,12 +34,14 @@
>
> # generate manual.html
> post-build:
> - asciidoctor ${WRKSRC}/docs/user/manual.adoc
> + cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
> + ${LOCALBASE}/bin/asciidoctor --safe docs/user/manual.adoc
>
> DOCDIR = ${PREFIX}/share/doc/rust-analyzer
> post-install:
> ${INSTALL_DATA_DIR} ${DOCDIR}
> ${INSTALL_DATA} ${WRKSRC}/docs/user/manual.html ${DOCDIR}
> + ${INSTALL_DATA} ${WRKSRC}/docs/user/manual.adoc ${DOCDIR}
>
> .include "crates.inc"
>
> diff -urNa /tmp/rust-analyzer/pkg/PLIST ./pkg/PLIST
> --- /tmp/rust-analyzer/pkg/PLIST Fri Jan 19 11:13:23 2024
> +++ ./pkg/PLIST Fri Jan 19 15:16:31 2024
> @@ -1,3 +1,4 @@
> @bin bin/rust-analyzer
> share/doc/rust-analyzer/
> +share/doc/rust-analyzer/manual.adoc
> share/doc/rust-analyzer/manual.html
--
Sebastien Marie
Re: Add devel/rust-analyzer
Edd Barrett writes:
> About the latter, the tests expect "stable" to appear in the output of
> `rustfmt
> --version`. But that's not so for our package:
>
> ```
> $ rustfmt --version
> rustfmt 1.7.0-
> ```
>
> I suspect it should return `rustfmt 1.7.0-stable`? CC semarie@
I will take a look at rustfmt.
for now, patching rust-analyzer is fine.
> Anyway, below is a diff showing what I changed, and I've attached a tarball
> for
> convenience.
>
> Still OK?
>
>
> diff -urNa rust-analyzer.old/Makefile rust-analyzer/Makefile
> --- rust-analyzer.old/MakefileFri Jan 19 10:49:54 2024
> +++ rust-analyzer/MakefileFri Jan 19 11:16:07 2024
> @@ -12,7 +12,11 @@
> # MIT OR Apache-2.0
> PERMIT_PACKAGE = Yes
>
> -RUN_DEPENDS =lang/rust,-src
> +RUN_DEPENDS =lang/rust,-src \
> + lang/rust,-rustfmt
> +BUILD_DEPENDS = ${RUN_DEPENDS} \
> + textproc/ruby-rouge \
> + textproc/asciidoctor
I am unsure to properly understand here. You need rust,-src and rustfmt
to build the port now ?
You mentionned rustfmt about tests previously.
>
> WANTLIB += ${MODCARGO_WANTLIB} m
>
> @@ -23,6 +27,19 @@
> SEPARATE_BUILD = Yes
>
> CONFIGURE_STYLE =cargo
> +
> +# Make `rust-analyzer --version` print the right thing.
> +# (otherwise it reports itself as version 0.0.0)
> +MAKE_ENV += CFG_RELEASE=${GH_TAGNAME}
> +
> +# generate manual.html
> +post-build:
> + asciidoctor ${WRKSRC}/docs/user/manual.adoc
> +
I would use a slightly different invocation:
post-build:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${LOCALBASE}/bin/asciidoctor \
docs/user/manual.adoc
it will more constraint the environment seen by asciidoctor (the one
configured in the port, and not the one of the build user).
if possible, I would use `asciidoctor --safe` also, but I didn't check it.
> +DOCDIR = ${PREFIX}/share/doc/rust-analyzer
> +post-install:
> + ${INSTALL_DATA_DIR} ${DOCDIR}
> + ${INSTALL_DATA} ${WRKSRC}/docs/user/manual.html ${DOCDIR}
Please install both manual.html and manual.adoc. AsciiDoc format is
readable in a terminal.
Thanks.
--
Sebastien Marie
Re: NEW: devel/zug devel/immer devel/lager (krita update depedencies)
Rafael Sadowski writes: > Hi All! > > Would someone be kind enough to review these 3 new ports? There are no > heavy dependencies necessary to build it. > Just one question, shouldn't they be using NO_BUILD = Yes ? If I properly understood, they are headers/source files only ports. Currently, when running the 'build' target, the output is the following: ===> Building for zug-0.1.1 Change Dir: '/data/semarie/repos/openbsd/ports/pobj/zug-0.1.1/build-amd64' Run Build Command(s): /usr/local/bin/ninja -v -j 1 ninja: no work to do. Thanks. -- Sebastien Marie
Re: Add devel/rust-analyzer
Theo Buehler writes:
>
> And as semarie pointed out crates.inc should be regenerated to include
> the licenses (make modcargo-gen-crates-licenses)
>
a few more comments.
- license is dual Apache 2.0 / MIT
- SEPARATE_BUILD=Yes is supported
- MODCARGO_RUSTFLAGS setting seems unnecessary (it built fine without it)
- do-install is unnecessary when using MODCARGO_INSTALL_TARGET_PATHS =
crates/rust-analyzer
- MAKE_ENV = ${MODCARGO_ENV} is unnecessary (the default build target
does it already)
Full diff below, with tb@ fixes incorported.
ok semarie@
Thanks.
--
Sebastien Marie
diff -ru rust-analyzer.orig/Makefile rust-analyzer/Makefile
--- rust-analyzer.orig/Makefile Tue Dec 19 12:12:41 2023
+++ rust-analyzer/Makefile Wed Jan 17 16:20:00 2024
@@ -9,24 +9,20 @@
HOMEPAGE = https://rust-analyzer.github.io/
-# Apache 2.0
+# MIT OR Apache-2.0
PERMIT_PACKAGE = Yes
-RUN_DEPENDS = lang/rust-src
+RUN_DEPENDS = lang/rust,-src
-WANTLIB += c c++abi m pthread util
+WANTLIB += ${MODCARGO_WANTLIB} m
MODULES = devel/cargo
-MODCARGO_CRATES_UPDATE = cc libc
-MODCARGO_RUSTFLAGS += -L${PREFIX}/lib
+MODCARGO_INSTALL_TARGET_PATHS =crates/rust-analyzer
-MAKE_ENV = ${MODCARGO_ENV}
+SEPARATE_BUILD = Yes
CONFIGURE_STYLE = cargo
-
-do-install:
- ${INSTALL_PROGRAM} ${MODCARGO_TARGET_DIR}/release/rust-analyzer
${PREFIX}/bin/
.include "crates.inc"
diff -ru rust-analyzer.orig/crates.inc rust-analyzer/crates.inc
--- rust-analyzer.orig/crates.inc Tue Dec 19 11:56:06 2023
+++ rust-analyzer/crates.incWed Jan 17 16:15:14 2024
@@ -1,190 +1,189 @@
-# run: make modcargo-gen-crates-licenses
-MODCARGO_CRATES += addr2line 0.19.0
-MODCARGO_CRATES += adler 1.0.2
-MODCARGO_CRATES += always-assert 0.1.3
-MODCARGO_CRATES += anyhow 1.0.75
-MODCARGO_CRATES += arbitrary 1.3.2
-MODCARGO_CRATES += arrayvec0.7.4
-MODCARGO_CRATES += autocfg 1.1.0
-MODCARGO_CRATES += backtrace 0.3.67
-MODCARGO_CRATES += bitflags1.3.2
-MODCARGO_CRATES += bitflags2.4.1
-MODCARGO_CRATES += byteorder 1.4.3
-MODCARGO_CRATES += camino 1.1.4
-MODCARGO_CRATES += cargo-platform 0.1.2
-MODCARGO_CRATES += cargo_metadata 0.18.1
-MODCARGO_CRATES += cc 1.0.79
-MODCARGO_CRATES += cfg-if 1.0.0
-MODCARGO_CRATES += chalk-derive0.95.0
-MODCARGO_CRATES += chalk-ir0.95.0
-MODCARGO_CRATES += chalk-recursive 0.95.0
-MODCARGO_CRATES += chalk-solve 0.95.0
-MODCARGO_CRATES += command-group 2.1.0
-MODCARGO_CRATES += countme 3.0.1
-MODCARGO_CRATES += cov-mark2.0.0-pre.1
-MODCARGO_CRATES += crc32fast 1.3.2
-MODCARGO_CRATES += crossbeam-channel 0.5.8
-MODCARGO_CRATES += crossbeam-deque 0.8.3
-MODCARGO_CRATES += crossbeam-epoch 0.9.15
-MODCARGO_CRATES += crossbeam-utils 0.8.16
-MODCARGO_CRATES += ctrlc 3.4.1
-MODCARGO_CRATES += dashmap 5.5.3
-MODCARGO_CRATES += derive_arbitrary1.3.2
-MODCARGO_CRATES += dissimilar 1.0.7
-MODCARGO_CRATES += dot 0.1.4
-MODCARGO_CRATES += drop_bomb 0.1.5
-MODCARGO_CRATES += either 1.9.0
-MODCARGO_CRATES += ena 0.14.2
-MODCARGO_CRATES += equivalent 1.0.0
-MODCARGO_CRATES += expect-test 1.4.1
-MODCARGO_CRATES += filetime0.2.22
-MODCARGO_CRATES += fixedbitset 0.4.2
-MODCARGO_CRATES += flate2 1.0.26
-MODCARGO_CRATES += form_urlencoded 1.2.0
-MODCARGO_CRATES += fsevent-sys 4.1.0
-MODCARGO_CRATES += fst 0.4.7
-MODCARGO_CRATES += gimli 0.27.3
-MODCARGO_CRATES += hashbrown 0.14.3
-MODCARGO_CRATES += heck0.4.1
-MODCARGO_CRATES += hermit-abi 0.2.6
-MODCARGO_CRATES += home0.5.5
-MODCARGO_CRATES += idna0.4.0
-MODCARGO_CRATES += indexmap2.1.0
-MODCARGO_CRATES += inotify 0.9.6
-MODCARGO_CRATES += inotify-sys 0.1.5
-MODCARGO_CRATES += itertools 0.12.0
-MODCARGO_CRATES += itoa1.0.6
-MODCARGO_CRATES += jod-thread 0.1.2
-MODCARGO_CRATES += kqueue 1.0.7
-MODCARGO_CRATES += kqueue-sys 1.0.3
-MODCARGO_CRATES += la-arena0.3.1
-MODCARGO_CRATES += lazy_static 1.4.0
-MODCARGO_CRATES += libc0.2.150
-MODCARGO_CRATES += libloading 0.8.0
-MODCARGO_CRATES += libmimalloc-sys 0.1.33
-MODCARGO_CRATES += line-index 0.1.1
-MODCARGO_CRATES += lock_api0.4.10
-MODCARGO_CRATES += log 0.4.19
-MODCARGO_CRATES += lsp-server 0.7.4
-MODCARGO_CRATES += lsp-types 0.94.0
-MODCARGO_CRATES += memchr 2.6.4
-MODCARGO_CRATES += memmap2 0.5.10
-MODCARGO_CRATES += memoffset 0.9.0
-MODCARGO_CRATES += mimalloc0.1.37
-MODCARGO_CRATES += miniz_oxide 0.6.2
-MODCARGO_CRATES += miniz_oxide 0.7.1
-MODCARGO_CRATES += mio 0.8.5
-MODCA
new: devel/c2ffi
Hi, I would like to import c2ffi (https://github.com/rpav/c2ffi), which is a simple program linked against clang libraries, to extracting FFI definitions from C, C++, and Objective C. It produces JSON or SEXP, and another tool could use the output to generate FFI. - cl-autowrap: Create bindings in Common Lisp from a .h with c2ffi using a simple (c-include "file.h") - c2ffi-ruby: Uses the JSON from c2ffi to produce a nicely-formatted Ruby file for ruby-ffi. I intent to use it for cl-autowrap (which depends on c2ffi binary). Comments or OK to import ? -- Sebastien Marie c2ffi.tgz Description: Binary data
Re: Update: PowerDNS Recursor 5.0.1
Otto Moerbeek writes:
> Hi,
>
> this is a somewhat large update as PowerDNS Recursor 5 uses Rust code
> (in addition to C++)
>
> So I would like some extra eyes and OK.
just few small nits:
- removing of patches/patch-mtasker_fcontext_cc is missing from your
diff (but I assume it is present in your tree).
- you want to add MAKE_ENV+= ${MODCARGO_ENV}
to have several options properly passed to underline cargo (mainly
make cargo to respect MAKE_JOBS).
- you want to specify MODCARGO_TARGET_DIR= ${WRKSRC}/settings/rust/target
as the default value for the port (passed via MODCARGO_ENV) makes the
build to fail: settings/rust/Makefile expect the target directory
to be at a know place (so set the target directory to it).
Diff of that below.
else, I am fine with it. ok semarie@
Thanks.
--
Sebastien Marie
diff /data/semarie/repos/openbsd/ports
commit - 3717ead760d2f470ed61b94fb9be46e8d9067f38
path + /data/semarie/repos/openbsd/ports
blob - 94553e4d9b9e123b32a832c030c6108690bc40d3
file + net/powerdns_recursor/Makefile
--- net/powerdns_recursor/Makefile
+++ net/powerdns_recursor/Makefile
@@ -1,8 +1,8 @@
COMMENT= recursive nameserver
-V= 4.9.2
+V= 5.0.1
DISTNAME= pdns-recursor-${V}
-EXTRACT_SUFX = .tar.bz2
+EXTRACT_SUFX= .tar.bz2
PKGNAME= powerdns-recursor-${V}
CATEGORIES=net
@@ -29,6 +29,13 @@ LIB_DEPENDS= devel/boost \
net/libfstrm \
security/libsodium
+MODULES+= devel/cargo
+MODCARGO_CARGOTOML=${WRKSRC}/settings/rust/Cargo.toml
+MODCARGO_TARGET_DIR= ${WRKSRC}/settings/rust/target
+MODCARGO_BUILD=No
+MODCARGO_INSTALL= No
+MODCARGO_TEST= No
+
MODULES+= lang/lua
MODLUA_VERSION=5.3
MODLUA_SA= Yes
@@ -37,8 +44,8 @@ WANTLIB+= ${MODLUA_WANTLIB}
SYSCONFDIR=${BASESYSCONFDIR}/pdns
-CONFIGURE_STYLE= autoreconf
-AUTOCONF_VERSION= 2.69
+CONFIGURE_STYLE= cargo autoreconf
+AUTOCONF_VERSION= 2.71
AUTOMAKE_VERSION= 1.16
USE_GMAKE= Yes
@@ -54,6 +61,8 @@ CONFIGURE_ARGS+= --disable-hardening \
CONFIGURE_ENV+=CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
+MAKE_ENV+= ${MODCARGO_ENV}
+
EXAMPLE_DIR=${PREFIX}/share/examples/pdns/
post-install:
@@ -63,4 +72,6 @@ post-install:
${INSTALL_DATA} ${WRKSRC}/recursor.conf ${EXAMPLE_DIR}
rm ${WRKINST}${SYSCONFDIR}/recursor.conf-dist
+.include "crates.inc"
+
.include
Re: Update: ruby-commonmarker 1.0.3 (switch to Rust backend)
Sebastien Marie writes:
> Jeremy Evans writes:
>
>> The commonmarker gem recently changed the backend they were using from a
>> C-based one (libcmark-gfm), to a Rust-based one (comrak). This required
>> a significant amount of work to get it to continue to build, because:
>>
>> * cargo wants to download the crates at runtime, and the way the cargo
>> module wants to handle this doesn't work for the gem case.
add CONFIGURE_STYLE += cargo , and it will be properly configured to
uses crates from modcargo-crates directory.
>> * One crate needs a source file that doesn't appear to ship in the crate
>> (or the cargo module removes it).
>
> yes, the cargo module removes the sources fixes for several crates, when
> the usual purpose is to build a library from source whereas it is
> present in the ports tree.
>
> if you only need the oniguruma library, you could just add:
> LIB_DEPENDS += textproc/oniguruma
> WANTLIB += onig
to have it properly used, you should also use MODCARGO_ENV:
MAKE_ENV += ${MODCARGO_ENV}
it will pass several environement variable to cargo, in particular one
for oniguruma to ask the config part (build.rs) to use system library.
> the onig_sys crate will first looks at pkg-config to search it (and try
> to build it if not present).
>
> if you need more than the library, you could opt-in to not remove the
> source files using:
> MODCARGO_CRATES_KEEP += onig_sys
>
>> * The cargo module needs to modification (extra variable) to build this,
>> because either it or the ruby module puts the downloaded crates in a
>> different location than expected.
>
>> To get around the last issue, I added MODCARGO_CRATE_EXTRACTDIR to the
>> cargo module. No backwards-incompatible changes for other ports
>> using the cargo module.
>
> I would like to properly understand the issue first. specially as you
> are also redefining lot of paths to have things properly working
> (MODCARGO_VENDOR_DIR and .cargo/config file generation).
>
> I will take a look at it.
the problem is due to lang/ruby module: the EXTRACT_CASES for *.gem
changes the current directory (cd ...) and doesn't go back to the
initial directory.
it could be solved by removing the cd part and use tar -C
diff /data/semarie/repos/openbsd/ports
commit - c6712808d625e9b2beb45cb5a9fa42e6e2df24ee
path + /data/semarie/repos/openbsd/ports
blob - c53117fb73c37e254632d41a0dc353961535cf25
file + lang/ruby/ruby.port.mk
--- lang/ruby/ruby.port.mk
+++ lang/ruby/ruby.port.mk
@@ -192,8 +192,8 @@ _GEM_MAKE= "make V=1"
# signatures.
EXTRACT_CASES += *.gem) \
mkdir ${WRKDIST} ${_GEM_CONTENT}; \
-cd ${_GEM_CONTENT} && tar -xf ${FULLDISTDIR}/$$archive; \
-cd ${WRKDIST} && tar -xzf ${_GEM_DATAFILE} && rm -f ${_GEM_DATAFILE}; \
+tar -xf ${FULLDISTDIR}/$$archive -C ${_GEM_CONTENT}; \
+tar -xzf ${_GEM_DATAFILE} -C ${WRKDIST} && rm -f ${_GEM_DATAFILE}; \
gzcat ${_GEM_CONTENT}/metadata.gz > ${WRKDIST}/.metadata; \
rm -f ${_GEM_CONTENT}/*.gz.sig ${_GEM_CONTENT}/checksums.yaml.gz;;
I don't have deeply tested the diff, only with ruby-commonmarker.
Alternatives are:
- do a 'cd ${WRKDIR}' at end of the case to restore the directory
- enclose the 'cd ... && tar' inside a subshell with ()
>> This also required a new dependency, ruby-rb_sys, which will likely
>> be used by any future Rust-based Ruby ports. Hopefully, the work
>> required to get this port updated will make it easier to get other
>> Rust-based Ruby ports working, should they show up.
>>
I have one small issue with ruby-rb_sys: it is hiding the build of the
crates, so a long part of the build has no output at all. I didn't go
into the source to see if it could be changed in some way, and it could
be done later.
I am fine to import it as it, and revisit it later.
>> This is my first time working on a port using Rust. Maybe there is an
>> easier way or I'm doing something wrong.
>
> The MODCARGO_CRATES lines could go inside an external "crates.inc" file
> and do a .include "crates.inc" in the Makefile. it is usually simpler
> for updating the port.
>
> $ make modcargo-gen-crates > crates.inc
>
> please also re-run the crates.inc generation (after the "make makesum"),
> to have proper licenses information in the file, using
>
> $ make modcargo-gen-crates-licenses > crates.inc
>
>> The use of Rust will probably knock out a few platforms. However, this
>> is a leaf port, so the affect on ports will be minimal.
>>
>> Tested on amd64.
>>
>> OKs for:
>>
>> * cargo module change
for me, lang/ruby module should be corrected.
>> * import ru
Re: Update: ruby-commonmarker 1.0.3 (switch to Rust backend)
Jeremy Evans writes:
> The commonmarker gem recently changed the backend they were using from a
> C-based one (libcmark-gfm), to a Rust-based one (comrak). This required
> a significant amount of work to get it to continue to build, because:
>
> * cargo wants to download the crates at runtime, and the way the cargo
> module wants to handle this doesn't work for the gem case.
>
> * There is a dummy cargo.toml file shipped in top level folder, but it
> is not the one used for building.
you could tell devel/cargo which Cargo.toml to use using:
MODCARGO_CARGOTOML = ${WRKSRC}/shomewhere/Cargo.toml
> * One crate needs a source file that doesn't appear to ship in the crate
> (or the cargo module removes it).
yes, the cargo module removes the sources fixes for several crates, when
the usual purpose is to build a library from source whereas it is
present in the ports tree.
if you only need the oniguruma library, you could just add:
LIB_DEPENDS += textproc/oniguruma
WANTLIB += onig
the onig_sys crate will first looks at pkg-config to search it (and try
to build it if not present).
if you need more than the library, you could opt-in to not remove the
source files using:
MODCARGO_CRATES_KEEP += onig_sys
> * The cargo module needs to modification (extra variable) to build this,
> because either it or the ruby module puts the downloaded crates in a
> different location than expected.
> To get around the last issue, I added MODCARGO_CRATE_EXTRACTDIR to the
> cargo module. No backwards-incompatible changes for other ports
> using the cargo module.
I would like to properly understand the issue first. specially as you
are also redefining lot of paths to have things properly working
(MODCARGO_VENDOR_DIR and .cargo/config file generation).
I will take a look at it.
> This also required a new dependency, ruby-rb_sys, which will likely
> be used by any future Rust-based Ruby ports. Hopefully, the work
> required to get this port updated will make it easier to get other
> Rust-based Ruby ports working, should they show up.
>
> This is my first time working on a port using Rust. Maybe there is an
> easier way or I'm doing something wrong.
The MODCARGO_CRATES lines could go inside an external "crates.inc" file
and do a .include "crates.inc" in the Makefile. it is usually simpler
for updating the port.
$ make modcargo-gen-crates > crates.inc
please also re-run the crates.inc generation (after the "make makesum"),
to have proper licenses information in the file, using
$ make modcargo-gen-crates-licenses > crates.inc
> The use of Rust will probably knock out a few platforms. However, this
> is a leaf port, so the affect on ports will be minimal.
>
> Tested on amd64.
>
> OKs for:
>
> * cargo module change
> * import ruby-rb_sys dependency
> * commonmarker update
>
> Thanks,
> Jeremy
>
Thanks.
--
Sebastien Marie
Re: www/mozilla and lang/rust
Stuart Henderson writes: > On 2024/01/02 08:50, Landry Breuil wrote: >> Le Mon, Jan 01, 2024 at 05:58:21PM +0100, Sebastien Marie a écrit : >> > Hi, >> > >> > I would like to commit the following diff to the www/mozilla module. >> > >> > It switches all ports using www/mozilla to use MODULES+=lang/rust >> > instead of BUILD_DEPENDS+=lang/rust, and adds MODRUST_WANTLIB to >> > WANTLIB. >> > >> > It makes these ports to use _SYSTEM_VERSION-rust and be bumped >> > automatically when rust (compiler or stdlib) changes, and so get the >> > package updated. >> > >> > It should affect: >> > - mail/mozilla-thunderbird >> > - www/tor-browser/browser >> > - www/firefox-esr >> > - www/mozilla-firefox >> > - www/seamonkey >> > >> > Comments or OK ? >> >> i suppose it needs a bump of REVISION for the consumers, if that changes >> WANTLIB ? > > If I read correctly, it shouldn't make an actual change to the @wantlib > lines in packages (which is sorted and deduplicated), so I believe bumps > are not needed. > in this particular case, I think that WANTLIB doesn't change (but I am not completely sure for all archs). But even if the WANTLIB changed, the ports is now using MODULES+=lang/rust, and it makes the @version tag to be bumped (_SYSTEM_VERSION-rust = 1 , actually). So REVISION bump wouldn't be necessary. -- Sebastien Marie
devel/spidermonkey115, x11/gnome/tour and lang/rust
Hi,
I would like to commit the following diffs to devel/spidermonkey115 and
x11/gnome/tour.
It switches the ports to use MODULES+=lang/rust instead of
BUILD_DEPENDS+=lang/rust, and adds MODRUST_WANTLIB to WANTLIB.
It makes the ports to use _SYSTEM_VERSION-rust and be bumped
automatically when rust (compiler or stdlib) changes, and so get the
package updated.
Comments or OK ?
--
Sebastien Marie
Index: devel/spidermonkey115/Makefile
===
RCS file: /cvs/ports/devel/spidermonkey115/Makefile,v
diff -u -p -r1.3 Makefile
--- devel/spidermonkey115/Makefile 20 Dec 2023 13:58:42 - 1.3
+++ devel/spidermonkey115/Makefile 1 Jan 2024 16:14:29 -
@@ -30,9 +30,10 @@ EXTRACT_SUFX = .tar.xz
PERMIT_PACKAGE=Yes
WANTLIB += curses ffi icudata icui18n icuuc m nspr4 plc4 plds4 z
-WANTLIB += ${COMPILER_LIBCXX}
+WANTLIB += ${COMPILER_LIBCXX} ${MODRUST_WANTLIB}
-MODULES = lang/python
+MODULES = lang/python \
+ lang/rust
MODPY_RUNDEP = No
@@ -47,8 +48,7 @@ LIB_DEPENDS = devel/libffi \
DEBUG_PACKAGES = ${BUILD_PACKAGES}
-BUILD_DEPENDS =devel/cbindgen \
- lang/rust
+BUILD_DEPENDS =devel/cbindgen
SEPARATE_BUILD = Yes
WRKDIST = ${WRKDIR}/firefox-${V}
Index: x11/gnome/tour/Makefile
===
RCS file: /cvs/ports/x11/gnome/tour/Makefile,v
diff -u -p -r1.14 Makefile
--- x11/gnome/tour/Makefile 8 Nov 2023 18:49:09 - 1.14
+++ x11/gnome/tour/Makefile 1 Jan 2024 16:14:29 -
@@ -13,15 +13,14 @@ DISTFILES= ${GNOME_PROJECT}-${GNOME_VER
# gnome-tour source code results in effective GPLv3+ for the resulting binary
PERMIT_PACKAGE=Yes
-WANTLIB += adwaita-1 c c++abi gio-2.0 glib-2.0 gobject-2.0 gtk-4
-WANTLIB += intl m pthread
+WANTLIB += ${MODRUST_WANTLIB}
+WANTLIB += adwaita-1 gio-2.0 glib-2.0 gobject-2.0 gtk-4 intl m
MODULES= devel/meson \
+ lang/rust \
x11/gnome
MODGNOME_TOOLS=desktop-file-utils gtk-update-icon-cache
-
-BUILD_DEPENDS= lang/rust
LIB_DEPENDS= x11/gnome/libadwaita
www/mozilla and lang/rust
Hi,
I would like to commit the following diff to the www/mozilla module.
It switches all ports using www/mozilla to use MODULES+=lang/rust
instead of BUILD_DEPENDS+=lang/rust, and adds MODRUST_WANTLIB to
WANTLIB.
It makes these ports to use _SYSTEM_VERSION-rust and be bumped
automatically when rust (compiler or stdlib) changes, and so get the
package updated.
It should affect:
- mail/mozilla-thunderbird
- www/tor-browser/browser
- www/firefox-esr
- www/mozilla-firefox
- www/seamonkey
Comments or OK ?
--
Sebastien Marie
Index: www/mozilla/mozilla.port.mk
===
RCS file: /cvs/ports/www/mozilla/mozilla.port.mk,v
diff -u -p -r1.171 mozilla.port.mk
--- www/mozilla/mozilla.port.mk 19 Dec 2023 14:23:43 - 1.171
+++ www/mozilla/mozilla.port.mk 1 Jan 2024 16:14:29 -
@@ -112,7 +112,8 @@ MODMOZ_BUILD_DEPENDS += devel/nasm
.endif
# 53 needs rust
-MODMOZ_BUILD_DEPENDS +=lang/rust
+MODULES += lang/rust
+MODMOZ_WANTLIB += ${MODRUST_WANTLIB}
#1670807
MODMOZ_BUILD_DEPENDS +=devel/m4
security/suricata and lang/rust
Hi,
I would like to commit the following diff to security/suricata.
It switches suricata to use MODULES+=lang/rust instead of
BUILD_DEPENDS+=lang/rust, and adds MODRUST_WANTLIB to WANTLIB.
It makes the ports to use _SYSTEM_VERSION-rust and be bumped
automatically when rust (compiler or stdlib) changes, and so get the
package updated.
Comments or OK ?
--
Sebastien Marie
Index: security/suricata/Makefile
===
RCS file: /cvs/ports/security/suricata/Makefile,v
diff -u -p -r1.63 Makefile
--- security/suricata/Makefile 17 Dec 2023 15:29:06 - 1.63
+++ security/suricata/Makefile 1 Jan 2024 16:14:29 -
@@ -21,15 +21,16 @@ PERMIT_PACKAGE= Yes
SITES =https://www.openinfosecfoundation.org/download/
# uses pledge()
-WANTLIB += ${COMPILER_LIBCXX} c elf iconv jansson lz4 m magic maxminddb
+WANTLIB += ${COMPILER_LIBCXX} ${MODRUST_WANTLIB}
+WANTLIB += elf iconv jansson lz4 m magic maxminddb
WANTLIB += net pcap pcre2-8 yaml-0 z
-MODULES = lang/python
+MODULES = lang/python \
+ lang/rust
BUILD_DEPENDS =devel/py-setuptools${MODPY_FLAVOR} \
textproc/py-sphinx${MODPY_FLAVOR} \
- textproc/py-yaml${MODPY_FLAVOR} \
- lang/rust
+ textproc/py-yaml${MODPY_FLAVOR}
RUN_DEPENDS = textproc/py-yaml${MODPY_FLAVOR}
security/clamav and lang/rust
Hi, I would like to commit the following diff to security/clamav. It switches clamav to use MODULES+=lang/rust instead of BUILD_DEPENDS+=lang/rust, and adds MODRUST_WANTLIB to WANTLIB. It makes the ports to use _SYSTEM_VERSION-rust and be bumped automatically when rust (compiler or stdlib) changes, and so get the package updated. Comments or OK ? -- Sebastien Marie Index: security/clamav/Makefile === RCS file: /cvs/ports/security/clamav/Makefile,v diff -u -p -r1.166 Makefile --- security/clamav/Makefile26 Oct 2023 06:40:00 - 1.166 +++ security/clamav/Makefile1 Jan 2024 16:14:29 - @@ -15,13 +15,12 @@ MAINTAINER= Stuart Henderson https://www.clamav.net/downloads/production/ -MODULES= devel/cmake +MODULES= devel/cmake \ + lang/rust CONFIGURE_ARGS=-DCLAMAV_USER=_clamav \ -DCLAMAV_GROUP=_clamav \ -DENABLE_EXTERNAL_MSPACK=ON \
lang/ruby: YJIT JIT compiler and lang/rust
Hi,
I would like to commit the following diff to ruby/3.2 and ruby/3.3.
It switches ruby to use MODULES+=lang/rust instead of
BUILD_DEPENDS+=lang/rust.
It makes the ports to use _SYSTEM_VERSION-rust and be bumped
automatically when rust (compiler or stdlib) changes, and so get the
package updated.
Comments or OK ?
--
Sebastien Marie
Index: lang/ruby/3.2/Makefile
===
RCS file: /cvs/ports/lang/ruby/3.2/Makefile,v
diff -u -p -r1.7 Makefile
--- lang/ruby/3.2/Makefile 27 Dec 2023 20:06:42 - 1.7
+++ lang/ruby/3.2/Makefile 1 Jan 2024 14:33:44 -
@@ -15,7 +15,7 @@ FLAVOR?=
.if ${MACHINE_ARCH:Mamd64} || ${MACHINE_ARCH:Maarch64}
# Support YJIT JIT compiler on arches Ruby supports
-BUILD_DEPENDS += lang/rust
+MODULES += lang/rust
WANTLIB-main +=c++abi
MAKE_ENV +=LIBRUBY_DLDFLAGS="-lc++abi"
.endif
Index: lang/ruby/3.3/Makefile
===
RCS file: /cvs/ports/lang/ruby/3.3/Makefile,v
diff -u -p -r1.1.1.1 Makefile
--- lang/ruby/3.3/Makefile 27 Dec 2023 20:04:59 - 1.1.1.1
+++ lang/ruby/3.3/Makefile 1 Jan 2024 14:33:45 -
@@ -16,7 +16,7 @@ FLAVOR?=
.if ${MACHINE_ARCH:Mamd64} || ${MACHINE_ARCH:Maarch64}
# Support YJIT JIT compiler on arches Ruby supports
-BUILD_DEPENDS += lang/rust
+MODULES += lang/rust
WANTLIB-main +=c++abi
MAKE_ENV +=LIBRUBY_DLDFLAGS="-lc++abi"
.endif
Re: lang/rust: roadmap for using SYSTEM_VERSION
- RUSTDOC=${LOCALBASE}/bin/rustdoc \
+ RUSTC=${MODRUST_RUSTC_BIN} \
+ RUSTDOC=${MODRUST_RUSTDOC_BIN} \
RUSTFLAGS="${MODCARGO_RUSTFLAGS}"
# Helper to shorten cargo calls.
The downside of the approch is the transition needs to be more in
one-time, as there is no more "old way" and "new way": both can't
coexist. As soon devel/cargo is modified to use lang/rust module, things
are bumped so there are expected to be right which, after review, isn't
the case at all.
The current status of rust ports is that on 78 ports, 33 ports has wrong
WANTLIB (not using MODCARGO_WANTLIB and hardcoding c++abi).
In a first time, I will correct that (by abusing a typo in the current
devel/cargo module which made MODCARGO_WANTLIB is "c pthread c++abi" in
all cases even on sparc64). And once the tree would be more clean,
add the lang/rust module and modify devel/cargo to use it.
I add below a full diff I have for now. I will see with some MAINTAINER
before changing ports.
Any comments ?
--
Sebastien Marie
? ports.diff
Index: databases/influxdb/Makefile
===
RCS file: /cvs/ports/databases/influxdb/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- databases/influxdb/Makefile 3 Dec 2023 16:57:35 - 1.29
+++ databases/influxdb/Makefile 1 Jan 2024 06:12:01 -
@@ -17,22 +17,25 @@ PERMIT_PACKAGE =Yes
MODULES = lang/go \
devel/cargo
-BUILD_DEPENDS =${MODCARGO_BUILD_DEPENDS} \
- textproc/xmlto \
+BUILD_DEPENDS =textproc/xmlto \
textproc/asciidoc
#some dists have -w
FIX_CLEANUP_PERMISSIONS = Yes
-WANTLIB += c c++abi pthread
+WANTLIB += ${MODCARGO_WANTLIB}
COMPILER = base-clang ports-gcc
MODCARGO_BUILD = No
MODCARGO_INSTALL = No
MODCARGO_CARGOTOML =
${WRKDIR}/go/pkg/mod/github.com/influxdata/flux@v0.194.3/libflux/Cargo.toml
MODCARGO_TARGET_DIR =
${WRKDIR}/go/pkg/mod/github.com/influxdata/flux@v0.194.3/libflux/target
+
+.if ${MACHINE_ARCH} != "sparc64"
# needed to make sure unwind* symbols are found
MODCARGO_RUSTFLAGS +=-C link-arg=-lc++abi
CGO_LDFLAGS=-lc++abi
+.endif
+
MAKE_ENV +=${MODCARGO_ENV} CGO_LDFLAGS=${CGO_LDFLAGS}
MAKE_ENV +=PKG_CONFIG=${WRKSRC}/scripts/pkg-config.sh
.include "crates.inc"
Index: devel/cargo/cargo.port.mk
===
RCS file: /cvs/ports/devel/cargo/cargo.port.mk,v
retrieving revision 1.41
diff -u -p -r1.41 cargo.port.mk
--- devel/cargo/cargo.port.mk 6 Nov 2023 20:44:36 - 1.41
+++ devel/cargo/cargo.port.mk 1 Jan 2024 06:12:01 -
@@ -1,4 +1,4 @@
-CATEGORIES += lang/rust
+MODULES += lang/rust
# List of static dependencies. The format is cratename-version.
# MODCARGO_CRATES will be downloaded from SITES_CRATESIO.
@@ -24,20 +24,8 @@ MODCARGO_VENDOR_DIR ?= ${WRKSRC}/modcarg
MODCARGO_CARGOTOML ?= ${WRKSRC}/Cargo.toml
# WANTLIB for Rust compiled code
-# it should be kept in sync with lang/rust code
-# - c/pthread : all syscalls
-# - c++abi / libgcc.a : unwind
-MODCARGO_WANTLIB = c pthread
-
-.if "${MARCHINE_ARCH}" != "sparc64"
-MODCARGO_WANTLIB +=c++abi
-.else
-# libgcc.a is static
-MODCARGO_WANTLIB +=
-.endif
-
+MODCARGO_WANTLIB = ${MODRUST_WANTLIB}
CHECK_LIB_DEPENDS_ARGS += -S MODCARGO_WANTLIB="${MODCARGO_WANTLIB}"
-CHECK_LIB_DEPENDS_ARGS += -F c++abi
# Define SITES_CRATESIO for crates.io
SITES.cargo = https://crates.io/api/v1/crates/
@@ -274,16 +262,9 @@ MODCARGO_configure += ;
.endif
# Build dependencies.
-MODCARGO_BUILD_DEPENDS = lang/rust
-
# devel/cargo-generate-vendor is mandatory for hooks.
BUILD_DEPENDS += devel/cargo-generate-vendor
-MODCARGO_BUILDDEP ?= Yes
-.if ${MODCARGO_BUILDDEP:L} == "yes"
-BUILD_DEPENDS += ${MODCARGO_BUILD_DEPENDS}
-.endif
-
# Location of cargo binary (default to devel/cargo binary)
MODCARGO_CARGO_BIN ?= ${LOCALBASE}/bin/cargo
@@ -305,8 +286,8 @@ MODCARGO_ENV += \
CARGO_BUILD_JOBS=${MAKE_JOBS} \
CARGO_TARGET_DIR=${MODCARGO_TARGET_DIR} \
RUST_BACKTRACE=full \
- RUSTC=${LOCALBASE}/bin/rustc \
- RUSTDOC=${LOCALBASE}/bin/rustdoc \
+ RUSTC=${MODRUST_RUSTC_BIN} \
+ RUSTDOC=${MODRUST_RUSTDOC_BIN} \
RUSTFLAGS="${MODCARGO_RUSTFLAGS}"
# Helper to shorten cargo calls.
Index: devel/cargo-audit/Makefile
===
RCS file: /cvs/ports/devel/cargo-audit/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- devel/cargo-audit/Makefile 21 Sep 2023 09:49:49 - 1.8
+++ devel/cargo-audit/Makefile 1 Jan 2024 06:12:01 -
@@ -17,7 +17,7 @@ HOMEPAGE =https://github.com/RustSec/r
# Apache 2/MIT
PERMIT_PACKAGE = Yes
-WANTLIB += c
Re: lang/rust: roadmap for using SYSTEM_VERSION
Theo Buehler writes:
> On Sat, Dec 30, 2023 at 07:32:18PM +0100, Sebastien Marie wrote:
>
> The outlined procedure makes sense to me and I like the approach, but I
> am a bit worried that it makes it harder for people to write Rust ports
> using the devel/cargo module, which is already tricky.
>
> Porters will now need to be able to grasp the separation of concerns to
> understand the distinction between the devel/cargo and lang/rust
> modules. They must now deal with two sets of variables: MODCARGO_* and
> MODRUST_*. The latter only has two user-visible bits for now, so maybe
> it's not that bad.
initially, I tried to hide the "lang/rust" module under "devel/cargo"
module (and have devel/cargo to sets MODULES+=lang/rust), but
arch-defines.mk is included before MODULES processing, which means that
the test ${MODULES:Mlang/rust} to check if lang/rust module is here or
not isn't trigger as the module comes too late in the variable.
Regarding MODCARGO_WANTLIB to MODRUST_WANTLIB transition, it might be
possible to define the first using the second (MODCARGO_WANTLIB =
${MODRUST_WANTLIB}).
But I am unsure if it would really help or not.
I don't intent to push lot of configuration variables in MODRUST_*. In
fact, only the minimal sets: if a port is using lang/rust module alone
without devel/cargo, it usually means the build to be somehow custom, so
no need to try to add magic.
> A small nit below. At the end is a small diff for port-modules which
> you can tweak and commit once we decide to go ahead with your plan.
thanks.
>> commit - a1995e6a715404d542f5d69eadb9a9bac7bbca61
>> path + /home/semarie/repos/openbsd/ports
>> blob - 4c5723bf509e5aaaf1541b76acd3b48119bb5b7c
>> file + devel/cargo/cargo.port.mk
>> --- devel/cargo/cargo.port.mk
>> +++ devel/cargo/cargo.port.mk
>> @@ -1,4 +1,8 @@
>> -CATEGORIES += lang/rust
>> +# we can't just add lang/rust to MODULES
>> +# it makes _SYSTEM_VERSION-rust (in arch-defines.mk) not properly defined
>> +.if defined(MODULES) && ! ${MODULES:Mlang/rust}
>> +ERRORS += "devel/cargo module needs also lang/rust in MODULES"
>
> this should be 'also needs'
>
> ERRORS += "devel/cargo requires lang/rust to be set in MODULES"
>
>> +.endif
>>
>
> Index: port-modules.5
> ===
> RCS file: /cvs/src/share/man/man5/port-modules.5,v
> diff -u -p -r1.266 port-modules.5
> --- port-modules.514 Sep 2023 03:53:26 - 1.266
> +++ port-modules.531 Dec 2023 08:33:48 -
> @@ -978,6 +978,20 @@ See
> .It lang/ruby
> See
> .Xr ruby-module 5 .
> +.It lang/rust
> +Ports using Rust must use this module so a rebuild can be triggered via
> +.Ev SYSTEM_VERSION-rust
> +on updates of the lang/rust port or changes to the Rust standard library.
> +Sets
> +.Ev MODRUST_WANTLIB
> +as appropriate for the architecture so it can be added to
> +.Ev WANTLIB .
> +It adds lang/rust to the
> +.Ev BUILD_DEPENDS
> +unless
> +.Ev MODRUST_BUILDDEP
> +is set to anything but
> +.Dq yes .
> .It lang/tcl
> Sets
> .Ev MODTCL_VERSION ,
--
Sebastien Marie
lang/rust: roadmap for using SYSTEM_VERSION
Hi,
We need a way to bump all ports built using lang/rust when the port is
updated (compiler change or rust stdlib changes).
Currently, lang/go is using SYSTEM_VERSION-go variable for that, so I
intent to copy the mecanism for rustc.
I can't simply use devel/cargo module for that: some (usually complexes)
ports aren't using it but are using rustc and rust stdlib. So I would
like to add a lang/rust module for this purpose, and move the bits
specific to rustc from devel/cargo to this new lang/rust module (mostly
the WANTLIB definition for code using rust stdlib).
We have 77 ports with lang/rust inside BUILD_DEPENDS. So modifying all
of them is doable but require a bit of preparation.
I intent to do the following:
1. add the lang/rust module and add the arch-defines.mk bits for
SYSTEM_VERSION-rust
nothing is using it at this stage. no changes.
2. modify all the ports (one by one) using lang/rust as compiler to use
the module lang/rust.
as soon MODULES += lang/rust is added, the port will be automatically
bumped (due to SYSTEM_VERSION-rust), which is fine (I modified the rust
stdlib on 30.12.2023, and all ports would need a bump anyway).
I will do the conversion from using MODCARGO_WANTLIB to MODRUST_WANTLIB
in the port at the same time.
During the step, both "new way" and "old way" will coexist and shouldn't
conflict. A port will be either "new way" or "old way".
3. modify the devel/cargo module to remove unused bits
(MODCARGO_WANTLIB), and add some checks for ensuring using devel/cargo
implies using also lang/rust.
It is mostly a cleaning step, and to ensure a hard fail if the "old way"
is used (missing changes, and new code added using "old way").
Diffs for 1 and 3 are below. Step 2 could be done on the fly with
MAINTAINER in Cc for the more complex cases.
Any comments or OK ?
--
Sebastien Marie
Step 1 diffs:
diff /home/semarie/repos/openbsd/ports/mystuff/lang/rust
commit - 14500989167797cabee408b40583056fe24a9f23
path + /home/semarie/repos/openbsd/ports/mystuff/lang/rust
blob - /dev/null
file + rust.port.mk (mode 640)
--- /dev/null
+++ rust.port.mk
@@ -0,0 +1,30 @@
+# increment after rust compiler update to trigger updates of
+# all compiled rust packages (see arch-defines.mk)
+_MODRUST_SYSTEM_VERSION = 1
+
+CATEGORIES += lang/rust
+
+# WANTLIB for Rust compiled code
+# it should be kept in sync with lang/rust code
+# - c/pthread : all syscalls
+# - c++abi / libgcc.a : unwind
+MODRUST_WANTLIB += c pthread
+
+.if "${MACHINE_ARCH}" != "sparc64"
+MODRUST_WANTLIB += c++abi
+.else
+# libgcc.a is static
+MODRUST_WANTLIB +=
+.endif
+
+CHECK_LIB_DEPENDS_ARGS += -S MODRUST_WANTLIB="${MODRUST_WANTLIB}"
+CHECK_LIB_DEPENDS_ARGS += -F c++abi
+
+MODRUST_BUILDDEP ?=Yes
+.if ${MODRUST_BUILDDEP:L} == "yes"
+BUILD_DEPENDS += lang/rust
+.endif
+
+# Location of rustc/rustdoc binaries
+MODRUST_RUSTC_BIN =${LOCALBASE}/bin/rustc
+MODRUST_RUSTDOC_BIN = ${LOCALBASE}/bin/rustdoc
diff /home/semarie/repos/openbsd/ports
commit - a1995e6a715404d542f5d69eadb9a9bac7bbca61
path + /home/semarie/repos/openbsd/ports
blob - dacb59716e3724cd0aad0110c42d6b2c1f672bfb
file + infrastructure/mk/arch-defines.mk
--- infrastructure/mk/arch-defines.mk
+++ infrastructure/mk/arch-defines.mk
@@ -105,6 +105,12 @@ _SYSTEM_VERSION-clang = 2
_SYSTEM_VERSION-go = ${_MODGO_SYSTEM_VERSION}
.endif
+# defined in rust.port.mk; added to version for all rust arches so that
+# rust-compiled packages can be updated easily for a new rust compiler
+.if defined(MODULES) && ${MODULES:Mlang/rust}
+_SYSTEM_VERSION-rust = ${_MODRUST_SYSTEM_VERSION}
+.endif
+
# @version = ${_SYSTEM_VERSION} + ${_SYSTEM_VERSION-${MACHINE_ARCH}}
_PKG_ARGS_VERSION += -V ${_SYSTEM_VERSION} -V
${_SYSTEM_VERSION-${MACHINE_ARCH}}
.if ${ARCH} != ${MACHINE_ARCH}
Step 3 diff:
diff /home/semarie/repos/openbsd/ports
commit - a1995e6a715404d542f5d69eadb9a9bac7bbca61
path + /home/semarie/repos/openbsd/ports
blob - 4c5723bf509e5aaaf1541b76acd3b48119bb5b7c
file + devel/cargo/cargo.port.mk
--- devel/cargo/cargo.port.mk
+++ devel/cargo/cargo.port.mk
@@ -1,4 +1,8 @@
-CATEGORIES += lang/rust
+# we can't just add lang/rust to MODULES
+# it makes _SYSTEM_VERSION-rust (in arch-defines.mk) not properly defined
+.if defined(MODULES) && ! ${MODULES:Mlang/rust}
+ERRORS += "devel/cargo module needs also lang/rust in MODULES"
+.endif
# List of static dependencies. The format is cratename-version.
# MODCARGO_CRATES will be downloaded from SITES_CRATESIO.
@@ -23,22 +27,6 @@ MODCARGO_VENDOR_DIR ?= ${WRKSRC}/modcargo-crates
# Default path for cargo manifest.
MODCARGO_CARGOTOML ?= ${WRKSRC}/Cargo.toml
-# WANTLIB for Rust compiled code
-# it should be kept in sync with lang/rust code
-# - c/pthread : all syscalls
-# - c++abi / libgcc.a : unwind
-MODCARGO_WANTLIB = c pthread
-
-.if
py-bcrypt wrong WANTLIB
Hi,
The following patch add MODCARGO_WANTLIB to WANTLIB.
It is required as python3.10/site-packages/bcrypt/_bcrypt.abi3.so file
reference libc++abi and libc.
0x0001 (NEEDED) Shared library: [libc++abi.so.6.0]
0x0001 (NEEDED) Shared library: [libc.so.98.0]
Without it, py3-bcrypt isn't updated when libc is bumped.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - 02bae0e33157daec047bd3f8064ef4dc3d7f19d9
path + /home/semarie/repos/openbsd/ports
blob - a75fa6b9dd49d531ab6f9ce09f3b992a5c0600ef
file + security/py-bcrypt/Makefile
--- security/py-bcrypt/Makefile
+++ security/py-bcrypt/Makefile
@@ -4,6 +4,7 @@ MODPY_EGG_VERSION= 4.1.1
DISTNAME= bcrypt-${MODPY_EGG_VERSION}
DISTFILES= bcrypt-${MODPY_EGG_VERSION}${EXTRACT_SUFX}
PKGNAME= py-${DISTNAME}
+REVISION= 0
.include "crates.inc"
@@ -12,7 +13,7 @@ CATEGORIES= security
# Apache License 2.0
PERMIT_PACKAGE=Yes
-WANTLIB += pthread ${MODPY_WANTLIB}
+WANTLIB += pthread ${MODPY_WANTLIB} ${MODCARGO_WANTLIB}
COMPILER= base-clang ports-gcc
COMPILER_LANGS=c
Re: 回复: math/igraph: Update to 0.10.8
wen heping writes: > ping ... > > > 发件人: owner-po...@openbsd.org 代表 wen heping > > 发送时间: 2023年12月8日 20:02 > 收件人: ports@openbsd.org > 主题: math/igraph: Update to 0.10.8 > > Hi, ports@: > > Here is a patch for math/igraph: > i) Update to 0.10.8 > ii) Enable `make -test`. (`make test` does not work in current version) > It build and run well on amd64-current system, and 100% tests pass. I commited the update, with small tweak for make test (to properly pass some environment configuration and build options). Thanks. -- Sebastien Marie
Re: wayland/sway: build fix and link to the tree
Matthieu Herrb writes:
>
> Here's a diff that allows sway to be linked, and patches the default
> config to use xterm (and also installs swaybg to have the default
> wallpaper)
>
> It also adds a startsway.sh script to start sway and updates DESCR
> accordingly
just some nits in startsway.sh
> Note that the build fix was already committed independently.
>
> ok?
else I am fine. ok semarie@
> Index: files/startsway.sh
> ===
> RCS file: files/startsway.sh
> diff -N files/startsway.sh
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ files/startsway.sh30 Nov 2023 21:10:29 -
> @@ -0,0 +1,13 @@
> +#! /bin/ksh
> +export XDG_RUNTIME_DIR=${HOME}/.local/run
> +if [ ! -d $XDG_RUNTIME_DIR ]; then
> +mkdir -m 700 -p $XDG_RUNTIME_DIR
> +fi
I would be a bit more defensive with env variables, and use
"${XDG_RUNTIME_DIR}" instead of $XDG_RUNTIME.
> +export WLR_DRM_DEVICES=/dev/dri/card0
> +export LIBSEAT_BACKEND=noop
> +
> +# Tell applications to use Wayland
> +# export MOZ_ENABLE_WAYLAND=1 # doesn't work yet
> +export XDG_CURRENT_DESKTOP=sway
> +
> +exec /usr/local/bin/sway $*
and variables should be overridable by the user.
An alternative script could be something like:
#!/bin/ksh
set -eu
: ${XDG_RUNTIME_DIR:=/tmp/run/$(/usr/bin/id -u)}
: ${WLR_DRM_DEVICES:=/dev/dri/card0}
: ${LIBSEAT_BACKEND:=noop}
#: ${MOZ_ENABLE_WAYLAND:=1} # doesn't work yet
: ${XDG_CURRENT_DESKTOP:=sway}
export XDG_RUNTIME_DIR WLR_DRM_DEVICES LIBSEAT_BACKEND CURRENT_DESKTOP
if [ ! -d "${XDG_RUNTIME_DIR}" ]; then
mkdir -m 700 -p "${XDG_RUNTIME_DIR}"
fi
exec /usr/local/bin/sway "$@"
- base id(1) is used (and not random one from PATH)
- the variables are defined to default values if not already present
- [ and mkdir are resistants to spaces inside XDG_RUNTIME
- sway is invoked without losing NULL arguments or splitting arguments
with spaces
Thanks.
--
Sebastien Marie
wayland/sway: build fix and link to the tree
Hi, The following patch makes wayland/sway to link to the tree (remove UNLINKED) and remove the RUN_DEPENDS on wayland/foot (which is still UNLINKED). foot is only need if you set it to be your "preferred terminal". it is a runtime configuration. a meta package (with sway, foot, swaylock, swayidle, …) might be a better solution to have a minimal "sway-desktop" working installation. This way, sway could be installable via package, and ease the testing. I also added wayland/wayland-protocols as BUILD_DEPENDS due to configure error if the package isn't here. The revision isn't bumped (port not linked), but it might be preferable to avoid local installation to plistdb conflict with package (changed rdepends). I could add a REVISION=0. Comments or OK ? -- Sebastien Marie diff /home/semarie/repos/openbsd/ports commit - cd569fb13fcce17ed39e026ce9ee6eb9f4c7b3a6 path + /home/semarie/repos/openbsd/ports blob - 71caf335dc6d6cf044c1bb7679de268326bbd52a file + wayland/sway/Makefile --- wayland/sway/Makefile +++ wayland/sway/Makefile @@ -1,5 +1,4 @@ COMMENT = i3-compatible Wayland compositor -UNLINKED = wayland GH_ACCOUNT = swaywm GH_PROJECT = sway @@ -23,7 +22,8 @@ WANTLIB +=c m BUILD_DEPENDS = \ graphics/gdk-pixbuf2 \ - textproc/scdoc + textproc/scdoc \ + wayland/wayland-protocols LIB_DEPENDS = devel/json-c \ devel/pango \ @@ -34,8 +34,7 @@ LIB_DEPENDS = devel/json-c \ wayland/wlroots \ x11/xkbcommon -RUN_DEPENDS = x11/gnome/themes-extra \ - wayland/foot +RUN_DEPENDS = x11/gnome/themes-extra CONFIGURE_ARGS = -Dtray=disabled
net/wmnetload: bogus RUNPATH entry
Hi, net/wmnetload is build with a bogus RUNPATH path, and the elements in the list aren't needed (all paths are standard ones). So just disable RPATH completely. No functional changes outside removing the bogus RUNPATH entry in ELF. Comments or OK ? -- Sebastien Marie diff /home/semarie/repos/openbsd/ports commit - bfc3aa1f209ab2b3deef5e1242ff12c617d46983 path + /home/semarie/repos/openbsd/ports blob - 2edee96fb3807bfab8bb34fa01dd9da87cba8cbc file + net/wmnetload/Makefile --- net/wmnetload/Makefile +++ net/wmnetload/Makefile @@ -1,7 +1,7 @@ COMMENT= wm-dockapp; simple network interface monitoring tool DISTNAME= wmnetload-1.3 -REVISION= 5 +REVISION= 6 CATEGORIES=net x11 x11/windowmaker HOMEPAGE= http://freshmeat.net/projects/wmnetload blob - 9b60c104bbfbee7c021010b4494651d35595a26a file + net/wmnetload/patches/patch-configure --- net/wmnetload/patches/patch-configure +++ net/wmnetload/patches/patch-configure @@ -1,4 +1,6 @@ -Hunk #2, 3: fix the build with libdockapp>=0.7 +- permit build on OpenBSD +- RPATH isn't need (all paths are standard) +- fix the build with libdockapp>=0.7 Index: configure --- configure.orig @@ -13,6 +15,18 @@ Index: configure *) echo "" echo "Sorry, $host_os is not supported yet." +@@ -4270,10 +4273,10 @@ else + RPATH= + echo "WARNING: do not know how to set RPATH with this compiler" + fi ++RPATH= + + + +- + X_LIBRARY_PATH=$x_libraries + XCFLAGS="$X_CFLAGS" + XLFLAGS="$X_LIBS" @@ -4713,7 +4716,7 @@ cat confdefs.h >>conftest.$ac_ext cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */
Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report
Tobias Heider writes: > On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote: >> gkoeh...@openbsd.org writes: >> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log >> >> Could someone test the following patch for lang/sbcl on powerpc ? >> If it works, I will push it upstream. > > This fixes the first problem but after that I ran into an undefined > symbol current_thread error. > > It looks like arm64 already handles this correctly in arm64-assem.S:114 > but a simple s/current_thread/__emutls_v.current_thread/ was not enough > since it caused runtime errors later on. oh. direct TLS seems to not be expected for powerpc: Linux code enable it only for some archs (and ppc isn't in the list). So follow the same way. Does it correct the problem ? (and does #include "validate.h" is still need ?) Thanks. diff /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl commit - 665eeac5c5d6c581db4785cba6292a0e5fc1bbf2 path + /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl blob - /dev/null file + patches/patch-make-config_sh (mode 640) --- /dev/null +++ patches/patch-make-config_sh @@ -0,0 +1,15 @@ +Index: make-config.sh +--- make-config.sh.orig make-config.sh +@@ -610,7 +610,10 @@ case "$sbcl_os" in + ;; + openbsd) + printf ' :openbsd' >> $ltf +-printf ' :gcc-tls' >> $ltf ++case "$sbcl_arch" in ++ arm64 | x86 | x86-64) ++ printf ' :gcc-tls' >> $ltf ++esac + link_or_copy Config.$sbcl_arch-openbsd Config + ;; + netbsd) blob - /dev/null file + patches/patch-src_runtime_ppc-assem_S (mode 640) --- /dev/null +++ patches/patch-src_runtime_ppc-assem_S @@ -0,0 +1,11 @@ +Index: src/runtime/ppc-assem.S +--- src/runtime/ppc-assem.S.orig src/runtime/ppc-assem.S +@@ -5,6 +5,7 @@ + + #include "sbcl.h" + #include "lispregs.h" ++#include "validate.h" + #include "genesis/closure.h" + #include "genesis/static-symbols.h" + #include "genesis/thread.h" -- Sebastien Marie
lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report
gkoeh...@openbsd.org writes: > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log Could someone test the following patch for lang/sbcl on powerpc ? If it works, I will push it upstream. diff /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl commit - 665eeac5c5d6c581db4785cba6292a0e5fc1bbf2 path + /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl blob - /dev/null file + patches/patch-src_runtime_ppc-assem_S (mode 640) --- /dev/null +++ patches/patch-src_runtime_ppc-assem_S @@ -0,0 +1,11 @@ +Index: src/runtime/ppc-assem.S +--- src/runtime/ppc-assem.S.orig src/runtime/ppc-assem.S +@@ -5,6 +5,7 @@ + + #include "sbcl.h" + #include "lispregs.h" ++#include "validate.h" + #include "genesis/closure.h" + #include "genesis/static-symbols.h" + #include "genesis/thread.h" Thanks. -- Sebastien Marie
Re: Update shelcheck to a ghc-9.6 compatible version from git
Caspar Schutijser writes: > Hey, > > I'm doing a build right now to check the diff. But wouldn't it be > better to name it 0.9.0.20231108 instead of 0.9.1.20231108? Because > if they release 0.9.1, we'd need EPOCH to make that work, right? > Please note that packages-spec(7) permits several extra suffix to avoid clashes with upstream versioning: - patchlevel: 0.9.0pl20231108 (< 0.9.1) - pre: 0.9.1pre20231108 (< 0.9.1) The full list in order is: rcN, alphaN, betaN, preN, [normal version], plN And the full doc is in packages-spec(7) man page as usual. -- Sebastien Marie
Re: socat does not provide TUN/TAP support
Luca Di Gregorio writes: > So, I installed socat with pkg_add and tried to do like this: > http://www.dest-unreach.org/socat/doc/socat-tun.html > > Anyway, I see this: > # socat UDP:1.2.3.4:11443 TUN:192.168.255.2/24,up > 2023/11/11 14:11:27 socat[4504] E unknown device/address "TUN" > Have you try to manually configure tun(4) interface and simply use /dev/tun0 ? To keep your example: # ifconfig tun0 create # ifconfig tun0 inet 192.168.255.2/24 # socat UDP:1.2.3.4:11443 GOPEN:/dev/tun0 Regards. -- Sebastien Marie
Re: [update] www/py-werkzeug to 2.2.3
Lucas Raab writes: > Hello, > > Here's an update that brings werkzeug up the minimum version required > for flask to move from 2.1.3 to 2.2.5. RDEPs (where possible) have been > make tested and the tests for werkzeug pass with only a couple failures. > The watchdog tests can be prone to hanging. > > There's a new TDEP needed, py-ephemeral_port_reserve, which is attached > and pretty basic. > > semarie@ and rnagy@, trytond and odoo are the two RDEPs that I haven't > tested since I don't run either. Can you give this update a whirl to see > if there's any breakage? tryton is mostly broken currently (5.0 branch needs a different python version than the current one, and 5.2 is EOL). I need to do something for that anyway. so no problem to update werkzeug regarding tryton :) thanks. -- Sebastien Marie
update mail/notmuch to 0.38
Hi,
The following diff updates mail/notmuch to 0.38.
ChangeLog: https://notmuchmail.org/news/release-0.38/
Tested on amd64. The test suite seems a bit better (with more tests).
=== 0.37 test suite ===
Notmuch test suite complete.
1393/1407 tests passed.
7 broken tests failed as expected.
7 tests failed.
All tests in 6 files skipped.
5 tests failed to report results.
=== 0.38 test suite ===
Notmuch test suite complete.
1708/1722 tests passed.
11 broken tests failed as expected.
3 tests failed.
All tests in 7 files skipped.
2 tests failed to report results.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - 89cf5b942df3c21a540652095538522236f17010
path + /home/semarie/repos/openbsd/ports
blob - dac07c722724d628396df4816b801f1aeaa2b1cd
file + mail/notmuch/Makefile.inc
--- mail/notmuch/Makefile.inc
+++ mail/notmuch/Makefile.inc
@@ -1,4 +1,4 @@
-V =0.37
+V =0.38
DISTNAME = notmuch-$V
EXTRACT_SUFX = .tar.xz
blob - 9154b43d3a01bdfde420b9206db83956ab1c6aa3
file + mail/notmuch/notmuch/distinfo
--- mail/notmuch/notmuch/distinfo
+++ mail/notmuch/notmuch/distinfo
@@ -1,2 +1,2 @@
-SHA256 (notmuch-0.37.tar.xz) = DnZt8ot4v064I1Ymqx9S8E8eNmZJMlqM6NPJCGAnhvY=
-SIZE (notmuch-0.37.tar.xz) = 792568
+SHA256 (notmuch-0.38.tar.xz) = oXkBrb5D9IGmv1PBWiogJovI3HrVzPaFoNF8FFbbr24=
+SIZE (notmuch-0.38.tar.xz) = 804536
blob - c68971195a98c0115273192bc0f0cc9410a18af2
file + mail/notmuch/notmuch/patches/patch-lib_Makefile_local
--- mail/notmuch/notmuch/patches/patch-lib_Makefile_local
+++ mail/notmuch/notmuch/patches/patch-lib_Makefile_local
@@ -24,7 +24,7 @@ Index: lib/Makefile.local
endif
ifeq ($(LIBDIR_IN_LDCONFIG),1)
ifeq ($(DESTDIR),)
-@@ -75,19 +79,23 @@ $(dir)/libnotmuch.a: $(libnotmuch_modules)
+@@ -76,19 +80,23 @@ $(dir)/libnotmuch.a: $(libnotmuch_modules)
$(dir)/$(LIBNAME): $(libnotmuch_modules) util/libnotmuch_util.a
parse-time-string/libparse-time-string.a
$(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules)
$(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@ util/libnotmuch_util.a
parse-time-string/libparse-time-string.a
blob - f38aeddf5a7c0b5ebfd29f3c7f839a8136481df2
file + mail/notmuch/notmuch/patches/patch-test_T360-symbol-hiding_sh
--- mail/notmuch/notmuch/patches/patch-test_T360-symbol-hiding_sh
+++ mail/notmuch/notmuch/patches/patch-test_T360-symbol-hiding_sh
@@ -1,7 +1,7 @@
Index: test/T360-symbol-hiding.sh
--- test/T360-symbol-hiding.sh.orig
+++ test/T360-symbol-hiding.sh
-@@ -26,7 +26,7 @@ test_begin_subtest 'checking output'
+@@ -30,7 +30,7 @@ test_begin_subtest 'checking output'
test_expect_equal "$result" "$output"
test_begin_subtest 'comparing existing to exported symbols'
blob - b32678bac5f3d835d8594e3d9c930c2365b71fa4
file + mail/notmuch/notmuch/patches/patch-test_test-lib_sh
--- mail/notmuch/notmuch/patches/patch-test_test-lib_sh
+++ mail/notmuch/notmuch/patches/patch-test_test-lib_sh
@@ -4,12 +4,12 @@ Removing the append logic fixes this
Index: test/test-lib.sh
--- test/test-lib.sh.orig
+++ test/test-lib.sh
-@@ -919,7 +919,7 @@ notmuch_with_shim () {
- base_name="$1"
+@@ -944,7 +944,7 @@ notmuch_with_shim () {
+ base_name=$1
shift
shim_file="${base_name}.so"
--LD_PRELOAD=${LD_PRELOAD:+:$LD_PRELOAD}:./${shim_file} notmuch-shared "$@"
-+LD_PRELOAD=./${shim_file} notmuch-shared "$@"
+-LD_PRELOAD=${LD_PRELOAD:+:$LD_PRELOAD}:./${shim_file} $notmuch_cmd "$@"
++LD_PRELOAD=./${shim_file} $notmuch_cmd "$@"
}
# Creates a script that counts how much time it is executed and calls
blob - f3e2f3143156c6012fc1c5e69acbba1bc02e82b0
file + mail/notmuch/py-notmuch/Makefile
--- mail/notmuch/py-notmuch/Makefile
+++ mail/notmuch/py-notmuch/Makefile
@@ -1,7 +1,6 @@
COMMENT = Python bindings for notmuch
PKGNAME = py-notmuch-${V}
-REVISION = 1
MODULES = lang/python
MODPY_EGG_VERSION = ${V}
blob - 9154b43d3a01bdfde420b9206db83956ab1c6aa3
file + mail/notmuch/py-notmuch/distinfo
--- mail/notmuch/py-notmuch/distinfo
+++ mail/notmuch/py-notmuch/distinfo
@@ -1,2 +1,2 @@
-SHA256 (notmuch-0.37.tar.xz) = DnZt8ot4v064I1Ymqx9S8E8eNmZJMlqM6NPJCGAnhvY=
-SIZE (notmuch-0.37.tar.xz) = 792568
+SHA256 (notmuch-0.38.tar.xz) = oXkBrb5D9IGmv1PBWiogJovI3HrVzPaFoNF8FFbbr24=
+SIZE (notmuch-0.38.tar.xz) = 804536
lang/ecl: update to 23.9.9
Hi,
The following diff updates lang/ecl to 23.9.9.
I tested it on amd64, and built reverse-depends using it (math/maxima,
math/wxMaxima, net/clic, and lang/sbcl [forcing the use of ecl]).
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - 774b5ac8593c8e368254a0c7382f33d6cdaeca56
path + /home/semarie/repos/openbsd/ports
blob - 744e4fac01aa428f635a2e64735ab4a34982b365
file + lang/ecl/Makefile
--- lang/ecl/Makefile
+++ lang/ecl/Makefile
@@ -1,12 +1,10 @@
COMMENT = embeddable common-lisp
CATEGORIES = lang
-V =21.2.1
+V =23.9.9
DISTNAME = ecl-$V
-SHARED_LIBS += ecl 8.0
+SHARED_LIBS += ecl 9.0
-REVISION = 0
-
HOMEPAGE = https://common-lisp.net/project/ecl/
MAINTAINER = Timo Myyra
@@ -44,7 +42,7 @@ LIB_DEPENDS +=devel/gmp \
devel/boehm-gc,-atomic \
devel/libffi
-TEST_DEPENDS = ${BASE_PKGPATH}
+TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH}
TEST_ENV = "ECL=${WRKDIST}/build/bin/ecl" \
"TEST_IMAGE=${WRKDIST}/build/bin/ecl"
blob - 5da17098084bbc837811a12478849c7eb0b6024e
file + lang/ecl/distinfo
--- lang/ecl/distinfo
+++ lang/ecl/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ecl-21.2.1.tgz) = sVp13PhLj2LmhyDMqxOT+WEcB4/NOv3WOaEIbK0BCQA=
-SIZE (ecl-21.2.1.tgz) = 7875088
+SHA256 (ecl-23.9.9.tgz) = xRvatMpsEXPdP+nP6XJ7zvuXuwo9ZDS2J8pr2usz+IA=
+SIZE (ecl-23.9.9.tgz) = 8129105
blob - a7763bffb61f13d0e7ff85917530a01dd3294ba7
file + lang/ecl/patches/patch-src_Makefile_in
--- lang/ecl/patches/patch-src_Makefile_in
+++ lang/ecl/patches/patch-src_Makefile_in
@@ -1,7 +1,7 @@
Index: src/Makefile.in
--- src/Makefile.in.orig
+++ src/Makefile.in
-@@ -213,29 +213,13 @@ install:
+@@ -201,29 +201,13 @@ install:
$(INSTALL_DATA) ecl/$$i $(DESTDIR)$(includedir)/ecl/$$i; \
done
$(INSTALL_SCRIPT) bin/ecl-config $(DESTDIR)$(bindir)
blob - /dev/null
file + lang/ecl/patches/patch-src_cmp_cmpbackend-cxx_cmpbackend-cxx_lsp (mode
640)
--- /dev/null
+++ lang/ecl/patches/patch-src_cmp_cmpbackend-cxx_cmpbackend-cxx_lsp
@@ -0,0 +1,16 @@
+Index: src/cmp/cmpbackend-cxx/cmpbackend-cxx.lsp
+--- src/cmp/cmpbackend-cxx/cmpbackend-cxx.lsp.orig
src/cmp/cmpbackend-cxx/cmpbackend-cxx.lsp
+@@ -274,11 +274,7 @@ the environment variable TMPDIR to a different value."
+
+ (defun ecl-library-directory ()
+ "Finds the directory in which the ECL core library was installed."
+- (cond ((and *ecl-library-directory*
+- (probe-file (merge-pathnames (compile-file-pathname "ecl" :type
+-#+dlopen :shared-library
+-#-dlopen :static-library)
+- *ecl-library-directory*)))
++ (cond (*ecl-library-directory*
+ *ecl-library-directory*)
+ ((probe-file "SYS:BUILD-STAMP")
+ (setf *ecl-library-directory* (namestring
(translate-logical-pathname "SYS:"
blob - a863e03254c2b802909d695af5cb0e2066962947
file + /dev/null
--- lang/ecl/patches/patch-src_cmp_cmpc-wt_lsp
+++ /dev/null
@@ -1,25 +0,0 @@
-backport
https://gitlab.com/embeddable-common-lisp/ecl/-/commit/f3d4cf4b66ab6c3cd8629ab6d0c7f7c50d7fd8a4
-
-Index: src/cmp/cmpc-wt.lsp
src/cmp/cmpc-wt.lsp.orig
-+++ src/cmp/cmpc-wt.lsp
-@@ -19,18 +19,7 @@
- (defun wt1 (form)
- (cond ((not (floatp form))
- (typecase form
-- (INTEGER
--(princ form *compiler-output1*)
--(princ
-- (cond ((typep form (rep-type->lisp-type :int)) "")
-- ((typep form (rep-type->lisp-type :unsigned-int)) "U")
-- ((typep form (rep-type->lisp-type :long)) "L")
-- ((typep form (rep-type->lisp-type :unsigned-long)) "UL")
-- ((typep form (rep-type->lisp-type :long-long)) "LL")
-- ((typep form (rep-type->lisp-type :unsigned-long-long))
"ULL")
-- (t (baboon :format-control "wt1: The number ~A doesn't fit
any integer type." form)))
-- *compiler-output1*))
-- ((or STRING CHARACTER)
-+ ((or INTEGER STRING CHARACTER)
- (princ form *compiler-output1*))
-(VAR (wt-var form))
-(t (wt-loc form
blob - 12ec82db34881b8159569d96e80a0e9649a32f3c
file + /dev/null
--- lang/ecl/patches/patch-src_cmp_cmploc_lsp
+++ /dev/null
@@ -1,36 +0,0 @@
-backport
https://gitlab.com/embeddable-common-lisp/ecl/-/commit/f3d4cf4b66ab6c3cd8629ab6d0c7f7c50d7fd8a4
-
-Index: src/cmp/cmploc.lsp
src/cmp/cmploc.lsp.orig
-+++ src/cmp/cmploc.lsp
-@@ -181,10 +181,30 @@
- (defun wt-temp (temp)
- (wt "T" temp))
-
-+(defun wt-fixnum (value &optional vv)
-+ (declare (ignore vv))
-+ (princ value *compiler-output1*)
-+ ;; Specify explicit type
Re: [Fix] editors/helix
Hi,
It looks good to me.
Maybe use the link to the exact commit in helix (instead of the commit as
proposed)
https://github.com/helix-editor/helix/commit/de0ef8af15945fb7f761503c615a2d6213d2fd82
ok semarie@ (but let's Maintainer time to reply too).
Thanks.
--
Sebastien Marie
On Fri, Sep 15, 2023 at 08:56:31PM +0200, Volker Schlecht wrote:
> Cc: Maintainer
>
> Seems like editors/helix has a bug when building with lang/rust > 1.70.
> See
>
> https://github.com/rust-lang/rust/issues/112171#issuecomment-1575573079
> https://github.com/helix-editor/helix/pull/7227
>
> for details.
>
> This backports the upstream patch, which fixes the issue for me (amd64).
>
> ok?
> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/helix/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 19 May 2023 16:24:08 - 1.4
> +++ Makefile 15 Sep 2023 18:52:16 -
> @@ -2,6 +2,7 @@ COMMENT = modal text editor
>
> VER =23.05
> DISTNAME = helix-${VER}
> +REVISION = 0
>
> CATEGORIES = editors
>
> Index: patches/patch-helix-vcs_src_diff_line_cache_rs
> ===
> RCS file: patches/patch-helix-vcs_src_diff_line_cache_rs
> diff -N patches/patch-helix-vcs_src_diff_line_cache_rs
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-helix-vcs_src_diff_line_cache_rs15 Sep 2023 18:52:16
> -
> @@ -0,0 +1,60 @@
> +Backport upstream compatibility fix for rust >= 1.71
> +https://github.com/helix-editor/helix/pull/7227/commits/269f637847140ddb9537efde4968bd92c91c9e1e
> +Index: helix-vcs/src/diff/line_cache.rs
> +--- helix-vcs/src/diff/line_cache.rs.orig
> helix-vcs/src/diff/line_cache.rs
> +@@ -20,8 +20,8 @@ use super::{MAX_DIFF_BYTES, MAX_DIFF_LINES};
> + /// A cache that stores the `lines` of a rope as a vector.
> + /// It allows safely reusing the allocation of the vec when updating the
> rope
> + pub(crate) struct InternedRopeLines {
> +-diff_base: Rope,
> +-doc: Rope,
> ++diff_base: Box,
> ++doc: Box,
> + num_tokens_diff_base: u32,
> + interned: InternedInput>,
> + }
> +@@ -34,8 +34,8 @@ impl InternedRopeLines {
> + after: Vec::with_capacity(doc.len_lines()),
> + interner: Interner::new(diff_base.len_lines() +
> doc.len_lines()),
> + },
> +-diff_base,
> +-doc,
> ++diff_base: Box::new(diff_base),
> ++doc: Box::new(doc),
> + // will be populated by update_diff_base_impl
> + num_tokens_diff_base: 0,
> + };
> +@@ -44,19 +44,19 @@ impl InternedRopeLines {
> + }
> +
> + pub fn doc(&self) -> Rope {
> +-self.doc.clone()
> ++Rope::clone(&*self.doc)
> + }
> +
> + pub fn diff_base(&self) -> Rope {
> +-self.diff_base.clone()
> ++Rope::clone(&*self.diff_base)
> + }
> +
> + /// Updates the `diff_base` and optionally the document if `doc` is not
> None
> + pub fn update_diff_base(&mut self, diff_base: Rope, doc: Option) {
> + self.interned.clear();
> +-self.diff_base = diff_base;
> ++self.diff_base = Box::new(diff_base);
> + if let Some(doc) = doc {
> +-self.doc = doc
> ++self.doc = Box::new(doc)
> + }
> + if !self.is_too_large() {
> + self.update_diff_base_impl();
> +@@ -74,7 +74,7 @@ impl InternedRopeLines {
> + .interner
> + .erase_tokens_after(self.num_tokens_diff_base.into());
> +
> +-self.doc = doc;
> ++self.doc = Box::new(doc);
> + if self.is_too_large() {
> + self.interned.after.clear();
> + } else {
DIST_TUPLE: add codeberg support, and permit some customization on extracted directory
Hi,
When trying to add codeberg to DIST_TUPLE stuff, I had a problem with the name
used to extract the downloaded tarball.
codeberg.org is using the following scheme:
the downloaded file is at:
https://codeberg.org///archive/.tar.gz
the tarball extracts at ${WRKDIR}// (and not
${WRKDIR}/-/ as expected by DIST_TUPLE)
So I customized a bit dist-tuple.port.mk to be able to use a template for this
name.
The variable is named TEMPLATE_WRKSRC.x (using WRKSRC for the similarity with a
port with only one distfile). But I am unsure about the name.
The following patch adds the machinery (and the doc) for using
TEMPLATE_WRKSRC.,
and adds also codeberg in templates.
I tested several github ports which differents schemes, but more testing will
be
appreciate.
Thanks.
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - d3b35887e0ba204a5916da1942dd81f98bfc2148
path + /home/semarie/repos/openbsd/ports
blob - b4bf842539bf825f55e78520f17b026f654419bb
file + infrastructure/mk/dist-tuple.port.mk
--- infrastructure/mk/dist-tuple.port.mk
+++ infrastructure/mk/dist-tuple.port.mk
@@ -38,9 +38,10 @@ HOMEPAGE ?= ${TEMPLATE_HOMEPAGE.${_template}:S//${_account}/g:S//${_project}/g:S//${_id:S/refs\/tags\///:S/^v//}/g:S//${_subdir}/g};
\
t=${WRKDIST}/${_targetdir}; [[ -d $$t ]] && rmdir $$t \
|| mkdir -p `dirname $$t` ; \
- mv ${WRKDIR}/${_project}-${_id:S/refs\/tags\///:S/^v//} $$t;
+ mv ${WRKDIR}/$$s $$t;
.endif
. endfor
diff /home/semarie/repos/openbsd/ports
commit - d3b35887e0ba204a5916da1942dd81f98bfc2148
path + /home/semarie/repos/openbsd/ports
blob - 3b11da9f1f4ef0be05caace3865d55f51d70d92c
file + infrastructure/db/dist-tuple.pattern
--- infrastructure/db/dist-tuple.pattern
+++ infrastructure/db/dist-tuple.pattern
@@ -1,9 +1,11 @@
# known MASTER_SITES.x
+MASTER_SITES.codeberg ?= https://codeberg.org/
MASTER_SITES.github ?= https://github.com/
MASTER_SITES.gitlab ?= https://gitlab.com/
MASTER_SITES.srht ?= https://git.sr.ht/
# EXTRACT_SUFX.x for each site
+EXTRACT_SUFX.codeberg ?= .tar.gz
EXTRACT_SUFX.github ?= .tar.gz
EXTRACT_SUFX.gitlab ?= .tar.gz
EXTRACT_SUFX.srht ?= .tar.gz
@@ -13,6 +15,9 @@ EXTRACT_SUFX.srht ?= .tar.gz
# -
# -
# - - used automatically if is in tag format
+TEMPLATE_DISTFILES.codeberg ?= \
+
--{//archive/}${EXTRACT_SUFX.codeberg}
+
TEMPLATE_DISTFILES.github ?= \
--{//archive/}${EXTRACT_SUFX.github}
@@ -23,6 +28,13 @@ TEMPLATE_DISTFILES.srht ?= \
--{~//archive/}${EXTRACT_SUFX.srht}
# templates for HOMEPAGE; same substitutions as for DISTFILES.x
+TEMPLATE_HOMEPAGE.codeberg ?= https://codeberg.org//
TEMPLATE_HOMEPAGE.github ?=https://github.com//
TEMPLATE_HOMEPAGE.gitlab ?=https://gitlab.com//
TEMPLATE_HOMEPAGE.srht ?= https://git.sr.ht/~/
+
+# templates for extraction; same substitutions as for DISTFILES.x
+TEMPLATE_WRKSRC.codeberg ?=
+TEMPLATE_WRKSRC.github ?= -
+TEMPLATE_WRKSRC.gitlab ?= -
+TEMPLATE_WRKSRC.srht ?=-
diff /home/semarie/repos/openbsd/src
commit - 5f7ea7bc25406ceab417284d038129723f0423a2
path + /home/semarie/repos/openbsd/src
blob - 099febdff4c5d7dba8b8aff137831c91abb57364
file + share/man/man5/bsd.port.mk.5
--- share/man/man5/bsd.port.mk.5
+++ share/man/man5/bsd.port.mk.5
@@ -1648,6 +1648,7 @@ List of distfile templates to use, each consisting of
The template
.Ar name
should be one of
+.Sq codeberg ,
.Sq github ,
.Sq gitlab ,
or
@@ -1656,7 +1657,8 @@ at the moment
.Po see
.Pa ${PORTSDIR}/db/dist-tuple.pattern ,
additional
-.Ev TEMPLATE_DISTFILES.
+.Ev TEMPLATE_DISTFILES. ,
+.Ev TEMPLATE_WRKSRC.
and
.Ev TEMPLATE_HOMEPAGE.
entries can be added as needed
@@ -3452,6 +3454,12 @@ when using
.Ev DIST_TUPLE .
Very similar to
.Ev TEMPLATE_DISTFILES. .
+.It Ev TEMPLATE_WRKSRC.
+Template for automatically generated the name of the source
+directory extracted when using
+.Ev DIST_TUPLE .
+Very similar to
+.Ev TEMPLATE_DISTFILES. .
.It Ev TEST_DEPENDS
See
.Ev BUILD_DEPENDS
Re: [new] editors/litexl v2.1.1
On Mon, Sep 11, 2023 at 04:17:33PM +0200, Denis Fondras wrote:
> Lite XL is derived from Lite. It is a lightweight text editor written mostly
> in
> Lua — it aims to provide something practical, pretty, small and fast easy to
> modify and extend, or to use without doing either.
>
> The aim of Lite XL compared to lite is to be more user friendly, improve the
> quality of font rendering, and reduce CPU usage.
>
> https://lite-xl.com/
- missing c and m in WANTLIB
- it seems to doesn't start without invocation with full path:
$ lite-xl
Error: [string "local core..."]:5: attempt to index a nil value (local 'exedir')
stack traceback:
[string "local core..."]:2: in main chunk
$ /usr/local/bin/lite-xl
[work]
as it is installed at a know place, it could be patched to fallback to
/usr/local:
--- /dev/null Mon Sep 11 16:42:08 2023
+++ patches/patch-src_main_cMon Sep 11 16:41:17 2023
@@ -0,0 +1,15 @@
+Index: src/main.c
+--- src/main.c.orig
src/main.c
+@@ -205,7 +205,10 @@ init_lua:
+ lua_pushstring(L, exename);
+ } else {
+ // get_exe_filename failed
+-lua_pushstring(L, argv[0]);
++if (strchr(argv[0], '/') != NULL)
++ lua_pushstring(L, argv[0]);
++else
++ lua_pushstring(L, "/usr/local/bin/lite-xl");
+ }
+ lua_setglobal(L, "EXEFILE");
+
ok semarie@ with the two points corrected.
--
Sebastien Marie
Re: NEW: riff - rust build/fake rebuilds
On Mon, Sep 04, 2023 at 12:35:13PM +, Klemens Nanni wrote:
>
> [...]
>
> Does anyone know why 'make build' builds stuff fine, but then 'make fake'
> also builds stuff?
>From the output, it seems that it is running (again) severals kinds of
>programs:
- build_scripts (build.rs machinery) : the script is run a second time (in case
something changed, and if it is the case it could rebuild things)
- potential macro stuff : but I don't really know how it is working
The 'cargo build' and the 'cargo install' invocation are very similar (but not
exactly the same: 'cargo install' has additional --root="${PREFIX}" option).
As after 'make fake', doing a 'make clean=fake' and rerunning 'make fake'
generate no build, I suppose the --root option change some elements and trigger
some rebuild.
I am unsure we could do better here as 'cargo' doesn't fit in
configure-build-fake steps.
Thanks.
--
Sebastien Marie
Re: check-lib-depends and modules' *_WANTLIB
On Sun, Sep 03, 2023 at 10:44:51AM +0200, Omar Polo wrote:
> On 2023/09/03 10:32:00 +0200, Omar Polo wrote:
> > I considered making the variable more like SUBST_VARS (i.e. just a
> > list of variable names) but then we loose the ability to express -F
> > which can be handy. Or maybe I'm overthinking it.
>
> just as I sent the email I noticed that my cargo.port.mk diff wasn't
> right. Turns out, -F is really needed :-)
>
> with the fixed carg.port.mk diff:
>
> % pwd
> /usr/ports/devel/difftastic
> % make port-lib-depends-check
> [...]
> WANTLIB += ${COMPILER_LIBCXX} ${MODCARGO_WANTLIB} m
> *** Error 1 in target 'port-lib-depends-check' (ignored)
>
>
> Index: cargo.port.mk
> ===
> RCS file: /home/cvs/ports/devel/cargo/cargo.port.mk,v
> retrieving revision 1.37
> diff -u -p -r1.37 cargo.port.mk
> --- cargo.port.mk 26 Jul 2023 07:56:18 - 1.37
> +++ cargo.port.mk 3 Sep 2023 08:41:42 -
> @@ -36,6 +36,9 @@ MODCARGO_WANTLIB += c++abi
> MODCARGO_WANTLIB +=
> .endif
>
> +CHECK_LIB_DEPENDS_ARGS += -S MODCARGO_WANTLIB="${MODCARGO_WANTLIB}"
> +CHECK_LIB_DEPENDS_ARGS += -F pthread -F c++abi
> +
> # Define MASTER_SITES_CRATESIO for crates.io
> MASTER_SITES_CRATESIO = https://crates.io/api/v1/crates/
>
cargo.port.mk isn't up to date on your side (1.38 was commited ~16h ago).
Regarding the diff, I am not sure to be fluent enough with check-lib-depends to
properly undertand all implications.
About MODCARGO_WANTLIB, it should be noted that the variable exists because the
content is different accross machine architecture.
The global picture is:
- sparc64 : MODCARGO_WANTLIB = c pthread
- others : MODCARGO_WANTLIB = c pthread c++abi
sparc64 is using unwinding code from libgcc.a (versus c++abi for others).
so if I properly understood check-lib-depends(1) man page:
- -S MODCARGO_WANTLIB="${MODCARGO_WANTLIB}" : is fine
- -F pthread : shouldn't be needed (as pthread will be always part of the
actual WANTLIB for a rust binary)
- -F c++abi : is fine, as on sparc64 it could be missing
Thanks.
--
Sebastien Marie
Re: MODULES: some documentation is needed!
On Wed, Aug 23, 2023 at 11:31:39PM +0200, Marc Espie wrote: > According to port-modules, variables starting with MOD* are public, so > should get documented, SOONER RATHER THAN LATER. Some of these variables are somehow internal to the modules, and named this way (MOD*) because of bsd.port.mk . > MODGO_pre-configure > MODCARGO_post-extract > MODCARGO_post-patch > MODCABAL_post-extract > MODGNU_configure > MODGNU_gen > MODGO_pre-configure > MODHEIMDAL_post-patch > MODIMAKE_configure > MODKF5_post-install > MODMESON_configure > MODOCAML_pre-fake > MODPERL_configure > MODPERL_gen > MODPERL_pre-configure > MODPERL_pre-fake > MODQMAKE_build > MODQMAKE_configure > MODQMAKE_install > MODQMAKE_test > MODRUBY_pre-configure > MODXFCE4_gen > MODXFCE4_post-install port-modules.5 also recommands some variable names as MODFOO_BUILD_TARGET. I don't really see the point of document them. Please also keep in mind that specific documentation for variable modules was not really possible at the time of writing the modules as all the documentation for all the modules was inside port-modules.5 (so only important parts was included in this file to not make the file unreadable). Thanks. -- Sebastien Marie
Re: [Update] fonts/juliamono
On Tue, Aug 15, 2023 at 08:17:31PM +0100, Laurence Tratt wrote: > A simple update to fonts/juliamono: tested working fine (though, as with > any font update, it will tend to mess up running applications, which > then need to be restarted). > > > Laurie commited. thanks. > > > diff --git fonts/juliamono/Makefile fonts/juliamono/Makefile > index 500dcc97953..ae484ee76db 100644 > --- fonts/juliamono/Makefile > +++ fonts/juliamono/Makefile > @@ -1,6 +1,6 @@ > COMMENT =typeface carefully crafted & designed for computer screens > > -V = 0.048 > +V = 0.050 > DISTNAME = JuliaMono > PKGNAME =juliamono-$V > > diff --git fonts/juliamono/distinfo fonts/juliamono/distinfo > index 43f857f43fc..4f6167524e4 100644 > --- fonts/juliamono/distinfo > +++ fonts/juliamono/distinfo > @@ -1,2 +1,2 @@ > -SHA256 (JuliaMono-0.048.tar.gz) = > J804RqJjpvSx00G0PRjN9wYIvQnsAXWUsZaJGWXdJ1M= > -SIZE (JuliaMono-0.048.tar.gz) = 31773698 > +SHA256 (JuliaMono-0.050.tar.gz) = > 5EZQVkVBAeSjWFgWtOGG1wmXAUAf2qX71Wf6/SUk6qM= > +SIZE (JuliaMono-0.050.tar.gz) = 32756039 > -- Sebastien Marie
Re: bsd.port.mk: check wxallowed after extract not patch
On Mon, Aug 14, 2023 at 01:33:24PM +, Klemens Nanni wrote:
> On Mon, Aug 07, 2023 at 10:03:17PM +0200, Marc Espie wrote:
> > > Doesn't "gen" also run GNU auto* which potentially needs wxallowed?
> > > That's why I have moved it there now.
> > >
> > > Either way, making the check the first step of a target instead needs
> > > its own target so that PORTS_PRIVSEP=Yes stays in effect.
> > >
> > > post-* or *-finalize where the first diff put it do not need that, as
> > > they're already run as _pbuild.
> > >
> > > Does that still work for everyone's favourite USE_WXNEEDED=Yes workflow
> > > without breaking other stuff, when you forget to set wxallowed?
> >
> > If I recall correctly, adding USE_WXNEEDED predates the gen step by some
> > time, so it might be good there days.
> >
>
> No further feedback.
>
> Unless you mistakenly forget "wxallowed" whilst porting, this diff
> should not change behaviour in any way.
>
> OK?
fine with me. ok semarie@
> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1596
> diff -u -p -r1.1596 bsd.port.mk
> --- bsd.port.mk 8 Aug 2023 12:43:53 - 1.1596
> +++ bsd.port.mk 9 Aug 2023 07:48:54 -
> @@ -2861,14 +2861,6 @@ ${_PATCH_COOKIE}: ${_EXTRACT_COOKIE}
>
> # Run as _pbuild
> _post-patch-finalize:
> -.if ${USE_WXNEEDED:L} == "yes"
> - @wrktmp=`df -P ${WRKOBJDIR_${PKGPATH}} | awk 'END { print $$6 }'`; \
> - if ! mount | grep -q " $${wrktmp} .*wxallowed"; then \
> - echo "Fatal: ${WRKOBJDIR_${PKGPATH}} must be on a wxallowed
> filesystem" \
> - "(in ${PKGPATH})" >&2; \
> - false; \
> - fi
> -.endif
> .if !empty(_LINKER_FLAGS) || ${_NONDEFAULT_LD:L} == "yes"
> @printf '#!/bin/sh\nexec ${_LD_PROGRAM} ${_LINKER_FLAGS} "$$@"\n'
> >${WRKDIR}/bin/ld
> @chmod 555 ${WRKDIR}/bin/ld
> @@ -2908,10 +2900,23 @@ _gen-finalize:
> esac; done
> .endif
>
> +.if ${USE_WXNEEDED:L} == "yes"
> +_use-wxneeded:
> + @wrktmp=`df -P ${WRKOBJDIR_${PKGPATH}} | awk 'END { print $$6 }'`; \
> + if ! mount | grep -q " $${wrktmp} .*wxallowed"; then \
> + echo "Fatal: ${WRKOBJDIR_${PKGPATH}} must be on a wxallowed
> filesystem" \
> + "(in ${PKGPATH})" >&2; \
> + false; \
> + fi
> +.endif
> +
> # The real gen stage
>
> ${_GEN_COOKIE}: ${_PATCH_COOKIE}
> @${ECHO_MSG} "===> Generating configure for ${FULLPKGNAME}${_MASTER}"
> +.if ${USE_WXNEEDED:L} == "yes"
> + @${_PMAKE} _use-wxneeded
> +.endif
> .if target(do-gen)
> @${_PMAKE} do-gen
> .endif
--
Sebastien Marie
Re: new www/shiori
On Tue, Aug 08, 2023 at 04:01:17PM +0200, Paco Esteban wrote:
>
> Find attached the updated version that removes the wrapper script and
> makes use of login classes.
>
one question:
in pkg/README, you have the example
# rcctl set shiori flags -a 0.0.0.0 -p 1234
and in pkg/shiori.rc, the default daemon_flags value is "serve -a localhost"
if I properly understand thecommand-line, 'serve' is a command which is
required
to be passed for the service.
if you don't want to have to pass it systematically (rcctl set shiori flags
serve -a 0.0.0.0 -p 1234),
maybe the following will work:
pkg/shiori.rc
-daemon="${TRUEPREFIX}/bin/shiori"
+daemon="${TRUEPREFIX}/bin/shiori serve"
daemon_user="_shiori"
-daemon_flags="serve -a localhost"
+daemon_flags="-a localhost"
thanks.
--
Sebastien Marie
Re: [Update] editors/emacs 28.2 -> 29.1
On Wed, Aug 02, 2023 at 11:38:40AM +0200, Omar Polo wrote: > On 2023/07/31 19:02:58 +0200, Jeremie Courreges-Anglas > wrote: > > > > Hi folks, > > > > [...] > > > > I have already spent time on this yesterday. While I can understand > > that you love your emacs being up to date, I'm maintaining this port > > and I would have three proposals to compare with my own wip diff. > > So let's hope that said diff addresses all the points mentioned in this > > thread... > > > > The two main points open to discussion IMO: > > > > 1. sqlite3: it doesn't seem to add any feature besides being able to > > access sqlite databases from emacs. So I'm not sure it's worth adding > > another explicit dep... > > > > 2. tree-sitter: I won't add it right now, since it uses rust at build > > time and I want emacs to stay available on as many architectures as > > possible. I have a wip diff to make rust optional in > > textproc/tree-sitter, but that can wait until emacs-29.1 is properly > > tested and committed. > > > > All flavors build-tested on amd64, no_x11 flavor build-tested on sparc64 > > and running on amd64. > > > > Test reports & oks welcome, especially for graphical flavors. > > I've used for a day the athena flavor, works fine for me. (right now > I'm using the 'lucid' flavor that I added locally.) fwiw ok op@ as op@, I am using it (but with gtk3). no problem seen. ok semarie@ -- Sebastien Marie
Re: (maintainer update) abcl-1.9.2
On Mon, Jul 31, 2023 at 08:07:43PM +0300, Timo Myyrä wrote: > Hi, > > Simple update for ABCL, seems to work on amd64. > Thanks, commited. -- Sebastien Marie
Re: (update) gambit-4.9.5
/42@gambit${API_V}@C/42.c
> +@bin lib/gambit/srfi/42/42@gambit${API_V}@C/42.o1
> +lib/gambit/srfi/42/42@gambit${API_V}@js/
> +lib/gambit/srfi/42/42@gambit${API_V}@js/42.js
> +lib/gambit/srfi/42/42@gambit${API_V}@js/42.o1
> +lib/gambit/srfi/42/test/
> +lib/gambit/srfi/42/test/test.scm
> lib/gambit/srfi/45/
> lib/gambit/srfi/45/45#.scm
> lib/gambit/srfi/45/45.scm
> @@ -1143,6 +1244,18 @@ lib/gambit/srfi/5/
> lib/gambit/srfi/45/45@gambit${API_V}@js/45.o1
> lib/gambit/srfi/45/test/
> lib/gambit/srfi/45/test/test.scm
> +lib/gambit/srfi/48/
> +lib/gambit/srfi/48/48#.scm
> +lib/gambit/srfi/48/48.scm
> +lib/gambit/srfi/48/48.sld
> +lib/gambit/srfi/48/48@gambit${API_V}@C/
> +lib/gambit/srfi/48/48@gambit${API_V}@C/48.c
> +@bin lib/gambit/srfi/48/48@gambit${API_V}@C/48.o1
> +lib/gambit/srfi/48/48@gambit${API_V}@js/
> +lib/gambit/srfi/48/48@gambit${API_V}@js/48.js
> +lib/gambit/srfi/48/48@gambit${API_V}@js/48.o1
> +lib/gambit/srfi/48/test/
> +lib/gambit/srfi/48/test/test.scm
> lib/gambit/srfi/5/
> lib/gambit/srfi/5/5#.scm
> lib/gambit/srfi/5/5.scm
>
--
Sebastien Marie
Re: bsd.port.mk: check wxallowed after extract not patch
On Mon, Jul 31, 2023 at 10:17:05PM +, Klemens Nanni wrote: > 'make patch' on a WXNEEDED=Yes port without wxallowed fails after > patching and before creating the patch cookie, so subsequent setting > of the option and rerunning the target will try to patch again. > > If the check is done right after extract, rerunning that target usually > has higher chances of just working. > > Is there a reason I'm not aware of that this is done after patch? > > > I just forgot to set wxallowed on /usr/ports/pobj when building > ungoogled-chromium where 'make clean && mount ... && make patch' takes > considerably longer than 'mount ... && make extract' to recover from > forgetting to set wxallowed. Personally, having it in extract step might be not convenient as extracting will require 'wxallowed', even if I just want to extract to look at source code. Ideally, I would put such control code at start of 'configure' step. -- Sebastien Marie
Re: [Update] editors/emacs 28.2 -> 29.1
On Mon, Jul 31, 2023 at 11:14:38AM +0300, Timo Myyrä wrote: > On Mon, Jul 31 2023, Renato Aguiar wrote: > > > On Mon, Jul 31 2023, lux wrote: > > > >> Hi, Emacs 29.1 was released yesterday, I update to 29.1. > >> > > > > Maybe add textproc/tree-sitter to LIB_DEPENDS to enable the new > > built-in tree-sitter integration? > > Hi, > > Here is a bit more fleshed out version for emacs-29 update. > > - adds sqlite, tree-sitter and libwebp dependencies webp ? anyway, the diff doesn't seems consistent: - CONFIGURE_ARGS += --without-webp - LIB_DEPENDS += graphics/libwebp - no WANTLIB change for webp Thanks. -- Sebastien Marie
lang/sbcl: remove threads FLAVOR
Hi,
I would like to remove the 'threads' FLAVOR of lang/sbcl and avoid providing
two
differents versions of sbcl (with and without sb-thread).
The following diff merges both lang/sbcl, and lang/sbcl,threads .
Only i386 and arm will be compiled without sb-thread.
x11/stumpwm and lang/Makefile would be adjusted accordingly.
I would be interested about drawbacks if we have only one version.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl
commit - edf880de9cb97c0d6dbb95a67deb3bc1ea612ea5
path + /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl
blob - 99a8e7ea544bcdb0dcae1487928a6941983c0733
file + Makefile
--- Makefile
+++ Makefile
@@ -7,6 +7,7 @@ PKGNAME = sbcl-${V}
V =2.3.7
DISTNAME = sbcl-${V}-source
PKGNAME = sbcl-${V}
+REVISION = 0
CATEGORIES = lang
@@ -28,7 +29,6 @@ FLAVORS = threads
WRKDIST = ${WRKDIR}/sbcl-${V}
PSEUDO_FLAVORS = native_bootstrap
-FLAVORS = threads
FLAVOR ?=
# Supported bootstrap methods:
@@ -66,22 +66,16 @@ ERRORS += "Fatal: unknown BOOTSTRAP_METHOD"
ERRORS += "Fatal: unknown BOOTSTRAP_METHOD"
.endif
-# sb-thread is available only on some architectures and required on others
-.if ${FLAVOR:Mthreads}
+# sb-thread is not available everywhere
+SB_THREAD-${MACHINE_ARCH} ?= Yes
+SB_THREAD-arm =No
+SB_THREAD-i386 = No
+
+.if ${SB_THREAD-${MACHINE_ARCH}:MYes}
EXTRA_PARAMS +=--with-sb-thread
WANTLIB += pthread
-
-# sb-thread on i386 requires i386_set_ldt()
-NOT_FOR_ARCHS += i386
-
-# no support for sb-thread
-NOT_FOR_ARCHS += arm
-
.else
EXTRA_PARAMS +=--without-sb-thread
-
-# no support without sb-thread
-NOT_FOR_ARCHS += aarch64 powerpc64
.endif
# sb-simd is available on amd64 only
blob - 5dcb95273231ce3040729fafb6f7855ffcd33770
file + pkg/PLIST
--- pkg/PLIST
+++ pkg/PLIST
@@ -1,3 +1,4 @@
+@pkgpath lang/sbcl,threads
@bin bin/sbcl
@info info/asdf.info
@info info/sbcl.info
cmake/lua: fix lua autodetection
Hi,
tb@ signaled some build problems with geo/osrm-backend when lua5.4 was junked
during the build, whereas osrm-backend is expected to use lua5.3.
After looking a bit to the build, osrm-backend was using include files from
lua5.3 and library from lua5.4: the configure stage using LUA_INCLUDE_DIR
passed
in CONFIGURE_ARGS and autodetecting the library (and picking 5.4).
Passing both LUA_INCLUDE_DIR and LUA_LIBRARY in CONFIGURE_ARGS fix it.
I built a set of ~50 ports on amd64 (based on ports using both devel/cmake and
lang/lua MODULES) to ensure it creates no problem at build time.
Comments or OK ?
--
Sebastien Marie
diff /data/semarie/repos/openbsd/ports
commit - ad60a6a0d7b0467885ae2577b00a7cc55e5089c7
path + /data/semarie/repos/openbsd/ports
blob - 256d812ac7fa17abafdf46a3b0353240c63dbfbd
file + devel/cmake/cmake.port.mk
--- devel/cmake/cmake.port.mk
+++ devel/cmake/cmake.port.mk
@@ -88,6 +88,7 @@ CONFIGURE_ARGS += -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR}
# Lua
.if ${MODULES:Mlang/lua}
CONFIGURE_ARGS += -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR}
+CONFIGURE_ARGS +=
-DLUA_LIBRARY=${LOCALBASE}/lib/liblua${MODLUA_VERSION}.so.${MODLUA_VERSION}
.endif
# Ruby
Re: x11/st xresources flavor?
On Mon, Jul 17, 2023 at 11:25:37PM -0600, Ashlen wrote:
> Hello,
> I am reaching out to discuss the possibility of adding an xresources
> flavor to x11/st. In my opinion, this addition would greatly enhance the
> functionality of the program by allowing it to read colors and a font
> from the .Xresources file.
>
> Personally, I find it beneficial to set Solarized colors in my
> .Xresources file as it helps reduce eye strain. By incorporating this
> flavor, it would simplify the process of setting up my development
> environment after a fresh OpenBSD installation.
>
> I've attached a diff for your review. I'd greatly appreciate it if you
> could take a look and let me know if it meets the necessary
> requirements.
My personal point of vue would be to have only one alternate flavour:
- no flavor : plain st
- "enhanced" flavor : st + scrollback + xresources
I think that xresources is interesting as it permits to somehow configure st
without having to recompile it (which defeat the fact to have it in ports tree).
What are others opinions ?
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/st/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- Makefile 12 Jan 2023 21:00:13 - 1.26
> +++ Makefile 18 Jul 2023 05:17:24 -
> @@ -2,7 +2,12 @@ COMMENT= simple X terminal
>
> V= 0.9
> DISTNAME=st-${V}
> -SUPDISTFILES=st-scrollback-0.8.5.diff:0
> +
> +PATCH_SCROLLBACK=st-scrollback-0.8.5.diff:0
> +PATCH_XRESOURCES=st-xresources-20230320-45a15676.diff:1
> +SUPDISTFILES=${PATCH_SCROLLBACK} \
> + ${PATCH_XRESOURCES}
> +
> REVISION=0
>
> CATEGORIES= x11
> @@ -19,6 +24,7 @@ WANTLIB=X11 Xft c fontconfig freetype
>
> MASTER_SITES=https://dl.suckless.org/st/
> MASTER_SITES0= https://st.suckless.org/patches/scrollback/
> +MASTER_SITES1= https://st.suckless.org/patches/xresources/
>
> MAKE_ENV=LDFLAGS="${LDFLAGS}" \
> X11INC=${X11BASE}/include \
> @@ -26,12 +32,17 @@ MAKE_ENV= LDFLAGS="${LDFLAGS}" \
>
> NO_TEST= Yes
>
> -FLAVORS= scrollback
> +FLAVORS= scrollback xresources
> FLAVOR?=
>
> .if ${FLAVOR:Mscrollback}
> -PATCHFILES= ${SUPDISTFILES}
> +PATCHFILES+= ${PATCH_SCROLLBACK}
> .endif
> +
> +.if ${FLAVOR:Mxresources}
> +PATCHFILES+= ${PATCH_XRESOURCES}
> +.endif
> +
> PATCH_DIST_STRIP=-p1
>
> do-install:
> Index: distinfo
> ===
> RCS file: /cvs/ports/x11/st/distinfo,v
> retrieving revision 1.17
> diff -u -p -r1.17 distinfo
> --- distinfo 12 Jan 2023 21:00:13 - 1.17
> +++ distinfo 18 Jul 2023 05:17:24 -
> @@ -1,4 +1,6 @@
> SHA256 (st-0.9.tar.gz) = 82NZeZc06ueFvss3QGPwvoM88i+ItPFpzSUbmTJOCOc=
> SHA256 (st-scrollback-0.8.5.diff) =
> 3H9SI7JvyBPZHUrjW9qlTWMCTK6fGK/Zs1lLozmd+lU=
> +SHA256 (st-xresources-20230320-45a15676.diff) =
> /ETVhdSM8d+wD7MMTixM+RmLd/VakfaO974mpcdXBKg=
> SIZE (st-0.9.tar.gz) = 48171
> SIZE (st-scrollback-0.8.5.diff) = 8914
> +SIZE (st-xresources-20230320-45a15676.diff) = 4853
> Index: pkg/DESCR
> ===
> RCS file: /cvs/ports/x11/st/pkg/DESCR,v
> retrieving revision 1.2
> diff -u -p -r1.2 DESCR
> --- pkg/DESCR 12 Jan 2023 21:00:14 - 1.2
> +++ pkg/DESCR 18 Jul 2023 05:17:24 -
> @@ -3,3 +3,4 @@ st is a simple virtual terminal emulator
> Flavour:
> scrollback - allows scrolling through terminal output with
> shift+pgup/pgdn
> + xresources - configure st through Xresources
--
Sebastien Marie
Re: lang/* BTI breakage - lang/ghc
On Fri, Jun 30, 2023 at 09:15:55PM +0200, Matthias Kilian wrote:
> Hi,
>
> On Thu, Jun 29, 2023 at 10:55:34PM -0700, Greg Steuck wrote:
> > Christian Weisgerber writes:
> >
> > > Since BTI affects any and all compilers that generate executable code,
> > > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > > list of failures:
> > >
> > > devel/jdk/1.8 # needs new bootstrap
> > > lang/crystal
> > > lang/fpc
> > > lang/gcc/11
> > > lang/ghc
> >
> > Naturally, as kili@ suspected, we need a new bootstrap with the right
> > flags plumbed through. Unfortunately I don't have access to the hardware
> > with this feature.
>
> Same here. Could someone be so kind to try the diff below? It uses a
> bootstrap I built from lang/ghc-8.10.7 with similar changes.
>
> If it works, I'll commit both (lang/ghc and lang/ghc-8.10.7) and also
> look to integrate Gregs work getting rid of USE_NOEXECONLY.
I have build tested lang/ghc on IBT machine, and it was fine.
ok semarie@
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ghc/Makefile,v
> retrieving revision 1.211
> diff -u -p -r1.211 Makefile
> --- Makefile 17 Mar 2023 10:40:44 - 1.211
> +++ Makefile 30 Jun 2023 19:05:02 -
> @@ -11,14 +11,16 @@ NO_CCACHE = Yes
> # Upstream bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22782
> USE_NOEXECONLY = Yes
>
> +USE_NOBTCFI =Yes
> +
> GHC_VERSION =9.2.7
> -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.20230316
> +BIN_VER =8.10.7.20230613
>
> # lang/python needed for regression tests.
> MODULES =lang/python
> @@ -114,7 +116,8 @@ CONFIGURE_ARGS += --with-ffi-includes=${
>
> CONFIGURE_ENV += SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
>
> -GHC_CC_OPTS =-Wl,--no-execute-only -Qunused-arguments
> +GHC_CC_OPTS =-Wl,--no-execute-only -Qunused-arguments \
> + -Wl,-z,nobtcfi
> CONFIGURE_ENV += CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
> CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}" \
> CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}" \
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/ghc/distinfo,v
> retrieving revision 1.67
> diff -u -p -r1.67 distinfo
> --- distinfo 17 Mar 2023 10:40:44 - 1.67
> +++ distinfo 30 Jun 2023 19:05:02 -
> @@ -1,8 +1,8 @@
> -SHA256 (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) =
> rj7ePY2zwgajLYmuRTyGi+TaJVFnE13TdaNpmPjEd1I=
> -SHA256 (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) =
> 8QVqNJq6XGI+Xw9Hdf4uMDAeYY9V97U0DDJFPePDe2U=
> +SHA256 (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) =
> /QCac6kB92pFCO9fzn90h/bFJysRl8GUQjOHBVA/5SA=
> +SHA256 (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) =
> LpQDN0fV+YASghLoGTjn0yzEeuYPNW9gtUasieUgu+g=
> SHA256 (ghc/ghc-9.2.7-src.tar.xz) =
> olNWehe3NKTA3Q/6KW0zwqW1pUp335iIBqKh4cp+iLg=
> SHA256 (ghc/ghc-9.2.7-testsuite.tar.xz) =
> JJSvF12xtiODaWBBo/N+s2VPyN9R8SifTygu6GsJ+1A=
> -SIZE (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) = 48940296
> -SIZE (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) = 2923557
> +SIZE (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) = 48998912
> +SIZE (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) = 2941676
> SIZE (ghc/ghc-9.2.7-src.tar.xz) = 24610432
> SIZE (ghc/ghc-9.2.7-testsuite.tar.xz) = 3219572
>
--
Sebastien Marie
Re: lang/sbcl: update to 2.3.6 (latest) and take MAINTAINER
On Fri, Jun 30, 2023 at 07:34:05PM +0200, develo...@robert-palm.de wrote: > Zitat von Sebastien Marie : > > > > The port is buildable on wider architectures range. > > > > Thank you. Will it be available for RISC V, too ? > yes, riscv64 should have it. I know sbcl has code for it, but as I don't have access to a riscv64 host to check that it build fine on OpenBSD. The bootstrapping is done natively using lang/ecl (which is C code). I have only tested aarch64 (arm64) and it was fine. -- Sebastien Marie
x11/stumpwm: few adjustments after lang/sbcl update
Hi,
As lang/sbcl has been updated to 2.3.6, the compression method changed from
libz
to libzstd.
As stumpwm is built using sbcl, the port needs few adjustments to add
LIB_DEPENDS on zstd, and updated WANTLIB.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - f2b2271db0cce22f098315362598c10c5db64ead
path + /home/semarie/repos/openbsd/ports
blob - 1fe35715ef106358692d35766dd50025d89563b0
file + x11/stumpwm/Makefile
--- x11/stumpwm/Makefile
+++ x11/stumpwm/Makefile
@@ -2,6 +2,7 @@ DISTNAME= stumpwm-${VERSION}
VERSION= 22.11
DISTNAME= stumpwm-${VERSION}
+REVISION= 0
CATEGORIES=x11
@@ -12,7 +13,7 @@ WANTLIB += c m pthread util z
# GPLv2
PERMIT_PACKAGE=Yes
-WANTLIB += c m pthread util z
+WANTLIB += c m pthread util zstd
MASTER_SITES= https://github.com/stumpwm/stumpwm/archive/
MASTER_SITES0= https://github.com/edicl/cl-ppcre/archive/
@@ -26,6 +27,7 @@ BUILD_DEPENDS=lang/sbcl,threads \
BUILD_DEPENDS= lang/sbcl,threads \
print/texinfo
+LIB_DEPENDS= archivers/zstd
AUTOCONF_VERSION= 2.69
CONFIGURE_STYLE= autoconf no-autoheader
Re: lang/sbcl: update to 2.3.6 (latest) and take MAINTAINER
On Fri, Jun 30, 2023 at 01:37:48PM +0200, solene wrote: > > I don't know if this is expected, I wanted to try to build sbcl using > ecl on amd64 because I don't have any other arch to try the build with > ecl, but it's not working, I attached the build log > ===> lang/sbcl > ===> Building from scratch sbcl-2.3.6p0 > ===> sbcl-2.3.6p0 depends on: ecl-* -> ecl-21.2.1 the ecl version isn't the latest in -current. you need ecl-21.2.1p0 which contains a backport to be able to build recent sbcl. the p0 version was commited yesterday. > ===> sbcl-2.3.6p0 depends on: texinfo-* -> texinfo-6.5p4 > ===> sbcl-2.3.6p0 depends on: gmake-* -> gmake-4.4.1 > ===> sbcl-2.3.6p0 depends on: dwz-* -> dwz-0.15 > ===> sbcl-2.3.6p0 depends on: bzip2-* -> bzip2-1.0.8p0 > ===> sbcl-2.3.6p0 depends on: zstd-* -> zstd-1.5.5 > ===> Verifying specs: c m util zstd > ===> found c.97.0 m.10.1 util.17.0 zstd.6.3 thanks for testing it. -- Sebastien Marie
Re: lang/* BTI breakage - lang/sbcl
On Fri, Jun 30, 2023 at 10:21:30AM +0100, Stuart Henderson wrote: > On 2023/06/30 06:47, Sebastien Marie wrote: > > On Thu, Jun 29, 2023 at 11:19:50PM +0200, Christian Weisgerber wrote: > > > Since BTI affects any and all compilers that generate executable code, > > > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the > > > list of failures: > > > > > > [...] > > > lang/sbcl > > > > the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI. > > I'm ok with that update and taking maintainer FWIW (but I don't run lisp > things myself). > > I guess it also needs a patch to sbcl itself to use nobtcfi when linking > though, so that sbcl-compiled code also works at runtime? (Or an equivalent > if it doesn't use the system linker). > sbcl compilation works by generating native code inside live managed memory, and permits to save the whole memory image to a file. it is why the binary currently also needs WX and RX memory (I intent to work a bit on it if possible). When generating an executable, it is copying /usr/local/bin/sbcl binary as base, and append the (optionally compressed) memory image to the file, to create a standalone executable. When the output file is executed, it is reading its own image, loads it in memory, and use an entrypoint for loaded code. So the generated file has all the flags it needs to run (because copied from /usr/local/bin/sbcl binary). -- Sebastien Marie
