NetBSD Problem Report #56906

From www@netbsd.org  Wed Jun 29 20:50:06 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id BE03F1A921F
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 29 Jun 2022 20:50:06 +0000 (UTC)
Message-Id: <20220629205005.8614F1A9239@mollari.NetBSD.org>
Date: Wed, 29 Jun 2022 20:50:05 +0000 (UTC)
From: vms@retrobsd.ddns.net
Reply-To: vms@retrobsd.ddns.net
To: gnats-bugs@NetBSD.org
Subject: libbsd: update devel/libbsd to 0.11.0
X-Send-Pr-Version: www-1.0

>Number:         56906
>Category:       pkg
>Synopsis:       libbsd: update devel/libbsd to 0.11.0
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 29 20:55:00 +0000 2022
>Last-Modified:  Fri Jul 15 02:00:02 +0000 2022
>Originator:     Paolo Vincenzo Olivo
>Release:        pkgsrc-2022Q1
>Organization:
>Environment:
SunOS Release 5.11 Version 11.4.42.111.0 64-bit
>Description:
Update request for devel/libbsd to version 0.11.0.

Noticeably, this version includes compatibility support for recallocarray() and freezero() from OpenBSD's malloc(3) [1], which can prove very useful in packaging anything related to the project. It's worth noting that the Illumos libc supports these function natively [2].  

[1] https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/01f0d1ea1e71f1018a009ebd9203dd48e6d90c45
[2] https://www.illumos.org/issues/8546
>How-To-Repeat:

>Fix:
Diffs to update to version 0.11.0 attached as follow:


--- Makefile.orig	2020-12-09 12:21:46.000000000 +0100
+++ Makefile	2022-06-29 22:07:27.619235798 +0200
@@ -1,6 +1,6 @@
 # $NetBSD: Makefile,v 1.1 2020/12/09 11:21:46 cheusov Exp $

-DISTNAME=	libbsd-0.10.0
+DISTNAME=	libbsd-0.11.0
 CATEGORIES=	devel
 MASTER_SITES=	http://libbsd.freedesktop.org/releases/
 EXTRACT_SUFX=	.tar.xz

--- PLIST.orig	2022-06-29 22:12:22.419101535 +0200
+++ PLIST	2022-06-29 22:13:16.874046083 +0200
@@ -1,13 +1,15 @@
-@comment $NetBSD: PLIST,v 1.1 2020/12/09 11:21:46 cheusov Exp $
+@comment $NetBSD$
 include/bsd/bitstring.h
 include/bsd/bsd.h
 include/bsd/err.h
 include/bsd/getopt.h
+include/bsd/grp.h
 include/bsd/inttypes.h
 include/bsd/libutil.h
 include/bsd/md5.h
 include/bsd/netinet/ip_icmp.h
 include/bsd/nlist.h
+include/bsd/pwd.h
 include/bsd/readpassphrase.h
 include/bsd/stdio.h
 include/bsd/stdlib.h
@@ -184,11 +186,14 @@
 man/man3/fmtcheck.3bsd
 man/man3/fparseln.3bsd
 man/man3/fpurge.3bsd
+man/man3/freezero.3bsd
 man/man3/funopen.3bsd
 man/man3/getbsize.3bsd
 man/man3/getmode.3bsd
 man/man3/getpeereid.3bsd
 man/man3/getprogname.3bsd
+man/man3/gid_from_group.3bsd
+man/man3/group_from_gid.3bsd
 man/man3/heapsort.3bsd
 man/man3/humanize_number.3bsd
 man/man3/le16dec.3bsd
@@ -205,11 +210,13 @@
 man/man3/pidfile_open.3bsd
 man/man3/pidfile_remove.3bsd
 man/man3/pidfile_write.3bsd
+man/man3/pwcache.3bsd
 man/man3/queue.3bsd
 man/man3/radixsort.3bsd
 man/man3/readpassphrase.3bsd
 man/man3/reallocarray.3bsd
 man/man3/reallocf.3bsd
