- openSUSE Packaging

Build problem with multi spec
by Eric Schirra 12 Apr '24

12 Apr '24

Hello everyone, I have a problem and acceptance with a request for factory. I want to build a package which builds an application with different versions for Leap and Tumbleweed. First attempt was to query in spec what is built and then set the version number dynamically. Worked in the home and devel repo. But was then rejected by factory. Second try was with 3 spec and change files for Leap 15.5, 15.6 and for Tumblweed. Also worked in home and devel repo. But again factory rejects it. Factory says it has no change file. But it actually has three! What should or can I do now to have a package that builds once for Leap in version A and for Tumbleweed in version X? Regards Eric

2 2

python311-kombu blocked by missing python311-boto3 in devel:languages:python
by Keil 04 Apr '24

04 Apr '24

Hi, currently python311-kombu does not build in the devel project because it misses python311-boto3, which is only built for plain python3. This makes python311-celery in turn uninstallable in 15.5 or 15.6 as this directly translates to devel:languages:python or :backports respectively. All build fine in Factory. I'm happy to raise this anywhere else, it just wasn't obvious to me where this fits best. Best regards, Christian

5 13

Packaging entry-point only Python packages
by Matthias Bach 02 Apr '24

02 Apr '24

Hi, Upstream Typer [1] has recently split up their package into the following: * typer-slim providing the core functionality * typer-cli providing the entry point for the optional typer command, and * typer which pulls in the other two and all optional dependencies. Trying to adjust the openSUSE package, I have into the following error being reported from rpmlint: python310-typer-cli.noarch: E: no-dependency-on python-base 3.10 python311-typer-cli.noarch: E: no-dependency-on python-base 3.11 python312-typer-cli.noarch: E: no-dependency-on python-base 3.12 This package only consists of an entry point. Thus, there is no module installed, only "binaries". These are versioned and there is a dependency on the corresponding Python's version of typer-slim. However, it seems as there are not modules installed the dependency on "python(abi)" is not generated. I found in some older threads the suggestion to add "%py_requires". But that macro no longer seems to exist. Is there any recommended way to approach this? I can of course just override the error via rpmlintrc. But I suspect that's not the proper solution to the issue and probably won't work for pushing into Factory. Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke

4 6

Problem verifying signature
by Axel Braun 31 Mar '24

31 Mar '24

Hi, I'm working on a new version of tiff and have a problem with the signature. I have a signature in the download directory, and added the owners gpg Key as source file in the spec. However, when checking in I get the error: docb@X1E:~/buildservice/home:DocB:branches:network:telephony/tiff> osc ci Default log message was not changed. Press 'c' to continue. a)bort, c)ontinue, e)dit: c - package has baselibs.conf: (unchanged) gpg: Signatur vom Do 28 Mär 2024 20:57:55 CET gpg: mittels RSA-Schlüssel 7028E1E83B6BF652 gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel ERROR: signature /home/docb/buildservice/home:DocB:branches:network:telephony/tiff/tiff-4.6.0t.tar.xz.sig does not validate Aborting: service call failed: /usr/lib/obs/service/source_validator --outdir /home/docb/buildservice/home:DocB:branches:network:telephony/tiff/tmpzrbafk6b.source_validator.service A service failed with error: 1 Any idea? Thanks! Axel

2 2

QMK Firmware CLI requirements in devel:languages:python
by Enrico Belleri 01 Mar '24

01 Mar '24

Hello, I would like to include the QMK cli program in Factory. qmk_cli helps to customize, compile and flash the QMK firmware to supported keyboards. To function correctly, qmk_cli needs some python packages that are not in Factory at the moment: - cursor - dotty-dict - halo - hid - hjson - log_symbols - milc - nose - spinners - types-colorama I created the packages already in home:iDesmI:qmk and am soon submitting them to devel:languages:python python-hid in particular requires hidapi libraries but rpmlint complains that I can't name libhidapi-hidraw and libhidapi-libusb explicitly. How to proceed? <https://qmk.fm/> <https://github.com/qmk/qmk_cli> -- Enrico Belleri

3 4

Handling mutually excluding alternatives
by Adam Mizerski 27 Feb '24

27 Feb '24

Hi, I wanted to push sequoia-octopus-librnp to Factory. It's a replacement for Thunderbird's default openpgp implementation. It works by being a drop-in replacement for a shared library librnp.so. What I want to achieve: - MozillaThunderbird-openpgp-librnp and sequoia-octopus-librnp are mutually exclusive - MozillaThunderbird-openpgp-librnp should always be preferred over sequoia-octopus-librnp, unless user explicitly wants it. See my WIP at https://build.opensuse.org/project/show/home:etamPL:branches:mozilla:experi… Here's what I did (just the important bits): MozillaThunderbird.spec Requires: %{name}-openpgp Recommends: %{name}-openpgp-librnp %package openpgp-librnp Provides: %{name}-openpgp Conflicts: %{name}-openpgp sequoia-octopus-librnp.spec Provides: MozillaThunderbird-openpgp Conflicts: MozillaThunderbird-openpgp And it works. Even on a fresh system "zypper in --no-recommends MozillaThunderbird" pulls MozillaThunderbird-openpgp-librnp, but I'm not quite sure if it's something I can rely on. With "--no-recommends" how is zypper choosing MozillaThunderbird-openpgp-librnp over sequoia-octopus-librnp?

