packaging February 2024

packaging@lists.fedoraproject.org

15 participants
8 discussions

license of the binary policy
by Jilayne Lovejoy 25 Mar '24

25 Mar '24

Hi Fedora legal and packaging, I'm cross-posting this, as I think it's relevant to both groups. The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelin… ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask." As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following: 1) how do you (package maintainers) interpret this policy in practice? 2) what further information/documentation about this policy would be helpful? 3) should this policy be different, and if so, how? 4) any other related thoughts or observations Thanks! Jilayne

12 39

Guiding co-dependent RPM packages to swap nicely
by Miro Hrončok 08 Mar '24

08 Mar '24

Hello. Assume I have two "stacks" of RPM packages available: postgresql16 provides postgresql-any version 16 conflicts with other postgresql-any postgresql16-plugin provides postgresql-any-plugin requires postgresql16 conflicts with other postgresql-any-plugin postgresql20 provides postgresql-any version 20 conflicts with other postgresql-any postgresql20-plugin provides postgresql-any-plugin requires postgresql20 conflicts with other postgresql-any-plugin On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*. Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20 However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin. Is there something I can do as a package maintainer to "guide" the co-dependent swap case? I was thinking something like: postgresql20-plugin: Obsoletes: (postgresql-any-plugin if postgresql-any != 20) However that is not possible in RPM, "No rich dependencies allowed for this type: Obsoletes". Is there anything else? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 4

Pre-Generated Binaries for Perforance from Upstream
by Tim Flink 19 Feb '24

19 Feb '24

I have another question about the review of miopen [1][2] but this time it's about the upstream's use of pre-generated binary files. The miopen upstream includes many compressed binaries (pretty much one per supported GPU architecture) which, according to their documentation, are tuning values meant to give its auto-tuning feature a good place to start from [3] in order to boost initial performance. As I write this, there is not a fully documented way to generate those tuning values at build time but we could just not include those tuning values if we accept the performance hit that would entail. A ticket has been filed upstream asking for an alternative to using the pre-built binary files [4] which has explained some of the process. My question is: do these binary files fall into the category of "If the content enhances the OS user experience, then the content is OK to be packaged in Fedora."? At the moment, my assumption is that the binary files are not allowed if the build process is not completely documented. If the build process is documented, they could be allowed but building/optimizing from scratch at package build time would be preferred. I would appreciate insight that folks may have. Thanks, Tim [1] https://bugzilla.redhat.com/show_bug.cgi?id=2261201 [2] https://github.com/ROCm/MIOpen [3] https://github.com/ROCm/MIOpen/blob/develop/docs/perfdatabase.md [4] https://github.com/ROCm/MIOpen/issues/2742

2 1

Import of key(s) didn't help, wrong key(s)?
by Brad Bell 17 Feb '24

17 Feb '24

I recently got the the response during a fedpkg mockbuild (that used to work). How should I proceed ? Not downloading unused CppAD-20240000.2.tar.gz setting SOURCE_DATE_EPOCH=1707955200 Wrote: /home/bradbell/fedora/cppad/cppad-20240000.3-1.fc41.src.rpm INFO: mock.py version 5.2 starting (python version = 3.12.0, NVR = mock-5.2-1.fc39), args: /usr/libexec/mock/mock -r fedora-rawhide-x86_64 --resultdir /home/bradbell/fedora/cppad/results_cppad/20240000.3/1.fc41 --rebuild /home/bradbell/fedora/cppad/cppad-20240000.3-1.fc41.src.rpm Start(bootstrap): init plugins . . . [SKIPPED] zstd-1.5.5-5.fc40.x86_64.rpm: Already downloaded fedora 1.6 MB/s | 1.6 kB 00:00 Importing GPG key 0xA15B79CC: Userid : "Fedora (40) <fedora-40-primary(a)fedoraproject.org>" Fingerprint: 115D F9AE F857 853E E844 5D0A 0727 707E A15B 79CC From : /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary Key imported successfully fedora 1.6 MB/s | 1.6 kB 00:00 GPG key at file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary (0xA15B79CC) is already installed fedora 1.6 MB/s | 1.6 kB 00:00 Importing GPG key 0x18B8E74C: Userid : "Fedora (39) <fedora-39-primary(a)fedoraproject.org>" Fingerprint: E8F2 3996 F232 1864 0CB4 4CBE 75CF 5AC4 18B8 E74C From : /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary Key imported successfully Import of key(s) didn't help, wrong key(s)? Public key for alternatives-1.26-3.fc40.x86_64.rpm is not installed. Failing package is: alternatives-1.26-3.fc40.x86_64 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary Public key for ansible-srpm-macros-1-14.fc40.noarch.rpm is not installed. Failing package is: ansible-srpm-macros-1-14.fc40.noarch GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary

