CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/19 09:56:00 Modified files: lang/zig : Makefile distinfo lang/zig/patches: patch-src_link_Elf_zig lang/zig/pkg : PLIST Removed files: lang/zig/patches: patch-lib_std_debug_zig patch-lib_std_dwarf_abi_zig patch-lib_std_os_zig Log message: update lang/zig to 0.12.0 (+ latest commits in 0.12.x branch)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/19 07:53:57 Modified files: www/seamonkey : Makefile Added files: mail/mozilla-thunderbird/patches: patch-gfx_qcms_src_lib_rs www/firefox-esr/patches: patch-gfx_qcms_src_lib_rs www/tor-browser/browser/patches: patch-gfx_qcms_src_lib_rs Log message: patch firefox-esr, mozilla-thunderbird and tor-browser after lang/rust update mark seamonkey BROKEN ok landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/19 07:52:16 Modified files: lang/rust : Makefile distinfo rust.port.mk lang/rust/patches: patch-compiler_rustc_mir_transform_src_abort_unwinding_calls_rs patch-compiler_rustc_session_src_options_rs patch-src_bootstrap_bootstrap_py patch-src_bootstrap_src_core_build_steps_test_rs patch-src_bootstrap_src_lib_rs patch-src_llvm-project_llvm_tools_llvm-shlib_CMakeLists_txt patch-vendor_openssl-sys_build_main_rs lang/rust/pkg : PLIST-gdb PLIST-src Added files: lang/rust/patches: patch-library_std_src_os_unix_net_addr_rs patch-src_etc_rust-lldb Removed files: lang/rust/patches: patch-vendor_openssl-sys_src_crypto_rs patch-vendor_openssl-sys_src_handwritten_crypto_rs patch-vendor_openssl-sys_src_handwritten_stack_rs patch-vendor_openssl-sys_src_macros_rs Log message: update lang/rust to 1.78.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/18 09:35:58 Modified files: telephony/py-phonenumbers: Makefile distinfo Log message: update telephony/py-phonenumbers to 8.13.37 drop maintainership while here
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/18 09:31:11 Modified files: databases/py-sql: Makefile distinfo databases/py-sql/pkg: PLIST Log message: update databases/py-sql to 1.5.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/18 09:18:47 Modified files: textproc/typst : Makefile crates.inc distinfo Removed files: textproc/typst/patches: patch-Cargo_lock patch-Cargo_toml Log message: update typst to 0.11.1 take maintainership ok volker@
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) =
ip7nDEOq9BfJFDlmRaD6hSY
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/11 07:12:11 Modified files: mail/offlineimap: Makefile distinfo mail/offlineimap/patches: patch-offlineimap_conf Log message: update mail/offlineimap to latest commit (2023-12-18) latest release 8.0.0 is a bit old, but the repository is somehow active and has proper python-3.11 support. ok sthen@
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.
#
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/09 04:11:58 Modified files: devel/cargo: cargo.port.mk Log message: devel/cargo: prepare deprecation of .cargo/config file configure the cargo ports using `config.toml` file (instead of `config`) warning: `.../.cargo/config` is deprecated in favor of `config.toml`
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/08 03:12:03 Modified files: devel/distcc : Makefile distinfo devel/distcc/patches: patch-man_distccd_1 Log message: update devel/distcc to 3.4 switch from gtk+2 to gtk+3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/06 09:57:09 Modified files: x11/stumpwm: Makefile Log message: bump x11/stumpwm after lang/sbcl update
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/05/06 09:56:24 Modified files: lang/sbcl : Makefile distinfo lang/sbcl/pkg : PLIST Added files: lang/sbcl/patches: patch-src_cold_shared_lisp patch-src_runtime_Config_generic-openbsd Removed files: lang/sbcl/patches: patch-xperfecthash30_lisp-expr Log message: update lang/sbcl to 2.4.4 - enable sb-linkable-runtime (libsbcl.a) - build and install shared-library (diff partially from Dima Pasechnik) on supported platforms
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 -
+++ patch
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/23 02:17:07 Modified files: textproc : Makefile Log message: hook textproc/typst reminded by tb@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/23 01:57:20 Log message: import textproc/typst 0.11.0 ok landry@ rsadowski@ 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 Status: Vendor Tag: semarie Release Tags: semarie_20240423 N ports/textproc/typst/Makefile N ports/textproc/typst/distinfo N ports/textproc/typst/crates.inc N ports/textproc/typst/patches/patch-Cargo_toml N ports/textproc/typst/patches/patch-Cargo_lock N ports/textproc/typst/pkg/DESCR N ports/textproc/typst/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/23 01:21:03 Modified files: telephony/py-phonenumbers: Makefile distinfo Log message: update telephony/py-phonenumbers to 8.13.35
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/23 01:18:31 Modified files: devel/py-stdnum: Makefile distinfo devel/py-stdnum/pkg: PLIST Log message: update devel/py-stdnum to 1.20
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/23 01:15:46 Modified files: print/py-relatorio: Makefile distinfo Log message: update print/py-relatorio to 0.10.2
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/18 21:58:17 Modified files: x11/stumpwm: Makefile Log message: force x11/stumpwm update, after lang/sbcl update noticed by Kirill A. Korinsky
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/10 03:46:01 Modified files: lang/rust : Makefile distinfo lang/rust/pkg : DESCR-bootstrap PLIST-main PLIST-src Log message: update lang/rust to 1.77.2 fix for CVE-2024-24576 (Windows only)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/08 09:32:45 Modified files: lang/sbcl : Makefile distinfo Added files: lang/sbcl/files: ecl-nodebugger.lisp lang/sbcl/patches: patch-xperfecthash30_lisp-expr Log message: update lang/sbcl to 2.4.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/08 09:29:42 Modified files: lang/rust : Makefile lang/rust/pkg : PLIST-main Added files: lang/rust/pkg : DESCR-bootstrap PLIST-bootstrap Log message: unbreak rust-src subpackage I missed removing some files in PLIST-main when updating lang/rust to 1.77.0, resulting conflicts between -main and -src subpackages. reported by tim@ and Foxy While here, add a -bootstrap subpackage.
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
-BOOTSTRAPDIR=${WRKDIR}/${BOOTSTRAPNAME}
-bootstrap: build
- ${_PBU
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/04/02 06:14:19 Modified files: lang/rust : Makefile distinfo Log message: update lang/rust to 1.77.1 while here, switch to lzip for compressing bootstraps and update riscv64 bootstrap (from jca@, recompressed by me, thanks)
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 207D684 20BE5F4 27E4E79 34001B1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/30 04:34:22 ports/lang/sbcl/files Update of /cvs/ports/lang/sbcl/files In directory cvs.openbsd.org:/tmp/cvs-serv31665/files Log Message: Directory /cvs/ports/lang/sbcl/files added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/22 08:05:57 Modified files: devel/rust-analyzer: Makefile crates.inc distinfo devel/rust-analyzer/patches: patch-crates_sourcegen_src_lib_rs Added files: devel/rust-analyzer/patches: patch-xtask_src_codegen_rs Removed files: devel/rust-analyzer/patches: patch-crates_rust-analyzer_tests_slow-tests_tidy_rs Log message: update devel/rust-analyzer to 2024-03-18 (and unbreak it)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/22 06:55:40 Modified files: devel/rust-analyzer: Makefile Log message: devel/rust-analyzer: mark broken for now (fail to build with lang/rust 1.77.0)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/22 06:53:06 Modified files: lang/rust : Makefile distinfo rust.port.mk lang/rust/patches: patch-compiler_rustc_session_src_options_rs patch-src_bootstrap_bootstrap_py patch-src_bootstrap_src_core_build_steps_test_rs patch-src_bootstrap_src_lib_rs patch-vendor_openssl-sys_build_main_rs patch-vendor_openssl_build_rs patch-vendor_openssl_src_lib_rs lang/rust/pkg : PLIST-main PLIST-src Added files: lang/rust/patches: patch-library_std_src_sys_pal_unix_os_rs patch-vendor_openssl-sys-0_9_92_build_main_rs patch-vendor_openssl-sys-0_9_92_src_handwritten_x509_rs Removed files: lang/rust/patches: patch-library_std_src_sys_unix_os_rs patch-library_std_src_sys_unix_thread_rs patch-vendor_openssl-sys-0_9_90_src_handwritten_x509_rs patch-vendor_openssl-sys_build_cfgs_rs patch-vendor_openssl-sys_src_handwritten_x509_rs patch-vendor_openssl-sys_src_handwritten_x509v3_rs patch-vendor_openssl_src_x509_mod_rs Log message: update lang/rust to 1.77.0 Announce: https://blog.rust-lang.org/2024/03/21/Rust-1.77.0.html ReleaseNotes: https://doc.rust-lang.org/nightly/releases.html#version-77-2024-03-21
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/11 03:07:30 Modified files: sysutils/sysclean: Makefile distinfo Log message: sysutils/sysclean: update to 3.8 - accounting files are expected to be present by default now ok sthen@
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/04 00:20:07 Modified files: devel/py-simpleeval: Makefile Log message: devel/py-simpleeval: update my MAINTAINER address (missed in previous commit)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 02:09:40 Modified files: databases/py-sql: Makefile distinfo Log message: update databases/py-sql to 1.4.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 02:04:07 Modified files: sysutils/sysclean: Makefile distinfo Log message: update sysutils/sysclean to 3.7 - call MAKEDEV(8) from /dev directory - use shared lock instead of exclusive lock for PKG_DBDIR
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 01:33:05 Modified files: telephony/py-phonenumbers: Makefile distinfo Log message: update telephony/py-phonenumbers to 8.13.31
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 01:30:57 Modified files: graphics/py-pygal: Makefile distinfo Log message: update graphics/py-pygal to 3.0.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 01:28:53 Modified files: devel/py-stdnum: Makefile distinfo devel/py-stdnum/pkg: PLIST Log message: update devel/py-stdnum to 1.19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 01:23:13 Modified files: devel/cargo-generate-vendor: Makefile devel/py-cached-property: Makefile lang/zig : Makefile print/py-relatorio: Makefile sysutils/checkrestart: Makefile textproc/py-ofxparse: Makefile www/woob : Makefile Log message: update MAINTAINER in ports I maintain
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 01:12:42 Removed files: productivity/tryton: Makefile Makefile.inc productivity/tryton/5.0: Makefile Makefile.inc productivity/tryton/5.0/account: Makefile distinfo productivity/tryton/5.0/account/pkg: DESCR PLIST productivity/tryton/5.0/account_asset: Makefile distinfo productivity/tryton/5.0/account_asset/pkg: DESCR PLIST productivity/tryton/5.0/account_be: Makefile distinfo productivity/tryton/5.0/account_be/pkg: DESCR PLIST productivity/tryton/5.0/account_credit_limit: Makefile distinfo productivity/tryton/5.0/account_credit_limit/pkg: DESCR PLIST productivity/tryton/5.0/account_de_skr03: Makefile distinfo productivity/tryton/5.0/account_de_skr03/pkg: DESCR PLIST productivity/tryton/5.0/account_deposit: Makefile distinfo productivity/tryton/5.0/account_deposit/pkg: DESCR PLIST productivity/tryton/5.0/account_dunning: Makefile distinfo productivity/tryton/5.0/account_dunning/pkg: DESCR PLIST productivity/tryton/5.0/account_dunning_email: Makefile distinfo productivity/tryton/5.0/account_dunning_email/pkg: DESCR PLIST productivity/tryton/5.0/account_dunning_fee: Makefile distinfo productivity/tryton/5.0/account_dunning_fee/pkg: DESCR PLIST productivity/tryton/5.0/account_dunning_letter: Makefile distinfo productivity/tryton/5.0/account_dunning_letter/pkg: DESCR PLIST productivity/tryton/5.0/account_es: Makefile distinfo productivity/tryton/5.0/account_es/pkg: DESCR PLIST productivity/tryton/5.0/account_eu: Makefile distinfo productivity/tryton/5.0/account_eu/pkg: DESCR PLIST productivity/tryton/5.0/account_fr: Makefile distinfo productivity/tryton/5.0/account_fr/pkg: DESCR PLIST productivity/tryton/5.0/account_fr_chorus: Makefile distinfo productivity/tryton/5.0/account_fr_chorus/pkg: DESCR PLIST productivity/tryton/5.0/account_invoice: Makefile distinfo productivity/tryton/5.0/account_invoice/pkg: DESCR PLIST productivity/tryton/5.0/account_invoice_correction: Makefile distinfo productivity/tryton/5.0/account_invoice_correction/pkg: DESCR PLIST productivity/tryton/5.0/account_invoice_history: Makefile distinfo productivity/tryton/5.0/account_invoice_history/pkg: DESCR PLIST productivity/tryton/5.0/account_invoice_line_standalone: Makefile distinfo productivity/tryton/5.0/account_invoice_line_standalone/pkg: DESCR PLIST productivity/tryton/5.0/account_invoice_stock: Makefile distinfo productivity/tryton/5.0/account_invoice_stock/pkg: DESCR PLIST productivity/tryton/5.0/account_payment: Makefile distinfo productivity/tryton/5.0/account_payment/pkg: DESCR PLIST productivity/tryton/5.0/account_payment_clearing: Makefile distinfo productivity/tryton/5.0/account_payment_clearing/pkg: DESCR PLIST productivity/tryton/5.0/account_payment_sepa: Makefile distinfo productivity/tryton/5.0/account_payment_sepa/pkg: DESCR PLIST productivity/tryton/5.0/account_payment_sepa_cfonb: Makefile distinfo productivity/tryton/5.0/account_payment_sepa_cfonb/pkg: DESCR PLIST productivity/tryton/5.0/account_product: Makefile distinfo productivity/tryton/5.0/account_product/pkg: DESCR PLIST productivity/tryton/5.0/account_statement: Makefile distinfo productivity/tryton/5.0/account_statement/pkg: DESCR PLIST productivity/tryton/5.0/account_statement_ofx: Makefile distinfo productivity/tryton/5.0/account_statement_ofx/pkg: DESCR PLIST productivity/tryton/5.0/account_stock_anglo_saxon: Makefile distinfo productivity/tryton/5.0/account_stock_anglo_saxon/pkg: DESCR PLIST productivity/tryton/5.0/account_stock_continental: Makefile
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 01:08:04 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm infrastructure/db: user.list Log message: free _tryton uid, and register all tryton ports as removed ok rsadowski@ daniel@ on initial proposition tweak from daniel@ for quirks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/03/03 01:06:25 Modified files: productivity : Makefile Log message: unhook productivity/tryton from the build ok rsadowski@ daniel@ on initial proposition
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/02/18 00:46:17 Modified files: x11/stumpwm: Makefile distinfo Added files: x11/stumpwm/patches: patch-make-image_lisp_in Log message: update x11/stumpwm to 23.11 from Kirill A. Korinsky ok Timo Myyra (maintainer) (with tweak)
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/02/10 05:23:28 Modified files: lang/rust : Makefile distinfo rust.port.mk lang/rust/patches: patch-compiler_rustc_mir_transform_src_abort_unwinding_calls_rs patch-compiler_rustc_session_src_options_rs patch-compiler_rustc_target_src_spec_targets_i686_unknown_openbsd_rs patch-library_std_src_sys_unix_os_rs patch-library_std_src_sys_unix_thread_rs patch-src_bootstrap_bootstrap_py patch-src_bootstrap_src_bin_rustc_rs patch-src_bootstrap_src_core_build_steps_test_rs patch-src_bootstrap_src_lib_rs lang/rust/pkg : PLIST-src Log message: update lang/rust to 1.76.0 Announce: https://blog.rust-lang.org/2024/02/08/Rust-1.76.0.html ChangeLog: https://doc.rust-lang.org/nightly/releases.html#version-1760-2024-02-08
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/02/08 08:33:43 Modified files: textproc/amber : Makefile crates.inc distinfo Log message: update textproc/amber to 0.6.0 0.6.0 is buildable with rust 1.75.0 and 1.76.0 ok edd@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/02/03 01:18:44 Modified files: lang/zig : Makefile lang/zig/patches: patch-lib_std_debug_zig patch-lib_std_os_zig Log message: lang/zig: unbreak the build msync() might return EPERM now. https://github.com/ziglang/zig/pull/18701
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/02/03 00:21:34 Modified files: lang/sbcl : Makefile distinfo Log message: lang/sbcl: update to 2.4.1 Release notes: https://www.sbcl.org/news.html#2.4.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/02/03 00:20:10 Modified files: lang/zig/patches: patch-lib_std_dwarf_abi_zig Log message: lang/zig: add reference to upstream commit for local patch
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/16 02:22:15 Modified files: devel : Makefile Log message: hook c2ffi
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/16 02:19:18 Log message: Import devel/c2ffi 16.0.0.0 ok tb@ Description: This is a tool for extracting definitions from C, C++, and Objective C headers for use with foreign function call interfaces. There are generally two steps to using `c2ffi`: - Generate output for a particular header or file, gathering macro definitions (with the `-M .c` parameter) - Generate output for macro definitions by running `c2ffi` again on the *generated* file (without `-M`) Currently JSON is the default output. This is in a rather wordy hierarchical format, with each object having a "tag" field which describes it. All objects are contained in an array. This should make it fairly easy (or at least far easier than parsing C yourself) to transform into language-specific bindings. The following language bindings exist for `c2ffi`: - [cl-autowrap](https://github.com/rpav/cl-autowrap/): Create bindings in Common Lisp from a `.h` with `c2ffi` using a simple `(c-include "file.h")` - [c2ffi-ruby](https://github.com/rpav/c2ffi-ruby): Uses the JSON from c2ffi to produce a nicely-formatted Ruby file for ruby-ffi. Status: Vendor Tag: semarie Release Tags: semarie_20240116 N ports/devel/c2ffi/Makefile N ports/devel/c2ffi/distinfo N ports/devel/c2ffi/pkg/DESCR N ports/devel/c2ffi/pkg/PLIST N ports/devel/c2ffi/patches/patch-CMake_setup_post_project_cmake N ports/devel/c2ffi/patches/patch-CMakeLists_txt No conflicts created by this import
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/10 01:20:59 Modified files: devel/cargo: cargo.port.mk Log message: devel/cargo: configure cargo options via MODCARGO_ENV and config.toml - unify cargo configuration in config.toml and MODCARGO_ENV - prefer to use config.toml and MODCARGO_ENV instead of arguments on the command-line (it permits external tools using cargo directly instead of MODCARGO_*_TARGET to have the right configuration)
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 ruby-rb_sys dependency
ok semarie@
>> *
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/06 01:02:53 Modified files: devel/cargo: cargo.port.mk devel/selene : Makefile mail/meli : Makefile Log message: devel/cargo: add support for installing several different paths - rename MODCARGO_INSTALL_TARGET_PATH to MODCARGO_INSTALL_TARGET_PATHS - and add support for multiples paths and changes the two ports currently using MODCARGO_INSTALL_TARGET_PATH
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/03 00:47:27 Modified files: security/suricata: Makefile Log message: security/suricata: uses lang/rust module It switches suricata 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. ok tb@ gonzalo@
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/02 03:33:43 Modified files: www/mozilla: mozilla.port.mk Log message: www/mozilla: uses lang/rust module It switches all ports using www/mozilla 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. ok tb@ landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 21:47:30 Modified files: security/clamav: Makefile Log message: security/clamav: uses lang/rust module It switches clamav 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. ok tb@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 12:21:10 Modified files: devel/spidermonkey115: Makefile x11/gnome/tour : Makefile Log message: devel/spidermonkey115 and x11/gnome/tour: uses lang/rust module It switches the ports 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. ok tb@ ajacoutot@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 10:03:48 Modified files: lang/ruby/3.2 : Makefile lang/ruby/3.3 : Makefile Log message: lang/ruby/3.2 and 3.3: uses lang/rust module 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. ok tb@ jeremy@
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 07:33:33 Modified files: games/0ad/base : Makefile Log message: games/0ad/base: use lang/rust module use lang/rust module instead of BUILD_DEPENDS lang/rust. the port will get automatic bump with SYSTEM-VERSION-rust. while here, add MODRUST_WANTLIB to WANTLIB.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 07:14:49 Modified files: databases/influxdb: Makefile devel/cargo: cargo.port.mk infrastructure/mk: arch-defines.mk mail/stalwart/jmap: Makefile net/synapse: Makefile www/newsboat : Makefile x11/gnome/librsvg: Makefile Added files: lang/rust : rust.port.mk Log message: lang/rust: add a module to cope with SYSTEM_VERSION-rust lang/rust module is intented to be only minimal. makes devel/cargo module to use lang/rust module. - makes MODCARGO_WANTLIB re-exports MODRUST_WANTLIB - it changes the WANTLIB to the right value for sparc64, but as SYSTEM_VERSION-rust is bumped, it should be fine adds SYSTEM_VERSION-rust ?= 0 to arch-defines.mk - this way, when lang/rust isn't used, -V 0 is passed (it is a no-op), and else, it is the value defined in lang/rust module. while here, correct few ports to use the right WANTLIB value ok tb@ "I'm happy with it" espie@ (regarding the usage of _SYSTEM_VERSION-rust)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: sema...@cvs.openbsd.org 2024/01/01 02:02:17
Modified files:
databases/influxdb: Makefile
devel/cargo-audit: Makefile
devel/cbindgen : Makefile
devel/elfcat : Makefile
devel/snare: Makefile
mail/meli : Makefile
mail/stalwart/cli: Makefile
mail/stalwart/imap: Makefile
mail/stalwart/smtp: Makefile
net/bore : Makefile
net/dog: Makefile
net/routinator : Makefile
security/py-cryptography: Makefile
security/rbw : Makefile
security/sn0int: Makefile
sysutils/bat : Makefile
sysutils/broot : Makefile
sysutils/fclones: Makefile
textproc/amber : Makefile
textproc/jless : Makefile
textproc/mdbook: Makefile
www/castor : Makefile
www/geckodriver: Makefile
www/nextcloud_notify_push: Makefile
www/py-adblock : Makefile
x11/alacritty : Makefile
x11/xcolor : Makefile
Log message:
rust ports cleanup: use MODCARGO_WANTLIB in WANTLIB
fix WANTLIB for simple ports. rust ports are expected to use MODCARGO_WANTLIB
instead of hardcoding values (which will be soon different across archs).
replace "c c++abi pthread" by ${MODCARGO_WANTLIB} in WANTLIB
no changes, as it is the current value of MODCARGO_WANTLIB (even if buggy).
ok tb@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 01:35:07 Modified files: devel/cargo: cargo.port.mk Log message: rust ports cleanup: (ab)use a typo in MODCARGO_WANTLIB MODCARGO_WANTLIB should be defined differently on sparc64: the unwind mecanism used comes from (static) libgcc.a, whereas it comes from (dynamic) c++abi library on others architectures. but the current code has a typo in the conditionnal: MARCHINE_ARCH is wrong and should have been MACHINE_ARCH initially. and we can't change it without bumping all the ports using MODCARGO_WANTLIB. this typo makes MODCARGO_WANTLIB to have the value "c pthread c++abi" in all cases. it isn't a big trouble for sparc64 (outside an unncessary dependency on c++abi). so for now, simplify the code and use MODCARGO_WANTLIB="c pthread c++abi" unconditionnally. it will be changed to the right value soon. no changes (due to the initial typo).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 01:27:06 Modified files: devel/cargo: cargo.port.mk Log message: rust ports cleanup: remove some unused variables in cargo.port.mk - MODCARGO_BUILD_DEPENDS (and hardcode lang/rust in BUILD_DEPENDS) - MODCARGO_BUILDDEP these variables aren't used in the ports tree, remove them.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2024/01/01 01:22:41 Modified files: databases/influxdb: Makefile devel/sccache : Makefile x11/gnome/librsvg: Makefile Log message: rust ports cleanup: remove explicit BUILD_DEPENDS lang/rust when not needed when MODULE devel/cargo is used, lang/rust is already added to BUILD_DEPENDS. no changes (outside removing one lang/rust from the two present in BUILD_DEPENDS).
Re: lang/rust: roadmap for using SYSTEM_VERSION
=${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 c++abi crypto git2 m pth
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 "${MARCHINE_ARC
