February 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

Handling mutually excluding alternatives
by Adam Mizerski 27 Feb '24

27 Feb '24

Hi, I wanted to push sequoia-octopus-librnp to Factory. It's a replacement for Thunderbird's default openpgp implementation. It works by being a drop-in replacement for a shared library librnp.so. What I want to achieve: - MozillaThunderbird-openpgp-librnp and sequoia-octopus-librnp are mutually exclusive - MozillaThunderbird-openpgp-librnp should always be preferred over sequoia-octopus-librnp, unless user explicitly wants it. See my WIP at https://build.opensuse.org/project/show/home:etamPL:branches:mozilla:experi… Here's what I did (just the important bits): MozillaThunderbird.spec Requires: %{name}-openpgp Recommends: %{name}-openpgp-librnp %package openpgp-librnp Provides: %{name}-openpgp Conflicts: %{name}-openpgp sequoia-octopus-librnp.spec Provides: MozillaThunderbird-openpgp Conflicts: MozillaThunderbird-openpgp And it works. Even on a fresh system "zypper in --no-recommends MozillaThunderbird" pulls MozillaThunderbird-openpgp-librnp, but I'm not quite sure if it's something I can rely on. With "--no-recommends" how is zypper choosing MozillaThunderbird-openpgp-librnp over sequoia-octopus-librnp?

3 5

After RPM is before RPM - Changes needed for RPM 4.20
by Dominique Leuenberger 24 Feb '24

24 Feb '24

Dear Tumbleweed hackers and packagers, It is just a few days ago that Factory was updated to RPM 4.19 (and we are still missing a few fixes for packages requiring user() symbols and not providing them) The next RPM version will come - for sure (if previous release cycles are any indication, RPM 4.20 should be out around September) So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. The preferred way to apply patches are, in order: * %autosetup -p1 * %autosetup -N / %autopatch -p1 * %setup / %patch -P <N> -p 1 (upper case P denotes patch number, lower case is the usual patch -p>num> strip level) * If your package has no patches, best to be prepared for the future and use %autosetup over %setup. Technically, RPM preferred would be %setup / %patch N when not using %autosetup/%autopatch, BUT %patch 1 is only supported properly from RPM 4.18 on, Not behaving as expected on older RPMs, like in Leap 15.x. That's why we switched our packages to the backward compatible form %patch -P 1 I (and some others) have started to go through the openSUSE:Factory packages that apply patches using %patchN (found a total of 2066 packages). About 10% of those have been fixed today with SRs to the development projects. I would appreciate it if you'd take a look at your packages over the next few days/weeks/months and adjust them to use autosetup or, if patches are applied conditionally, use the %patch -P N format. Cheers, Dominique

3 2

rubygem packaging: macro for the gems path?
by Johannes Kastl 10 Feb '24

10 Feb '24

Hi all, to silence some of the warnings on the rubygem-krane package I added the following to the gem2rpm.yml file: > :post_install: |- > cd %{buildroot}%{_libdir}/ruby/gems/3.3.0/gems/krane-%{version}/ > rm -rvf .github > rm -vf .gitignore > rm -vf .rubocop-http---shopify-github-io-ruby-style-guide-rubocop-yml > rm -vf .rubocop.yml > sed -i 's|usr/bin/env bash|usr/bin/bash|g' bin/setup > sed -i 's|usr/bin/env bash|usr/bin/bash|g' dev/flamegraph-from-tests > https://build.opensuse.org/package/view_file/home:ojkastl_buildservice:Bran… This works, but obviously only for one ruby version. Is there a convenient macro for this? I failed to find one... Or is there a wrapper macro like the python expand macro, that executes something with each ruby version that is being built? Kind Regards, Johannes

2 1

Re: patching a source outside of %{buildroot}
by Axel Braun 08 Feb '24

08 Feb '24

Hello Dominique, Am Donnerstag, 8. Februar 2024, 16:40:38 CET schrieb Dominique Leuenberger: > On Thu, 2024-02-08 at 16:16 +0100, Axel Braun wrote: > > Hi, > > I need to patch a source file in the /usr/src of the build > > environment. > > > > In absolute terms, this is in /var/tmp/build- > > root/openSUSE_Tumbleweed-x86_64/usr/src > > > > It seems that %autosetup resp %patch0 work only in %{buildroot}, > > which is /var/tmp/build-root/openSUSE_Tumbleweed- > > x86_64/home/abuild/rpmbuild/BUILDROOT/ > > > > Any idea? > > That sounds like something really bad to do for a package (and blocked > by the fact that builds do not run as root) > > Stuff that's been installed to /usr/src comes from a different package. > If this needs patching, then I'd probably target that very package that > installs the sources there. Isn't this an option? Would the patch harm > there? Its a workaround until https://bugzilla.opensuse.org/show_bug.cgi?id=1218423 is fixed. That would be the patch in the source package... > Alternaitvely, copy the stuff form /usr/src into the buildroot, patch > it and make sure your build picks it up from there. Considering you're > patching files from a different package though, the chance of it > breaking is quite high. Beside this, no idea how I make sure that the source inside the buildroot gets picked... Cheers Axel

1 0

patching a source outside of %{buildroot}
by Axel Braun 08 Feb '24

08 Feb '24

Hi, I need to patch a source file in the /usr/src of the build environment. In absolute terms, this is in /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/usr/src It seems that %autosetup resp %patch0 work only in %{buildroot}, which is /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/home/abuild/rpmbuild/BUILDROOT/ Any idea? Thanks Axel

1 0

Re: Creating a new user for Hashicorp Vault and its fork OpenBao?
by Johannes Kastl 08 Feb '24

08 Feb '24

Hi Callum, On 06.02.24 12:32 Callum Farmer wrote: > No such split is needed if the user/group is only needed by that > package, keep it in the main package. As the user would be shared by the vault and OpenBao packages, I think it makes sense to put it into a separate package. > For more information: > https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups Thanks, I'll have a look, now that the certificate is valid again... FYI, this is what I put together this morning, but will check again now: > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_se… Kind Regards, Johannes P.S.: No need for CC, I am subscribed...

3 2

Update/add package in Leap 15.5/15.6 from Tumbleweed
by code＠luigifab.fr 06 Feb '24

06 Feb '24

Hi everybody! Don't kill me, I'm lost. At Fedora level it's easier for me (40/Rawhide, 39, 38, git...). I recently pushed updates for my packages in openSUSE. for example https://software.opensuse.org/package/awf-gtk2 2.8.0 official in Tumbleweed But how to add/update it in 15.5/15.6 with official status? - is it possible? - is it automatic? - how to request on build.opensuse.org? I saw at https://repology.org/project/awf-widget-factory/versions that it seems there is already the package (old release) in Leap 15.5 even if software.opensuse.org doesn't display it. Thanks

2 3

Creating a new user for Hashicorp Vault and its fork OpenBao?
by Johannes Kastl 06 Feb '24

06 Feb '24

Hi all, I found that there is a fork of Hashicorp Vault, called OpenBao, in the works. To prepare for packaging it, I started packaging Vault (to avoid errors due to OpenBao being pre-alpha and in the middle of forking, it seems). The package seems to be working, but I require a user and group for running vault. AFAIK I need to create a package for the user, something like system-user-prometheus or system-user-wwwrun. Is there a process to request users and groups, to avoid clashes in regards to UIDs and such? The wiki gave nothing (or my search sucked...). Or do I simply omit the UID, as in the prometheus package? Thanks in advance! Puzzled, Johannes

2 1

RPM 4.19 already in Factory
by Ana Guerrero Lopez 05 Feb '24

05 Feb '24

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 > >

10 13