4 4

Handling Upstream that has Diverging Licenses in Source Files but not LICENSE file
by Tim Flink 16 Feb '24

16 Feb '24

I'm doing a review for miopen [1][2] and I'm hitting an issue with the license file(s) that I'm not sure how to handle. I suspect that this isn't a unique situation so I'm asking here. The upstream is distributed as MIT but contains a few files which have additional or different licenses. Two files include BSD-2-Clause, two files include Apache-2.0 and one is Public Domain. The upstream project includes a LICENSE.txt file which only contains the MIT license. As I understand packaging policy, we're only supposed to include license text which is present upstream. If the package only includes the LICENSE.txt file with the binaries, that's missing the BSD and Apache licenses. I'm unclear on how this is supposed to be handled. Can't we just include the text from the files with non-MIT licenses in a separate file or by appending them to the end of upstream's LICENSE.txt? We could ask upstream to include the BSD-2-Clause and Apache-2.0 text in their LICENSE file but this seems like something that's not really their problem. They're not distributing binaries, they're distributing the copyright notice with the individual files. Does anyone have knowledge on how situations like this have been handled in the past? Thanks, Tim [1] https://bugzilla.redhat.com/show_bug.cgi?id=2261201 [2] https://github.com/ROCm/MIOpen

6 6

Issues with mock and dnf on rawhide/F40
by José Abílio Matos 15 Feb '24

15 Feb '24

Hi, while testing building some packages on rawhide, using mock --rebuild, I got into trouble with the following error: $ mock -r fedora-40-x86_64 --rebuild pygsl-2.3.4-1.fc41.src.rpm Start: installing minimal buildroot with dnf5 execv(/usr/bin/dnf5) failed: No such file or directory ERROR: Exception(pygsl-2.3.4-1.fc41.src.rpm) Config(fedora-rawhide-x86_64) 0 minutes 2 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result ERROR: Command failed: # /usr/bin/systemd-nspawn -q -M 3740df7c87a249ebb62eeaed758aea07 -D /var/lib/ mock/fedora-rawhide-x86_64-bootstrap/root -a --capability=cap_ipc_lock -- bind=/tmp/mock-resolv.dpfedow6:/etc/resolv.conf --console=pipe -- setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/var/lib/mock/fedora- rawhide-x86_64/root/installation-homedir --setenv=HOSTNAME=mock -- setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin '--setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007"' '--setenv=PS1=<mock-chroot> \s-\v\$ ' -- setenv=LANG=C.UTF-8 --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/ dnf5 --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 41 install @buildsys-build --setopt=deltarpm=False -- setopt=allow_vendor_change=yes --allowerasing --setopt=tsflags=nocontexts execv(/usr/bin/dnf5) failed: No such file or directory This happened last week from F39 and now also with F40. The only option for me was to add --config-opts='package_manager=dnf' to the call. How can I fix that? Either to use dnf4 or dnf5 without further changes? Are there any configuration files that are changed on my installation? Best regards, -- José Abílio Matos

2 2

python package with binary
by Fabrice 11 Feb '24

11 Feb '24

