- openSUSE Packaging

Re: Cloud:Tools is low on active maintainers
by Dominik Wombacher 28 Apr '25

28 Apr '25

Hi Johannes, Andreas, > On 03/29/2025 10:37 AM CET Johannes Kastl <opensuse_buildservice(a)ojkastl.de> wrote: > > > Team, it may also be advisable to have Dominik, who is build solutions > > with AWS + SUSE(!) and spoke about this at oSC 24, maintain > > aws-cli-2.... https://build.opensuse.org/request/show/1175839 > > Yes, it's sad to see a SR open for 10 month. I accepted it now and > made Dominik maintainer and bugowner for the package. > I appreciate the call-out from Andreas and that Johannes added me as Maintainer. But unfortunately my Situation has changed in the meantime. I don't have the bandwidth to actively maintain aws-cli-2 or work on any of its dependencies anymore. Please consider to drop me from the package Maintainers, otherwise I will likely become just another inactive one on the list. Dom -- The Wombelix Post https://dominik.wombacher.cc

1 0

Package file conflicts: How to handle symlinks
by Tobias Görgens 28 Apr '25

28 Apr '25

Hi packagers, I just had an interesting issue with zypper and file conflicts and wanted to know what the "correct" way is to handle this situation. I got this error when I tried to update a package I'm packaging from version 0.58 to 0.61: File /usr/share/pipewire/hardware-profiles/default/pipewire.conf.d/filter-chain.conf from install of steamdeck-dsp-0.61.0-16.1.x86_64 (yuga_unstable) conflicts with file /usr/share/pipewire/hardware-profiles/valve-jupiter/pipewire.conf.d/filter-chain.conf from install of steamdeck-dsp-0.61.0-16.1.x86_64 (yuga_unstable) which I found odd: A package has a conflict with itself on two different files? I looked at the content of both files and saw: In version 0.58 /usr/share/pipewire/hardware-profiles/default is a symlink to /usr/share/pipewire/hardware-profiles/valve-jupiter, in version 0.61, they are seperate and the filter-chain.conf's in them differ. I fixed the issue by adding %pretrans # if user has the old version symlinked, remove it before we install the new real dir if [ -L %{_datadir}/pipewire/hardware-profiles/default ]; then rm -f %{_datadir}/pipewire/hardware-profiles/default fi to my spec file, but it feels wrong. I shouldn't need to remove the symlink before installing the package (it fixed it though). So, I was wondering if my spec file is incorrect. Do I need to specify symlinks in a special way? This is the spec file: Name: steamdeck-dsp Version: 0.0.git.1816.0520dcba Release: 7%{?dist} Summary: Steamdeck Audio Processing License: GPLv2 URL: https://github.com/ublue-os/bazzite Source0: valve-hardware-audio-processing-%{version}.tar.xz Patch0: fedora.patch Requires: wireplumber Requires: pipewire-modules-0_3 Requires: ladspa-rnnoise Requires: systemd BuildRequires: pipewire-modules-0_3 BuildRequires: ladspa-rnnoise BuildRequires: wireplumber BuildRequires: make BuildRequires: faust BuildRequires: faust-devel BuildRequires: boost-devel BuildRequires: lv2-devel BuildRequires: gcc-c++ BuildRequires: ladspa-devel BuildRequires: xz BuildRequires: systemd %description Steamdeck Audio Processing # Disable debug packages %define debug_package %{nil} %prep %setup -n valve-hardware-audio-processing-%{version} %patch 0 -p1 %build %make_build FAUSTINC="/usr/include/faust" FAUSTLIB="/usr/share/faust" %install mkdir -p %{buildroot}/run/wireplumber %make_install DEST_DIR="%{buildroot}" LIB_DIR="%{buildroot}%{_libdir}" mkdir -p %{buildroot}%{_datadir}/licenses/%{name}/ cp LICENSE %{buildroot}%{_datadir}/licenses/%{name}/LICENSE xz --check=crc32 %{buildroot}%{_prefix}/lib/firmware/amd/sof/* xz --check=crc32 %{buildroot}%{_prefix}/lib/firmware/amd/sof-tplg/* # This lists all the files that are included in the rpm package and that # are going to be installed into target system where the rpm is installed. %files %license LICENSE %{_prefix}/lib/firmware/amd/ %{_prefix}/lib/firmware/amd/* #%{_libdir}/lv2/svg #%{_libdir}/lv2/svg/valve_deck_* %{_libdir}/lv2 %{_libdir}/lv2/valve_* %{_datadir}/alsa/ucm2 %{_datadir}/alsa/ucm2/* %{_datadir}/pipewire/hardware-profiles %{_datadir}/pipewire/hardware-profiles/default %{_datadir}/pipewire/hardware-profiles/valve-galileo %{_datadir}/pipewire/hardware-profiles/pipewire-hwconfig %{_datadir}/pipewire/hardware-profiles/valve-galileo/pipewire.conf.d %{_datadir}/pipewire/hardware-profiles/pipewire-hwconfig #%{_datadir}/wireplumber/bluetooth.lua.d/*.lua #%{_prefix}/share/wireplumber/main.lua.d #%{_datadir}/wireplumber/main.lua.d/*.lua #%{_datadir}/wireplumber/scripts/*.lua %{_prefix}/lib/systemd/system/multi-user.target.wants/wireplumber-sysconf.service %{_prefix}/lib/systemd/system/wireplumber-sysconf.service %{_prefix}/lib/systemd/system/multi-user.target.wants/pipewire-sysconf.service %{_prefix}/lib/systemd/system/pipewire-sysconf.service %{_prefix}/share/wireplumber/hardware-profiles %{_prefix}/share/wireplumber/hardware-profiles/* /etc/wireplumber # Finally, changes from the latest release of your application are generated from # your project's Git history. It will be empty until you make first annotated Git tag. %changelog Not too pretty, but it worked (so far). The package can be found here: https://build.opensuse.org/package/show/devel:microos:yuga:unstable/steamde… I'm very curious to hear what you think how this would need to be handled, I would like to prevent these situations in the future :) Sincerely, Tobias G.

