license of the binary policy
by Jilayne Lovejoy
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/LicensingGuidel...
) 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
1 month, 3 weeks
Guiding co-dependent RPM packages to swap nicely
by Miro Hrončok
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
2 months, 1 week
Pre-Generated Binaries for Perforance from Upstream
by Tim Flink
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
3 months
Import of key(s) didn't help, wrong key(s)?
by Brad Bell
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
3 months
Handling Upstream that has Diverging Licenses in Source Files but not LICENSE file
by Tim Flink
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
3 months
Issues with mock and dnf on rawhide/F40
by José Abílio Matos
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
3 months
python package with binary
by Fabrice
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
3 months, 1 week
%forgesetup failing to unpack *multiple* spec SOURCEs -- usage, or bug?
by pgnd
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-x...),
...
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-x...),
...
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/#_mul...
%forgesetup _should_ correctly unpack BOTH sources
is my usage incorrect in the .spec?
or, a bug here?
3 months, 2 weeks
