April 2023 - openSUSE Packaging - openSUSE Mailing Lists

sle15_python_module_pythons
by Eric Schirra 08 May '23

08 May '23

I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes. But i can't find any documentation about it. Not in wiki and not in python-rpm-macro. So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ? Regards Eric

7 24

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