4 5

Prepare for CMake 4.0 with package rebuild?
by Christoph G 14 Apr '25

14 Apr '25

Dear fellow openSuse packagers! CMake prepares for a new major release 4.0. By default this will break every package that requires a minimum version of CMake <= 3.5. Can we create in OBS a mass rebuild with the latest release candidate of CMake 4.0 to see the fallout? I don't know how to do it and if I am allowed to do so. This would help to identify which package needs to be patched or even better, we can reach out to upstream with patches. Is it worth to open an issue to track the packages which needs to be addressed? By the way, SUSE libraries might be affected, too. For example libsolv has an according open merge request since last December, see https://github.com/openSUSE/libsolv/pull/575 Bye Christoph -- Most customers will not accept source code with compile errors in it. Dan Saks, CppCon 2016 (https://youtu.be/D7Sd8A6_fYU)

3 6

Package update
by Fabrice 07 Apr '25

07 Apr '25

Hello I'm sorry to ask (again), but I'm lost (again). https://repology.org/badge/vertical-allrepos/human-theme-gtk.svg?header=hum… https://software.opensuse.org/package/human-theme-gtk - openSUSE Tumbleweed: alright, v2.3.0 official - openSUSE Leap 15.6: there is only 2.3.0 experimental - openSUSE Leap 15.5: there is only 2.3.0 experimental I don't understand anything because my maintenance request to 15.5 was rejected because 15.5 is EOL. I think repology.org says the truth. Is there another (better) website to find official packages in openSUSE? -- I didn't find a wiki with simple commands, so my package is: https://build.opensuse.org/package/show/X11:common:Factory/human-theme-gtk Some days ago, I have "Branch package", I added some commits, then I made a request from my home branch to X11:common:Factory/human-theme-gtk via build.opensuse.org (1267213). Then I made another submit package request from X11:common:Factory/human-theme-gtk to openSUSE:Factory/human-theme-gtk via build.opensuse.org (1267214). So my package is now officially available in openSUSE Tumbleweed at v2.3.0. To update the package in openSUSE Leap 15.6, I made a maintenance request via the command line: osc mr -m ... openSUSE:Factory human-theme-gtk openSUSE:Backports:SLE-15-SP6:Update -- alright, it's in progress (1267752). -- There were an automatic request to submit the package in openSUSE Leap 16 (https://build.opensuse.org/package/show/openSUSE:Leap:16.0/human-theme-gtk) What is the right project for my futur maintenance? request? There is also openSUSE Slowroll (https://build.opensuse.org/package/show/openSUSE:Slowroll:Build:1/human-the…) but: - not displayed at software.opensuse.org and repology.org - is the package in Slowroll? - how to update the package? maintenance? request? project? openSUSE 15.7 on X11:common:Factory pages (https://build.opensuse.org/package/show/X11:common:Factory/human-theme-gtk) it doesn't exist? it's the old project for openSUSE 16.0? Thank you (again).

1 0

Having fun with nodejs: Packaging bruno-cli
by Johannes Kastl 30 Mar '25

30 Mar '25

