openSUSE Packaging December 2022

packaging@lists.opensuse.org

23 participants
10 discussions

Memory problems at build time
by Eric Schirra 25 Jan '23

25 Jan '23

Hello all, I have now noticed with a wide variety of packages that they build in OBS itself, but not locally using osc. It comes then memory error. e.g.: RangeError: WebAssembly.Instance(): Out of memory: wasm memory As said on the OBS server online the packages are built. But not locally. Does anyone know this? Do others have this problem? Is there a solution? What do I have to do then? I would be very grateful for any help. Regards Eric

6 10

spec sources with spaces in filename (rpm 4.18)
by Manfred Schwarb 25 Jan '23

25 Jan '23

Hi, In a package, I have a source file with spaces in it: Source: Mobile Atlas Creator %{version}.zip ... %prep %setup -q -c -n mobac This used to work fine, and resulted in: [ 76s] + cd /home/abuild/rpmbuild/BUILD [ 76s] + rm -rf mobac [ 76s] + /usr/bin/mkdir -p mobac [ 76s] + cd mobac [ 76s] + /usr/bin/unzip -qq '/home/abuild/rpmbuild/SOURCES/Mobile Atlas Creator 2.3.0.zip' [ 77s] + STATUS=0 But since rpm 4.18, a new tool rpmuncompress is used. This now gives: [ 38s] + cd /home/abuild/rpmbuild/BUILD [ 38s] + rm -rf mobac [ 38s] + /usr/bin/mkdir -p mobac [ 38s] + cd mobac [ 38s] + /usr/lib/rpm/rpmuncompress -x /home/abuild/rpmbuild/SOURCES/Mobile Atlas Creator 2.3.0.zip [ 38s] error: File /home/abuild/rpmbuild/SOURCES/Mobile: No such file or directory [ 38s] error: Bad exit status from /var/tmp/rpm-tmp.SgyFCX (%prep) Is this just a plain bug in rpm? Is there some recommended way to deal with spaces in filenames? TIA for advice, Manfred

3 4

Deprecating the %usrmerged macro
by Ludwig Nussel 09 Jan '23

09 Jan '23

Hi! When transitioning to usrmerged systemd we introduced the %usrmerged macro. Since there is no way back for Tumbleweed and already released distributions won't ever go for usrmerge, the macro is actually obsolete. It's sufficient to check for Tumbleweed which is usually done by checking %suse_version. So I propose to remove use of the %usrmerged macro in spec files. Of course spec files could manually set it based on %suse_version if that's convenient. Spec files just shouldn't rely on an externally set %usrmerged anymore. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)

6 8

%configure errors out on SLES12 SP5 due to --disable-dependency-tracking
by Johannes Kastl 21 Dec '22

21 Dec '22

Hi all, I just tried to build a package for SLES12SP5, but it failed during %configure. The problem is that the rpm macro, defined in /usr/lib/rpm/macros, contains the argument "--disable-dependency-tracking". Which is not recognized somehow: > [ 22s] + cd os-update-1.8 > [ 22s] + CFLAGS='-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection' > [ 22s] + export CFLAGS > [ 22s] + CXXFLAGS='-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection' > [ 22s] + export CXXFLAGS > [ 22s] + FFLAGS='-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection' > [ 22s] + export FFLAGS > [ 22s] + ./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-vendordir=/etc > [ 22s] configure: WARNING: unrecognized options: --disable-dependency-tracking, --disable-dependency-tracking If I replace the macro with the configure call from the error message, but just leave out the --disable-dependency-tracking option (that is included twice), everything builds fine. > https://build.opensuse.org/package/rdiff/home:ojkastl_buildservice:systemd-… > https://build.opensuse.org/project/show/home:ojkastl_buildservice:systemd-s… The project is standard, no funny things in prjconf. I just added the build targets via the GUI. So I am surprised that the rpm macros file contains things the configure call does not understand. For now it is fine to just hardcode this, but I wanted to report this or rather ask, if it is a bug and should be reported. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 2

Disable automatic detection of RPM dependencies from shebangs (for some files only?)
by Johannes Kastl 19 Dec '22

19 Dec '22

Hi all, TL;DR: Ist it possible to disable the automatic detection of RPM dependencies from shebangs? Maybe only for some files? Ansible is now including lots of collections, most of them are using a "#!/usr/bin/python" or "#!/usr/bin/python3" shebang. I modified the shebang for all of them to not have python2 as a dependency for the ansible package. Turns out, some of those python files in the collections need to have a python shebang (not python3), e.g. the zypper module. If I change that to python3, it does not work when managing SLES12 targets (as the python3 is too old on SLES12). But python2 is working for SLES12 targets. If I do not modify the shebang, the ansible package wants to install python2 as a dependency due to the automatic detection Can I override this? Can I somehow only ignore the dependency for python2 aka python? And leave all other dependency detections in place? Or maybe just ignore some files during dependency detection? Thanks in advance, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

3 4

New version for a python package doesn't support python3.6 -- How to build for LEAP 15.4
by Greg Freemyer 18 Dec '22

18 Dec '22

All, I'm trying to update security:forensics/python-dfVFS I've branched it to: https://build.opensuse.org/package/show/home:gregfreemyer:Tools-for-forensi… The new release builds fine for factory, but for LEAP it fails with: [ 75s] + /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s' [ 76s] Unsupported Python version: 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC], version 3.7 or higher required. [ 76s] error: Bad exit status from /var/tmp/rpm-tmp.LM9LB1 (%build) Is there a relatively easy way to get this build. I would really like to have this available for 15.4 at a minimum (in addition to factory). Thanks Greg -- Greg Freemyer Advances are made by answering questions. Discoveries are made by questioning answers. — Bernard Haisch

