- openSUSE Packaging

RFC: Factory review policy change regarding multi-specfile packages
by Frederic Crozat 25 Apr '23

25 Apr '23

Hi all, As part of the setup of ALP products into build service, we would like to change Factory review policy regarding multi-specfile package: Currently, packages containing multiple specfiles require creating links to another package, with the name of secondary specfiles. For instance: on Build service, package foo contains: -foo.spec -bar.spec Only foo.spec will be built. For bar.spec to be built, a linkpac is needed from foo => bar. Creation of this link is handled by OBS when accepting a sr. With ALP, our goal is to migrate source management to git backend in the (hopefully) near future (there won't be any immediate change on how to do package submissions, don't worry ;). To do that and after discussing with Build Service project managers, it would be easier (and cleaner) to add to packages with multiple specfiles a _multibuild file to handle additional specfile, without the need of linkpac. In the example above, package foo would contains: - foo.spec - bar.spec - _multibuild _multibuild content: <multibuild> <flavor>bar.spec</flavor> </multibuild> (there is no need to mention foo.spec). If there is an agreement, all multi-spec Factory packages will need to be migrated, factory-auto bot will need to be adapted to reject submission without multi-spec. Hopefully, this will be a one-time only cleanup. Questions ? Comments ? -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE

7 13

Re: RFC: Factory review policy change regarding multi-specfile packages
by Egbert Eich 25 Apr '23

25 Apr '23

Frederic Crozat writes: > Le mardi 25 avril 2023 =E0 13:42 +0200, Marcus R=FCckert a =E9crit=A0: > > 1. not sure that using the same element for multiple build > > descriptions > > and flavors within a build description is a good idea >=20 > This is wanted, according to Adrian (see > https://github.com/openSUSE/open-build-service/issues/8847#issuecomment-= 570156830 > where package xml tag is considered obsolete) This discussion attempts to address exactly the problem pointed out by Darix. Unfortunately, the only answer I can deduce from the discussion there is that one may have *either* multiple spec files *or* meaningful build flavors (ie replacements for @BUILD_FLAVOR@). Since replacing @BUILD_FLAVOR@ by the spec file name does not allow for a useful disctinction between different 'flavors' inside the spec file. Is this really the goal here - in the hope to avoid extending the semantics (as Stefan Br=FCns has proposed in an earlier response)? Cheers, Egbert.

1 0

Pla to move openSUSE Tumbleweed to version 1699
by Dominique Leuenberger 24 Apr '23

24 Apr '23

Dear Tumbleweed users, hackers and packagers, ALP is shaping up internally and the time has come where packages need to distinguish betweeh SUSE's next platform and products based on this platform from openSUSE Tumbleweed. In a natural course, SUSE ALP will be picking suse_version 1600 (which is internal to packages only) As Tumbleweed is always 'ahead of the game' this means that we need to do a big step. In line with the experences gained over the last years, the decision was taken to move openSUSE Tumbleweed to suse_version 1699 For you as a packager, this has no immediate effect: you keep on using the normal constructs like: %if 0%{?suse_version} > 1500 # i.e. newer products than the SLE/Leap 15 family (there exist also >= 1550 and >= 1599 which was just picked by people, which are all fine. There are only very few cases where you require to distinguish - for now - between Tumbleweed (> CODE 15 family) and the ALP platform. So unless there is specific need (which you are likely given by ALP Release Managers): don't distinguish the two :) Keep your spec files clean and as simple as possible To sum up: openSUSE:Factory will change suse_version to 1699 in the next days (once staging is ready and the build script is adjusted) Chers, Dominique

2 2

Re: Building go packages: Is "__arch_install_post export NO_BRP_STRIP_DEBUG=true" still needed?
by Jeff Kowalczyk 18 Apr '23

18 Apr '23

From: Johannes Kastl Sent: Tuesday, April 18, 2023 01:16 To: packaging(a)lists.opensuse.org Subject: Re: Building go packages: Is "__arch_install_post export NO_BRP_STRIP_DEBUG=true" still needed? > Morning Richard, > On 18.04.23 at 10:08 Richard Biener wrote: > > > ISTR that Go requires functional backtrace() for quite some of its > > functionality (which users expect to work) and without debug info > > the quality of that is severely degraded. So to check you'd have > > to actually run built go packages, compiling isn't good enough. > > Sorry, I was unclear. I executed the binary, at least the "version" > part and it did not crash or segfault. Hello Johannes, I looked into this again after seeing your initial email in this thread. Yes, it may now be possible to remove NO_BRP_STRIP_DEBUG with currently supported versions of openSUSE and SLE. Further testing is needed before making a general recommendation. I will continue investigating and update in this thread with the results. Some background for those interested: In 2016, https://bugzilla.opensuse.org/show_bug.cgi?id=964546 reported errors on Go binaries built in OBS manifesting as: fmt.a: go archive is missing __.PKGDEF Aleksa Sarai reported https://github.com/golang/go/issues/17890. Summarizing, GNU strip circa 2016 would incorrectly strip .a archives output by the Go compiler and write out a modified invalid archive instead of exiting with error and leaving the .a file unchanged. Aleksa closed the upstream issue and created https://github.com/openSUSE/brp-check-suse/pull/7 to revert stripping if strip outputs to stderr. This was not merged, so if the issue was fixed by subsequent changes in brp-check-suse change or binutils it would be best to document those minimum versions in our Go packaging guidance, as well as the current state of GNU strip with Go binaries. In the time since 2016, Go packages use the spec comment "# nodebug" and %define __arch_install_post export NO_BRP_STRIP_DEBUG=true. These may no longer have any effect today, so removal will be tested. I am starting testing with vale (a grammar checker) at https://build.opensuse.org/request/show/1080075 which executes the binary --help in the %check section for platform and repository coverage. We will need to test CGo enabled applications as well. To address the golang-packaging question from your initial email: golang-packaging has the macro go_nostrip to undefine _build_create_debug and define NO_BRP_STRIP_DEBUG as above. go_nostrip is one of the only macros from the original golang-packaging that is still useful today with Go modules. Much of the golang-packaging functionality automates complex file movements that populate the file tree under GOPATH with declared dependencies, obsolete when working with Go modules. Jeff Jeff Kowalczyk Software Engineer, Go Developer Experience SUSE Linux http://suse.com