+man/man3/recallocarray.3bsd
 man/man3/setmode.3bsd
 man/man3/setproctitle.3bsd
 man/man3/setproctitle_init.3bsd
@@ -238,6 +245,7 @@
 man/man3/timercmp.3bsd
 man/man3/timerisset.3bsd
 man/man3/timersub.3bsd
+man/man3/timespec.3bsd
 man/man3/timespecadd.3bsd
 man/man3/timespecclear.3bsd
 man/man3/timespeccmp.3bsd
@@ -245,7 +253,9 @@
 man/man3/timespecsub.3bsd
 man/man3/timeval.3bsd
 man/man3/tree.3bsd
+man/man3/uid_from_user.3bsd
 man/man3/unvis.3bsd
+man/man3/user_from_uid.3bsd
 man/man3/vis.3bsd
 man/man3/wcslcat.3bsd
 man/man3/wcslcpy.3bsd

--- distinfo.orig	2021-10-26 12:15:15.000000000 +0200
+++ distinfo	2022-06-29 22:09:42.305214252 +0200
@@ -1,5 +1,5 @@
 $NetBSD: distinfo,v 1.3 2021/10/26 10:15:15 nia Exp $

-BLAKE2s (libbsd-0.10.0.tar.xz) = 6ce3c0e1456420835c035d607273b4ef5184f6a00e6852ea74e2abb9e6300d90
-SHA512 (libbsd-0.10.0.tar.xz) = b75529785b16c93d31401187f8a58258fbebe565dac071c8311775c913af989f62cd29d5ce2651af3ea6221cffd31cf04826577d3e546ab9ca14340f297777b9
-Size (libbsd-0.10.0.tar.xz) = 393576 bytes
+BLAKE2s (libbsd-0.11.0.tar.xz) = b90e6a6c619b134601dd8b96c077e10b0aca79807b093dd6f08feaaa4a28a394
+SHA512 (libbsd-0.11.0.tar.xz) = 86122f2ce7fda0ad6866a7eb154784b072dfea6a2c0ce9d67d3d59e0c153489de627b96798cc7f8460c19c190ac31a3065b05ff8227671e1f6dfcead991a9b31
+Size (libbsd-0.11.0.tar.xz) = 395808 bytes

>Release-Note:

>Audit-Trail:
From: "David H. Gutteridge" <david@gutteridge.ca>
To: Gnats Bugs <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: pkg/56906: libbsd: update devel/libbsd to 0.11.0
Date: Thu, 30 Jun 2022 09:00:25 -0400

 The current upstream release is actually 0.11.6, so it would make more
 sense to update to that, unless there's a reason not to?

 Regardless, starting with 0.11.0, it expects a separate libmd
 dependency (or equivalent) to be available. This breaks the build for
 me, e.g., on Fedora 36:

 checking for library containing MD5Update... no
 configure: error: cannot find required message digest functions in libc 
 or libmd
 *** Error code 1

 (0.10.0 does build correctly for me.)

 We don't have libmd in pkgsrc, so this would have to be added first,
 and reflected as a dependency of libbsd. (Or libbsd would have to be
 patched differently.)

 Regards,

 Dave

From: Paolo Vincenzo Olivo <vms@retrobsd.ddns.net>
To: gnats-bugs@netbsd.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org,
	david@gutteridge.ca
