On Mon, Jan 22, 2024 at 6:22 AM John Paul Adrian Glaubitz wrote:

On Fri, 2024-01-19 at 13:56 +0100, Ana Guerrero Lopez via openSUSE Factory wrote:

...

The %patch one is rather simple and results in a build failure; monitoring your devel packages should give you hints very soon if your package is impacted. We created submit requests for most, if not all, packages affected by that in the last months.

Shouldn't this be extended to sources as well? There can be more than one Source entry after all and Source will work as well as Source0, Source1, Source2 etc.

I'm not sure I understand the reasoning behind this change. It will result in unnecessary FTBFS.

The point of this change is so that %PATCHN can eventually behave like %SOURCEN (point to the path of the patch file) rather than being masked by a macro that applies the patch. It also allows %prep to be a completely normal scriptlet like the other phases. This warning has been emitted since RPM 4.18, too. And it doesn't affect you if you use %autosetup or %setup + %autopatch. -- 真実はいつも一つ！/ Always, there's only one truth!

On Fri, Feb 2, 2024 at 3:03 PM Ana Guerrero Lopez wrote:

Dear community,

In case you didn't update your Tumbleweed systems yet, RPM 4.19.1 was accepted earlier this week.

As outlined below, some packages will still need updates.

Have a nice weekend!

Ana

On 19/01/2024 13:56, Ana Guerrero Lopez wrote:

...

Dear Tumbleweed hackers and packagers,

After a lengthy staging period, RPM 4.19 is shaping up and all issues noticed in the rings (packages guaranteed to build/be installable) have been addressed or have fixes pending.

As you are all aware, the rings cover only about 20% of the packages in Factory.

The release notes for RPM 4.19 are at https://rpm.org/wiki/Releases/4.19.0

