January 2024 - openSUSE Packaging - openSUSE Mailing Lists

python311-kombu blocked by missing python311-boto3 in devel:languages:python
by Keil 04 Apr '24

04 Apr '24

Hi, currently python311-kombu does not build in the devel project because it misses python311-boto3, which is only built for plain python3. This makes python311-celery in turn uninstallable in 15.5 or 15.6 as this directly translates to devel:languages:python or :backports respectively. All build fine in Factory. I'm happy to raise this anywhere else, it just wasn't obvious to me where this fits best. Best regards, Christian

5 13

False positive: update-alternatives-postun-call-missing in rubygem package?
by Johannes Kastl 04 Feb '24

04 Feb '24

Hi all, I packaged rubygem-krane recently, but could not get rid of one error in rpmlint: > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_de… > [ 11s] ruby3.2-rubygem-krane.x86_64: E: update-alternatives-postun-call-missing > [ 11s] The package does not call update-alternatives --remove in postun phase to > [ 11s] remove all the configuration for each individual --install binary that was > [ 11s] done in postun. Not sure if this is a false positive, as there is a call to update-alternatives in %postun: > %postun > update-alternatives --remove krane %{_bindir}/krane Or is there something wrong with this one (that I copied from another package using update-alternatives? Kind Regards, Johannes P.S.: Have a merry christmas y'all!

3 4

Re: RPM 4.19 soon in Factory (packaging changes inside)
by John Paul Adrian Glaubitz 22 Jan '24

22 Jan '24

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

4 4

Re: RPM 4.19 soon in Factory (packaging changes inside)
by Callum Farmer 19 Jan '24

19 Jan '24

On Fri, 19 Jan 2024, 12:57 Ana Guerrero Lopez via openSUSE Factory, < factory(a)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(a)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 > >

1 0

Re: RPM 4.19 soon in Factory (packaging changes inside)
by Ana Guerrero Lopez 19 Jan '24

19 Jan '24

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

1 0