March 2022 - openSUSE Packaging - openSUSE Mailing Lists

Different source package versions building library with identical soname
by Aaron Puchert 10 Apr '22

10 Apr '22

Hi, I want to submit a package into Factory that provides a library with an soname identical to that provided by another package, but this seems to conflict with the convention to name such packages lib%{name}%{sonum}, since obviously the packages can't share the same name. [1] The background: Clang has both a stable API (the "C API" in libclang.so) and an instable API (the "C++ API" in libclang-cpp.so). Now upstream noticed that this should perhaps be reflected by not increasing the so number of libclang.so [2], so that with LLVM 14 we now have libclang-cpp.so -> libclang-cpp.so.14 libclang-cpp.so.14 libclang.so -> libclang.so.13 libclang.so.13 -> libclang.so.14.0.0 libclang.so.14.0.0 Of course libclang-cpp.so.* libraries need to be able to coexist, whereas libclang.so cannot coexist with the previous version that provides libclang.so.13 -> libclang.so.13.0.1 So I have to split up the libraries. But then both package versions provide libclang.so.13()(64bit) libclang.so.13(LLVM_13)(64bit) Indeed only the newer version should ever be needed, so should I stop building the older version or, more realistically, don't package it? (There are binaries in clang13 that use it, so I can't stop building or shipping it that easily. These binaries should of course also work with libclang.so.13 provided by LLVM 14.) Easier would be to keep shipping the old package, but have the new version obsolete it. Is that enough? Additionally, how should I name that package? Of course I can't also call it libclang13 unless I modify the LLVM 13 packaging to remove the library there, so should it be libclang14 or libclang13-14? The former would be the easiest, but rpmlint doesn't like it: libclang14.x86_64: E: shlib-policy-name-error SONAME: libclang.so.13, expected package suffix: 13 Best regards, Aaron [1] https://en.opensuse.org/openSUSE:Shared_library_packaging_policy [2] https://reviews.llvm.org/D105527

3 8

Anyone using obs-service-go_modules with upstream having multiple go.mod files?
by Johannes Kastl 31 Mar '22

31 Mar '22

Hi Jeff, hi all, apparently kubescape (https://github.com/armosec/kubescape) reorganized their repository structure and moved/split up the go.mod file from the root of the repository to some directories in "core" and "cmd". So the vendoring approach currently being used in the package does no longer work, as only one of the go.mod files will be found by the obs-service-go_modules. > https://build.opensuse.org/package/show/devel:kubic/kubescape > INFO:obs-service-go_modules:Using go.mod found at /home/Buildservice/Branches/Branch_devel_kubic/kubescape/tmp_35r3omj.go_modules.service/kubescape-2.0.150/core/go.mod I found no hints in the docs, so I guess there is no way to tell the service to use more than one go.mod? Or to tell it which one to use? 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 4

Build Fail Reminder
by Stephan Kulow 29 Mar '22

29 Mar '22

Hi, While the emails are sent under Dominique's name, I made some changes to the underlying script, so I would like to make you aware of some changes you might see in your inbox tonight. The whole reminder was lifted to include more cases of a problematic package, so you will see "reminders" of problems you haven't heard of before. What we do so far: for failing packages we - send an email one week after the first failure - send a reminder the week after - include the package in a mail to factory@opensuse for the wider audience after 4 weeks - create a delete request after 6 weeks What's new now: - unresolvable packages in openSUSE:Factory will get the same 6 weeks before drop as failing packages. - packages with multibuild flavors failing will get the same 6 weeks - packages with 2nd spec files failing will get the same 6 weeks - i586 failures also get the same 6 weeks. If you don't care for i586, it's fine for me but then use ExclusiveArch or ExcludeArch - uninstallable packages will also get the same 6 weeks. Including packages uninstallable on i586. For this case, I now add the installcheck output as comment to the package in openSUSE:Factory (as the reminder links there). This already triggers a comment email notification if you're subscribed to it. Greetings, Stephan

1 0

Re: /work/src/done/SLE15-SP4-STAGING/package-translations not checked in
by Stanislav Brabec 20 Mar '22

20 Mar '22

It was submitted to Factory in parallel: https://build.opensuse.org/request/show/962550 Dne 18. 03. 22 v 10:13 wengel napsal(a): > Script 'mail_helper' called by wengel > > Hi sbrabec(a)suse.com, > /work/src/done/SLE15-SP4-STAGING/package-translations was not checked in by wengel for the following reasons: > (submitrequest 267818 on https://build.suse.de) > > Please also submit to Factory > > > > your dist/autobuild team. > -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.com Křižíkova 148/34 (Corso IIa) tel: +420 284 084 060 186 00 Praha 8-Karlín fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76

1 0

/work/src/done/SLE15-SP4-STAGING/package-translations not checked in
by wengel 18 Mar '22

18 Mar '22

Script 'mail_helper' called by wengel Hi sbrabec(a)suse.com, /work/src/done/SLE15-SP4-STAGING/package-translations was not checked in by wengel for the following reasons: (submitrequest 267818 on https://build.suse.de) Please also submit to Factory your dist/autobuild team.

1 0

Build a package with a some non-free headers
by Hans-Peter Jansen 17 Mar '22

17 Mar '22

Hi, I am faced with a dilemma. A bunch of users are asking me to activate the OptiX renderer for Blender. Unlike CUDA, OptiX requires some non-free include files during build[1]. The idea is to fetch the headers, that are provided by NVidia with wget in order to avoid packaging them up in the source rpm. I understand, that this is a problem, but is there any chance to get this going. E.g. using the download service, but not packaging it later on. If I look at builds like gradle or rancher-desktop, they all end up fetching huge amounts of binaries from some web resources. Here; we're talking about a few header files, that we just should avoid to redistribute. Here's my current state of affairs[2]. Cheers, Pete -- Life without chameleons is possible, but pointless. [1] https://devtalk.blender.org/t/blender-2-8-cycles-optix-packaging/12533/14 [2] https://build.opensuse.org/package/show/home:frispete:blender/blender-310

4 4

Packaging kcbench: Where to submit to?
by Johannes Kastl 11 Mar '22

11 Mar '22

Hi all, I packaged kcbench, Thorsten Leemhuis' kernel benchmark script: https://gitlab.com/knurd42/kcbench https://build.opensuse.org/package/show/home:ojkastl_buildservice/kcbench Side note: Currently not working on Tumbleweed, see explanation/discussion here: https://gitlab.com/knurd42/kcbench/-/issues/14. As this is low maintenance and might be interesting for other people, where should I submit this to? This does not seem appropriate: https://build.opensuse.org/project/show/Kernel:tools Tools for working with the SUSE kernel sources I found "benchmark" in devel:tools, not sure if that fits? Have a nice weekend everyone! 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 4

Moving modprobe.d files to (/usr)/lib
by Martin Wilck 07 Mar '22

07 Mar '22

Historically, modprobe configuration files have been installed in /etc/modprobe.d on openSUSE. This has a number of disadvantages. - packages should generally avoid shipping files under /etc - customization requires %config or %config(noreplace), with the well-known issues this may cause on upgrades. The more "modern" style to enable user customization is to place distribution-shipped configuration files under /lib/modprobe.d or /usr/lib/modprobe.d, and let users override them by files of the same name under /etc/modprobe.d if they desire. This technique has been supported by kmod for years, and is well established these days by systemd, udev, dracut, etc., which use the same scheme. I've started an effort to move all modprobe configuration files shipped by packages into /usr/lib/modprobe.d on Factory, and /lib/modprobe.d on Leap. The %config or %config(noreplace) file attributes for the distribution-shipped defaults are removed. If the user has modified some of the distro-shipped %config files, they'll be renamed to .rpmsave by rpm when the update package moves the config file out of /etc. This would undo user customizations, which is undesirable. To avoid it, code is added to the spec files of affected packages, which looks like this (example from "bluez"): %global modprobe_d_files 50-bluetooth.conf %pre # Avoid restoring pre-existing .rpmsave files in %posttrans later by renaming them for _f in %{?modprobe_d_files}; do [ ! -f "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" ] || \ mv -f "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" "%{_sysconfdir}/modprobe.d/${_f}.rpmsave.%{name}-%{VERSION}-%{RELEASE}" || : done %posttrans # Modified config files are renamed to .rpmsave by rpm when moved to /usr/lib. # Restore the user's customizations. for _f in %{?modprobe_d_files}; do [ ! -f "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" ] || \ mv -fv "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" "%{_sysconfdir}/modprobe.d/${_f}" || : done The current status can be seen on OBS in the home:mwilck:modprobe.d project (currently WIP). There has been some confusion about the correct path (/usr/lib/modprobe.d vs. /lib/modprobe.d). Here's a short summary of the discussion: - upstream kmod does supports /lib/modprobe.d only. - SUSE's kmod is currently patched to support both /lib/modprobe.d and /usr/lib/modprobe.d. - On usr-merged Factory, /lib/modprobe.d is an alias for /usr/lib/modprobe.d, thus they can be used interchangeably. For correctness and to avoid filename clashes, we use /usr/lib. - on non-usr-merged distros, we keep the upstream path /lib/modprobe.d. Scripts and "consumers" of modprobe.d files can safely look them up under /lib/modprobe.d, which will "work" on both usr-merged and non- usr-merged variants. In the future, %_modprobedir should be used by packages. Currently though, %_modprobedir is (wrongly) set to /usr/lib/modprobe.d in the systemd-rpm-macros package on SLE/Leap up to 15.3. Likewise, the filesystem package on Leap currently contains /usr/lib/modprobe.d but not /lib/modprobe.d. This will be fixed sooner or later, but spec files currently need to work around this issue with a conditional. packages that install into %_modprobedir should add a "%dir %{_modprobedir}" line to the %files list to avoid build errors. Furthermore, discussion is ongoing whether the definition of %_modprobedir should be moved to a different package, and which. Regards Martin PS: @maintainers of affected packages: I've sent a bunch of OBS requests on Friday and revoked them, because I hadn't added the code for restoring user modifications yet and I figured I should rather do that first.

4 6