Re: [update] shells/tcsh 6.24.07 -> 6.24.10
On Mon Jan 08, 2024 at 05:40:50PM -0500, Josh Grosse wrote: > Ping. Thanks Josh Grosse. Committed with missing patches updates (make update-patches). > > On Thu, Dec 28, 2023 at 01:44:15PM -0500, Josh Grosse wrote: > > I've been using this minor update on amd64 for a week > > without any issues. > > > diff --git a/shells/tcsh/Makefile b/shells/tcsh/Makefile > > index 9d88e16c1c5..57525949880 100644 > > --- a/shells/tcsh/Makefile > > +++ b/shells/tcsh/Makefile > > @@ -1,6 +1,6 @@ > > COMMENT= extended C-shell with many useful features > > > > -DISTNAME= tcsh-6.24.07 > > +DISTNAME= tcsh-6.24.10 > > CATEGORIES=shells > > HOMEPAGE= https://www.tcsh.org/ > > > > diff --git a/shells/tcsh/distinfo b/shells/tcsh/distinfo > > index 9888bbfe496..e4b94f0cf0b 100644 > > --- a/shells/tcsh/distinfo > > +++ b/shells/tcsh/distinfo > > @@ -1,2 +1,2 @@ > > -SHA256 (tcsh-6.24.07.tar.gz) = dOTpgFy9lBPtNLT/odcvyNDvgaW3lHaFQJFBbOkzaZU= > > -SIZE (tcsh-6.24.07.tar.gz) = 946889 > > +SHA256 (tcsh-6.24.10.tar.gz) = E0dcD763QTnTPteTvwD/u7KsLcn7HURGekEHYKujZmQ= > > +SIZE (tcsh-6.24.10.tar.gz) = 956578 >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/01/09 00:34:01 Modified files: shells/tcsh: Makefile distinfo shells/tcsh/patches: patch-tests_subst_at patch-tests_variables_at Log message: Update tcsh to 6.24.10 Update diff from Josh Grosse with patches regen by me.
Re: [new] sysutils/cloud-init (again)
On Fri Jan 05, 2024 at 01:05:38AM +, Mina Galić wrote: > > > Hi folks, > > > > > > I'm writing to the list to add a new port. > > > This is the second attempt (I'm aware of) to add this > > > port. My work is based on the first attempt. > > > See https://marc.info/?l=openbsd-ports=165239608209610 > > > and https://marc.info/?l=openbsd-ports=165364771409636 > > > > > > I am one of the main contributors of BSD (mostly FreeBSD) > > > patches to cloud-init, and I spent the last couple of weeks > > > fixing OpenBSD issues. > > > > > > You can find the current state of my port here: > > > https://codeberg.org/meena/openbsd-ports/src/branch/add/cloud-init/sysutils/cloud-init > > > > > > This is a snapshot of what the final thing will look like. > > > Most importantly, you'll notice that it's using > > > > > > GH_ACCOUNT = igalic > > > > > > instead of > > > > > > GH_ACCOUNT = canonical > > > > > > because two of my Pull requests haven't been merged yet. > > > After the holidays (next year), but especially with the > > > next cloud-init release (in about 3 months), I expect to > > > not need any extra patches. > > > > > > > > Please use the default GH_ACCOUNT and add your changes as patches, this > > make it easier to keep track of what has changed. > > > > Will test out tonight and let you know more. > > > > Now that the holidays are over, and cloud-init developers are back > to merging my very good patches, I have switched this port back to > canonical's GH_ACCOUNT and declare it finished. > > Browse, > https://codeberg.org/meena/openbsd-ports/src/branch/add/cloud-init/sysutils/cloud-init > see patch: > https://codeberg.org/meena/openbsd-ports/commit/b671f56ebadb601b13385750b84018603e96bfe3 > download and apply patch: > https://codeberg.org/meena/openbsd-ports/commit/b671f56ebadb601b13385750b84018603e96bfe3.patch > > > Thanks, > > Aisha > > > > > This is a bit ambitious, because currently there are 19 > > > failing tests. (On FreeBSD we're down to 0) > > (I have not gotten around to this yet) > > Thank you all in advance, > > Kind regards, > > Mina http://www.unicode-symbol.com/u/0107.html Galić Could you provide a tarball with the new port?
devel/flake8: Update to 7.0.0
Hi, ports@:
Here is a simple patch for devel/flake8 to update to 7.0.0.
It build and run well on amd64-current system.
Cheers !
wenIndex: Makefile
===
RCS file: /cvs/ports/devel/flake8/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile26 Oct 2023 10:03:48 - 1.33
+++ Makefile9 Jan 2024 06:13:00 -
@@ -1,8 +1,7 @@
COMMENT= modular python code checker wrapping pep8 and pyflakes
-MODPY_EGG_VERSION= 6.1.0
+MODPY_EGG_VERSION= 7.0.0
DISTNAME= flake8-${MODPY_EGG_VERSION}
-REVISION= 0
CATEGORIES=devel
@@ -19,7 +18,7 @@ MODPY_PYBUILD=setuptools
RUN_DEPENDS= devel/py-codestyle${MODPY_FLAVOR}<2.12.0 \
devel/py-mccabe${MODPY_FLAVOR}<0.8.0 \
- devel/pyflakes${MODPY_FLAVOR}<3.2.0
+ devel/pyflakes${MODPY_FLAVOR}<3.3.0
BUILD_DEPENDS= devel/py-test-runner${MODPY_FLAVOR}
Index: distinfo
===
RCS file: /cvs/ports/devel/flake8/distinfo,v
retrieving revision 1.14
diff -u -p -r1.14 distinfo
--- distinfo25 Oct 2023 15:54:25 - 1.14
+++ distinfo9 Jan 2024 06:13:00 -
@@ -1,2 +1,2 @@
-SHA256 (flake8-6.1.0.tar.gz) = 1bOFfwfAML21v0HH9TeZVx11xEkXSKOtzUfekp40zSM=
-SIZE (flake8-6.1.0.tar.gz) = 48767
+SHA256 (flake8-7.0.0.tar.gz) = M/lmIQWeZe7EdBaQhdySvybnstRzZrcL4vZ6uA3CUTI=
+SIZE (flake8-7.0.0.tar.gz) = 48219
devel/pyflakes: Update to 3.2.0
Hi, ports@:
Here is a simple patch for devel/pyflakes to update to 3.2.0.
It build well and pass all tests on amd64-current system.
It is required by the update of devel/flake8.
Cheers !
wenIndex: Makefile
===
RCS file: /cvs/ports/devel/pyflakes/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- Makefile25 Oct 2023 15:53:02 - 1.31
+++ Makefile9 Jan 2024 06:14:36 -
@@ -1,6 +1,6 @@
COMMENT= passive checker of Python programs
-MODPY_EGG_VERSION= 3.1.0
+MODPY_EGG_VERSION= 3.2.0
DISTNAME= pyflakes-${MODPY_EGG_VERSION}
CATEGORIES=devel
Index: distinfo
===
RCS file: /cvs/ports/devel/pyflakes/distinfo,v
retrieving revision 1.14
diff -u -p -r1.14 distinfo
--- distinfo25 Oct 2023 15:53:02 - 1.14
+++ distinfo9 Jan 2024 06:14:36 -
@@ -1,2 +1,2 @@
-SHA256 (pyflakes-3.1.0.tar.gz) = oKrgNMRE2wBxqgd5crpHaNQMgw2VOf1Fv0zT+PaZLvw=
-SIZE (pyflakes-3.1.0.tar.gz) = 63636
+SHA256 (pyflakes-3.2.0.tar.gz) = HGFgP/FUYh+yqRcgN9hNyjUA3vjItjBlfRcB8Cb4rz8=
+SIZE (pyflakes-3.2.0.tar.gz) = 63788
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: t...@cvs.openbsd.org2024/01/08 22:07:12 Modified files: lang/hashlink : Makefile distinfo lang/hashlink/patches: patch-Makefile patch-src_module_c patch-src_std_socket_c patch-src_std_thread_c Log message: update to hashlink 1.14; tested with Dead Cells, Northgard, and Nuclear Blaze without issues
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2024/01/08 21:23:07 Modified files: sysutils/rclone: Makefile distinfo Log message: Update to rclone-1.65.1 Changelog: https://rclone.org/changelog/#v1-65-1-2024-01-08
Re: UPDATE: sysutils/coreutils 9.3 => 9.4
On 1/8/2024 9:27 AM, Theo Buehler wrote: >> Tests pass on amd64 and i386; big endian testing would be appreciated. >> >> OK? > > I'm ok with this, but I'm unsure how much testing is required since it > is a dep for a sizable number of ports. > I feel the same way. That's why I always post updates and give it a fair bit of time. > Tests look good on sparc64: > Thanks for the sparc64 test! ~Brian
Re: www/p5-Plack: Update to 1.0051
looks ok to me On Mon, Jan 8, 2024 at 6:47 PM wen heping wrote: > Hi, > >Here is a simple patch for www/p5-Plack update to 1.0051, > it build well and pass all tests on amd64-current system. >Many ports depend on Plack, I tests some of it, no problem meet. > > > Cheers ! > wen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/01/08 18:21:47 Modified files: net/gpodder: Makefile distinfo Log message: update to gpodder 3.11.4; from maintainer Tim
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/01/08 18:05:34 Modified files: net/tdesktop : Makefile distinfo Log message: update to tdesktop 4.14.4
www/p5-Plack: Update to 1.0051
Hi, Here is a simple patch for www/p5-Plack update to 1.0051, it build well and pass all tests on amd64-current system. Many ports depend on Plack, I tests some of it, no problem meet. Cheers ! wenIndex: Makefile === RCS file: /cvs/ports/www/p5-Plack/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- Makefile11 Mar 2022 20:10:34 - 1.16 +++ Makefile8 Jan 2024 07:21:26 - @@ -2,7 +2,7 @@ COMMENT = interface between perl web fr MODULES = cpan PKG_ARCH = * -DISTNAME = Plack-1.0048 +DISTNAME = Plack-1.0051 CATEGORIES = www MAINTAINER = Abel Abraham Camarillo Ojeda Index: distinfo === RCS file: /cvs/ports/www/p5-Plack/distinfo,v retrieving revision 1.7 diff -u -p -r1.7 distinfo --- distinfo10 Feb 2021 07:39:24 - 1.7 +++ distinfo8 Jan 2024 07:21:26 - @@ -1,2 +1,2 @@ -SHA256 (Plack-1.0048.tar.gz) = MPXyXhm0N4WRVqJSb2HKmrcI1Q1XMMJ5GJQDqr/lQqY= -SIZE (Plack-1.0048.tar.gz) = 190445 +SHA256 (Plack-1.0051.tar.gz) = vr3pHEIpjtbsjmyCshQzobSao5QSwkfzkFuA+VWs93s= +SIZE (Plack-1.0051.tar.gz) = 191249
Re: LXQt, kwin, meta-packages and toolkit purity
I preinstalled kwin and qutebrowser and pulled the wip-ports zip into
/usr/ports/mystuff. Using the recommended build order, everything seems to
be building fine with the exception of on overlooked "make makesum" for
lxqt-sudo.
I am starting to see packaging issues:
"Tigger# make install
===> Checking files for qterminal-1.4.0
`/usr/ports/distfiles/lxqt/qterminal-1.4.0.tar.xz' is up to date.
(SHA256) lxqt/qterminal-1.4.0.tar.xz: OK
===> qterminal-1.4.0 depends on: qtermwidget->=1.4.0 - default
qtermwidget-1.0.0p0 does not match
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2384
'/usr/ports/pobj/qterminal-1.4.0/.dep-STEM-ge-1.4.0-x11-lxqt-qtermwidget':
@...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2794
'/usr/ports/pobj/qterminal-1.4.0/.extract_done': @cd
/usr/ports/mystuff/x11/...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2233
'/usr/ports/packages/amd64/all/qterminal-1.4.0.tgz': @cd
/usr/ports/mystuff/...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2723
'_internal-package': @case X${_DEPENDS_CACHE} in X) _DEPENDS_CACHE=$(
mktem...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2702 'package': @:;
cd /usr/ports/mystuff/x11/lxqt/qterminal && PKGPATH=x11/lxqt/...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2254
'/var/db/pkg/qterminal-1.4.0/+CONTENTS': @cd
/usr/ports/mystuff/x11/lxqt/qte...)
*** Error 2 in /usr/ports/mystuff/x11/lxqt/qterminal
(/usr/ports/infrastructure/mk/bsd.port.mk:2702 'install':
@lock=qterminal-1.4.0; expor...)
Tigger# vi Makefile
Tigger# pkg_info | grep qterm
qtermwidget-1.4.0 the terminal widget for QTerminal"
On Mon, 8 Jan 2024, Rafael Sadowski wrote:
Would you recommend completely replacing the current ports tree with wip-ports
or is there some way to update the libraries that I did not catch in the
porting guide? I had similiar issues with lximage-qt and pcmanfm-qt - both
fake installs built but had a mismatch.
Thanks
On Sat Jan 06, 2024 at 11:46:42AM -0800, J. Scott Heppler wrote:
Most of the CAD software is Qt Based and I've been running an OpenBSD Dual
Boot system with ArchLinux and LXQt. Essentially, I tried to build the
lightest, CAD compatible environment possible. With all of Rafael Sadows'
work, I suspect updating LXQt should be low hanging fruit.
My own build uses kwin instead of openbox and the only issue I had was
turning off the animation eye candy without kwindowsystems installed. It
was actually a ~/config file that I preserved before deleting kwindowsystem.
The older meta-package brought in openbox and gtk dependencies that would be
unused code when using kwin. Kwin should also be more wayland friendly
going forward.
I think it's worth opening a discussion to set the meta-package structure
and get developers behind the project. I'm not interested in spending days
generating patches only to have them ignored for months and go stale.
If it can come together, I'll contribute some of the updates.
---
J. Scott Heppler
If you want to update and test LXQt 1.4.0 you can find an update diff
here:
https://github.com/sizeofvoid/wip-ports/commit/79f5e47c05c4a8341e7873dd850e2077ca5e7293
In a Sunday evening mood I update LXQt to 1.4.0 just for fun. It's quite
straightforward but I don't plan to continue here unless someone starts
taking a look.
https://twitter.com/sizeofvoid/status/1744090390892867838/photo/1
--
J. Scott Heppler
Penguin Innovations
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTICE: This e-mail message and any attachments may
contain legally privileged and confidential information intended
solely for the use of the intended recipients. If you are not an
intended recipient, you are hereby notified that you have
received this message in error and any review, dissemination,
distribution, copying, or other unauthorized use of this email
and any attachment is strictly prohibited. If you have received
this email in error, please notify the sender immediately and
delete the message and any attachments from your system.
Re: [update] shells/tcsh 6.24.07 -> 6.24.10
Ping. On Thu, Dec 28, 2023 at 01:44:15PM -0500, Josh Grosse wrote: > I've been using this minor update on amd64 for a week > without any issues. > diff --git a/shells/tcsh/Makefile b/shells/tcsh/Makefile > index 9d88e16c1c5..57525949880 100644 > --- a/shells/tcsh/Makefile > +++ b/shells/tcsh/Makefile > @@ -1,6 +1,6 @@ > COMMENT= extended C-shell with many useful features > > -DISTNAME=tcsh-6.24.07 > +DISTNAME=tcsh-6.24.10 > CATEGORIES= shells > HOMEPAGE=https://www.tcsh.org/ > > diff --git a/shells/tcsh/distinfo b/shells/tcsh/distinfo > index 9888bbfe496..e4b94f0cf0b 100644 > --- a/shells/tcsh/distinfo > +++ b/shells/tcsh/distinfo > @@ -1,2 +1,2 @@ > -SHA256 (tcsh-6.24.07.tar.gz) = dOTpgFy9lBPtNLT/odcvyNDvgaW3lHaFQJFBbOkzaZU= > -SIZE (tcsh-6.24.07.tar.gz) = 946889 > +SHA256 (tcsh-6.24.10.tar.gz) = E0dcD763QTnTPteTvwD/u7KsLcn7HURGekEHYKujZmQ= > +SIZE (tcsh-6.24.10.tar.gz) = 956578
bsd.port.mk linker "if !exists" check and USE_LLD=ports
bsd.port.mk has this check to see whether a non-default linker exists:
revision 1.1468
date: 2019/05/28 20:08:17; author: naddy; state: Exp; lines: +6 -1;
commitid: xn33Wb6skIgmKqtI;
When switching to a non-default linker with USE_LLD, check whether
that linker (ld.bfd, ld.lld) actually exists, otherwise skip the
port. ok jca@ sthen@
this was fine with linkers in the base os, but now we also support
lld from ports
revision 1.1626
date: 2023/09/27 08:21:06; author: semarie; state: Exp; lines: +7 -1;
commitid: t7EqTUvUeFoCAazh;
extent USE_LLD to Yes/No/ports values.
'ports' permits to force the use of ld.lld from lang/clang module.
ok landry@
and there's a further complication now that we have both llvm 13 and
16 available; most ports are now using 16 but, on i386, lang/gcc
requires lld from llvm 13.
this typically results in the following from a bulk build:
$ grep lang/gcc/8 engine.log
35995@1704094961.28: !: lang/gcc/8 requires /usr/local/llvm13/bin/ld.lld
35995@1704094961.28: !: lang/gcc/8,-libs requires /usr/local/llvm13/bin/ld.lld
35995@1704094961.28: !: lang/gcc/8,-f95 requires /usr/local/llvm13/bin/ld.lld
35995@1704094961.38: !: math/cblas because of lang/gcc/8,-libs
35995@1704094961.52: !: math/lapack because of lang/gcc/8,-f95
35995@1704094961.61: !: lang/gcc/8,-f95 ignored already
35995@1704094961.61: !: lang/gcc/8 ignored already
35995@1704094961.62: !: lang/gcc/8,-libs ignored already
35995@1704094961.90: !: math/blas because of lang/gcc/8,-f95
35995@1704094962.08: !: lang/gcc/8,-f95 ignored already
35995@1704094962.08: !: lang/gcc/8 ignored already
35995@1704094962.09: !: lang/gcc/8,-libs ignored already
35995@1704094975.39: !: astro/wcslib because of lang/gcc/8,-f95
35995@1704094979.29: !: audio/cmu-sphinx3 because of lang/gcc/8,-f95
35995@1704094979.41: !: audio/cmu-sphinxbase because of lang/gcc/8,-libs
35995@1704095135.51: !: devel/openmpi because of lang/gcc/8,-c++
35995@1704095481.37: !: lang/compcert because of lang/gcc/8,-c++
35995@1704095554.99: !: math/R because of lang/gcc/8
35995@170409.98: !: math/cfitsio because of lang/gcc/8
35995@1704095560.11: !: math/hdf5 because of lang/gcc/8,-f95
35995@1704095569.74: !: math/plplot,-fortran because of lang/gcc/8
35995@1704095569.74: !: math/plplot,-main because of lang/gcc/8
35995@1704095569.75: !: math/plplot,-c++ because of lang/gcc/8
35995@1704095573.57: !: math/qrupdate because of lang/gcc/8,-libs
35995@1704095574.02: !: math/suitesparse because of lang/gcc/8,-libs
35995@1704096153.87: !: x11/kde-applications/cantor because of lang/gcc/8,-f95
35995@1704096241.69: !: lang/gcc/8 ignored already
35995@1704096241.84: !: lang/gcc/8,-f95 ignored already
35995@1704096242.33: !: lang/gcc/8,-c++ requires /usr/local/llvm13/bin/ld.lld
35995@1704096242.73: !: lang/gcc/8,-libs ignored already
and nothing with "lang/gcc/8,-f95" (i.e. gfortran) in the dependency
chain will build (e.g. numpy -> boost -> various).
Currently the only ports using USE_LLD=ports are lang/gcc/8 and
lang/gcc/11, and only on i386.
After trying many things, I think the diff below is probably the only
way to fix it (short of fixing the issues that require using llvm 13's
ld.lld for gcc).
I haven't put this through a bulk, but I _have_ done a bulk with the
IGNORE line commented-out (and not touching the !exists line) which
I think is an equivalent test, and of course boost and friends are
now getting built.
Does anyone have comments/objections or would like to OK?
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
diff -u -p -r1.1636 bsd.port.mk
--- bsd.port.mk 11 Nov 2023 11:53:38 - 1.1636
+++ bsd.port.mk 8 Jan 2024 22:12:34 -
@@ -821,7 +821,7 @@ _NONDEFAULT_LD = Yes
.endif
_NONDEFAULT_LD ?= No
.if ${_NONDEFAULT_LD:L} == "yes"
-. if !exists(${_LD_PROGRAM})
+. if !exists(${_LD_PROGRAM}) && ${USE_LLD:L} != "ports"
IGNORE = "requires ${_LD_PROGRAM}"
. endif
.endif
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/01/08 14:57:47 Modified files: devel/github-cli: Makefile distinfo modules.inc Log message: update to github-cli 2.41.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/08 14:12:45 Modified files: sysutils/m1n1/patches: patch-data_makelogo_sh Log message: regen patch
Update: ruby-commonmarker 1.0.3 (switch to Rust backend)
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.
* One crate needs a source file that doesn't appear to ship in the crate
(or the cargo module removes it).
* 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.
* This requires libclang for building, since it uses it to parse and
type check C/C++ header files. It does not link to it, so I have made
llvm a build depends.
* gmake must be used for building. I raised the issue upstream, since
almost all Ruby native gems will build with BSD make, but they think
that requiring gmake is acceptable.
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.
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 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
Index: devel/cargo/cargo.port.mk
===
RCS file: /cvs/ports/devel/cargo/cargo.port.mk,v
retrieving revision 1.45
diff -u -p -r1.45 cargo.port.mk
--- devel/cargo/cargo.port.mk 6 Jan 2024 08:02:52 - 1.45
+++ devel/cargo/cargo.port.mk 8 Jan 2024 20:43:52 -
@@ -56,6 +56,8 @@ DISTFILES += ${GH_DISTFILE}
DISTFILES.cargo +=
${_MODCARGO_DIST_SUBDIR}${_cratename}-${_cratever}.tar.gz{${_cratename}/${_cratever}/download}
.endfor
+MODCARGO_CRATE_EXTRACTDIR ?= ${WRKDIR}
+
# post-extract target for preparing crates directory.
# It will put all crates in the local crates directory.
MODCARGO_post-extract = \
@@ -63,7 +65,7 @@ MODCARGO_post-extract = \
mkdir -p ${MODCARGO_VENDOR_DIR} ;
.for _cratename _cratever in ${MODCARGO_CRATES}
MODCARGO_post-extract += \
- mv ${WRKDIR}/${_cratename}-${_cratever}
${MODCARGO_VENDOR_DIR}/${_cratename}-${_cratever} ;
+ mv ${MODCARGO_CRATE_EXTRACTDIR}/${_cratename}-${_cratever}
${MODCARGO_VENDOR_DIR}/${_cratename}-${_cratever} ;
.endfor
# post-extract target to provide clean environment for specific crates
Index: textproc/ruby-commonmarker/Makefile
===
RCS file: /cvs/ports/textproc/ruby-commonmarker/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- textproc/ruby-commonmarker/Makefile 1 Sep 2023 19:23:31 - 1.2
+++ textproc/ruby-commonmarker/Makefile 8 Jan 2024 20:43:52 -
@@ -1,14 +1,184 @@
-COMMENT = ruby wrapper for libcmark-gfm
+COMMENT = ruby wrapper for comrak rust crate
-DISTNAME = commonmarker-0.23.10
+DISTNAME = commonmarker-1.0.3
CATEGORIES = textproc
HOMEPAGE = https://github.com/gjtorikian/commonmarker
+ONIG_V = 6.9.9
+DISTFILES.onig =onig-${ONIG_V}.tar.gz
+SITES.onig = https://github.com/kkos/oniguruma/releases/download/v${ONIG_V}/
+
# MIT License
PERMIT_PACKAGE = Yes
-MODULES = lang/ruby
+MODULES = devel/cargo \
+ lang/ruby
+
+WANTLIB += ${MODCARGO_WANTLIB}
+
+BUILD_DEPENDS =devel/ruby-rb_sys,${MODRUBY_FLAVOR}>=0.9 \
+ devel/llvm/16,-main
CONFIGURE_STYLE = ruby gem ext
+
+MODCARGO_CRATE_EXTRACTDIR = ${WRKDIST}
+MODCARGO_VENDOR_DIR = ${WRKDIR}/modcargo-crates
+MODCARGO_BUILD = No
+MODCARGO_INSTALL = No
+
+USE_GMAKE = Yes
+CONFIGURE_ENV =MAKE=gmake
+MAKE_ENV = MAKE=gmake \
+ RUBY=${RUBY} \
+ HOME=${WRKSRC} \
+ LIBCLANG_PATH=${PREFIX}/llvm16/lib
+
+pre-configure:
+ mv ${WRKSRC}/onig-${ONIG_V} \
+ ${MODCARGO_VENDOR_DIR}/onig_sys-69.8.1/oniguruma
+ mkdir ${WRKSRC}/.cargo
+ echo '[source.crates-io]' > ${WRKSRC}/.cargo/config.toml
+ echo 'replace-with = "vendored-sources"' >> ${WRKSRC}/.cargo/config.toml
+ echo '[source.vendored-sources]' >> ${WRKSRC}/.cargo/config.toml
+ echo 'directory = "${MODCARGO_VENDOR_DIR}"' >>
${WRKSRC}/.cargo/config.toml
+
+# run: make modcargo-gen-crates-licenses
+MODCARGO_CRATES += adler 1.0.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org 2024/01/08 13:01:25
Modified files:
devel/cmake: Makefile
devel/cmake/pkg: PLIST
Log message:
fix PLIST (${MODPY_VERSION}.html should be 3.10.html), and avoid readding
it in future with "UPDATE_PLIST_ARGS = -i MODPY_VERSION", spotted by daniel@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: kette...@cvs.openbsd.org2024/01/08 13:00:31 Modified files: sysutils/firmware/apple-boot: Makefile Log message: Bump m1n1 and u-boot versions. ok tobhe@, sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: kette...@cvs.openbsd.org2024/01/08 12:59:12 Modified files: sysutils/u-boot-asahi: Makefile distinfo Removed files: sysutils/u-boot-asahi/patches: patch-arch_arm_dts_t600x-j314-j316_dtsi patch-arch_arm_dts_t600x-j375_dtsi patch-arch_arm_dts_t8103-j293_dts patch-arch_arm_dts_t8103-j313_dts patch-arch_arm_dts_t8112-j413_dts patch-arch_arm_dts_t8112-j493_dts Log message: Update to openbsd-v2024.01. This also brings us newer device trees that are needed for the upcoming KMS driver. ok tobhe@, sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: kette...@cvs.openbsd.org2024/01/08 12:57:24 Modified files: sysutils/m1n1 : Makefile distinfo Log message: Update to m1n1 1.4.11 ok tobhe@, sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/01/08 12:19:54 Modified files: www/yt-dlp : Makefile distinfo www/yt-dlp/pkg : PLIST Log message: Update to yt-dlp-2023.12.30. ok mestre@ (maintainer)
Re: Fix cmake in math/fftw3
On Mon Jan 08, 2024 at 05:53:02PM +0100, Rafael Sadowski wrote:
> Please find a diff to fix the missing FFTW3LibraryDepends.cmake in
> fftw3. This file would normally be generated by cmake, but we are using
> the more feature-complete and stable autotools configure.
>
> https://github.com/FFTW/fftw3/issues/130
>
> While I'm here, I think the cmake files should be moved from -double,
> -float to -common?
>
Forget the previews diff. Here is a proper diff that fix the build with
upcoming krita. More consumer tests needed but I think this is the way
to go.
- Split cmake files in fftw3 and fftw3f depending on the FLAVOR.
- Subst FFTW3LibraryDepends.cmake (missing in the old diff)
- With this approach we could introduce "--enable-long-double" (l) and
"--enable-quad-precision" (q) if we need it. I saw it in krita 5.2:
-- Could NOT find FFTW3l (missing: FFTW3l_DIR)
-- Could NOT find FFTW3q (missing: FFTW3q_DIR)
-- Found FFTW3: /usr/local/include (found version "3.3.10")
In the next step I would test all consumers. Happy to read your input.
Rafael
Index: Makefile
===
RCS file: /cvs/ports/math/fftw3/Makefile,v
diff -u -p -u -p -r1.41 Makefile
--- Makefile27 Sep 2023 09:27:54 - 1.41
+++ Makefile8 Jan 2024 18:26:41 -
@@ -14,6 +14,9 @@ SHARED_LIBS= fftw3 7.1 \
fftw3f_threads 1.2
CATEGORIES=math
+REVISION-main= 0
+REVISION-common= 0
+
HOMEPAGE= https://www.fftw.org/
# GPL
@@ -34,8 +37,11 @@ USE_GMAKE= Yes
CONFIGURE_STYLE=gnu
CONFIGURE_ARGS=--enable-threads
+FFTW3_SUFX=
+
.if ${FLAVOR} == "float"
-CONFIGURE_ARGS+=--enable-float
+FFTW3_SUFX=f
+CONFIGURE_ARGS+= --enable-float
FULLPKGNAME-main= fftw3-float-${V}
.endif
@@ -44,8 +50,17 @@ RUN_DEPENDS-main=${FULLPKGPATH-common}
WANTLIB-main= c m pthread
PKG_ARCH-common= *
+SUBST_VARS += FFTW3_SUFX
+
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/fftw3
${INSTALL_DATA} ${WRKSRC}/doc/fftw3.pdf ${PREFIX}/share/doc/fftw3
+.if ${FLAVOR} == "float"
+ mv ${WRKINST}/${LOCALBASE}/lib/cmake/fftw3/
${PREFIX}/lib/cmake/fftw3${FFTW3_SUFX}
+.endif
+ # https://github.com/FFTW/fftw3/issues/130
+ ${INSTALL_DATA} ${FILESDIR}/FFTW3LibraryDepends.cmake.in \
+ ${PREFIX}/lib/cmake/fftw3${FFTW3_SUFX}/FFTW3LibraryDepends.cmake
+ ${SUBST_CMD}
${PREFIX}/lib/cmake/fftw3${FFTW3_SUFX}/FFTW3LibraryDepends.cmake
.include
Index: files/FFTW3LibraryDepends.cmake.in
===
RCS file: files/FFTW3LibraryDepends.cmake.in
diff -N files/FFTW3LibraryDepends.cmake.in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/FFTW3LibraryDepends.cmake.in 8 Jan 2024 18:26:41 -
@@ -0,0 +1,68 @@
+# Generated by CMake
+
+if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.8)
+ message(FATAL_ERROR "CMake >= 2.8.0 required")
+endif()
+if(CMAKE_VERSION VERSION_LESS "2.8.3")
+ message(FATAL_ERROR "CMake >= 2.8.3 required")
+endif()
+cmake_policy(PUSH)
+cmake_policy(VERSION 2.8.3...3.25)
+#
+# Generated CMake target import file.
+#
+
+# Commands may need to know the format version.
+set(CMAKE_IMPORT_FILE_VERSION 1)
+
+# Protect against multiple inclusion, which would fail when already imported
targets are added once more.
+set(_cmake_targets_defined "")
+set(_cmake_targets_not_defined "")
+set(_cmake_expected_targets "")
+foreach(_cmake_expected_target IN ITEMS FFTW3::fftw3${FFTW3_SUFX})
+ list(APPEND _cmake_expected_targets "${_cmake_expected_target}")
+ if(TARGET "${_cmake_expected_target}")
+list(APPEND _cmake_targets_defined "${_cmake_expected_target}")
+ else()
+list(APPEND _cmake_targets_not_defined "${_cmake_expected_target}")
+ endif()
+endforeach()
+unset(_cmake_expected_target)
+if(_cmake_targets_defined STREQUAL _cmake_expected_targets)
+ unset(_cmake_targets_defined)
+ unset(_cmake_targets_not_defined)
+ unset(_cmake_expected_targets)
+ unset(CMAKE_IMPORT_FILE_VERSION)
+ cmake_policy(POP)
+ return()
+endif()
+if(NOT _cmake_targets_defined STREQUAL "")
+ string(REPLACE ";" ", " _cmake_targets_defined_text
"${_cmake_targets_defined}")
+ string(REPLACE ";" ", " _cmake_targets_not_defined_text
"${_cmake_targets_not_defined}")
+ message(FATAL_ERROR "Some (but not all) targets in this export set were
already defined.\nTargets Defined: ${_cmake_targets_defined_text}\nTargets not
yet defined: ${_cmake_targets_not_defined_text}\n")
+endif()
+unset(_cmake_targets_defined)
+unset(_cmake_targets_not_defined)
+unset(_cmake_expected_targets)
+
+
+# Create imported target FFTW3::fftw3${FFTW3_SUFX}
+add_library(FFTW3::fftw3${FFTW3_SUFX} SHARED IMPORTED)
+
+set_target_properties(FFTW3::fftw3${FFTW3_SUFX} PROPERTIES
+
Fix cmake in math/fftw3
Please find a diff to fix the missing FFTW3LibraryDepends.cmake in
fftw3. This file would normally be generated by cmake, but we are using
the more feature-complete and stable autotools configure.
https://github.com/FFTW/fftw3/issues/130
While I'm here, I think the cmake files should be moved from -double,
-float to -common?
Rafael
Index: Makefile
===
RCS file: /cvs/ports/math/fftw3/Makefile,v
diff -u -p -u -p -r1.41 Makefile
--- Makefile27 Sep 2023 09:27:54 - 1.41
+++ Makefile8 Jan 2024 16:47:57 -
@@ -14,6 +14,9 @@ SHARED_LIBS= fftw3 7.1 \
fftw3f_threads 1.2
CATEGORIES=math
+REVISION-main= 0
+REVISION-common= 0
+
HOMEPAGE= https://www.fftw.org/
# GPL
@@ -47,5 +50,8 @@ PKG_ARCH-common= *
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/fftw3
${INSTALL_DATA} ${WRKSRC}/doc/fftw3.pdf ${PREFIX}/share/doc/fftw3
+ # https://github.com/FFTW/fftw3/issues/130
+ ${INSTALL_DATA} ${FILESDIR}/FFTW3LibraryDepends.cmake.in \
+ ${PREFIX}/lib/cmake/fftw3/FFTW3LibraryDepends.cmake.in
.include
Index: files/FFTW3LibraryDepends.cmake.in
===
RCS file: files/FFTW3LibraryDepends.cmake.in
diff -N files/FFTW3LibraryDepends.cmake.in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/FFTW3LibraryDepends.cmake.in 8 Jan 2024 16:47:57 -
@@ -0,0 +1,68 @@
+# Generated by CMake
+
+if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.8)
+ message(FATAL_ERROR "CMake >= 2.8.0 required")
+endif()
+if(CMAKE_VERSION VERSION_LESS "2.8.3")
+ message(FATAL_ERROR "CMake >= 2.8.3 required")
+endif()
+cmake_policy(PUSH)
+cmake_policy(VERSION 2.8.3...3.25)
+#
+# Generated CMake target import file.
+#
+
+# Commands may need to know the format version.
+set(CMAKE_IMPORT_FILE_VERSION 1)
+
+# Protect against multiple inclusion, which would fail when already imported
targets are added once more.
+set(_cmake_targets_defined "")
+set(_cmake_targets_not_defined "")
+set(_cmake_expected_targets "")
+foreach(_cmake_expected_target IN ITEMS FFTW3::fftw3%%FFTW3_SUFX%%)
+ list(APPEND _cmake_expected_targets "${_cmake_expected_target}")
+ if(TARGET "${_cmake_expected_target}")
+list(APPEND _cmake_targets_defined "${_cmake_expected_target}")
+ else()
+list(APPEND _cmake_targets_not_defined "${_cmake_expected_target}")
+ endif()
+endforeach()
+unset(_cmake_expected_target)
+if(_cmake_targets_defined STREQUAL _cmake_expected_targets)
+ unset(_cmake_targets_defined)
+ unset(_cmake_targets_not_defined)
+ unset(_cmake_expected_targets)
+ unset(CMAKE_IMPORT_FILE_VERSION)
+ cmake_policy(POP)
+ return()
+endif()
+if(NOT _cmake_targets_defined STREQUAL "")
+ string(REPLACE ";" ", " _cmake_targets_defined_text
"${_cmake_targets_defined}")
+ string(REPLACE ";" ", " _cmake_targets_not_defined_text
"${_cmake_targets_not_defined}")
+ message(FATAL_ERROR "Some (but not all) targets in this export set were
already defined.\nTargets Defined: ${_cmake_targets_defined_text}\nTargets not
yet defined: ${_cmake_targets_not_defined_text}\n")
+endif()
+unset(_cmake_targets_defined)
+unset(_cmake_targets_not_defined)
+unset(_cmake_expected_targets)
+
+
+# Create imported target FFTW3::fftw3%%FFTW3_SUFX%%
+add_library(FFTW3::fftw3%%FFTW3_SUFX%% SHARED IMPORTED)
+
+set_target_properties(FFTW3::fftw3%%FFTW3_SUFX%% PROPERTIES
+ INTERFACE_LINK_LIBRARIES "m"
+)
+
+# Import target "FFTW3::fftw3%%FFTW3_SUFX%%" for configuration "Release"
+set_property(TARGET FFTW3::fftw3%%FFTW3_SUFX%% APPEND PROPERTY
IMPORTED_CONFIGURATIONS RELEASE)
+set_target_properties(FFTW3::fftw3%%FFTW3_SUFX%% PROPERTIES
+ IMPORTED_LOCATION_RELEASE
"%%LOCALBASE%%/lib/libfftw3%%FFTW3_SUFX%%.so.%%SHLIB_VER_MAJ%%"
+ IMPORTED_SONAME_RELEASE "libfftw3%%FFTW3_SUFX%%.so.%%SHLIB_VER%%"
+ )
+
+# This file does not depend on other imported targets which have
+# been exported from the same project but in a separate export set.
+
+# Commands beyond this point should not need to know the version.
+set(CMAKE_IMPORT_FILE_VERSION)
+cmake_policy(POP)
Index: pkg/PFRAG.double-main
===
RCS file: /cvs/ports/math/fftw3/pkg/PFRAG.double-main,v
diff -u -p -u -p -r1.7 PFRAG.double-main
--- pkg/PFRAG.double-main 21 Nov 2022 23:01:17 - 1.7
+++ pkg/PFRAG.double-main 8 Jan 2024 16:47:57 -
@@ -1,8 +1,6 @@
@pkgpath math/fftw3
@pkgpath math/fftw3,double
@bin bin/fftw-wisdom
-lib/cmake/fftw3/FFTW3Config.cmake
-lib/cmake/fftw3/FFTW3ConfigVersion.cmake
@static-lib lib/libfftw3.a
lib/libfftw3.la
@lib lib/libfftw3.so.${LIBfftw3_VERSION}
Index: pkg/PFRAG.float-main
===
RCS file:
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/01/08 09:44:42 ports/math/fftw3/files Update of /cvs/ports/math/fftw3/files In directory cvs.openbsd.org:/tmp/cvs-serv37003/files Log Message: Directory /cvs/ports/math/fftw3/files added to the repository
Re: LXQt, kwin, meta-packages and toolkit purity
I just installed current on an older machine and will try to build. My intent is to change the WM in the meta package to kwin for 2 reasons: 1) Upstream is Qt centric and if they don't fork their own Qt Window Manager, they should continue to accomodate kwin. 2) Theme options (kvantum) would be consistent. The older Qt4 based kwin was said to pull in alot of dependencies, the newer Qt5 kwin not so much. If OpenBSD's build of kwin works reasonably well, I will incorporate Landry's guidance into the meta package with kwin, xfwm4 and openbox. We have a snowstorm coming in and I'll be home bound for a day or two. If this goes smoothly, hopefull I can post a patch by midweek. On Mon, 8 Jan 2024, Rafael Sadowski wrote: On Sat Jan 06, 2024 at 11:46:42AM -0800, J. Scott Heppler wrote: Most of the CAD software is Qt Based and I've been running an OpenBSD Dual Boot system with ArchLinux and LXQt. Essentially, I tried to build the lightest, CAD compatible environment possible. With all of Rafael Sadows' work, I suspect updating LXQt should be low hanging fruit. My own build uses kwin instead of openbox and the only issue I had was turning off the animation eye candy without kwindowsystems installed. It was actually a ~/config file that I preserved before deleting kwindowsystem. The older meta-package brought in openbox and gtk dependencies that would be unused code when using kwin. Kwin should also be more wayland friendly going forward. I think it's worth opening a discussion to set the meta-package structure and get developers behind the project. I'm not interested in spending days generating patches only to have them ignored for months and go stale. If it can come together, I'll contribute some of the updates. --- J. Scott Heppler If you want to update and test LXQt 1.4.0 you can find an update diff here: https://github.com/sizeofvoid/wip-ports/commit/79f5e47c05c4a8341e7873dd850e2077ca5e7293 In a Sunday evening mood I update LXQt to 1.4.0 just for fun. It's quite straightforward but I don't plan to continue here unless someone starts taking a look. https://twitter.com/sizeofvoid/status/1744090390892867838/photo/1 -- J. Scott Heppler Penguin Innovations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - NOTICE: This e-mail message and any attachments may contain legally privileged and confidential information intended solely for the use of the intended recipients. If you are not an intended recipient, you are hereby notified that you have received this message in error and any review, dissemination, distribution, copying, or other unauthorized use of this email and any attachment is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the message and any attachments from your system.
Re: Hello new port request
Hello, On 2024/01/08 14:56:37 +0100, Stefan wrote: > Hey there, > > just curious if someone maybe please could port this great tool to openbsd > > https://github.com/HACKERALERT/Picocrypt Gave it a try for fun. It's not straightforward since it's not the 'usual' go port; it cannot be fetched using `go get' as far as i can see. I've ran `go mod vendor' in the src directory, tar'ed up the contents and used that to make the attached port. Somehow it needed some patching to compile. The tool seems to work upon some quick testing, except for the file picker button that crashes the program if pressed. It'll need more investigation. Cheers, Omar Polo picocrypt.tar.gz Description: GNU Zip compressed data
Re: numpy 1.24.1 -> 1.25.2
On Mon, Jan 01 2024, Daniel Dickman wrote: > The next version of matplotlib requires numpy 1.25 or newer. > > The below diff updates numpy to 1.25.2 so matplotlib can be updated. > > Numpy 1.26 switched to a new build system using mesonpy, so someone will > have to port mesonpy before we can get to newer versions. > > I've tested that all reverse dependencies continue to build on amd64 with > numpy 1.25.2 and run numpy regress tests which look like the usual set of > failures as in older versions: > > 34 failed, 35312 passed, 1628 skipped, 1308 deselected, 31 xfailed, 4 > xpassed, 420 warnings in 405.91s (0:06:45) -27 failed, 24661 passed, 899 skipped, 1306 deselected, 33 xfailed, 4 xpassed, 49 warnings in 2839.17s (0:47:19) +77 failed, 33117 passed, 964 skipped, 1308 deselected, 31 xfailed, 4 xpassed, 410 warnings in 3173.28s (0:52:53) on riscv64. It looks worse but all the regressions are in the same file/function: core/tests/test_casting_floatingpoint_errors.py::test_floatingpoint_errors_casting The issue is most likely that floating-point exceptions are not mandated in the RISC-V ISA[0], and have to be implemented by the compiler or in the code directly. [0] https://github.com/riscv-collab/riscv-gnu-toolchain/issues/417 > ok on this update? > > p.s. Testing on !amd64 is always useful as there has been > platform-specific breakage in the past. Bulk tests would also be helpful > given how much of the tree depends on numpy. Regarding the bulk build tests: like Stuart I think you do not need more than testing that consumers are still happy requirements-wise (which I understand you did on amd64). The positive results of the bulk build done by sthen on i386 is quite promising, and so are the additional tests on sparc64 and riscv64. IIUC the only known issue is tb's tests results on arm64. If those are a regression, it would be nice to investigate (can't do that myself), if they're not a regression from what we have in tree, definitely ok jca@ Logs for riscv64: https://wxcvbn.org/~jca/tmp/py3-numpy-1.24.1.log.gz https://wxcvbn.org/~jca/tmp/py3-numpy-1.25.2.log.gz -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Sun Dec 17 14:48:35 UTC 2023 finished at Sat Jan 6 16:09:29 UTC 2024 lasted 21D01h20m done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #22: Sat Dec 16 01:29:36 MST 2023 built packages:8792 Dec 17:1394 Dec 18:642 Dec 19:284 Dec 20:350 Dec 21:1150 Dec 22:963 Dec 23:690 Dec 24:745 Dec 25:226 Dec 30:286 Dec 31:483 Jan 1:269 Jan 2:132 Jan 3:633 Jan 4:525 Jan 6:19 build failures: 60 http://build-failures.rhaalovely.net/mips64/2023-12-17/astro/gnuastro.log http://build-failures.rhaalovely.net/mips64/2023-12-17/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2023-12-17/devel/arm-none-eabi/gcc,aarch64.log http://build-failures.rhaalovely.net/mips64/2023-12-17/devel/clang-tools-extra.log http://build-failures.rhaalovely.net/mips64/2023-12-17/devel/codechecker.log http://build-failures.rhaalovely.net/mips64/2023-12-17/devel/objfw.log http://build-failures.rhaalovely.net/mips64/2023-12-17/devel/py-thrift,python3.log http://build-failures.rhaalovely.net/mips64/2023-12-17/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2023-12-17/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2023-12-17/emulators/desmume.log http://build-failures.rhaalovely.net/mips64/2023-12-17/emulators/libretro-pcsx-rearmed.log http://build-failures.rhaalovely.net/mips64/2023-12-17/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/cataclysm-dda.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/gnukem.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/goldberg_emulator.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/nblood.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/wesnoth.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/widelands.log http://build-failures.rhaalovely.net/mips64/2023-12-17/games/witchblast.log http://build-failures.rhaalovely.net/mips64/2023-12-17/graphics/openvdb.log http://build-failures.rhaalovely.net/mips64/2023-12-17/inputmethods/ibus.log http://build-failures.rhaalovely.net/mips64/2023-12-17/lang/STk.log http://build-failures.rhaalovely.net/mips64/2023-12-17/lang/gambit.log http://build-failures.rhaalovely.net/mips64/2023-12-17/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2023-12-17/lang/go.log http://build-failures.rhaalovely.net/mips64/2023-12-17/lang/librep.log http://build-failures.rhaalovely.net/mips64/2023-12-17/lang/moarvm.log http://build-failures.rhaalovely.net/mips64/2023-12-17/math/flintlib.log http://build-failures.rhaalovely.net/mips64/2023-12-17/math/gbc.log http://build-failures.rhaalovely.net/mips64/2023-12-17/math/lean.log http://build-failures.rhaalovely.net/mips64/2023-12-17/math/lrs.log http://build-failures.rhaalovely.net/mips64/2023-12-17/math/matio.log http://build-failures.rhaalovely.net/mips64/2023-12-17/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2023-12-17/math/ntl.log http://build-failures.rhaalovely.net/mips64/2023-12-17/misc/remind.log http://build-failures.rhaalovely.net/mips64/2023-12-17/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2023-12-17/net/gtk-gnutella.log http://build-failures.rhaalovely.net/mips64/2023-12-17/net/icinga/core2.log http://build-failures.rhaalovely.net/mips64/2023-12-17/net/powerdns_recursor.log http://build-failures.rhaalovely.net/mips64/2023-12-17/net/utox.log http://build-failures.rhaalovely.net/mips64/2023-12-17/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2023-12-17/security/botan2.log http://build-failures.rhaalovely.net/mips64/2023-12-17/security/distorm3.log http://build-failures.rhaalovely.net/mips64/2023-12-17/security/gpgme.log http://build-failures.rhaalovely.net/mips64/2023-12-17/shells/nsh,static.log http://build-failures.rhaalovely.net/mips64/2023-12-17/sysutils/ansible-lint.log http://build-failures.rhaalovely.net/mips64/2023-12-17/sysutils/borgmatic.log http://build-failures.rhaalovely.net/mips64/2023-12-17/sysutils/libvirt.log http://build-failures.rhaalovely.net/mips64/2023-12-17/sysutils/nix.log http://build-failures.rhaalovely.net/mips64/2023-12-17/textproc/aspell/core.log http://build-failures.rhaalovely.net/mips64/2023-12-17/textproc/p5-SWISH-API.log http://build-failures.rhaalovely.net/mips64/2023-12-17/wayland/gtk-layer-shell.log http://build-failures.rhaalovely.net/mips64/2023-12-17/wayland/gtk4-layer-shell.log http://build-failures.rhaalovely.net/mips64/2023-12-17/x11/jgmenu.log http://build-failures.rhaalovely.net/mips64/2023-12-17/x11/qt5/qtbase.log http://build-failures.rhaalovely.net/mips64/2023-12-17/x11/qt6/qtbase.log
Re: UPDATE: sysutils/coreutils 9.3 => 9.4
> Tests pass on amd64 and i386; big endian testing would be appreciated. > > OK? I'm ok with this, but I'm unsure how much testing is required since it is a dep for a sizable number of ports. Tests look good on sparc64: Testsuite summary for GNU coreutils 9.4 # TOTAL: 474 # PASS: 386 # SKIP: 88 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 test.log.xz Description: Binary data
Re: WPA_supplicant no longer working on -current
Thank you for the reply! Do you mind sharing your wpa_supplicant.conf? Best, g On Tue, 26 Dec 2023 at 23:01, Корякин Артём wrote: > > It seems to be working on my machine. I am using LibreSSL wpa_supplicant > flavor on OpenBSD 7.4-current. > > To test if it works I restarted wpa_supplicant with doas rcctl restart > wpa_supplicant command. > > Then, to view log files I executed following command: > tail -n 50 -f /var/log/daemon | grep $(pgrep wpa_supplicant) > > For convenience I pasted results of execution below. > > It is sad to find out, that there is no maintainer for this port, > because I need it to connect to my university network. > > You may try to go back to wpa_supplicant standard LibreSSL flavor and > adjust key_mgmt and eap variables in /etc/wpa_supplicant.conf > > Best regards, Artsiom. > > Before sysupgrade: > Dec 26 14:49:15 Kanamori wpa_supplicant[73283]: iwm0: Associated with > 80:26:89:9b:a2:d1 > Dec 26 14:49:15 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 > Dec 26 14:49:17 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-STARTED EAP authentication started > Dec 26 14:49:17 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-STARTED EAP authentication started > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/CN=*.bsuir.by' > hash=f2d948d19c52934b3e43253b6bbf21effed7367e3066fb2766b5bf6795210274 > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PEER-ALT depth=2 DNS:*.bsuir.by > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PEER-ALT depth=2 DNS:bsuir.by > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: EAP-MSCHAPV2: > Authentication succeeded > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully > Dec 26 14:49:47 Kanamori wpa_supplicant[73283]: iwm0: CTRL-EVENT-CONNECTED > - Connection to 80:26:89:9b:a2:d1 completed [id=0 id_str=] > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-STARTED EAP authentication started > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/CN=*.bsuir.by' > hash=f2d948d19c52934b3e43253b6bbf21effed7367e3066fb2766b5bf6795210274 > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PEER-ALT depth=2 DNS:*.bsuir.by > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-PEER-ALT depth=2 DNS:bsuir.by > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: EAP-MSCHAPV2: > Authentication succeeded > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Dec 26 14:57:57 Kanamori wpa_supplicant[73283]: iwm0: > CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully > > Before sysupgrade, after pkg_add -u -Dsnap: > Dec 26 16:18:57 Kanamori wpa_supplicant[78666]: iwm0: Associated with > 80:26:89:9b:a2:d1 > Dec 26 16:18:57 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 > Dec 26 16:18:59 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-STARTED EAP authentication started > Dec 26 16:18:59 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-STARTED EAP authentication started > Dec 26 16:19:29 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 > Dec 26 16:19:29 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected > Dec 26 16:19:30 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/CN=*.bsuir.by' > hash=f2d948d19c52934b3e43253b6bbf21effed7367e3066fb2766b5bf6795210274 > Dec 26 16:19:30 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-PEER-ALT depth=2 DNS:*.bsuir.by > Dec 26 16:19:30 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-PEER-ALT depth=2 DNS:bsuir.by > Dec 26 16:19:30 Kanamori wpa_supplicant[78666]: EAP-MSCHAPV2: > Authentication succeeded > Dec 26 16:19:30 Kanamori wpa_supplicant[78666]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Dec 26 16:19:31 Kanamori wpa_supplicant[78666]: iwm0: > CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully > Dec 26 16:19:31 Kanamori wpa_supplicant[78666]: iwm0: CTRL-EVENT-CONNECTED > - Connection to 80:26:89:9b:a2:d1 completed [id=0 id_str=] > Dec 26 16:28:10 Kanamori wpa_supplicant[78666]: iwm0: >
UPDATE: sysutils/coreutils 9.3 => 9.4
Hi ports -- Reviving this. Update to the GNU coreutils. Changelog is here: https://git.savannah.gnu.org/cgit/coreutils.git/tree/NEWS Tests pass on amd64 and i386; big endian testing would be appreciated. OK? ~BrianIndex: Makefile === RCS file: /cvs/ports/sysutils/coreutils/Makefile,v retrieving revision 1.28 diff -u -p -r1.28 Makefile --- Makefile27 Sep 2023 17:16:24 - 1.28 +++ Makefile8 Jan 2024 00:32:08 - @@ -1,6 +1,6 @@ COMMENT = file, shell and text manipulation utilities -DISTNAME = coreutils-9.3 +DISTNAME = coreutils-9.4 CATEGORIES = sysutils MAINTAINER = Brian Callahan Index: distinfo === RCS file: /cvs/ports/sysutils/coreutils/distinfo,v retrieving revision 1.14 diff -u -p -r1.14 distinfo --- distinfo4 Jun 2023 17:26:47 - 1.14 +++ distinfo8 Jan 2024 00:32:08 - @@ -1,2 +1,2 @@ -SHA256 (coreutils-9.3.tar.xz) = rbz8/omSNbceh2jc8HzVMlILf1T5qAZIQ/jRmakEu6o= -SIZE (coreutils-9.3.tar.xz) = 5808696 +SHA256 (coreutils-9.4.tar.xz) = 6mE6TPRGEjJukXIBu7zfvTAd4h/8O1m25cB+BAsnXlI= +SIZE (coreutils-9.4.tar.xz) = 5979200 Index: patches/patch-Makefile_in === RCS file: /cvs/ports/sysutils/coreutils/patches/patch-Makefile_in,v retrieving revision 1.14 diff -u -p -r1.14 patch-Makefile_in --- patches/patch-Makefile_in 4 Jun 2023 17:26:47 - 1.14 +++ patches/patch-Makefile_in 8 Jan 2024 00:32:08 - @@ -3,7 +3,7 @@ XXX: Avoid rebuilding coreutils.info; ou Index: Makefile.in --- Makefile.in.orig +++ Makefile.in -@@ -21087,6 +21087,7 @@ doc/$(am__dirstamp): +@@ -22186,6 +22186,7 @@ doc/$(am__dirstamp): @: > doc/$(am__dirstamp) $(srcdir)/doc/coreutils.info: doc/coreutils.texi $(srcdir)/doc/version.texi $(doc_coreutils_TEXINFOS) Index: pkg/PLIST === RCS file: /cvs/ports/sysutils/coreutils/pkg/PLIST,v retrieving revision 1.12 diff -u -p -r1.12 PLIST --- pkg/PLIST 4 Jun 2023 17:26:47 - 1.12 +++ pkg/PLIST 8 Jan 2024 00:32:08 - @@ -291,8 +291,6 @@ share/locale/it/LC_TIME/coreutils.mo share/locale/ja/LC_MESSAGES/coreutils.mo share/locale/ja/LC_TIME/ share/locale/ja/LC_TIME/coreutils.mo -share/locale/ka/ -share/locale/ka/LC_MESSAGES/ share/locale/ka/LC_MESSAGES/coreutils.mo share/locale/ka/LC_TIME/ share/locale/ka/LC_TIME/coreutils.mo @@ -352,6 +350,11 @@ share/locale/sr/LC_TIME/coreutils.mo share/locale/sv/LC_MESSAGES/coreutils.mo share/locale/sv/LC_TIME/ share/locale/sv/LC_TIME/coreutils.mo +share/locale/ta/ +share/locale/ta/LC_MESSAGES/ +share/locale/ta/LC_MESSAGES/coreutils.mo +share/locale/ta/LC_TIME/ +share/locale/ta/LC_TIME/coreutils.mo share/locale/tr/LC_MESSAGES/coreutils.mo share/locale/tr/LC_TIME/ share/locale/tr/LC_TIME/coreutils.mo
Hello new port request
Hey there, just curious if someone maybe please could port this great tool to openbsd https://github.com/HACKERALERT/Picocrypt Kind regards
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2024/01/08 06:11:40 Modified files: meta/gnome : Makefile Log message: Bump GNOME to version 45.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2024/01/08 06:11:25 Modified files: x11/gnome/shell: Makefile distinfo Log message: Update to gnome-shell-45.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2024/01/08 06:02:09 Modified files: x11/gnome/mutter: Makefile distinfo Removed files: x11/gnome/mutter/patches: patch-src_backends_meta-fd-source_c Log message: Update to mutter-45.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2024/01/08 05:55:57 Modified files: x11/gnome/gjs : Makefile distinfo Log message: Update to gjs-1.78.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2024/01/08 05:54:52 Modified files: sysutils/govmomi: Makefile distinfo Log message: Update to govc-0.34.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2024/01/08 05:53:10 Modified files: devel/mm-common: Makefile distinfo Log message: Update to mm-common-1.0.6.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: e...@cvs.openbsd.org2024/01/08 03:33:09 Modified files: shells/zsh : Makefile Added files: shells/zsh/patches: patch-Completion_Unix_Type__diff_options Log message: shells/zsh: Fix diff(1) completions for OpenBSD. https://sourceforge.net/p/zsh/code/ci/996b51515600859ce7f952f22c6262ecd24578e1/ OK sthen@, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/08 03:15:19 Modified files: net/bitcoin: Makefile Log message: bitcoin: fix hidden dep on libnatpmp ok rsadowski (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2024/01/08 02:57:56 Modified files: net/synapse: Makefile net/synapse/pkg: README Log message: fix synapse README, drop --generate-keys which is now done implicitly OK from renaud (MAINTAINER)
Re: [fix] net/synapse update README
On 1/8/24 10:46, Stefan Hagen wrote:
Hi,
while setting up a synapse instance, I saw that the command below
doesn't work anymore. You can either supply --generate-config OR
--generate-keys, but not both.
When doing a --generate-config, the keys are generated as well,
so this switch can simply be left out.
Maintainer on CC.
OK?
OK for me
Best regards,
Stefan
Index: net/synapse/Makefile
===
RCS file: /cvs/ports/net/synapse/Makefile,v
diff -u -p -u -p -r1.69 Makefile
--- net/synapse/Makefile1 Jan 2024 14:14:49 - 1.69
+++ net/synapse/Makefile8 Jan 2024 09:40:19 -
@@ -7,6 +7,8 @@ GH_PROJECT =synapse
GH_TAGNAME = v${MODPY_EGG_VERSION}
CATEGORIES = net
+REVISION = 0
+
HOMEPAGE =https://matrix.org/
MAINTAINER = Renaud Allard
Index: net/synapse/pkg/README
===
RCS file: /cvs/ports/net/synapse/pkg/README,v
diff -u -p -u -p -r1.4 README
--- net/synapse/pkg/README 21 Nov 2022 14:03:29 - 1.4
+++ net/synapse/pkg/README 8 Jan 2024 09:40:19 -
@@ -9,7 +9,7 @@ As root (or _synapse), go into ${LOCALST
doas -u _synapse ${MODPY_BIN} -m synapse.app.homeserver \
-c ${LOCALSTATEDIR}/synapse/homeserver.yaml --generate-config \
--server-name matrix.example.com --report-stats=no \
- --generate-keys --keys-directory ${LOCALSTATEDIR}/synapse
+ --keys-directory ${LOCALSTATEDIR}/synapse
Register a user
===
smime.p7s
Description: S/MIME Cryptographic Signature
[fix] net/synapse update README
Hi,
while setting up a synapse instance, I saw that the command below
doesn't work anymore. You can either supply --generate-config OR
--generate-keys, but not both.
When doing a --generate-config, the keys are generated as well,
so this switch can simply be left out.
Maintainer on CC.
OK?
Best regards,
Stefan
Index: net/synapse/Makefile
===
RCS file: /cvs/ports/net/synapse/Makefile,v
diff -u -p -u -p -r1.69 Makefile
--- net/synapse/Makefile1 Jan 2024 14:14:49 - 1.69
+++ net/synapse/Makefile8 Jan 2024 09:40:19 -
@@ -7,6 +7,8 @@ GH_PROJECT =synapse
GH_TAGNAME = v${MODPY_EGG_VERSION}
CATEGORIES = net
+REVISION = 0
+
HOMEPAGE = https://matrix.org/
MAINTAINER = Renaud Allard
Index: net/synapse/pkg/README
===
RCS file: /cvs/ports/net/synapse/pkg/README,v
diff -u -p -u -p -r1.4 README
--- net/synapse/pkg/README 21 Nov 2022 14:03:29 - 1.4
+++ net/synapse/pkg/README 8 Jan 2024 09:40:19 -
@@ -9,7 +9,7 @@ As root (or _synapse), go into ${LOCALST
doas -u _synapse ${MODPY_BIN} -m synapse.app.homeserver \
-c ${LOCALSTATEDIR}/synapse/homeserver.yaml --generate-config \
--server-name matrix.example.com --report-stats=no \
- --generate-keys --keys-directory ${LOCALSTATEDIR}/synapse
+ --keys-directory ${LOCALSTATEDIR}/synapse
Register a user
===
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/01/08 02:36:03 Modified files: geo/kgeotag: Makefile distinfo geo/kgeotag/pkg: PLIST Log message: Update kgeotag to 1.5.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2024/01/08 02:02:23 Modified files: x11/kde-applications/kio-gdrive: Makefile x11/kde-applications/kio-gdrive/pkg: PLIST Log message: link kio-gdrive and regen PLIST OK kn@
Re: LXQt, kwin, meta-packages and toolkit purity
On Sat Jan 06, 2024 at 11:46:42AM -0800, J. Scott Heppler wrote: > > Most of the CAD software is Qt Based and I've been running an OpenBSD Dual > Boot system with ArchLinux and LXQt. Essentially, I tried to build the > lightest, CAD compatible environment possible. With all of Rafael Sadows' > work, I suspect updating LXQt should be low hanging fruit. > > My own build uses kwin instead of openbox and the only issue I had was > turning off the animation eye candy without kwindowsystems installed. It > was actually a ~/config file that I preserved before deleting kwindowsystem. > > The older meta-package brought in openbox and gtk dependencies that would be > unused code when using kwin. Kwin should also be more wayland friendly > going forward. > > I think it's worth opening a discussion to set the meta-package structure > and get developers behind the project. I'm not interested in spending days > generating patches only to have them ignored for months and go stale. > > If it can come together, I'll contribute some of the updates. > --- > > J. Scott Heppler > If you want to update and test LXQt 1.4.0 you can find an update diff here: https://github.com/sizeofvoid/wip-ports/commit/79f5e47c05c4a8341e7873dd850e2077ca5e7293 In a Sunday evening mood I update LXQt to 1.4.0 just for fun. It's quite straightforward but I don't plan to continue here unless someone starts taking a look. https://twitter.com/sizeofvoid/status/1744090390892867838/photo/1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2024/01/08 01:46:17 Modified files: geo/mapproxy : Makefile distinfo Log message: geo/mapproxy: update to 2.0.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2024/01/08 01:16:49 Modified files: www/varnish: Makefile distinfo www/varnish/pkg: PLIST Log message: Update for Varnish to 7.4.2 OK rsadowski@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2024/01/08 01:14:12 Modified files: emulators/nono : Makefile distinfo Log message: Update for Nono to 0.6.4 OK op@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/08 01:03:04 Modified files: security/xmlsec: Makefile distinfo security/xmlsec/patches: patch-tests_testrun_sh security/xmlsec/pkg: PLIST-docs Removed files: security/xmlsec/patches: patch-apps_crypto_c patch-apps_xmlsec_c patch-include_xmlsec_xmlsec_h patch-src_errors_helpers_h patch-src_mscrypto_certkeys_c patch-src_mscrypto_signatures_c Log message: update to xmlsec-1.3.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/08 01:03:01 Modified files: net/librenms : Makefile distinfo net/librenms/patches: patch-misc_config_definitions_json net/librenms/pkg: PLIST Log message: update to librenms-24.1.0