Dear packagers, I recently read an interesting article on Bruno, a postman alternative. It has a CLI. I could package that, though my slightly younger and a lot more enthusiastic self. How naive... OK, it is in nodejs. But I have packaged other things using nodejs. How hard can it be? > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_ne… I opened an issue with the node_modules service as the package-lock.json they have in their repository was throwing errors due to "integrity" keys missing. Adam told me to always recreate the package-lock.json. Adam was kind enough to supply a package-lock.json that at least got the local-npm-registry to not fail in the %prep section already. But later the installation of the CLI failed. Missing dependencies. Hooray. I tried to recreate the package-lock.json, but whatever I do and whichever arguments I use during "npm install" (outside the build), I cannot get node_modules to not throw the "integrity" error. I tried various incatations of - npm install --package-lock-only --ignore-scripts - npm install --package-lock-only --legacy-peer-deps --ignore-scripts I ran this on my laptop (Tumbleweed, same npm version Adam used). I ran this in a Tumbleweed container not sharing my $HOME, using the same npm version. I ran this in the packages/bruno-cli/ subdirectory and in the repository root. I removed their package-lock.json before in all cases. I would really like to understand why my files created the integrity error. And why I cannot get a package-lock.json that is accepted by the node_modules service. So, if anyone wants to have a look and point out my mistake, I would be really glad. Because I am puzzled, but don't want to just blame nodejs and its ecosystem... :-) Kind Regards, Johannes

1 0

Moving /etc/sysconfig files
by Thomas Renninger 28 Mar '25

28 Mar '25

Hi, Afaik package provided config files have to move to /usr/etc? There seem to be quite a lot packages making use of the ugly fillup macros. All seem to be config files setting environment variables for systemd service process via EnvironmentFile=-XY: ---------------------- grep 'EnvironmentFile=-/etc/sysconfig' /usr/lib/systemd/system -r |wc -l 54 ls -1 /etc/sysconfig/ |wc -l 51 ls -1 /etc/sysconfig/network/ |wc -l 3 ---------------------- Afaik the fillup scripts were mostly for merging user changes and add some extra safety compared to limited rpm %config backup features. But having the split between package provided and on-top user config in 2 separate files makes things much easier anyway. EnvironmentFile=-/usr/etc/env/${service} EnvironmentFile=-/etc/env/${service} Concrete example is irqbalance where mainline does it similar: -------------------------------------------- Add optional config file in /usr/lib immutable distributions have a need for distribution specific configs in a read only space, and so modify the service file to optionally read a config file from /usr/lib/irqbalance/default.env -EnvironmentFile=/path/to/irqbalance.env +Environmentfile=-/usr/lib/irqbalance/defaults.env +EnvironmentFile=-/path/to/irqbalance.env -------------------------------------------- But as I do not see a single package doing it this way, nearly all are still located in /etc/sysconfig I do not want to begin something which already is decided/thought to be done differently. Long story short: How are other distros doing this? Do we want to get rid of fillup scripts and /etc/sysconfig and how? Is the double Environmentfile (/usr/etc and /etc) a suitable solution, maybe collect them in separate dir? Thanks for any thoughts and feedback, Thomas

5 23

osc newbie problem(?) building python3 stuck (running: test_faulthandler (2 hour 37 min))
by Paul Neuwirth 28 Mar '25

28 Mar '25

