- openSUSE Packaging

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

Re: RPM 4.19 - first list of missing user provides
by Andreas Schwab 05 Feb '24

05 Feb '24

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/dashb… -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

1 0

Re: RPM 4.19 - first list of missing user provides
by Dominique Leuenberger 05 Feb '24

05 Feb '24

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

1 0

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