RPM 4.19 soon in Factory (packaging changes inside)
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. Ana, on behalf of the Release Team
On Fri, 19 Jan 2024, 12:57 Ana Guerrero Lopez via openSUSE Factory, < factory@lists.opensuse.org> 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.
* 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
It doesn't have to be another package, it can be the same one. Another package is only needed if another package needs the same user/group aswell then it'll need to be seperated to prevent duplication which would cause duplicate provides which would upset RPM.
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)
Ideally, migrate it to sysusers.d, the process is listed at the page Ana pointed to above which I've attempted to make as clear as possible
If you have any questions or need with your package, the opensuse-packaging mailing list is always at your disposal.
Yep, any help needed with migration I'll be available to help, post to openSUSE Packaging (packaging@lists.opensuse.org) and I'll see it unless someone else manages to help before I get to it if I'm busy. Callum F
Ana,
on behalf of the Release Team
On 19/01/2024 13.56, Ana Guerrero Lopez via openSUSE Factory wrote:
After a lengthy staging period, RPM 4.19 is shaping up
As you are all aware, the rings cover only about 20% of the packages in Factory.
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.
some SRs were missing https://build.opensuse.org/request/show/1140031 garlic (forward) 1140032 docbook2x 1140034 perl-GD-Graph3d 1140035 perl-Net-OpenID-Consumer 1140036 perl-XML-SAX-ExpatXS 1140037 python-leveldb 1140038 python-pydocumentdb 1140039 fcitx-zhuyin 1140040 fcitx-skk 1140041 fcitx-rime 1140042 fcitx-kkc 1140043 fcitx-configtool 1140044 fcitx-chewing 1140045 emacs-flim 1140046 emil (forward to Factory) 1140047 khunphan 1140048 perl-BIND-Conf_Parser 1140049 perl-Boost-Geometry-Utils 1140050 perl-Mozilla-LDAP 1140051 perl-Net-Jabber and some are still pending 1123611 authbind 1123809 notify-sharp3 1123814 pbm2l7k I found these with a git grep "^%patch$" git grep "^%patch "|grep -v -e -P -e ' 0' in a checkout of https://github.com/bmwiedemann/openSUSE/ Ciao Bernhard M.
On Fri, Jan 19, 2024 at 9:47 PM Bernhard M. Wiedemann via openSUSE Factory <factory@lists.opensuse.org> wrote:
On 19/01/2024 13.56, Ana Guerrero Lopez via openSUSE Factory wrote:
After a lengthy staging period, RPM 4.19 is shaping up
As you are all aware, the rings cover only about 20% of the packages in Factory.
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.
some SRs were missing https://build.opensuse.org/request/show/1140031 garlic (forward) 1140032 docbook2x 1140034 perl-GD-Graph3d 1140035 perl-Net-OpenID-Consumer 1140036 perl-XML-SAX-ExpatXS 1140037 python-leveldb 1140038 python-pydocumentdb 1140039 fcitx-zhuyin 1140040 fcitx-skk 1140041 fcitx-rime 1140042 fcitx-kkc 1140043 fcitx-configtool 1140044 fcitx-chewing 1140045 emacs-flim 1140046 emil (forward to Factory) 1140047 khunphan 1140048 perl-BIND-Conf_Parser 1140049 perl-Boost-Geometry-Utils 1140050 perl-Mozilla-LDAP 1140051 perl-Net-Jabber
and some are still pending 1123611 authbind 1123809 notify-sharp3 1123814 pbm2l7k
I found these with a git grep "^%patch$" git grep "^%patch "|grep -v -e -P -e ' 0' in a checkout of https://github.com/bmwiedemann/openSUSE/
Please take the opportunity to evaluate moving to "%autosetup" or "%setup + %autopatch" instead of maintaining manual "%patch" calls. It's far less error-prone. -- 真実はいつも一つ！/ Always, there's only one truth!
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. Adrian
On Monday 2024-01-22 12:21, John Paul Adrian Glaubitz via openSUSE Factory...:
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.
But there is no %source2 macro that would be affected, just %{SOURCE:2} (parsed differently, suppose?).
I'm not sure I understand the reasoning behind this change. It will result in unnecessary FTBFS.
AIUI, %patch2 and %patch3 are technically two different macros, which $sucks, and the parser had to take turns and twists to recognize them as one and the same (well, %patch -P 2 vs %patch -P 3).
On Mon, Jan 22, 2024 at 6:22 AM John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> 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, Jan 19, 2024 at 01:56:19PM +0100, Ana Guerrero Lopez via openSUSE Factory 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.
Would be nice to extend the automatic dependencies to udev rules. These are the major user of non-default ownership besides shipped files. Not sure how this works eg. for systemd sockets. Thanks Michal
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.
Ana,
on behalf of the Release Team
Hello Python packagers, Ana used the RPM 4.19.1 release as last blocker for the python312 flavor as well. All packages in Ring1 have been fixed in time, but the rest of the universe is being rebuilt just now. If your package is not compatible with Python 3.12 yet, don't be afraid to `%define skip_python312 1`. But please keep in mind that this will also be required for all consuming packages which depend on yours. And of course we will have to remove it before python312 becomes the primary python. Regards, Ben Am 02.02.24 um 16:02 schrieb Ana Guerrero Lopez via openSUSE Factory:
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 Fri, Feb 2, 2024 at 3:03 PM Ana Guerrero Lopez <ana.guerrero@suse.com> 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, 02 Feb 2024, 17:03:14 +0100, Neal Gompa wrote:
[...] Also, if you use "%patchN", please switch to "%patch -P N"
Mind to explain *why*?
or if you can, replace all your %patch calls with %autopatch (or replace %setup + %patch with %autosetup).
I totally agree with this, but it might need to regenerate patches due to different prefixes. Cheers. l8er manfred
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 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? Best, Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 We understand our competition isn’t with Caldera or SuSE--our competition is with Microsoft. -- Bob Young of Red Hat http://www.linuxjournal.com/article/3553
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 Sat, 2024-02-03 at 12:27 +0100, Dominique Leuenberger wrote:
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
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 would be very helpful for any kind of setup where files are shared between different hosts, e.g. via NFS. Regards Martin
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
Hi Dominique, that Fix goes into a github project, right? Viele Grüße Axel -- Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet. Am 3. Februar 2024 11:59:24 MEZ schrieb Dominique Leuenberger <dimstar@opensuse.org>: >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: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
Am Samstag, 3. Februar 2024, 12:35:44 CET schrieben Sie:
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)
Some years ago I had to register user/group tryton in a githb project. Not sure it was about rpmlint checks? So I'm surprised to see tryton again in that list Cheers Axel
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/.
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. -- 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."
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
Dominique Leuenberger <dimstar@opensuse.org> writes:
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:
I found another missing group: Problem: nothing provides 'group(plugdev)' needed by the to be installed pmount-0.9.99alpha-3.232.x86_64 Cheers Berthold
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 Mon, 2024-02-05 at 10:53 +0100, Michal Suchánek wrote:
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?
zypper se --requires "group(git)" Loading repository data... Reading installed packages...
S | Name | Summary | Type --+----------+------------------------------------------+-------- | gitolite | Server for git directory version tracker | package The reson is to be found in gitolite.spec: %define git_user git … %config(noreplace) %attr(640,%{git_user},%{git_user}) %{gitolite_homedir}/.ssh/authorized_keys i.e RPM is supposed to install a file to be owned by user/group git (and, as announced, RPM takes this info to formulate an automatic dependency to ensure that user/group exists). Cheers, Dominique
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 Mon, Feb 05, 2024 at 11:04:55AM +0100, Andreas Schwab wrote:
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...
Thanks. It's not always clear to which package the user/group belongs. In this case the git package uses the user git-daemon, and it's properly created with sysuser-tools. Michal
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 Feb 3, 2024, at 4:59 AM, Dominique Leuenberger <dimstar@opensuse.org> 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. Thank you, Paul -- "Anyone who is unwilling to learn is entitled to absolutely nothing." - graysonf
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 <dimstar@opensuse.org> 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
participants (18)
-
Ana Guerrero Lopez -
Andreas Schwab -
Axel Braun -
Axel Braun -
Ben Greiner -
Bernhard M. Wiedemann -
Berthold Höllmann -
Callum Farmer -
Dominique Leuenberger -
Jan Engelhardt -
John Paul Adrian Glaubitz -
Manfred Hollstein -
Marcus Meissner -
Martin Wilck -
mcepl＠cepl.eu -
Michal Suchánek -
Neal Gompa -
Paul Lipps