3 5

After RPM is before RPM - Changes needed for RPM 4.20
by Dominique Leuenberger 24 Feb '24

24 Feb '24

Dear Tumbleweed hackers and packagers, It is just a few days ago that Factory was updated to RPM 4.19 (and we are still missing a few fixes for packages requiring user() symbols and not providing them) The next RPM version will come - for sure (if previous release cycles are any indication, RPM 4.20 should be out around September) So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. The preferred way to apply patches are, in order: * %autosetup -p1 * %autosetup -N / %autopatch -p1 * %setup / %patch -P <N> -p 1 (upper case P denotes patch number, lower case is the usual patch -p>num> strip level) * If your package has no patches, best to be prepared for the future and use %autosetup over %setup. Technically, RPM preferred would be %setup / %patch N when not using %autosetup/%autopatch, BUT %patch 1 is only supported properly from RPM 4.18 on, Not behaving as expected on older RPMs, like in Leap 15.x. That's why we switched our packages to the backward compatible form %patch -P 1 I (and some others) have started to go through the openSUSE:Factory packages that apply patches using %patchN (found a total of 2066 packages). About 10% of those have been fixed today with SRs to the development projects. I would appreciate it if you'd take a look at your packages over the next few days/weeks/months and adjust them to use autosetup or, if patches are applied conditionally, use the %patch -P N format. Cheers, Dominique

3 2

rubygem packaging: macro for the gems path?
by Johannes Kastl 10 Feb '24

10 Feb '24

Hi all, to silence some of the warnings on the rubygem-krane package I added the following to the gem2rpm.yml file: > :post_install: |- > cd %{buildroot}%{_libdir}/ruby/gems/3.3.0/gems/krane-%{version}/ > rm -rvf .github > rm -vf .gitignore > rm -vf .rubocop-http---shopify-github-io-ruby-style-guide-rubocop-yml > rm -vf .rubocop.yml > sed -i 's|usr/bin/env bash|usr/bin/bash|g' bin/setup > sed -i 's|usr/bin/env bash|usr/bin/bash|g' dev/flamegraph-from-tests > https://build.opensuse.org/package/view_file/home:ojkastl_buildservice:Bran… This works, but obviously only for one ruby version. Is there a convenient macro for this? I failed to find one... Or is there a wrapper macro like the python expand macro, that executes something with each ruby version that is being built? Kind Regards, Johannes

2 1

Re: patching a source outside of %{buildroot}
by Axel Braun 08 Feb '24

08 Feb '24

Hello Dominique, Am Donnerstag, 8. Februar 2024, 16:40:38 CET schrieb Dominique Leuenberger: > On Thu, 2024-02-08 at 16:16 +0100, Axel Braun wrote: > > Hi, > > I need to patch a source file in the /usr/src of the build > > environment. > > > > In absolute terms, this is in /var/tmp/build- > > root/openSUSE_Tumbleweed-x86_64/usr/src > > > > It seems that %autosetup resp %patch0 work only in %{buildroot}, > > which is /var/tmp/build-root/openSUSE_Tumbleweed- > > x86_64/home/abuild/rpmbuild/BUILDROOT/ > > > > Any idea? > > That sounds like something really bad to do for a package (and blocked > by the fact that builds do not run as root) > > Stuff that's been installed to /usr/src comes from a different package. > If this needs patching, then I'd probably target that very package that > installs the sources there. Isn't this an option? Would the patch harm > there? Its a workaround until https://bugzilla.opensuse.org/show_bug.cgi?id=1218423 is fixed. That would be the patch in the source package... > Alternaitvely, copy the stuff form /usr/src into the buildroot, patch > it and make sure your build picks it up from there. Considering you're > patching files from a different package though, the chance of it > breaking is quite high. Beside this, no idea how I make sure that the source inside the buildroot gets picked... Cheers Axel

1 0

patching a source outside of %{buildroot}
by Axel Braun 08 Feb '24

08 Feb '24

Hi, I need to patch a source file in the /usr/src of the build environment. In absolute terms, this is in /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/usr/src It seems that %autosetup resp %patch0 work only in %{buildroot}, which is /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/home/abuild/rpmbuild/BUILDROOT/ Any idea? Thanks Axel

1 0