10 17

Config files moving to /usr
by Callum Farmer 13 Dec '22

13 Dec '22

Hi all, As many of you will have seen there is an ongoing effort to move config files which currently sit in /etc to /usr (where possible). I just wanted to provide a quick overview of the wider changes and how this affects new packages. DBUS-1 conf files: - Currently in /etc/dbus-1/system.d - Moving to /usr/share/dbus-1/system.d - If this is a change to an existing package, please file a SUSE security bug before sending it to Factory (example: https://bugzilla.suse.com/show_bug.cgi?id=1204055) - If this is a new package, please try to move the file to the /usr location and then you'll have to create a security bug anyway for Factory inclusion. pam.d files: - Currently in /etc/pam.d - Moving to /usr/lib/pam.d - Please use the %_pam_vendordir macro - These were previously moving to /usr/etc/pam.d (SUSE location) but then upstream created a vendor location so we follow that, files located in /usr/etc will still be read. XDG autostart files: - Currently in /etc/xdg/autostart - Moving to /usr/etc/xdg/autostart - There previously was an issue where files located in /usr/etc weren't being detected by the systemd generator, this was fixed (ref: https://github.com/openSUSE/aaa_base/pull/118) (bug: https://bugzilla.suse.com/show_bug.cgi?id=1201802) System user accounts and groups: - Currently created by useradd in %pre - Moving to creation based on /usr/lib/sysusers.d conf file (systemd / sysuser-shadow) - Information on how to create a sysusers.d file can be found at: https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups Notes: - When moving existing packages config files to /usr, you will require a section in the %pre and %posttrans sections to restore the admin's copy of the conf file (ref: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_f…). Although this doesn't really apply to the dbus-1 changes since admins typically would have no reason to overwrite them. - Don't use %config or %config(noreplace) on the /usr version of the file More information on other smaller changes and packaging information can be found here: https://en.opensuse.org/openSUSE:Packaging_UsrEtc P.S. This was a quick general guide, so some information may be slightly wrong. -- Callum Farmer gmbr3(a)opensuse.org openSUSE - gmbr3

7 19

How to correctly package my Shared Library: shlib-policy-name-error ???
by Lee Duncan 12 Dec '22

12 Dec '22

Hi: I maintain the open-iscsi package. It delivers the PRMs: - libopeniscsiusr0_2_0 - open-iscsi-2.1.8 - open-iscsi-devel-2.1.8 My problem is with libopeniscsiusr0_2_0. And this problem only seems to occur on SUSE's Internal Build Service, but I'm hoping you can help anyway. My libopeniscsiusr package has only two files in it: a shared library, and a symlink to that library. Here are the two after %build: > lrwxrwxrwx 1 lduncan 24 Dec 9 12:21 libopeniscsiusr.so.0 -> libopeniscsiusr.so.0.2.0* > -rwxr-xr-x 1 lduncan 143424 Dec 9 12:21 libopeniscsiusr.so.0.2.0* So libopeniscsiusr.so.0 is a symlink to libopeniscsiusr.so.0.2.0, the real shared library. [A development package adds the "libopeniscsiusr.so" symlink] In my RPM SPEC file, I specify the files in the library RPM like this: > %files -n libopeniscsiusr0_2_0 > %{_libdir}/libopeniscsiusr.so.* > And when the RPM is built and I examine it (or install it), sure enough the package is installed correctly, in /usr/lib64, i.e. libopeniscsiusr.so.0 is a symlink to libopeniscsiusr.so.0.2.0. As I said, our open build service handles this fine. But when I submit this same package to SUSE for SLE, it complains: > [ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 > [ 117s] Your package contains a single shared library but is not named after its > [ 117s] SONAME. So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink. By the way, my package has been like this for a couple of year in SLE, so I'm not sure why it's complaining. Help? -- Lee Duncan

7 19

Un-define a %_with_foo feature in a prjconf?
by Johannes Kastl 12 Dec '22

12 Dec '22

Hi all, if I read the docs[1] correctly, it is enough for a %_with_XXX feature to be defined, the value does not matter. So setting it to 0 does not disabled it. TL;DR: Is it possible to to un-define a %_with_XXX at project level in the prjconf? I already tried defining %_without_XXX, but that did not work, apparently as %_with_XXX was still defined. In my case I am trying to package some rubygems for SLES15/Leap15 using a newer ruby. I managed to get the ruby to be co-installable without causing harm, and if I drop large parts of the rubygems-gem2rpm spec file, I get building packages. But as the rubygems-gem2rpm spec file has these nice little %bcond_with_ruby21 and "%if %{with ruby21}" things, I tried to built without touching it. I succeeded in getting some packages to build by just building for ruby21 and ruby31, but as soon as a package requires ruby > 2.5 it falls apart. Hence my question: Can I un-define or disable a %_with_ruby21 or similar at project level? Or do I need to modify the spec file? Kind Regards Johannes [1] https://en.opensuse.org/openSUSE:RPM_conditional_builds https://en.opensuse.org/openSUSE:Build_Service_prjconf#%25bcond -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

3 5

Scripts in /etc/sysconfig/network/if-{down,up}.d
by Thorsten Kukuk 08 Dec '22

08 Dec '22

Hi, we have still some few packages which install scripts in /etc/sysconfig/network/if-{down,up}.d With a fresh default installation, scripts in this directory will not be executed anymore! Additional, 2/3 of the scripts I looked at until now are broken and don't work since years, one could even have never worked after an analysis together with todays package maintainer. So, if you have such a script, please look careful on it if it is really needed (which is questionable as it doesn't get executed anymore) and if yes, please port it to NetworkManagers dispatcher.d and drop the old one. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging December 2022