2 1

Building go packages: Is "__arch_install_post export NO_BRP_STRIP_DEBUG=true" still needed?
by Johannes Kastl 18 Apr '23

18 Apr '23

Hi all, Fabian and me had a chat about whether the following is actually still needed in a spec file for a go package: %define __arch_install_post export NO_BRP_STRIP_DEBUG=true In some thread a long time ago (that I did not find unfortunately) Jeff pointed me at the hugo package as an up-to-date example for building go packages. And told me not to use the %go_... macros, that were deprecated/outdated/... At least that is what I seem to remember. > https://build.opensuse.org/package/view_file/openSUSE:Factory/hugo/hugo.spe… That is what I took as a blueprint for the many go packages I packaged for devel:kubic. Question: Is that NO_BRP_STRIP_DEBUG=true thingy actually still needed? Or could it be left out? The wiki page https://en.opensuse.org/openSUSE:Packaging_Go only mentions the go_strip or go_nostrip macros. My remembrance from the conversation with Jeff was that this page was outdated. Not sure if this is still true, last edit was on April 5th. Maybe someone can give recommendations on what to use. I'll be happy to change that in the packages I need to touch anyway... 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

3 4

Announce: Conditional Build Dependencies per Project
by Thorsten Kukuk 25 Mar '23

25 Mar '23

Hi, Our base packages include support for all sorts of features, making our base OS very large due to dependencies. While this is not a problem for e.g. openSUSE Tumbleweed, where the extra packages do not really matter in the overall size, it is a big problem when building a small single-purpose OS where you want something really small without any unnecessary packages. Like ALP. The "useless" packages create yet another problem: Libraries are installed for features that are not supported or do not work. E.g. AppArmor and SELinux are exclusive, so why should e.g. ALP ship AppArmor that can't work and isn't supported, but creates a high maintenance overhead on all sides without any benefit? We use already %bcond in our spec files set in the project config for various reasons, one is to bootstrap the distro. Another reason is, that it looks like as some maintainers build already smaller versions of some packages for their need in their projects. To avoid that e.g. ALP is shipped with AppArmor and SELinux, while only SELinux will be used, we decided to "formalize" and document this: https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies 85% of the keywords are already used today in projects. What does this mean for you? 1. if somebody added this %bcond to your packages, please accept them and forward them to Factory. 2. if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard. 3. If we create bug reports for ALP since you are a maintainer of a core package which has dependencies we don't want to see, please work on them with a higher priority. 4. Yes, it is known that you cannot build every package without this dependencies. Thanks, 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)

9 15

Building python-libtmux: OBS errors out with "couldn't create directory /run/tmux/399 (No such file or directory)"
by Johannes Kastl 17 Mar '23

17 Mar '23

Hi all, I am trying to package the new ansible-sign utility. One of the dependencies is python-libtmux, which builds successfully. But only locally or if I disable the %check section. > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_de… Inside OBS the checks fail with this error message: > [ 54s] if proc.stderr: > [ 54s] > raise exc.LibTmuxException(proc.stderr) > [ 54s] E libtmux.exc.LibTmuxException: ["couldn't create directory /run/tmux/399 (No such file or directory)"] > [ 54s] > [ 54s] ../../BUILDROOT/python-libtmux-0.21.0-5.1.x86_64/usr/lib/python3.8/site-packages/libtmux/server.py:483: LibTmuxException My guess is that somehow /run and /run/tmux are not setup properly. I tried to create it manually, I tried "systemd-tmpfiles --create", but nothing worked. /run is existing, but only contains utmp and some other directory I forgot. What would be the OBS way to get that working? Or is this not possible inside OBS? Thanks in advance! 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

license of not built library
by Cor Blom 11 Mar '23

11 Mar '23

Hi, If the source package include a library that is not built and not part of the binary, should it then be mentioned in the license line in the spec? This is specifically about musescore, which contain google crash client, but we disable it during build. It is the only part with an apache license. Thanks, Cor

3 2

Buildservice _constraints
by Arjen de Korte 07 Mar '23

07 Mar '23

What does the specifying jobs [1] in the _constraints file actually do? I expected it to work similarly as specifying 'osc build --jobs N' on the command line, but looking in the logs of a remote build server, it see that it actually runs with a higher number '+ /usr/bin/make -O VERBOSE=1 -j8'. Is there a way to limit the requested number of parallel build jobs in the _constraints file, or is the only way to put this in the spec file like '%cmake_build --jobs 4'? [1] https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.build_job_…

4 4

Proper dependencies for bash/fish/zsh completion sub-packages
by Johannes Kastl 04 Mar '23

04 Mar '23

Hi all, what are the proper dependencies for packages that contain some completion for bash, zsh or fish? Should they Require bash-completion/fish/zsh? I came across this today, as I was wondering why the bash-completion subpackage of kubie did not require the bash-completion package. Of course it makes no sense to install a zsh completion package if I am not using zsh, but should this not be reflected in the subpackage's requirements? For bash it might be even more prominent, because the completion files for kubie are not being used without the bash-completion package itself (if I am understanding the scripts correctly). Thanks in advance and have a nice weekend, everyone! 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

3 4