Out of the RPM release notes (https://rpm.org/wiki/Releases/4.19.0) the two most noteworthy bullets are:

* Any non-root ownership in the %files section (through %attr() or %defattr()) now generates an automatic dependency on the named user and/or group. This dependency can be satisfied by another package shipping a sysusers.d(5) file or the /etc/passwd and /etc/group files themselves. Existing packages shipping any of these files will have to be rebuilt with RPM 4.19 in order for them to carry the respective user and/or group provides. This may require distro-level coordination to ensure proper installation of all the affected packages. For more information, please consult the manual.

* %patch without arguments (previously an alias to %patch 0) is now a build error (use %patch N instead)

The %patch one is rather simple and results in a build failure; monitoring your devel packages should give you hints very soon if your package is impacted. We created submit requests for most, if not all, packages affected by that in the last months.

The story around the users can be trickier to be identified, as the build might succeed, but the package not being installable at the end due to missing dependencies reported. This usually happens when users are generated in %pre scripts using useradd. Either convert those packages to use sysusers.d (https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups) or, as a quickest measure, usually helpful if no other package relies on the same users, manually add the respective Provides: user(USERNAME) and Provides: group(GROUPNAME) to the package generating the relevant user (as done for example in cluster-glue, https://build.opensuse.org/request/show/1138101 for reference)

If you have any questions or need with your package, the opensuse-packaging mailing list is always at your disposal.

Also, if you use "%patchN", please switch to "%patch -P N" or if you can, replace all your %patch calls with %autopatch (or replace %setup + %patch with %autosetup). -- 真実はいつも一つ！/ Always, there's only one truth!

On Fri, 2024-02-02 at 16:02 +0100, Ana Guerrero Lopez via openSUSE Factory wrote:

Dear community,

In case you didn't update your Tumbleweed systems yet, RPM 4.19.1 was accepted earlier this week.

As outlined below, some packages will still need updates.

Have a nice weekend!

AS iformed by Ana, RPM 4.19 adds a dependency on user/group whenever the package installs file as non-root. Factory has just received a larger rebuild due to glibc 2.39 and python 3.12 addition - which in turn also uncovered a lot of missing user/group provides. So far I have found this list:

grep -P "(user|group)" rebuildpacs.openSUSE\:Factory-standard.yaml | sed "s/needed by.*//g" | sort -u - nothing provides group(amanda) - nothing provides group(atheme) - nothing provides group(bird) - nothing provides group(bitcoin) - nothing provides group(bitlbee) - nothing provides group(boinc) - nothing provides group(caddy) - nothing provides group(_cscreen) - nothing provides group(davfs2) - nothing provides group(ddclient) - nothing provides group(dehydrated) - nothing provides group(dlt-daemon) - nothing provides group(dnscrypt) - nothing provides group(dnsdist) - nothing provides group(dochazka-rest) - nothing provides group(dochazka-www) - nothing provides group(etcd) - nothing provides group(firejail) - nothing provides group(fonehome) - nothing provides group(galene) - nothing provides group(ganesha) - nothing provides group(gerbera) - nothing provides group(git) - nothing provides group(_gns3) - nothing provides group(greeter) - nothing provides group(guixbuild) - nothing provides group(hsqldb) - nothing provides group(hyperkitty) - nothing provides group(i2pd) - nothing provides group(icecast) - nothing provides group(icecream) - nothing provides group(icingaweb2) - nothing provides group(influxdb) - nothing provides group(iouyap) - nothing provides group(janus) - nothing provides group(kanku) - nothing provides group(keadhcp) - nothing provides group(keepalived) - nothing provides group(lighttpd) - nothing provides group(mailman) - nothing provides group(minetest) - nothing provides group(monero) - nothing provides group(mosquitto) - nothing provides group(motion) - nothing provides group(mtail) - nothing provides group(nagcmd) - nothing provides group(nagios) - nothing provides group(netdata) - nothing provides group(nfdump) - nothing provides group(_nsd) - nothing provides group(opendkim) - nothing provides group(orthos) - nothing provides group(owntone) - nothing provides group(pkcs11) - nothing provides group(privoxy) - nothing provides group(prosody) - nothing provides group(ptokax) - nothing provides group(quasselcore) - nothing provides group(rabbitmq) - nothing provides group(radiusd) - nothing provides group(restund) - nothing provides group(shibd) - nothing provides group(solanum) - nothing provides group(strelaysrv) - nothing provides group(tomcat) - nothing provides group(tor) - nothing provides group(toxcmd) - nothing provides group(transmission) - nothing provides group(tryton) - nothing provides group(usbauth) - nothing provides group(usbauth-notifier) - nothing provides group(vacation) - nothing provides group(varnish) - nothing provides group(xonotic) - nothing provides group(zabbix) - nothing provides group(zabbixs) - nothing provides group(znc) - nothing provides user(amanda) - nothing provides user(atheme) - nothing provides user(bird) - nothing provides user(bitcoin) - nothing provides user(bitlbee) - nothing provides user(boinc) - nothing provides user(caddy) - nothing provides user(cntlm) - nothing provides user(_cscreen) - nothing provides user(davfs2) - nothing provides user(ddclient) - nothing provides user(dehydrated) - nothing provides user(dlt-daemon) - nothing provides user(dnscrypt) - nothing provides user(dnsdist) - nothing provides user(dochazka-rest) - nothing provides user(dochazka-www) - nothing provides user(etcd) - nothing provides user(fax) - nothing provides user(fonehome) - nothing provides user(galene) - nothing provides user(ganesha) - nothing provides user(gerbera) - nothing provides user(git) - nothing provides user(_gns3) - nothing provides user(greeter) - nothing provides user(hsqldb) - nothing provides user(hyperkitty) - nothing provides user(i2pd) - nothing provides user(icecast) - nothing provides user(icecream) - nothing provides user(icingadirector) - nothing provides user(influxdb) - nothing provides user(janus) - nothing provides user(kankurun) - nothing provides user(keadhcp) - nothing provides user(keepalived) - nothing provides user(lighttpd) - nothing provides user(mailman) - nothing provides user(mednafen) - nothing provides user(minetest) - nothing provides user(monero) - nothing provides user(mosquitto) - nothing provides user(mpd) - nothing provides user(nagios) - nothing provides user(netdata) - nothing provides user(nfdump) - nothing provides user(_nsd) - nothing provides user(opendkim) - nothing provides user(orthos) - nothing provides user(owntone) - nothing provides user(postgrey) - nothing provides user(privoxy) - nothing provides user(prosody) - nothing provides user(ptokax) - nothing provides user(quasselcore) - nothing provides user(rabbitmq) - nothing provides user(radiusd) - nothing provides user(_rmt) - nothing provides user(shibd) - nothing provides user(siproxd) - nothing provides user(solanum) - nothing provides user(strelaysrv) - nothing provides user(stunnel) - nothing provides user(tinyproxy) - nothing provides user(tomcat) - nothing provides user(tor) - nothing provides user(tox) - nothing provides user(transmission) - nothing provides user(tryton) - nothing provides user(varnish) - nothing provides user(vnstat) - nothing provides user(xonotic) - nothing provides user(znc)

If you spot a user which belongs to one of your packages, please pick it up and provide a fix for it (packages will be uninstallable by zypper until fixed) Cheers, Dominique

On Sat, 2024-02-03 at 12:18 +0100, mcepl@cepl.eu wrote:

On 2024-02-03 11:59, Dominique Leuenberger wrote:

...

If you spot a user which belongs to one of your packages, please pick it up and provide a fix for it (packages will be uninstallable by zypper until fixed)

Is there some quick HOWTO for creating a group? Where should it be done? For example, if I see here missing group(bitlbee), I guess it should be provided package bitlbee, right? Is it enough just to add `Provides: group(bitlbee)` to metadata?

There are two ways: * package generates user/groups by manually calling useradd/groupadd in a pre script. Then the package needs to provide the user/group symbols * using sysusers.d (preferred way) a drop in file is installed and the user/group be generated by sysuser_generator https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups All that are currently on the list use the manual useradd/groupadd method - or RPM would have auto-detected the provides based on the sysusers drop-in files. I'd say: if time is limited, add the provides, if time permits, migrate the package to sysusers.d. Cheers, Dominique

On Monday 2024-02-05 14:52, Martin Wilck via openSUSE Factory wrote:

...

https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups

While we're at it, would it make sense to create something like an UID/GID registry and assign fixed UID/GID numbers to some system users and groups?

That was done 25 years ago and it did not prevail even then. https://github.com/openSUSE/aaa_base/ e.g. commit 5d7a12d8ce9e48606a027bd2fbbe5c932246b184

On Sat, 2024-02-03 at 12:24 +0100, Axel Braun via openSUSE Factory wrote:

Hi Dominique, that Fix goes into a github project, right? Viele Grüße Axel

I'm not sure I understand the question: all fixes on our packages are done in OBS in the spec files (some few packages use the new OBS/SCM way, but that's far from the norm) Cheers, Dominique

On Saturday 2024-02-03 11:59, Dominique Leuenberger wrote:

...

Dear community,

In case you didn't update your Tumbleweed systems yet, RPM 4.19.1 was accepted earlier this week.

As outlined below, some packages will still need updates.

Factory has just received a larger rebuild due to glibc 2.39 and python 3.12 addition - which in turn also uncovered a lot of missing user/group provides.

There is a different problem with py3.12, too: security:forensics/lib* does a multipython build, which errors out with ... [ 43s] make[2]: Entering directory '/home/abuild/rpmbuild/BUILD/libevt-20240203/pyevt' [ 43s] /usr/bin/mkdir -p '/home/abuild/rpmbuild/BUILD/rtpython312_bin_suffix/usr/' [ 43s] /usr/bin/bash ../libtool --mode=install /usr/bin/install -c pyevt.la '/home/abuild/rpmbuild/BUILD/rtpython312_bin_suffix/usr/' [ 43s] libtool: error: error: cannot install 'pyevt.la' to a directory not ending in /usr/ That only seems to happen with python 3.12 && security:forensics, and the error message does not even make sense, of course it ends in usr/.

Am 05.02.24 um 09:52 schrieb Andreas Schwab:

On Feb 03 2024, Jan Engelhardt wrote:

...

There is a different problem with py3.12, too:

security:forensics/lib* does a multipython build, which errors out with

... [ 43s] make[2]: Entering directory '/home/abuild/rpmbuild/BUILD/libevt-20240203/pyevt' [ 43s] /usr/bin/mkdir -p '/home/abuild/rpmbuild/BUILD/rtpython312_bin_suffix/usr/' [ 43s] /usr/bin/bash ../libtool --mode=install /usr/bin/install -c pyevt.la '/home/abuild/rpmbuild/BUILD/rtpython312_bin_suffix/usr/' [ 43s] libtool: error: error: cannot install 'pyevt.la' to a directory not ending in /usr/

That only seems to happen with python 3.12 && security:forensics, and the error message does not even make sense, of course it ends in usr/. It is the trailing slash that apparently confuses it, but then the library directory should be /usr/lib or /usr/lib64, not /usr. Looks like the expansion of a variable with an empty value.

Correct. (There must be some copy and paste error. The current build log of libevt does not have the unexpanded python312_bin_suffix in that path: [ 60s] /usr/bin/bash ../libtool --mode=install /usr/bin/install -c pyevt.la '/home/abuild/rpmbuild/BUILD/rt/usr/' [ 60s] libtool: error: error: cannot install 'pyevt.la' to a directory not ending in /usr Compare to the python3.10 iteration before: [ 44s] /usr/bin/mkdir -p '/home/abuild/rpmbuild/BUILD/rt/usr/lib64/python3.10/site-packages' [ 44s] /usr/bin/bash ../libtool --mode=install /usr/bin/install -c pyevt.la '/home/abuild/rpmbuild/BUILD/rt/usr/lib64/python3.10/site-packages' So don't let yourself mislead you by the bogus error message. The real problem is that python 3.12 removed distutils from the standard library. Upstream's python autoconf macro depends on it. It's all either solved by replacing distutils.sysconfig with sysconfig [1] or providing distutils from setuptools in the interim [2].  - Ben [1] https://github.com/libyal/libbde/pull/68 [2] https://build.opensuse.org/request/show/1143980

On Sat, Feb 03, 2024 at 11:59:24AM +0100, Dominique Leuenberger wrote:

On Fri, 2024-02-02 at 16:02 +0100, Ana Guerrero Lopez via openSUSE Factory wrote:

...

Dear community,

In case you didn't update your Tumbleweed systems yet, RPM 4.19.1 was accepted earlier this week.

As outlined below, some packages will still need updates.

Have a nice weekend!

AS iformed by Ana, RPM 4.19 adds a dependency on user/group whenever the package installs file as non-root.

Factory has just received a larger rebuild due to glibc 2.39 and python 3.12 addition - which in turn also uncovered a lot of missing user/group provides.

So far I have found this list:

...

grep -P "(user|group)" rebuildpacs.openSUSE\:Factory-standard.yaml | sed "s/needed by.*//g" | sort -u

- nothing provides group(git)

What requires it, though? Thanks Michal

On Feb 05 2024, Michal Suchánek wrote:

On Sat, Feb 03, 2024 at 11:59:24AM +0100, Dominique Leuenberger wrote:

...

So far I have found this list:

...

grep -P "(user|group)" rebuildpacs.openSUSE\:Factory-standard.yaml | sed "s/needed by.*//g" | sort -u

...

- nothing provides group(git)

What requires it, though?

You can look it up in https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashbo... -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

On Sat, Feb 03, 2024 at 11:59:24AM +0100, Dominique Leuenberger wrote:

On Fri, 2024-02-02 at 16:02 +0100, Ana Guerrero Lopez via openSUSE Factory wrote:

...

Dear community,

In case you didn't update your Tumbleweed systems yet, RPM 4.19.1 was accepted earlier this week.

As outlined below, some packages will still need updates.

Have a nice weekend!

AS iformed by Ana, RPM 4.19 adds a dependency on user/group whenever the package installs file as non-root.

Factory has just received a larger rebuild due to glibc 2.39 and python 3.12 addition - which in turn also uncovered a lot of missing user/group provides.

So far I have found this list:

...

grep -P "(user|group)" rebuildpacs.openSUSE\:Factory-standard.yaml | sed "s/needed by.*//g" | sort -u

- nothing provides group(ddclient)

FWIW this shows off pretty much everything that would be possibly needed except custom group. Comments welcome https://build.opensuse.org/request/show/1144178 Thanks Michal

On Mon, Feb 05, 2024 at 11:24:33PM -0600, Paul Lipps via openSUSE Factory wrote:
> 
> 
> > On Feb 3, 2024, at 4:59 AM, Dominique Leuenberger  wrote:
> > 
> > So far I have found this list:
> > 
> >> grep -P "(user|group)" rebuildpacs.openSUSE\:Factory-standard.yaml |
> > sed "s/needed by.*//g" | sort -u
> >    - nothing provides group(amanda) 
> >    - nothing provides group(atheme) 
> >    - nothing provides group(bird) 
> >  snip
> >    - nothing provides user(znc) 
> > 
> > If you spot a user which belongs to one of your packages, please pick
> > it up and provide a fix for it (packages will be uninstallable by
> > zypper until fixed)
> 
> 
> 
> Are items on this list being addressed? I ask because I am a user of znc, and I’m not sure if I need to open a bug or report this elsewhere.

various volunteers are going over the list. znc fix is already submitted for
instance.

Ciao, Marcus