Subject: Re: pkg/56906: libbsd: update devel/libbsd to 0.11.0
Date: Thu, 30 Jun 2022 17:14:07 +0200

 --i627f3skdxide7du
 Content-Type: text/plain; charset=utf-8
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 Hi David,=20
 Thanks for the prompt reply.

 On 22/06/30 01:05PM, David H. Gutteridge wrote:

 >  The current upstream release is actually 0.11.6, so it would make more
 >  sense to update to that, unless there's a reason not to?

 Yes. I was aware of this, but I assumed that, being libbsd quite a
 critical component on non-bsd platform, it would have been preferable
 to pick an already widely tested release; so I picked 0.11.0 since was
 the one introducing most noteworthy changes and the one which a couple
 of packages I was working on required.

 Anyway, I had already packaged libbsd-0.11.5. Today I committed it to
 @wip, and subsequently updated it to 0.11.6 [1].

 My only reason to be sceptical about 0.11.6 is that few packages
 depending on it which I tested, didn't manage to build successfully:
 the build hangs as the compiler tries to link against it. Unfortunately
 I really won't have time in the following days to debug that (and I may
 also like the skill). I'd first go look at the libbsd CHANGELOG thogh. =20

 [1] https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=3Dpkgsrc-wip.git;a=3Dtree;f=
 =3Dlibbsd


 >  Regardless, starting with 0.11.0, it expects a separate libmd
 >  dependency (or equivalent) to be available. This breaks the build for
 >  me, e.g., on Fedora 36:
 > =20
 >  We don't have libmd in pkgsrc, so this would have to be added first,
 >  and reflected as a dependency of libbsd. (Or libbsd would have to be
 >  patched differently.)
  =20
 I packaged [2] libmd a while ago, and it's available on wip and
 currently at the most recent version.
 The only packages with which I tested libmd so far are wip/got-portable (wh=
 en
 built on Linux) and wip/signify-libbsd (Linux and Solaris). But that was
 with libbsd-0.11.0.=20

 Speaking of which, as a side note, I also added a port of OpenBSD's
 signify(1) to NetBSD, which is available as wip/signify. Tested and
 working, in case you wanted to import it in the main tree.

 [1] https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=3Dpkgsrc-wip.git;a=3Dtree;f=
 =3Dlibmd

 Regards,
 PVO

 --=20
 ----------------------------+----------------------------
 vms[-at]retrobsd.ddns.net   |   https://retrobsd.ddns.net


 --i627f3skdxide7du
 Content-Type: application/pgp-signature; name="signature.asc"

 -----BEGIN PGP SIGNATURE-----

 iHUEABEKAB0WIQRxHb+RTf9yD0TTVi4vViwbB9te9gUCYr29uwAKCRAvViwbB9te
 9nKGAP4380VIpRJU6U89knrDmgsWgD2paOiyPV4hh48+4wk5sAD/awIORtq3Kpen
 z5gG78bfgZKIhxZzff9+a7td3n7WsYU=
 =0pLP
 -----END PGP SIGNATURE-----

 --i627f3skdxide7du--

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/56906: libbsd: update devel/libbsd to 0.11.0
Date: Sun, 10 Jul 2022 00:33:03 +0000

 Several messages in this discussion weren't sent to gnats.

 (Send replies to bug reports to gnats-bugs@; it then remails them.
 Mails sent to just the mailing list or to gnats-admin don't get into
 the bug database unless someone notices and forwards a copy.)

 (Generally it seems that if you reply to your own message it does not
 go to the right place by default...)

 These are the first two, from last weekend.

    ------

 On Sun, Jul 03, 2022 at 11:32:33AM +0200, Paolo Vincenzo Olivo wrote:
  > Apparently, also libbsd contains Beerware-licensed code [1], so the
  > LICENSE entry of the devel/libbsd package (which is `original-bsd'),
  > should be changed to reflect the fact libbsd it's multi-licensed.
  > 
  > [1] https://libbsd.freedesktop.org/wiki/
  > 
  > - PVO


 On Sat, Jul 02, 2022 at 04:37:22PM +0200, Paolo Vincenzo Olivo wrote:
  > So, an update on this topic is due. 
  > 
  > I modified wip/libbsd 's Makefile to enable link-time optimization when
  > supported, and I forced autoreconf at pre-configure stage, since the
  > README for 0.11.6 recommends running `autogen'.
  > 
  > The package now explicitly depends on devel/libmd (available as wip/libmd)
  > through the buildlink methodology.
  > 
  > wip/libbsd (0.11.6) compiles fine on Linux, but any time I try to link
  > against it in a package (with -lbsd or pkg-config), the compiler hangs
  > indefinitely at build stage. This didn't ahppen with previous versions
  > of libbsd.
  > 
  > I was able to reproduce it by attempting to compile the same programs
  > manually, both on my workstation (Slackware 15.0) and on SDF's MetaArray
  > (Debian 11), using a very standard mk.conf. Still same issue, as soon as
  > the compiler tries to link against libbsd, the build freezes forever,
  > without printing any error.
  > 
  > Apparently nobody else reported this so far. Other distributions do not
  > apply any noteworthy patch to libbsd-0.11.6, aside from removing the
  > libtool archives, which for them is common practice. 
  > 
  > I wonder whether this has anything to do with the pkgsrc infrastructure
  > (default compiler flags, linked libs, mitigations) or if I'm missing
  > something very stupid in the Makefile, which somebody more knowledgeable
  > would catch immediately while looking at libbsd's build log.
  > 
  > Anyway, at least I've nailed down the issue to some change introduced
  > between 0.11.3 and 0.11.4, as libbsd-0.11.3 allows me to pass -lbsd
  > safely in other packages, while 0.11.4 does not (resulting in the
  > aforementioned 'hang').
  > 
  > The ChangeLog for libbsd is available at:
  > https://cgit.freedesktop.org/libbsd/log/?h=main
  > 
  > I'd look at any commit between 0.11.3 and 0.11.4. One may be:
  > "Switch md5 compatibility logic back to direct linking"
  > https://cgit.freedesktop.org/libbsd/commit/?h=main&id=e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888
  > 
  > Would it make sense, for the time being, to pull libbsd-0.11.3, together
  > to libmd-1.0.4 (latest) in the main tree, and try to understand what's
  > the issue with 11.0.6 in the meantime?
  > 
  > Speaking of libmd, I successfully built wip/libmd on NetBSD and Solaris
  > 11 (and Linux). It's a very simple package and unless someone has
  > something to object, I'd consider it ready to import. 
  > The only problem with libmd is that it contains code licensed under
  > 'beer-ware' [1], an extremely permissive and substantially copyright-
  > only license, which, while being supposedly BSD/GPL compatible, is not
  > included among the accepted licenses in licenses.mk  
  > 
  > I found libbsd to be very linux-centric instead (not something
  > unheard of freedesktop's), in spite of their supposed focus on
  > portability. Ii'm confident  that libbsd is routinely tested on Linux,
  > macOS (and perhaps MingW) only.
  > 
  > They recently dropped OpenBSD support, since their obsd-specific
  > arc4random implementation wouldn't compile in it.
  > 
  > On Solaris 11.4 the build fails early on, due to incompatible
  > arc4random_addrandom(). I suppose this would turn out the same way on
  > illumos too.
  > 
  > On NetBSD, arc4random.c, getopt.c and some others compile fine after
  > patching bsd/unistd.h for closefrom(), but I found that multiple other
  > functions need major rework. And at this point, it's probably better to
  > rely on a ad-hoc compat library when porting openbsd software, as done
  > for openssh, or devel/got.
  > 
  > At the same time, a good portion of *BSD utils ported to Linux adn OS X
  > relies on libbsd, so it does make sense to have a working and up to date
  > version in repo.
  >   
  > [1] https://en.wikipedia.org/wiki/Beerware
  > 
  > - PVO


From: "David H. Gutteridge" <david@gutteridge.ca>
To: Gnats Bugs <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: pkg/56906: libbsd: update devel/libbsd to 0.11.0
Date: Sun, 03 Jul 2022 15:48:53 -0400

 (Responding to everything in one message. There is a lot to cover, and
 I'm pressed for time, so I may have missed things.)

 > [...] I assumed that, being libbsd quite a
 > critical component on non-bsd platform, it would have been preferable
 > to pick an already widely tested release; so I picked 0.11.0 since was
 > the one introducing most noteworthy changes and the one which a couple
 > of packages I was working on required.

 That's a quite reasonable position, it's just pkgsrc tends to always
 update to the most recent stable release of a project, unless there's a
 known reason not to (which there may be here, it seems). And we'd
 generally expect if a project makes "minor" or "teeny" releases, that
 implies they're minor bug/security/doc/whatever fixes, and shouldn't
 introduce significant changes or build breakages. That's not always a
 correct assumption, of course.

 If there are regressions with 0.11.6 vs. 0.11.5 (etc.), those should
 really be reported back upstream (regardless of what we'd do).

 > I packaged [2] libmd a while ago, and it's available on wip and
 > currently at the most recent version.

 I did look to see if libmd was in wip, but didn't realize the search
 function at the landing page doesn't work as I'd expect. (I used to use
 pkgsrc.se, but have found it sometimes doesn't work as I'd expect
 anymore, either. E.g., it shows that libbsd has no dependant packages,
 which is wrong.)

 Something to think about with both libbsd and libmd is if they should
 provide proper built-in detection. libbsd has an attempt at it, but
 seems wrong to me, as it doesn't work on BSDs. (I guess the assumption
 is that no one would choose to build it in that context, and depending
 packages would conditionally handle this, though they don't seem to
 entirely consistently or correctly, e.g., audio/rtunes or
 graphics/scrot.)

 Trying to build the current libbsd 0.10 on NetBSD 9.99.97/amd64 fails
 with:

 In file included from arc4random.c:33:
 ../include/bsd/unistd.h:62:6: error: conflicting types for 'closefrom'
     62 | void closefrom(int lowfd);
        |      ^~~~~~~~~
 In file included from ../include/bsd/unistd.h:31,
                   from arc4random.c:33:
 /usr/include/unistd.h:329:6: note: previous declaration of 'closefrom' 
 was here
    329 | int  closefrom(int);
        |      ^~~~~~~~~
 *** [arc4random.lo] Error code 1

 make[2]: stopped in 
 /home/disciple/pkgsrc/devel/libbsd/work/libbsd-0.10.0/src
 1 error

 I see you found the same, and it sounds like it may be complicated to
 resolve.

 Built-in handling for libmd would be a bit more complicated, I think,
 given there are more OSes involved (and SunOS variants, perhaps).

 > Speaking of libmd, I successfully built wip/libmd on NetBSD and Solaris
 > 11 (and Linux). It's a very simple package and unless someone has
 > something to object, I'd consider it ready to import.
 > The only problem with libmd is that it contains code licensed under
 > 'beer-ware' [1], an extremely permissive and substantially copyright-
 > only license, which, while being supposedly BSD/GPL compatible, is not
 > included among the accepted licenses in licenses.mk

 I'd prefer it to have a working built-in guard, as above, but that may
 be non-trivial. Others may have a different opinion than me.

 I think there is a mismatch here in how the licensing is reflected by
 the pkgsrc infrastructure. That is, the rule is supposed to be, if
 something is default acceptable, it does not contain "license" in its
 name in pkgsrc. We have it as "beer-ware". Also, the NetBSD tree itself
 contains Beer-Ware licensed code in a place that implies the same
 interpretation[1]. So I think it should be default acceptable. (But I'm
 not a licensing maven.)

 > At the same time, a good portion of *BSD utils ported to Linux adn OS X
 > relies on libbsd, so it does make sense to have a working and up to 
 > date
 > version in repo.

 Sure, though I don't see many actual dependencies in pkgsrc itself, and
 presumably 0.10 satisfies them all (no idea), so I don't see a
 particular urgency to this, personally. It's a nice to have. (Maybe I'm
 missing something?) Please don't get me wrong, certainly the efforts
 you're making are appreciated!

 > Apparently, also libbsd contains Beerware-licensed code [1], so the
 > LICENSE entry of the devel/libbsd package (which is `original-bsd'),
 > should be changed to reflect the fact libbsd it's multi-licensed.

 Yes, I noticed the entry was wrong for the package, too. It looks like
 it should actually list four or five different licenses, similar to
 what you've done for libmd.

 Regards,

 Dave

 1. E.g., src/lib/libc/hash/hashhl.c

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/56906: libbsd: update devel/libbsd to 0.11.0
Date: Sun, 10 Jul 2022 00:33:03 +0000

 Several messages in this discussion weren't sent to gnats.

 These are the second two from July 8, after the above reply.

    ------

 On Fri, Jul 08, 2022 at 02:39:23PM +0200, Paolo Vincenzo Olivo wrote:
  > (Splitting this reply in 2 mails; one regarding the libbsd bug, the
  > other dedicated to discussing the observations made in the parent message).
  > 
  > On 22/07/03 07:50PM, David H. Gutteridge wrote:
  > >  
  > >  If there are regressions with 0.11.6 vs. 0.11.5 (etc.), those should
  > >  really be reported back upstream (regardless of what we'd do).
  > >  
  > 
  > And we have a culprit.
  > The bug was introduced indeed between 0.11.3 and 0.11.4 [1]. In
  > particular, this added chunk of code in the `install-exec-hook' target of
  > the Makefile.am:
  > 
  > ```
  > + if NEED_TRANSPARENT_LIBMD
  > + # The "GNU ld script" magic is required so that GNU ldconfig does not complain
  > + # about an unknown format file.
  > +   soname=`readlink $(DESTDIR)$(libdir)/libbsd.so`; \
  > +   $(RM) $(DESTDIR)$(libdir)/libbsd.so; \
  > +   (echo '/* GNU ld script'; \
  > +	 echo ' * The MD5 functions are provided by the libmd library. */'; \
  > +	 cat format.ld; \
  > +	 echo "GROUP($(runtimelibdir)/$$soname AS_NEEDED($(MD5_LIBS)))"; \
  > +	)>$(DESTDIR)$(libdir)/libbsd.so
  > ```
  > 
  > Results in having the target shared objects of @libbsd.so (the
  > libbsd.so.0.11.6 shared lib) overwritten with the content echoed in
  > quotes, whenever $(RM) is undefined or null and @libbsd.so isn't
  > consequently preemptively removed.
  > 
  > This leads to a circular reference between the @libbsd.so the libbsd
  > library file, whereby the latter itself points to a non-existing object.
  > And this accounts for the hangings witnessed while trying to link
  > against libbsd.
  > 
  > By skimming through the DESTDIR, I had noticed that libbsd.so.0.11.6
  > curiously consisted of a plain text file, but I couldn't make up my mind
  > about it. It was @RVP, in a private mail exchange, to point me to 
  > where the problem actually lied.
  > 
  > The reason why this happens on pkgsrc, whereas nobody else reported it
  > in the Linux ecosystem, is that GNU Make defines RM among its implicit
  > variables [2] and aliases it to `rm -f'. When the install-exec-hook
  > target is executed, $(RM) is lost and bmake tries to execute @libbsd.so
  > rather than forcibly removing it.
  > 
  > I wouldn't strictly consider this a bug, as much as a portability
  > concern, especially considering freedesktop doesn't mention gmake as a
  > dependency for libbsd. This further reinforces my previous impression of
  > libbsd being very linux-centric and hardly tested outside of Linux, in
  > open contrast with the supposed goals of the project.
  > 
  > I've committed a very simple a patch to wip/libbsd to address the
  > problem (replacing $(RM) with `rm -f'in that single line) . Now libbsd
  > works just as expected, at least with my packages.  Another way to
  > address to problem would be to redefine pkgsrc's RM in the package
  > Makefile and pass it to libbsd as a MAKEFLAG. Or add gmake to USE_TOOLS.
  > Which approach is considered best? 
  > 
  > Putting the other considerations made in this thread temporarily aside I
  > now consider libbsd (+libmd) ready to import. 
  > 
  > [1] 'Switch md5 compatibility logic back to direct linking' \
  > https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888
  > 
  > [2] https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
  > 
  > -- 
  > ----------------------------+----------------------------
  > vms[-at]retrobsd.ddns.net   |   https://retrobsd.ddns.net
  > 


 On Fri, Jul 08, 2022 at 04:46:29PM +0200, Paolo Vincenzo Olivo wrote:
  > On 22/07/03 07:50PM, David H. Gutteridge wrote:
  > >  
  > >  Something to think about with both libbsd and libmd is if they should
  > >  provide proper built-in detection. libbsd has an attempt at it, but
  > >  seems wrong to me, as it doesn't work on BSDs. (I guess the assumption
  > >  is that no one would choose to build it in that context, and depending
  > >  packages would conditionally handle this.
  > 
  > Yes, I haven't touched the original builtin.mk of libbsd-0.10.0. Indeed,
  > it only checks if libbsd is already available on the host system.
  > There's no wrapper to test supported functions/calls and verify their
  > compatibility} with those provided by libbsd.  
  > 
  > My take? Somebody more experienced than me could look at the libbsd code
  > and port whatever function is lacking to libncompat. Then all packages
  > relying on libbsd could have a conditional to include the required
  > headers whenever `HAVE_NBCOMPAT_H' is defined. 
  > 
  > NetBSD could for example benefit from having compatibility for
  > explicit_bzero(), readpassprhase(), strtofflags(), pledge(),
  > freezero(), and recallocarray(). iAtthe same time, libbsd includes
  > support for NetBSD-specific functions like strtoi() and strtou(), and
  > uses NetBSD's vins/unvis.
  > 
  > > though they don't seem to entirely consistently or correctly, e.g.,
  > > audio/rtunes or graphics/scrot.)
  > 
  > The packages currently depending on libbsd usually only include
  > libbsd's buildlnk3.mk if the target platform is either Linux or
  > different from *BSD. No clear standardised behavior. Undefined *BSD is a
  > too generic assumption and not very robust imho. It works with older
  > packages, but not with new software designed on and for any of the BSDs,
  > which typically relies on system-specific features, making it non
  > portable across BSDs. Packages currently requiring libbsd on Linux are
  > usually tools ported from OpenBSD, and sometimes from other BSDs. It's
  > not like they will simply compile on NetBSD without patches. 
  > 
  > A major shortcoming of linking to libbsd anywhere outside of *BSD (which
  > is for example what audio/rtunes does), is that the target platform may
  > not need libbsd as much as Linux does or not need it at all. This is the
  > case of illumos for example, and to a good extent, Solaris 11. libbsd
  > won't compile here.  macOS is an exception (libbsd can be found in
  > MacPorts), but this is probably the consequence of a stronger focus and
  > attention to the platform. 
  > 
  > I think this thread as a whole raises the question about the potential
  > need of a reworked userspace shim for BSD functions capable of building
  > on NetBSD first, and other platforms later on.
  > 
  > >  Trying to build the current libbsd 0.10 on NetBSD 9.99.97/amd64 fails
  > >  with:
  > >  
  > >  In file included from arc4random.c:33:
  > >  ../include/bsd/unistd.h:62:6: error: conflicting types for 'closefrom'
  > >      62 | void closefrom();
  > >         |      ^~~~~~~~~
  > >  In file included from ../include/bsd/unistd.h:31,
  > >                    from arc4random.c:33:
  > >  /usr/include/unistd.h:329:6: note: previous declaration of 'closefrom' 
  > >  was here
  > >     329 | int  closefrom(int);
  > >         |      ^~~~~~~~~
  > >  *** [arc4random.lo] Error code 1
  > >  
  > >  make[2]: stopped in 
  > >  /home/disciple/pkgsrc/devel/libbsd/work/libbsd-0.10.0/src
  > >  1 error
  > >  
  > >  I see you found the same, and it sounds like it may be complicated to
  > >  resolve.
  > 
  > 
  > Yes, and pretty much any other function will have some conflicting
  > declaration. I had come to the point of successfully building arc4random
  > and getopt, but then gave up in front of the fact the rest also required a
  > non-negligible amount of work (at least for me). 
  > 
  > An alternative approach would be to try to compile only what's needed on
  > NetBSD (as I did for wip/signify, but it was a much simpler package).
  > 
  > >  Built-in handling for libmd would be a bit more complicated, I think,
  > >  given there are more OSes involved (and SunOS variants, perhaps).
  > 
  > It would; however libmd is a very small package and compiles fast, even
  > on SunOS (tested). So the effort required for a homebrew library could
  > be spared?
  > 
  > >  I'd prefer it to have a working built-in guard, as above, but that may
  > >  be non-trivial. Others may have a different opinion than me.
  > 
  > I'm fine with them staying in wip, as long as they work on Linux.
  > Platform-specific stuff doesn't really fit pkgsrc.
  > 
  > >  Sure, though I don't see many actual dependencies in pkgsrc itself, and
  > >  presumably 0.10 satisfies them all (no idea), so I don't see a
  > >  particular urgency to this, personally. It's a nice to have. (Maybe I'm
  > >  missing something?) Please don't get me wrong, certainly the efforts
  > >  you're making are appreciated!
  > 
  > Oh, sure, I simply notified it,in light of the relevant TODO note in
  > pkgsrc and the fact you asked me about getting te latest version in
  > repo. I was playing at packaging a couple of things which required
  > libbsd>=0.11.0, and that's why I started the thread in the first place.
  > 
  > The only possibly relevant package to require libbsd>=0.11.0 and libmd
  > is the portable version of the got VCS from OpenBSD (wip/got-portable),
  > which I packaged a while ago and works fine on Linux as long as these
  > dependencies are satisfied. It should be noted, however, that  the
  > package builds just fine on NetBSD without neither libbsd nor libmd and
  > so so does on Darwin.
  > 
  > Then again, I'm perfectly fine with libbsd 0.11.6 staying in wip, given
  > the very small amount of packages requiring it. My objective was to get
  > a working up to date version in pkgsrc, and apparently this is the case
  > now (albeit it needs testing)
  > 
  > Side Note: as far as I cant tell net/ucspi-tools is the only
  > optionally-libbsd-dependent package which builds on Linux. I remember 
  > having some issue with graphics/scrot, which I worked out with a local
  > patch. 
  > 
  > >  Yes, I noticed the entry was wrong for the package, too. It looks like
  > >  it should actually list four or five different licenses, similar to
  > >  what you've done for libmd.
  > 
  > To be 100% honest, I find this license (and other similar, like wtf),
  > just a way to complicate the life of whomever wants to use author's code
  > and implement it in a differently licensed project. The developer may
  > just stick with 2-CLAUSE-BSD if complete freedom and minimalism are the
  > goal, since the license is well-known, broadly adopted and has no
  > pending compliance evaluation on it. I haven't investigated further in
  > this topic, but I think that, since all Linux distros provide libbsd and
  > libmd binaries, it should really be a concern.  
  > 
  > Kindest Regards,
  > PVO
  > 
  > -- 
  > ----------------------------+----------------------------
  > vms[-at]retrobsd.ddns.net   |   https://retrobsd.ddns.net
  > 

From: "David H. Gutteridge" <david@gutteridge.ca>
To: Gnats Bugs <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: pkg/56906: libbsd: update devel/libbsd to 0.11.0
Date: Thu, 14 Jul 2022 21:53:48 -0400

 One very minor thing has been taken care of: I've added Beer-Ware to the
 list of default acceptable licenses.

 Dave

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.