Hi, A long time ago I have created a spec file for python-radexreader: https://src.fedoraproject.org/rpms/python-radexreader But today, I have a problem. I'm working on version 2.0.0, and the program will provide graphical interfaces. With Debian, it's easy, currently the "spec" makes: - python3-radexreader (python library) - radexreader (cli command line) I have added: - radexreader-gtk3 - radexreader-gtk4 - radexreader-qt5 - radexreader-qt6 But with Fedora (and openSUSE), currently the spec file makes: - python3-radexreader (python library and cli command line) I guess I'll have to update the specs this way: ---- %package -n python3-radexreader Summary: ... BuildRequires: ... Requires: ... %description -n python3-radexreader ... %files -n python3-radexreader ... %package -n radexreader Summary: ... BuildRequires: ... Requires: ... %description -n radexreader ... %files -n radexreader ... %package -n radexreader-gtk3 Summary: ... BuildRequires: ... Requires: ... %description -n radexreader-gtk3 ... %files -n radexreader-gtk3 ... ... --- Is it correct? Thanks! All is based on https://packages.debian.org/source/trixie/scour + https://src.fedoraproject.org/rpms/python-scour

2 1

%forgesetup failing to unpack *multiple* spec SOURCEs -- usage, or bug?
by pgnd 02 Feb '24

02 Feb '24

i'm building a 2-source pkg @ COPR (https://copr.fedorainfracloud.org/coprs/pgfed/test/) i'm using %forge pkg'ing macros. my spec contains Source0: %{forgesource0} Source1: %{forgesource1} if %prep contains (@ test1.spec) ... %prep %forgesetup -a (or %forgesetup -z 0 %forgesetup -z 1 ) exit 255 ... COPR build fails to unpack the 2nd SOURCE (https://download.copr.fedorainfracloud.org/results/pgfed/test/fedora-39-x86…) ... archiveurl0: https://api.github.com/repos/owasp-modsecurity/ModSecurity/tarball/v3.0.12 ... extractdir0: owasp-modsecurity-ModSecurity-e7ecdd6 ... forgesource1: https://api.github.com/repos/client9/libinjection/tarball/v3.10.0 ... extractdir1: client9-libinjection-bf234eb ... Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.2IIb7G + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf owasp-modsecurity-ModSecurity-e7ecdd6 + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/v3.0.12 + STATUS=0 + '[' 0 -ne 0 ']' + cd owasp-modsecurity-ModSecurity-e7ecdd6 + rm -rf /builddir/build/BUILD/owasp-modsecurity-ModSecurity-e7ecdd6-SPECPARTS + /usr/bin/mkdir -p /builddir/build/BUILD/owasp-modsecurity-ModSecurity-e7ecdd6-SPECPARTS + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . + cd /builddir/build/BUILD + rm -rf client9-libinjection-bf234eb + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/v3.0.12 + STATUS=0 + '[' 0 -ne 0 ']' + cd client9-libinjection-bf234eb /var/tmp/rpm-tmp.2IIb7G: line 52: cd: client9-libinjection-bf234eb: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.2IIb7G (%prep) ... NOTE, that after the proc'ing of the 2nd SOURCE begins, + rm -rf client9-libinjection-bf234eb rpmuncompress execs, **incorrectly**, on the **1st** SOURCE @ /builddir/build/SOURCES/v3.0.12 rather than the /builddir/build/SOURCES/v3.10.0 OTOH, if i mod %prep (@ test2.spec; otherwise unchanged ...), ... %prep - %forgesetup -a + rm -rf %{extractdir0} + rm -rf %{extractdir1} + /usr/lib/rpm/rpmuncompress -x -v %{_sourcedir}/%{branch0} + pigz -dcq "%{_sourcedir}/%{branch0}" | tar -xvvof - + /usr/lib/rpm/rpmuncompress -x -v %{_sourcedir}/%{branch1} + pigz -dcq "%{_sourcedir}/%{branch1}" | tar -xvvof - exit 255 ... the build 'fails correctly, at the `exit 255`, after correctly unpacking BOTH sources (https://download.copr.fedorainfracloud.org/results/pgfed/test/fedora-39-x86…) ... RPM build errors: + /bin/cp -af /builddir/build/BUILD/client9-libinjection-bf234eb/src /builddir/build/BUILD/owasp-modsecurity-ModSecurity-e7ecdd6/others/libinjection/ + exit 255 iiuc https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_multi… %forgesetup _should_ correctly unpack BOTH sources is my usage incorrect in the .spec? or, a bug here?

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2024