[devel/openmpi]: documenting I/O issue in readme
Hello!
I've been having some issues with OpenMPI io capabilities for a while.
It seems that the default io component used (ompio) is still not working
with
OpenBSD (but it is not segfaulting anymore).
This can be resolved by changing to romio321 component as was
discussed here:
https://www.mail-archive.com/misc@openbsd.org/msg177085.html
Tested this with:
kern.version=OpenBSD 7.0-current (GENERIC.MP) #288
/usr/src/sys/arch/amd64/compile/GENERIC.MP
Do you think it would be useful to add a note in the openmpi README
(devel/openmpi/pkg/README) with the following changes (or with some
other more explicit / better comments of yours) + adding one C example?
Thanks!
Diff below:
--- README.origThu Jan 27 07:37:22 2022
+++ READMEThu Jan 27 07:37:34 2022
@@ -29,6 +29,9 @@
PMIX_MCA_gds=hash
This is the one gds (general data service) that works on OpenBSD.
+ OMPI_MCA_io=romio321
+ This is the only IO component that seems to work on OpenBSD
+
**Example code taken from:
https://hpcc.usc.edu/support/documentation/examples-of-mpi-programs/
@@ -57,4 +60,48 @@
MPI_Finalize();
return 0;
+}
+
+
+** Example code taken from OpenBSD ML:
+ """ OpenMPI 4.0.5 segfault with mpi_file_open() """
+/*
+ * MPI test: creating a file
+ *
+ * Compile with:
+ * $ mpicc -o mpitest mpitest.c
+ *
+ * Run with:
+ * $ mpiexec --mca io romio321 ./mpitest
+ */
+
+#include
+#include
+#include
+
+int main(int argc, char *argv[])
+{
+MPI_File fh;
+int rank, sze;
+
+MPI_Init(NULL,NULL);
+MPI_Comm_rank(MPI_COMM_WORLD, &rank);
+MPI_Comm_size(MPI_COMM_WORLD, &sze);
+
+printf("This is process %d / %d\n", rank+1, sze);
+
+if(MPI_File_open(MPI_COMM_WORLD, "test.txt",
+ MPI_MODE_CREATE|MPI_MODE_WRONLY,
+ MPI_INFO_NULL, &fh))
+{
+printf("From process %d: Unable to create file"
+ "\"test.txt\" ...\n", rank);
+fflush(stdout);
+}
+else
+{
+MPI_File_close(&fh);
+}
+MPI_Finalize();
+return 0;
}
[Update]devel/p5-Moose: Update to 2.2201
Hi, ports@: Here is a patch for devel/p5-Moose: i) Update to 2.2201 ii) Update DEPENDS It build well and pass all tests on OpenBSD-current amd64 system. Many ports(80+) depend on it, I tested about 20 of it, did not meet any problem. Cheers ! wenIndex: Makefile === RCS file: /cvs/ports/devel/p5-Moose/Makefile,v retrieving revision 1.31 diff -u -p -r1.31 Makefile --- Makefile24 May 2021 00:00:05 - 1.31 +++ Makefile27 Jan 2022 02:46:21 - @@ -3,7 +3,7 @@ COMMENT = postmodern object system for Perl 5 MODULES = cpan -DISTNAME = Moose-2.2015 +DISTNAME = Moose-2.2201 CATEGORIES = devel # Perl @@ -32,7 +32,6 @@ RUN_DEPENDS = devel/p5-Class-Load>=0.09 devel/p5-Package-Stash-XS>=0.24 \ devel/p5-Params-Util>=1.0 \ devel/p5-Sub-Exporter>=0.980 \ - devel/p5-Sub-Name>=0.20 \ devel/p5-Try-Tiny>=0.17 # Moose recommends Index: distinfo === RCS file: /cvs/ports/devel/p5-Moose/distinfo,v retrieving revision 1.15 diff -u -p -r1.15 distinfo --- distinfo24 May 2021 00:00:05 - 1.15 +++ distinfo27 Jan 2022 02:46:21 - @@ -1,2 +1,2 @@ -SHA256 (Moose-2.2015.tar.gz) = pnnTnT4sB1qI/n3gNJI+ftfKykZdoYgzfrEEOvBQ9RU= -SIZE (Moose-2.2015.tar.gz) = 899314 +SHA256 (Moose-2.2201.tar.gz) = zV/5tHUfc+y2h0updhND01c31N31/2sZwA0Br1/8PrI= +SIZE (Moose-2.2201.tar.gz) = 902701
[Update]textproc/p5-PPI: Update to 1.271
Hi, ports@: Here is a simple patch for textproc/p5-PPI to update to 1.271. It build well and pass all tests on OpenBSD-current amd64 system. There are 7 ports depend on it. All build well and pass all tests on OpenBSD-current amd64 system. Cheers ! wenIndex: Makefile === RCS file: /cvs/ports/textproc/p5-PPI/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- Makefile3 Jul 2020 21:45:48 - 1.19 +++ Makefile27 Jan 2022 02:02:52 - @@ -4,9 +4,8 @@ COMMENT=parse, analyze and manipulate MODULES= cpan PKG_ARCH= * -DISTNAME= PPI-1.270 +DISTNAME= PPI-1.271 CATEGORIES=textproc -REVISION= 0 # perl PERMIT_PACKAGE=Yes Index: distinfo === RCS file: /cvs/ports/textproc/p5-PPI/distinfo,v retrieving revision 1.10 diff -u -p -r1.10 distinfo --- distinfo26 Jul 2019 14:45:23 - 1.10 +++ distinfo27 Jan 2022 02:02:52 - @@ -1,2 +1,2 @@ -SHA256 (PPI-1.270.tar.gz) = YippjHgbuF0r33u/4ED+cNM7eXdMmuAfziN13HP69Fc= -SIZE (PPI-1.270.tar.gz) = 251100 +SHA256 (PPI-1.271.tar.gz) = klYgkOSaXt8GreTvKXnx9tnlHcVmiRYsKKR8CkYyVt0= +SIZE (PPI-1.271.tar.gz) = 241810
[Update]textproc/p5-PPIx-QuoteLike:Update to 0.019
Hi, ports@: Here is a simple patch for textproc/p5-PPIx-QuoteLike to update to 0.019. It build well and pass all tests on OpenBSD-current amd64 system. Only one port depends on it : devel/p5-Perl-Critic. It build well and pass all tests on OpenBSD-current amd64 system too.Index: Makefile === RCS file: /cvs/ports/textproc/p5-PPIx-QuoteLike/Makefile,v retrieving revision 1.7 diff -u -p -r1.7 Makefile --- Makefile29 Oct 2021 05:23:07 - 1.7 +++ Makefile27 Jan 2022 01:54:49 - @@ -2,7 +2,7 @@ COMMENT = parse Perl string literals and string-literal-like things -DISTNAME = PPIx-QuoteLike-0.018 +DISTNAME = PPIx-QuoteLike-0.019 CATEGORIES = textproc Index: distinfo === RCS file: /cvs/ports/textproc/p5-PPIx-QuoteLike/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo29 Oct 2021 05:23:07 - 1.5 +++ distinfo27 Jan 2022 01:54:49 - @@ -1,2 +1,2 @@ -SHA256 (PPIx-QuoteLike-0.018.tar.gz) = 5qxSPet2xwuZlLJPRAHivB7KMcbujcMUPNj+f45PL/8= -SIZE (PPIx-QuoteLike-0.018.tar.gz) = 72180 +SHA256 (PPIx-QuoteLike-0.019.tar.gz) = sHF/9hKNkwZlqCHJumi8bSMn1qNZcLI8ypQYCnXxDGQ= +SIZE (PPIx-QuoteLike-0.019.tar.gz) = 73446
[Update] textproc/p5-PPIx-Regexp: Update to 0.082
Hi, ports@: Here is a simple patch for textproc/p5-PPIx-Regexp to Update to 0.082. It build well and pass all tests on OpenBSD-current amd64 system. Only one port depends on it : devel/p5-Perl-Critic. It build well and pass all tests on OpenBSD-current amd64 system too. Cheers ! wenIndex: Makefile === RCS file: /cvs/ports/textproc/p5-PPIx-Regexp/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- Makefile7 Feb 2021 14:31:36 - 1.19 +++ Makefile27 Jan 2022 01:40:33 - @@ -4,7 +4,7 @@ COMMENT=parse regular expressions MODULES= cpan PKG_ARCH= * -DISTNAME = PPIx-Regexp-0.078 +DISTNAME = PPIx-Regexp-0.082 CATEGORIES=textproc # perl Index: distinfo === RCS file: /cvs/ports/textproc/p5-PPIx-Regexp/distinfo,v retrieving revision 1.12 diff -u -p -r1.12 distinfo --- distinfo7 Feb 2021 14:31:36 - 1.12 +++ distinfo27 Jan 2022 01:40:33 - @@ -1,2 +1,2 @@ -SHA256 (PPIx-Regexp-0.078.tar.gz) = s4jzriIPVEJ9kYdIVLaYAAKss2bO+YQ4NCgiUEd0tEA= -SIZE (PPIx-Regexp-0.078.tar.gz) = 237189 +SHA256 (PPIx-Regexp-0.082.tar.gz) = X7GQf3RWvQHYLVfe7wyrTGa2t/tTD64MD002C/Gx3U8= +SIZE (PPIx-Regexp-0.082.tar.gz) = 240877
Re: [misc] flashrom fails w/ LIBUSB_ERROR_TIMEOUT
On 2022/01/26 20:19, rgc wrote:
> On Tue, Jan 25, 2022 at 09:49:05PM +0900, rgc wrote:
> > misc@
> >
> > got a CH341A SPI programmer.
> > works on Linux.
> > anybody got it to work with 70-current? or previous?
> >
> >
> > caveat from /usr/local/share/doc/pkg-readmes/flashrom:
> > -
> > flashrom also supports some external programming devices via USB; in
> > those cases it can be run from a normal boot.
> >
> > so flashrom should just work (tm) right!?
>
> i just found the time to try flashrom in single user mode ("boot -s") and
> i get the same error ... still timeout.
Single user mode for flashrom is to provide raw system access for direct
programming of the motherboard that you are running on, it won't help
USB.
> > glitch# flashrom -p ch341a_spi -r top.rom
> > flashrom v1.2 on OpenBSD 7.0 (amd64)
> > flashrom is free software, get the source code at https://flashrom.org
> >
> > Using clock_gettime for delay loops (clk_id: 3, resolution: 1ns).
> > Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on ch341a_spi.
> > Reading flash... ch341a_spi_spi_send_command: failed to submit OUT
> > transfer: LIBUSB_ERROR_TIMEOUT
> > ch341a_spi_spi_send_command: Failed to write 4265 bytes
> > Read operation failed!
> > FAILED.
Looking at the ch341a_spi code in flashrom, it looks like it uses bulk
async transfers; these are known *not* to work on OpenBSD with libusb.
(In general USB support, especially to programs running in userland, is
not brilliant on OpenBSD; you're probably better off with a little Linux
box for those.)
Re: [maintainer update] net/py-nbxmpp 2.0.4
On Wed, Jan 26, 2022 at 05:04:29PM +0100, Paco Esteban wrote:
> Hi ports@,
> This is an update for net/py-nbxmpp which is needed for an upcoming
> update for net/gajim.
> Changelog says:
> * Ignore messages with incorrect id
> * AdHoc: Make parsing AdHoc commands more compliant
> Port update is pretty simple.
> Ok to commit ?
ok kmos
--Kurt
>
> diff --git net/py-nbxmpp/Makefile net/py-nbxmpp/Makefile
> index 25e7f140946..c24a88e802f 100644
> --- net/py-nbxmpp/Makefile
> +++ net/py-nbxmpp/Makefile
> @@ -2,11 +2,10 @@
>
> COMMENT =Python XMPP and Jabber implementation
>
> -MODPY_EGG_VERSION = 2.0.2
> +MODPY_EGG_VERSION = 2.0.4
> DISTNAME = nbxmpp-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME}
> CATEGORIES = net devel
> -REVISION = 0
>
> HOMEPAGE = https://python-nbxmpp.gajim.org/
>
> diff --git net/py-nbxmpp/distinfo net/py-nbxmpp/distinfo
> index f629920419a..ad79fc3902c 100644
> --- net/py-nbxmpp/distinfo
> +++ net/py-nbxmpp/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (nbxmpp-2.0.2.tar.gz) = o4Y2cauImS0+pdR1slyI/+GKoQMMnOmA4QFEcNR2ApE=
> -SIZE (nbxmpp-2.0.2.tar.gz) = 138519
> +SHA256 (nbxmpp-2.0.4.tar.gz) = LMlngI/nPQGt7lnAhNF79fHSfjPpjtTyRnoefGOEV+g=
> +SIZE (nbxmpp-2.0.4.tar.gz) = 142604
>
> --
> Paco Esteban.
> 0x5818130B8A6DBC03
>
[maintaner update] net/gajim 1.3.3
Hi ports@,
This is an update of net/gajim to its latest version 1.3.3
We go from 1.3.1 to 1.3.3.
The changelog mentions this changes:
* Profile: Add NOTE entry
* Accounts: Add account switch description
* Port AdHocCommand window to new Assistant
* Update API JID for search.jabber.network integration
* Build with Python 3.9
* Provider list: Remove blabber.im
* MessageInput: Remove custom placeholder
* MessageInput: Add focus borders
Bug fixes
* #10638 Depend on nbxmpp>=2.0.4 (CVE-2021-41055)
* #10560 HTTPUpload: Raise FileError if path is not accessible
* #10558 Fix spell checking
* #10551 Check for gstreamer GTK plugin for AV support
* #10545 Jingle: Fix UnboundLocalError for transports variable
* #10540 Windows: Add GSSAPI dependency
* #10539 Stop gdbus.exe when running uninstaller
* #10478 Fix test_gui_interface testsuite
* #10477 Migration routine for portable installer
* #10441 Reload CSS after switching dark/light theme
* #10150 Dead key improvements
* Fix starting History Manager in standalone mode
* #10010 Only convert domain name to ASCII
* #10342 UnicodeDecodeError related to avatars
* #10428 Roster: Handle missing avatar_sha
On the port itself, nothing special. Upstream had to correct the
tarball again as it did not include the plugin updater and the unpacked
folder was wrong.
Works fine for me on amd64.
Ok to commit ?
diff --git net/gajim/Makefile net/gajim/Makefile
index e683f289011..e18a6d25d9d 100644
--- net/gajim/Makefile
+++ net/gajim/Makefile
@@ -1,19 +1,18 @@
# $OpenBSD: Makefile,v 1.96 2021/11/02 00:01:39 sthen Exp $
COMMENT= jabber client written in pygtk
-MODPY_EGG_VERSION= 1.3.1
+MODPY_EGG_VERSION= 1.3.3
DISTNAME= gajim-${MODPY_EGG_VERSION}
CATEGORIES=net x11
-REVISION= 1
HOMEPAGE= https://www.gajim.org
MAINTAINER=Paco Esteban
MASTER_SITES= ${HOMEPAGE}/downloads/1.3/
-# upstream did not include the plugin installer on 1.3.1
-# and fixed it on 1.3.1-2
-# https://dev.gajim.org/gajim/gajim/-/issues/10467
+# upstream did not include the plugin installer on 1.3.3 again
+# and fixed it on 1.3.3-2
+# https://dev.gajim.org/gajim/gajim/-/issues/10719
DISTFILES= gajim-${MODPY_EGG_VERSION}-2${EXTRACT_SUFX}
# GPLv3 only
@@ -30,7 +29,7 @@ RUN_DEPENDS= audio/gsound \
devel/libsoup \
graphics/py-Pillow${MODPY_FLAVOR} \
graphics/py-cairo${MODPY_FLAVOR} \
- net/py-nbxmpp${MODPY_FLAVOR}>=2.0.1 \
+ net/py-nbxmpp${MODPY_FLAVOR}>=2.0.4 \
security/py-cryptodome${MODPY_FLAVOR} \
security/py-gnupg${MODPY_FLAVOR} \
security/py-keyring${MODPY_FLAVOR} \
diff --git net/gajim/distinfo net/gajim/distinfo
index bcb0d23be90..1b2cf925c66 100644
--- net/gajim/distinfo
+++ net/gajim/distinfo
@@ -1,2 +1,2 @@
-SHA256 (gajim-1.3.1-2.tar.gz) = nmvP74AQTE7UVO2fghexgmNGHGZqgo1T43NvkyOh9yY=
-SIZE (gajim-1.3.1-2.tar.gz) = 9538193
+SHA256 (gajim-1.3.3-2.tar.gz) = UUHqHCf00sGTbeE23Ckoml6/QeVn3agyHinZZRhxcgM=
+SIZE (gajim-1.3.3-2.tar.gz) = 9578053
--
Paco Esteban.
0x5818130B8A6DBC03
[maintainer update] Python 3.10.0 -> 3.10.2
https://docs.python.org/3.10/whatsnew/changelog.html#python-3-10-2-final
Numerous bugfixes, none of them labelled as security fixes though.
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/lang/python/3.10/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile23 Jan 2022 21:32:07 - 1.4
+++ Makefile26 Jan 2022 16:23:52 -
@@ -5,13 +5,10 @@
# requirement of the PSF license, if it constitutes a change to
# Python itself.
-FULL_VERSION = 3.10.0
+FULL_VERSION = 3.10.2
SHARED_LIBS = python3.10 0.0
VERSION_SPEC = >=3.10,<3.11
#PSUBDIR = python/3.10.0
-
-REVISION-main =1
-
CONFIGURE_ARGS += --with-ensurepip=no
CONFIGURE_ARGS += --enable-loadable-sqlite-extensions
Index: distinfo
===
RCS file: /cvs/ports/lang/python/3.10/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo1 Nov 2021 14:16:09 - 1.1.1.1
+++ distinfo26 Jan 2022 16:23:52 -
@@ -1,2 +1,2 @@
-SHA256 (Python-3.10.0.tgz) = xODLrVfJBpDLgT+0Zj72cLTQ9YfYFx4sQr1MkkW9J1g=
-SIZE (Python-3.10.0.tgz) = 25007016
+SHA256 (Python-3.10.2.tgz) = PA7eiTARMZ+bCla0SVOj1Sx6v5ZXwj+0vJztk7hunJc=
+SIZE (Python-3.10.2.tgz) = 25067363
Index: patches/patch-Makefile_pre_in
===
RCS file: /cvs/ports/lang/python/3.10/patches/patch-Makefile_pre_in,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-Makefile_pre_in
--- patches/patch-Makefile_pre_in 1 Nov 2021 14:16:09 - 1.1.1.1
+++ patches/patch-Makefile_pre_in 26 Jan 2022 16:23:52 -
@@ -13,8 +13,8 @@ Index: Makefile.pre.in
+PY_LDFLAGS= $(LDFLAGS)
PY_LDFLAGS_NODIST=$(CONFIGURE_LDFLAGS_NODIST) $(LDFLAGS_NODIST)
NO_AS_NEEDED= @NO_AS_NEEDED@
- SGI_ABI= @SGI_ABI@
-@@ -671,7 +671,7 @@ gdbhooks: $(BUILDPYTHON)-gdb.py
+ CCSHARED= @CCSHARED@
+@@ -670,7 +670,7 @@ gdbhooks: $(BUILDPYTHON)-gdb.py
SRC_GDB_HOOKS=$(srcdir)/Tools/gdb/libpython.py
$(BUILDPYTHON)-gdb.py: $(SRC_GDB_HOOKS)
Index: patches/patch-Modules__hashopenssl_c
===
RCS file: /cvs/ports/lang/python/3.10/patches/patch-Modules__hashopenssl_c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-Modules__hashopenssl_c
--- patches/patch-Modules__hashopenssl_c1 Nov 2021 14:16:09 -
1.1.1.1
+++ patches/patch-Modules__hashopenssl_c26 Jan 2022 16:23:52 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-Modules__hashopenssl_c,v
Index: Modules/_hashopenssl.c
--- Modules/_hashopenssl.c.orig
+++ Modules/_hashopenssl.c
-@@ -40,11 +40,6 @@
+@@ -45,11 +45,6 @@
#define MUNCH_SIZE INT_MAX
@@ -12,6 +12,6 @@ Index: Modules/_hashopenssl.c
-#define PY_OPENSSL_HAS_SHAKE 1
-#define PY_OPENSSL_HAS_BLAKE2 1
-
- static PyModuleDef _hashlibmodule;
-
- typedef struct {
+ #if OPENSSL_VERSION_NUMBER >= 0x3000L
+ #define PY_EVP_MD EVP_MD
+ #define PY_EVP_MD_fetch(algorithm, properties) EVP_MD_fetch(NULL, algorithm,
properties)
Index: patches/patch-configure_ac
===
RCS file: /cvs/ports/lang/python/3.10/patches/patch-configure_ac,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-configure_ac
--- patches/patch-configure_ac 1 Nov 2021 14:16:09 - 1.1.1.1
+++ patches/patch-configure_ac 26 Jan 2022 16:23:52 -
@@ -16,27 +16,15 @@ Index: configure.ac
# The later defininition of _XOPEN_SOURCE disables certain features
# on Linux, so we need _GNU_SOURCE to re-enable them (makedev, tm_zone).
-@@ -717,7 +717,7 @@ then
- fi
-
-
--MULTIARCH=$($CC --print-multiarch 2>/dev/null)
-+MULTIARCH=$(false)
- AC_SUBST(MULTIARCH)
-
- AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])
-@@ -733,8 +733,8 @@ cat >> conftest.c
[maintainer update] net/py-nbxmpp 2.0.4
Hi ports@,
This is an update for net/py-nbxmpp which is needed for an upcoming
update for net/gajim.
Changelog says:
* Ignore messages with incorrect id
* AdHoc: Make parsing AdHoc commands more compliant
Port update is pretty simple.
Ok to commit ?
diff --git net/py-nbxmpp/Makefile net/py-nbxmpp/Makefile
index 25e7f140946..c24a88e802f 100644
--- net/py-nbxmpp/Makefile
+++ net/py-nbxmpp/Makefile
@@ -2,11 +2,10 @@
COMMENT = Python XMPP and Jabber implementation
-MODPY_EGG_VERSION =2.0.2
+MODPY_EGG_VERSION =2.0.4
DISTNAME = nbxmpp-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
CATEGORIES = net devel
-REVISION = 0
HOMEPAGE = https://python-nbxmpp.gajim.org/
diff --git net/py-nbxmpp/distinfo net/py-nbxmpp/distinfo
index f629920419a..ad79fc3902c 100644
--- net/py-nbxmpp/distinfo
+++ net/py-nbxmpp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (nbxmpp-2.0.2.tar.gz) = o4Y2cauImS0+pdR1slyI/+GKoQMMnOmA4QFEcNR2ApE=
-SIZE (nbxmpp-2.0.2.tar.gz) = 138519
+SHA256 (nbxmpp-2.0.4.tar.gz) = LMlngI/nPQGt7lnAhNF79fHSfjPpjtTyRnoefGOEV+g=
+SIZE (nbxmpp-2.0.4.tar.gz) = 142604
--
Paco Esteban.
0x5818130B8A6DBC03
Re: Remove sysutils/py-filelock?
On Wed, 26 Jan 2022, Kurt Mosiejczuk wrote: > Nothing uses py-filelock. Remove it? Sure. ok paco -- Paco Esteban. 0x5818130B8A6DBC03
Remove sysutils/py-filelock?
Nothing uses py-filelock. Remove it? --Kurt
Re: update MULTI_PACKAGE example in faq/ports/guide.html
On Wed, Jan 26, 2022 at 01:29:31PM +0100, Omar Polo wrote:
> Hello,
>
> I was looking at the guide.html and the MULTI_PACKAGE example caught my
> eye: it keeps mentioning -core but AFAIK the main package is, err,
> -main. Also, after a recent-ish change by espie the various PKGNAME-xyz
> are not needed as they have a sensible default.
>
> While I was here I've also indented the lines and sorted some variables
> as per template more or less, the reasoning being that IMHO it still
> count as an example of how to write a port makefile so we might just as
> well do it well. I've also changed slightly how MULTI_PACKAGES is
> handled: i.e. define both -main and -x11 together since the x11 is
> already excluded when the user specifies the no_x11 flavor. This
> produces:
>
> % make show=PKGNAMES
> foo-1.0 foo-x11-1.0
> % FLAVOR=no_x11 make show=PKGNAMES
> foo-1.0
>
> as expected.
>
> I've also changed how the CONFIGURE_ARGS is handled following how
> x11/wxWidgets does it.
>
> What do you think?
>
>
> Index: guide.html
> ===
> RCS file: /home/cvs/www/faq/ports/guide.html,v
> retrieving revision 1.95
> diff -u -p -r1.95 guide.html
> --- guide.html26 Nov 2021 07:53:26 - 1.95
> +++ guide.html26 Jan 2022 12:28:42 -
> @@ -801,8 +801,6 @@ in two variants:
> You need to write those COMMENT-s1 and COMMENT-s2
> in the Makefile, split your PLIST into two parts,
> and create DESCR-s1/DESCR-s2.
> -You will also need to specify separate PKGNAMEs
> -for all subpackages.
>
>
> It is a good idea to start with the minimal framework work required:
> @@ -846,35 +844,37 @@ allowed to modify the actual package con
>
>
> For instance, assuming you separated the graphical interface into a separate
> -subpackage (MULTI_PACKAGES=-core -x11), you could create a
> pseudo
> +subpackage (MULTI_PACKAGES=-main -x11), you could create a
> pseudo
> flavor no_x11 that avoids building the -x11 subpackage.
> -The crucial point is that this flavor should NOT affect the -core package
> +The crucial point is that this flavor should NOT affect the -main package
> in any way.
>
>
> You would end up with a Makefile that looks something like this:
>
>
> -CATEGORIES = app
> -COMMENT-core = foo core application
> -COMMENT-x11 = foo graphical interface
> -V = 1.0
> -DISTNAME = foo-$V
> -PKGNAME-core = foo-core-$V
> -PKGNAME-x11 = foo-x11-$V
> -PSEUDO_FLAVORS = no_x11
> +COMMENT-main = foo core application
> +COMMENT-x11 =foo graphical interface
> +
> +V = 1.0
> +DISTNAME = foo-$V
> +CATEGORIES = app
> +
> +MULTI_PACKAGES = -main -x11
> +PSEUDO_FLAVORS = no_x11
> FLAVOR ?=
> -CONFIGURE_STYLE = gnu
>
> -MULTI_PACKAGES = -core
> WANTLIB = c m crypto ssl
> WANTLIB-x11 = ${WANTLIB} X11 Xt
> -RUN_DEPENDS-x11 = ${BASE_PKGPATH},-core
>
> -.if ${FLAVOR:L:Mno_x11}
> +RUN_DEPENDS-x11 =${BASE_PKGPATH},-main>=$V
> +
> +CONFIGURE_STYLE = gnu
> +
> +.include
> +
> +.if !${BUILD_PACKAGES:M-x11}
> CONFIGURE_ARGS += --disable-x11
> -.else
> -MULTI_PACKAGES += -x11
> .endif
>
> .include
>
>
At first glance, this looks great. Commit it, we'll fix nits if need be.
update MULTI_PACKAGE example in faq/ports/guide.html
Hello,
I was looking at the guide.html and the MULTI_PACKAGE example caught my
eye: it keeps mentioning -core but AFAIK the main package is, err,
-main. Also, after a recent-ish change by espie the various PKGNAME-xyz
are not needed as they have a sensible default.
While I was here I've also indented the lines and sorted some variables
as per template more or less, the reasoning being that IMHO it still
count as an example of how to write a port makefile so we might just as
well do it well. I've also changed slightly how MULTI_PACKAGES is
handled: i.e. define both -main and -x11 together since the x11 is
already excluded when the user specifies the no_x11 flavor. This
produces:
% make show=PKGNAMES
foo-1.0 foo-x11-1.0
% FLAVOR=no_x11 make show=PKGNAMES
foo-1.0
as expected.
I've also changed how the CONFIGURE_ARGS is handled following how
x11/wxWidgets does it.
What do you think?
Index: guide.html
===
RCS file: /home/cvs/www/faq/ports/guide.html,v
retrieving revision 1.95
diff -u -p -r1.95 guide.html
--- guide.html 26 Nov 2021 07:53:26 - 1.95
+++ guide.html 26 Jan 2022 12:28:42 -
@@ -801,8 +801,6 @@ in two variants:
You need to write those COMMENT-s1 and COMMENT-s2
in the Makefile, split your PLIST into two parts,
and create DESCR-s1/DESCR-s2.
-You will also need to specify separate PKGNAMEs
-for all subpackages.
It is a good idea to start with the minimal framework work required:
@@ -846,35 +844,37 @@ allowed to modify the actual package con
For instance, assuming you separated the graphical interface into a separate
-subpackage (MULTI_PACKAGES=-core -x11), you could create a pseudo
+subpackage (MULTI_PACKAGES=-main -x11), you could create a pseudo
flavor no_x11 that avoids building the -x11 subpackage.
-The crucial point is that this flavor should NOT affect the -core package
+The crucial point is that this flavor should NOT affect the -main package
in any way.
You would end up with a Makefile that looks something like this:
-CATEGORIES = app
-COMMENT-core = foo core application
-COMMENT-x11 = foo graphical interface
-V = 1.0
-DISTNAME = foo-$V
-PKGNAME-core = foo-core-$V
-PKGNAME-x11 = foo-x11-$V
-PSEUDO_FLAVORS = no_x11
+COMMENT-main = foo core application
+COMMENT-x11 = foo graphical interface
+
+V =1.0
+DISTNAME = foo-$V
+CATEGORIES = app
+
+MULTI_PACKAGES = -main -x11
+PSEUDO_FLAVORS = no_x11
FLAVOR ?=
-CONFIGURE_STYLE = gnu
-MULTI_PACKAGES = -core
WANTLIB = c m crypto ssl
WANTLIB-x11 = ${WANTLIB} X11 Xt
-RUN_DEPENDS-x11 = ${BASE_PKGPATH},-core
-.if ${FLAVOR:L:Mno_x11}
+RUN_DEPENDS-x11 = ${BASE_PKGPATH},-main>=$V
+
+CONFIGURE_STYLE = gnu
+
+.include
+
+.if !${BUILD_PACKAGES:M-x11}
CONFIGURE_ARGS += --disable-x11
-.else
-MULTI_PACKAGES += -x11
.endif
.include
Re: Tool to scan/watch upstream source for new releases ?
Stefan Sperling wrote in : |On Wed, Jan 26, 2022 at 10:44:50AM +, Yifei Zhan wrote: |> On 22/01/26 10:16AM, Laurent Cheylus wrote: |>> Hi, |>> |>> for Debian Linux distribution, uscan tool is used to scan/watch \ |>> upstream |>> sources for new releases of software. |>> https://manpages.debian.org/bullseye-backports/devscripts/uscan.1.en.htm\ |>> l |>> |>> This tool is used with watchfiles : defines URL for upstream tarball(s) |>> and download it if the upstream tarball have highest version newer than |>> the last upstream version. |>> |>> Is there a similar tool for OpenBSD ports ? |>> |> |> This might be what you are looking for: |> https://portroach.openbsd.org/ |> |> but now I mostly just use repology.org since they support OpenBSD |> Ports and allow me to do cross reference with other distros. | |ropology is slow with updating its data for OpenBSD ports. |It sometimes lags behind by several days, perhaps by a week. |Watch out for this if you really need up-to-date info. The core group of the CRUX Linux i am contributing ports to installed some repology json i think it was info on the ports master server; ie now repology looks at the json data, and this seems to happen "almost instantly". I personally like it very much as i do not install things like ck4up or similar utilities to track upstream changes -- what does not come in via oss-security or announcement mails (which often are forgotten, take st: huhu!!!) may linger a bit. |For example, for devel/got, repology keeps showing that FreeBSD keeps |updating before OpenBSD, which in reality has never happened. |https://repology.org/project/got-game-of-trees/history --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Tool to scan/watch upstream source for new releases ?
> On Jan 26, 2022, at 6:06 AM, Stefan Sperling wrote: > > On Wed, Jan 26, 2022 at 10:44:50AM +, Yifei Zhan wrote: >>> On 22/01/26 10:16AM, Laurent Cheylus wrote: >>> Hi, >>> >>> for Debian Linux distribution, uscan tool is used to scan/watch upstream >>> sources for new releases of software. >>> https://manpages.debian.org/bullseye-backports/devscripts/uscan.1.en.html >>> >>> This tool is used with watchfiles : defines URL for upstream tarball(s) >>> and download it if the upstream tarball have highest version newer than >>> the last upstream version. >>> >>> Is there a similar tool for OpenBSD ports ? >>> >> >> This might be what you are looking for: >> https://portroach.openbsd.org/ >> >> but now I mostly just use repology.org since they support OpenBSD >> Ports and allow me to do cross reference with other distros. > > ropology is slow with updating its data for OpenBSD ports. > It sometimes lags behind by several days, perhaps by a week. > Watch out for this if you really need up-to-date info. > > For example, for devel/got, repology keeps showing that FreeBSD keeps > updating before OpenBSD, which in reality has never happened. > https://repology.org/project/got-game-of-trees/history > I believe the source for repology is https://ftp.fr.openbsd.org/pub/sqlports So it would be as current as that link is. I think that link is checked quite frequently. See: https://repology.org/repositories/updates Which shows the last fetch and last parse times.
Re: [update] net/usockets-0.8.1, www/uwebsockets-20.8.0, www/purritobin-0.6.7
Aisha Tammy writes:
> ping
Hello,
The uwebsockets diff looks fine to me.
The usockets one I think it's missing a `c' for ar when creating the
libusockets.a archive (otherwise it is still created but it issues a
warning.) In the test target of files/Makefile CC should be used
instead of CXX, as hammer_test.c is a C file. Tests fails around 6%
here with "FAILED TO START CONNECTION, WILL EXIT NOW" but I assume it's
due to the file descriptor limits. I haven't tried to raise them. It's
also missing WANTLIB += m (as reported by make port-lib-depends-check.)
The purritobin diff looks fine, just some comments:
- nit: there was a line indented with spaces in the httpd example.
- pkg/README mentions share/purritobin but now it's share/PurritoBin
- it's expected for /var/www/purritobin to be empty? It should be
mentioned somewhere to copy /usr/local/share/PurritoBin/*.html there?
It's quite intuitive IMHO, but asking anyway. Otherwise it works,
i.e. I can upload stuff with purr :D
I've not played too much with the web interface, but I think it should
be mentioned somewhere that /usr/local/share/PurritoBin/index.html uses
bsd.ca by default and that users that want to deploy their own instance
need to change PURRITOBIN_URL (diff below doesn't address this.)
One general nit: I wouldn't move PKGNAME. The previous place was as per
Makefile.template and (very) slightly reduces the churn.
Here's an updated diff that address most points above.
Cheers,
Omar Polo
Index: net/usockets/Makefile
===
RCS file: /home/cvs/ports/net/usockets/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- net/usockets/Makefile 11 Dec 2020 22:34:51 - 1.5
+++ net/usockets/Makefile 26 Jan 2022 10:44:03 -
@@ -1,40 +1,33 @@
# $OpenBSD: Makefile,v 1.5 2020/12/11 22:34:51 sthen Exp $
COMMENT= eventing, networking & crypto for async applications
-CATEGORIES = net
-
-VERSION = 0.6.0
-REVISION = 1
-
-DISTNAME = usockets-${VERSION}
PKGNAME = ${DISTNAME:L}
-SHARED_LIBS = usockets 1.0
+CATEGORIES = net
+
+SHARED_LIBS = usockets 2.0
GH_ACCOUNT = uNetworking
GH_PROJECT = uSockets
-#GH_TAGNAME = v0.6.0
-# cstdlib include error
-GH_COMMIT =7683672d87067cd75b854f4e36b9820f4809a4be
-
+GH_TAGNAME = v0.8.1
MAINTAINER = Aisha Tammy
# Apache 2.0
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX} crypto ssl uv
+WANTLIB += ${COMPILER_LIBCXX} crypto m ssl uv
# C11 C++17
COMPILER = base-clang ports-gcc
LIB_DEPENDS = devel/libuv
-USE_GMAKE =Yes
-MAKE_FLAGS = CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \
- CC="${CC}" CXX="${CXX}" \
- LIBusockets_VERSION="${LIBusockets_VERSION}"
+MAKE_ENV = LIBusockets_VERSION="${LIBusockets_VERSION}"
+
+# tests need A LOT of file desrciptors ~5000-6000
-NO_TEST = Yes
+post-patch:
+ cp "${FILESDIR}"/{Makefile,libusockets.pc.in,localhost.conf} "${WRKSRC}"
.include
Index: net/usockets/distinfo
===
RCS file: /home/cvs/ports/net/usockets/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- net/usockets/distinfo 11 Dec 2020 22:33:22 - 1.4
+++ net/usockets/distinfo 26 Jan 2022 09:37:06 -
@@ -1,2 +1,2 @@
-SHA256 (usockets-0.6.0-7683672d.tar.gz) =
0OooGCHD8ezNIcaB1zDPK6RQLGGYGZJb24Vemjlat7c=
-SIZE (usockets-0.6.0-7683672d.tar.gz) = 57634
+SHA256 (uSockets-0.8.1.tar.gz) = OzO1kkqSV3hU4jJrPi05OEnsAL64ZaEnG/JMDyEMwdY=
+SIZE (uSockets-0.8.1.tar.gz) = 65470
Index: net/usockets/files/Makefile
===
RCS file: net/usockets/files/Makefile
diff -N net/usockets/files/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/usockets/files/Makefile 26 Jan 2022 10:14:20 -
@@ -0,0 +1,38 @@
+# $OpenBSD$
+
+PREFIX ?= /usr/local
+LIBDIR ?= "$(PREFIX)/lib"
+INCLUDEDIR ?= "$(PREFIX)/include"
+
+PKG_CONFIG ?= pkg-config
+
+LIBTARGET =libusockets.so.$(LIBusockets_VERSION)
+
+REQUIRES = libcrypto libssl libuv
+COMMON_FLAGS = -Isrc -DLIBUS_USE_OPENSSL -DLIBUS_USE_LIBUV `$(PKG_CONFIG)
--cflags $(REQUIRES)`
+
+CFLAGS += -std=c11 -fPIC $(COMMON_FLAGS)
+CXXFLAGS +=-std=c++17 -fPIC $(COMMON_FLAGS)
+LDFLAGS += `$(PKG_CONFIG) --libs $(REQUIRES)`
+
+all:
+ $(CC) $(CFLAGS) -c src/*.c src/eventing/*.c src/crypto/*.c
+ $(CXX) $(CXXFLAGS) -c src/crypto/*.cpp
+ $(AR) rcvs libusockets.a *.o
+ $(CXX) $(CXXFLAGS) -shared -o $(LIBTARGET) *.o -Wl,-soname,$(LIBTARGET)
$(LDFLAGS)
+ sed -e "s:@PREFIX@:$(PREFIX):" -e "s:@VERSION@:$(LIBusockets_VERSION):"
libusockets.pc.in > libusockets.pc
+
+install:
+ install -d "$(LIBDIR)/pkgconfig" "$(INCLUDEDIR)"
+ install -m 644 src/libusockets.h "$(INCLUDEDIR)/"
+ install -m 644 $(LIBTARGET) "$(LIBDIR)/"
+ install -m 64
Re: Tool to scan/watch upstream source for new releases ?
On Wed, Jan 26, 2022 at 10:44:50AM +, Yifei Zhan wrote: > On 22/01/26 10:16AM, Laurent Cheylus wrote: > > Hi, > > > > for Debian Linux distribution, uscan tool is used to scan/watch upstream > > sources for new releases of software. > > https://manpages.debian.org/bullseye-backports/devscripts/uscan.1.en.html > > > > This tool is used with watchfiles : defines URL for upstream tarball(s) > > and download it if the upstream tarball have highest version newer than > > the last upstream version. > > > > Is there a similar tool for OpenBSD ports ? > > > > This might be what you are looking for: > https://portroach.openbsd.org/ > > but now I mostly just use repology.org since they support OpenBSD > Ports and allow me to do cross reference with other distros. ropology is slow with updating its data for OpenBSD ports. It sometimes lags behind by several days, perhaps by a week. Watch out for this if you really need up-to-date info. For example, for devel/got, repology keeps showing that FreeBSD keeps updating before OpenBSD, which in reality has never happened. https://repology.org/project/got-game-of-trees/history
Tool to scan/watch upstream source for new releases ?
Hi, for Debian Linux distribution, uscan tool is used to scan/watch upstream sources for new releases of software. https://manpages.debian.org/bullseye-backports/devscripts/uscan.1.en.html This tool is used with watchfiles : defines URL for upstream tarball(s) and download it if the upstream tarball have highest version newer than the last upstream version. Is there a similar tool for OpenBSD ports ? thx, Laurent
Re: Fwd: [SECURITY] [UPDATE] lang/node to 16.13.2
On 2022/01/26 08:12, Volker Schlecht wrote:
> At the risk of being considered a PITA: Is there anything *I* can do to
> move this a step forward?
I can only speak for myself and there are other people that can
review too, but I already mentioned what would have made it easier for
me to review on the ghostscript thread,
: reformatting the whole makefile in an update (especially for a complex
: port) makes it really hard to see what's changed, making review more
: difficult and take longer
Cut the size of the diff and you make it easier to review (and easier
for anyone trying to figure out what exactly was changed in an update
when looking at commit history).
Take this for example
-DISTFILES =node-pledge-{}${PLEDGE_VER}.tar.gz:0 \ -
${DISTNAME}-headers.tar.gz \-
${DISTNAME}.tar.gz
-
-DISTNAME = node-${NODE_VERSION}
-PKGNAME = ${DISTNAME:S/v//g}
-REVISION = 0
+DISTFILES =${DISTNAME}${EXTRACT_SUFX}
+DISTFILES += ${DISTNAME}-headers${EXTRACT_SUFX}
+DISTFILES += node-pledge-{}${PLEDGE_VER}.tar.gz:0
+
+DISTNAME = node-${NODE_VERSION}
+PKGNAME = ${DISTNAME:S/v//g}
The following one line has the same effect
-REVISION = 0
The rest is just a lot of extra cognitive load when reviewing,
and it's like this all through the diff. Like changing from the
existing
LIB_DEPENDS = ... \
... \
to
LIB_DEPENDS += ...
LIB_DEPENDS += ...
So everything has to be read together rather than just working through
the diff in order.
(incidentally with the LIB_DEPENDS, what's there now is what's normally
used in the ports tree for hand-written continuation lines; it's not
"wrong" with += on each line, but this change moves the port further
from what "a normal port" looks like.)
Overall effect is that it's going to take probably half an hour+ just
to figure out what the actual changes are before looking at them.
Meaning that it takes a bigger chunk of free time in order for it to
be possible to start on it. And if that sort of chunk of time is
available then frankly there are more useful things to do with it than
figuring out which are noop changes and which are real..
I will get to it if nobody beats me to it but it may take a few days yet.
Re: Update sysutils//fzf to 0.29.0
Hi, On Mon, 17 Jan 2022 08:20:50 +0100, Stefan Hagen wrote: >> I updated sysutils/fzf port to the last version 0.29.0 => >> https://github.com/junegunn/fzf/releases/tag/0.29.0 > Hmm, yes, but there must be no manual steps between "make fetch" and > "make package". The build servers won't perform these ;-) > > This is, why Edd is hosting a tarball with this change on his website, > which is then used in MASTER_SITES. > > So your change to github won't work. Sorry. Thanks for your remarks. I know that my update for fzf port cannot be integrated like this. My goal was to propose a method to update fzf manually without updated Ed's tarball. >> make build/package/install and tests OK on OpenBSD 7.0/amd64. > > When submitting a port, it's good practice to test it on a -current > system. As least if you're planning to submit more often. OK, I updated my OpenBSD VM to current version. > Even though we can't commit this port, I gave you more feedback below > for your next port maybe? Thanks, I will do some rework on this port to apply correctly OpenBSD porting rules. Laurent
Re: dpd -d BUILD_USER=
On Wed, Jan 26, 2022 at 04:58:11PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> I'm trying
>
> dpb -d BUILD_USER=releng
>
> but dpb executes portlock(1) by default "_pbuild" user.
>
> It seems that overriding internal default "build_user" is missing.
>
> Is the diff ok?
>
> Index: infrastructure/lib/DPB/Config.pm
> ===
> RCS file: /disk/cvs/openbsd/ports/infrastructure/lib/DPB/Config.pm,v
> retrieving revision 1.91
> diff -u -p -r1.91 Config.pm
> --- infrastructure/lib/DPB/Config.pm 3 May 2021 07:16:46 - 1.91
> +++ infrastructure/lib/DPB/Config.pm 26 Jan 2022 07:47:30 -
> @@ -335,6 +335,9 @@ sub command_line_overrides
> if (defined $state->{port_user}) {
> $override_prop->{port_user} = $state->{port_user};
> }
> + if (defined $state->{build_user}) {
> + $override_prop->{build_user} = $state->{build_user};
> + }
> if (!$state->{subst}->empty('HISTORY_ONLY')) {
> $state->{want_fetchinfo} = 1;
> $state->{opt}{f} = 0;
>
Okay. I've always used it in the config file instead of the command line
which is why I didn't run into that bug.
Thanks for hunting it down.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/26 17:41, Damien Miller wrote: > On Fri, 21 Jan 2022, joshua stein wrote: > > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > > > Maybe we can do something radical like enable GitHub pull requests > > to let people submit changes against the ports repo on GitHub, do > > review and feedback on those on GitHub, and once it's been approved > > by a developer, that developer can do the final legwork of > > committing it to CVS and closing the pull request (since we can't > > commit directly to the Git repo). > > I'm late to the party (as usual), but we've been doing this for a while > in OpenSSH - we'll review pull requests on github and have one of the > developers do the final tidying and commit to CVS. I can certainly see this working for some areas of OpenBSD. Especially more defined areas where primarily a smaller group of people handle most diffs going in, and where the mechanics of getting something committed account for a small part of the overall time taken to handle a submission. i.e. a higher % of the overall time is taken for review etc than with the mechanics of committing than is often the case for ports. In particular I think it's the case for OpenSSH where the vast majority of people using it are not OpenBSD users at all. > It's worked pretty well, and the quality of submissions is about as > good as we get from other outside sources. I believe it's allowed > a number of people who would otherwise not have contributed to do so, > since the tools are familiar and the hassle factor is so much lower. Ports by its nature needs domain-specific knowledge to successfully prepare an update. Nothing difficult, just some things to learn and do. Things like bumping revision numbers when changes are made, regenerating plists to pick up new files, looking for ABI changes in shared libraries, working on -current. In the context of that, putting the diff in an email rather than in a github PR isn't a high extra hurdle,
Re: [new] net/py-tremc - curses interface for transmission
Thim writes: > Tarballs attached yet again :) imported both, thanks!
Re: [new] sysutils/gitmux - git repo status in tmux status bar
On 2022/01/25 20:40, Aaron Bieber wrote: > Hi, > > Here is a port of gitmux, a tool to display git repo status info in your > tmux status bar. Since there's no manual, can you install the readme so the package includes somw details of how to use it? Otherwise OK.