Hi, (posted this previously in buildservice list, but no replies) I am completely new to using osc. I started an osc build for python3 from an rather old package/project (need to backport Python >= 3.6 to Leap 42) the build ran normal for about an hour. Since then it seems to be stuck: [...] [12250s] running: test_faulthandler (2 hour 41 min) [12280s] running: test_faulthandler (2 hour 42 min) pstree shows │ │ └─osc,14534 /usr/bin/osc build --clean --target openSUSE_Leap_42.2 x86_64 │ │ └─sudo,14547 /usr/bin/build --root=/var/tmp/build-root/openSUSE_Tumbleweed-x86_64 --rpmlist=/tmp/rpmlist.t9yub01a --dist=/root/backports/python/home:frispete:python/python3/.osc/_buildconfig-openSUSE_Tumbleweed-x86_64 --arch=x86_64 --statistics --norootforbuild --clean --changelog ... │ │ └─sudo,14548 /usr/bin/build --root=/var/tmp/build-root/openSUSE_Tumbleweed-x86_64 --rpmlist=/tmp/rpmlist.t9yub01a --dist=/root/backports/python/home:frispete:python/python3/.osc/_buildconfig-openSUSE_Tumbleweed-x86_64 --arch=x86_64 --statistics --norootforbuild --clean --changelog ... │ │ └─build,14549 /usr/bin/build --root=/var/tmp/build-root/openSUSE_Tumbleweed-x86_64 --rpmlist=/tmp/rpmlist.t9yub01a --dist=/root/backports/python/home:frispete:python/python3/.osc/_buildconfig-openSUSE_Tumbleweed-x86_64 --arch=x86_64 --statistics --norootforbuild --clean --changelog ... │ │ ├─perl,14563 -e open(F,">>",$ARGV[0])||die("$ARGV[0]: $!\\n");$|=1;select(F);$|=1;while(<STDIN>){my $p=sprintf("[%5ds] ", time()-1742978924);print STDOUT $p.$_;print F $p.$_} /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/.build.log │ │ └─su,16513 -c /.build.command - abuild │ │ └─rpmbuild,16514 -ba --define _srcdefattr (-,root,root) --nosignature --target=openSUSE_Leap_42.2 --define _build_create_debug 1 /home/abuild/rpmbuild/SOURCES/python3.spec │ │ └─bash,523 -e /var/tmp/rpm-tmp.s0oX95 │ │ └─make,526 -j1 test TESTOPTS=-u curses -v -x test_gdb test_pydoc test_uuid test_cmd_line_script test_multiprocessing_main_handling test_runpy │ │ └─python,552 -u -W default -bb -E -m test -r -w -j 0 -u curses -v -x test_gdb test_pydoc test_uuid test_cmd_line_script test_multiprocessing_main_handling test_runpy │ │ ├─python,939 -bb -E -Wdefault -u -m test.regrtest --worker-args[{"testdir": null, "verbose": 1, "quiet": false, "exclude": true, "single": false, "randomize": true, "fromfile": null, "findleaks": false, "use_resources": ["curses"], "trace": false, "coverdir": " │ │ │ └─python,1521 -E -c import faulthandler\012faulthandler.enable()\012faulthandler._stack_overflow() │ │ └─{python},564 process 1521 is on top's top: 1521 399 20 0 9284 1024 896 R 79.02 0.013 2405:06 python but a strace -f doesn't show any activity at all Since I am new to using osc, I don't know if that's normal time for it or if the process got stuck in a loop or so. what I did (according to .bash_history) - (on Leap 15.6): osc -A https://api.opensuse.org checkout home:frispete:python/python3 -r 18 cd home\:frispete\:python/python3/ vi python3.spec osc build --target openSUSE_Leap_42.2 x86_64 I had to modify the .spec file, since the original used older syntax - which was no longer accepted. https://www.swabian.net/extern/opensuse/python3.spec thanks for your help Regards, Paul

1 0

Reduce dependencies on upower
by Thomas Renninger 28 Mar '25

28 Mar '25

Hi, I saw by chance the submitrequest from Michal from yesterday for libimobiledevice. Maybe this was not a coincident that Olaf asked me to reduce package dependencies for upower on exactly this (libimobiledevice) and libplist packages. The optional libimobiledevice and libplist dependencies on upower seem to serve specific Apple devices (iPad?, ...). A typical use case of upower is to detect low battery or other power related HW events and react accordingly. I would simply remove BuildRequires: to these 2 packages and upower should still compile and work fine on remaining HW. It should still run on Apple HW as well with a reduced feature set. Is there still an rpm/spec conditional flag (OpenSUSE vs SLE vs Micro or whatever) or a multibuild flavor/flag one should use to e.g. enable as much as possible (or special multimedia/desktop features/HW,...)? Any hints and help are welcome, Thomas

4 7

Cloud:Tools is low on active maintainers
by Johannes Kastl 26 Mar '25

26 Mar '25

Dear all, is there someone who could check and accept the open SRs to Cloud:Tools? It has a long list of maintainers, but I had several requests being open for weeks. Hence I sent a SR to become a project maintainer to help out with getting my requests in. Of course, this SR is also waiting for 10 days now... https://build.opensuse.org/project/requests/Cloud:Tools Could someone please check those SRs? Thank you in advance. Kind Regards, Johannes

2 1

How to package rust bindings properly?
by Johannes Kastl 24 Mar '25

24 Mar '25

Dear packagers, how does one package "rust bindings" properly? In my case I seem to require the magnum-opus "Safe Rust bindings for libopus" as a dependency for another package, so I gave it a try. It compiles, but due to missing rust knowledge I have no clue how to install/package the resulting files. > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_X1… This is what is in the "release" directory created by the build: > [ 34s] + ls -lh /home/abuild/rpmbuild/BUILD/magnum-opus-1684549265.5cd2bf9-build/magnum-opus-1684549265.5cd2bf9/target/release > [ 34s] total 536K > [ 34s] drwxr-xr-x 24 abuild abuild 4.0K Mar 21 17:52 build > [ 34s] drwxr-xr-x 2 abuild abuild 12K Mar 21 17:53 deps > [ 34s] drwxr-xr-x 2 abuild abuild 4.0K Mar 21 17:52 examples > [ 34s] drwxr-xr-x 2 abuild abuild 4.0K Mar 21 17:52 incremental > [ 34s] -rw-r--r-- 1 abuild abuild 618 Mar 21 17:53 libmagnum_opus.d > [ 34s] -rw-r--r-- 2 abuild abuild 506K Mar 21 17:53 libmagnum_opus.rlib Any ideas or RTFM? Kind Regards, Johannes

2 2