libguestfs fails to build with Python 3.13.0a2. + mkdir cachedir repo + find /var/cache/dnf /var/cache/yum -type f -name '*.rpm' -print0 + xargs -0 -n 1 cp -t repo cp: missing file operand Try 'cp --help' for more information. This may not be related to Python 3.13 but I've seen successful builds of libguestfs in Koschei in Fedora Rawhide, and the Copr build failed, hence the report. For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.13/fedora-rawhide-x86_64/06864056-libguestfs/ For all our attempts to build libguestfs with Python 3.13, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.13/package/libguestfs/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.13: https://copr.fedorainfracloud.org/coprs/g/python/python3.13/ Let us know here if you have any questions. Python 3.13 is planned to be included in Fedora 41. To make that update smoother, we're building Fedora packages with all pre-releases of Python 3.13. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
The problem seems to be related to Koji & dnf5. We normally expect to find a cache of the RPMs that were used during installation in /var/cache/dnf, but in this case they are not available. Possibly the builder needs to set this in dnf.conf: keepcache=1 See: https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.org/thread/ZIBY53JAURLT3QRBBJIJJ7EZWLZDE3TI/ If this is already set, then possibly the cache is no longer in /var/cache/dnf (maybe /var/cache/dnf5 instead?) I'm not sure who maintains this Koji instance, so where this bug should be redirected.
> I'm not sure who maintains this Koji instance. It is Copr, but the plan is to switch Koji as well: https://fedoraproject.org/wiki/Changes/BuildWithDNF5
Thank you for the report. This seems like that with dnf5, caches are not stored within --installroot, and also that the directory is /var/cache/libdnf5 It also seems that cachedir option is not respected. [main] keepcache=1 cachedir=/var/cache/dnf
The man dnf5-installroot says: The --installroot parameter is used to specify an alternative install‐ root, relative to where all packages will be installed. Think of it like doing chroot <root> dnf, except using --installroot allows DNF5 to work before the chroot is created. cachedir, log files, releasever, and gpgkey are taken from or stored in the installroot. GPG keys are imported into the installroot from a path relative to the host which can be specified in the repository section of configuration files. The following commands caches RPMs in /tmp/the-cache though on host: dnf5 --use-host-config --installroot /tmp/the-root install dnf-data fedora-repos --setopt=cachedir=/tmp/the-cache --setopt=keepcache=1 dnf5 --installroot /tmp/the-root install tar --setopt=cachedir=/tmp/the-cache --setopt=keepcache=1 The configuration in dnf.conf is ignored: rm -rf /tmp/the-root /tmp/the-cache dnf5 -y --use-host-config --installroot /tmp/the-root install dnf-data fedora-repos --setopt=cachedir=/tmp/the-cache --setopt=keepcache=1 echo cachedir=/tmp/xyz >> /tmp/the-root/etc/dnf/dnf.conf echo keepcache=1 >> /tmp/the-root/etc/dnf/dnf.conf dnf5 -y --installroot /tmp/the-root install tar In this case, I'm unable to find tar-1.35-2.fc39.x86_64.rpm anywhere. rpm -q dnf5 libdnf5 libdnf rpm dnf5-5.1.10-1.fc39.x86_64 libdnf5-5.1.10-1.fc39.x86_64 libdnf-0.72.0-1.fc39.x86_64 rpm-4.19.1-1.fc39.x86_64
Thanks for the bug report and to Pavel for the investigation. We are finding a healthy number of DNF 5 bugs since deploying it on Copr :) In my view there are a couple things going on: 1) When run as root, DNF 5 stores cache in /var/cache/libdnf5 by default, not /var/cache/dnf. This directory can be redefined using the `system_cachedir` configuration (rather than `cachedir`). When run as a non-root user, DNF 5 stores cache in ~/.cache/libdnf5, and that location is set with the `cachedir` option. Previously, DNF 4 had only the `cachedir` option and all users shared the system cache at /var/cache/dnf. See https://dnf5.readthedocs.io/en/latest/misc/caching.7.html#caching-misc-ref-label. 2) The `system_cachedir` and `cachedir` options are not currently treated as relative to the installroot, and Pavel is right: this current behavior does not match our documentation. I have opened a PR [0] to treat the cachedir options as paths relative to the installroot. With this patch, the default cache directory will be $installroot/var/cache/libdnf5, so you should be able to find your cached RPMs there. I did not notice any issue with the `keepcache` option after making sure the cache was in the right place. [0] https://github.com/rpm-software-management/dnf5/pull/1148
Thanks for this explanation. I have changed libguestfs so it also looks in /var/cache/libdnf5 ... https://src.fedoraproject.org/rpms/libguestfs/c/43a1d7a11032d396a019cce570d7ef47d59168f3?branch=rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=111493567
+ mkdir cachedir repo + find /var/cache/dnf /var/cache/libdnf5 /var/cache/yum -type f -name '*.rpm' -print0 + xargs -0 -n 1 cp -t repo find: ‘/var/cache/libdnf5’: No such file or directory cp: missing file operand Try 'cp --help' for more information.
Evan wrote: > This directory can be redefined using the `system_cachedir` configuration (rather than `cachedir`) Good to know. Can we set `system_cachedir=/var/cache/dnf` in Mock like this? https://github.com/rpm-software-management/mock/pull/1282 Namely, wouldn't this cause some weird collision with other caches? I assume /var/cache/dnf is entirely unused by DNF5 by default. But please confirm. Miro wrote: > cp: missing file operand Seems like an innocent warning, since we don't use Shell's pipefail.
(In reply to Miro Hrončok from comment #7) > + mkdir cachedir repo > + find /var/cache/dnf /var/cache/libdnf5 /var/cache/yum -type f -name > '*.rpm' -print0 > + xargs -0 -n 1 cp -t repo > find: ‘/var/cache/libdnf5’: No such file or directory > cp: missing file operand > Try 'cp --help' for more information. Where did this error come from, and is that the full output? As you can see from here the package built fine in Fedora's koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=2342515
(In reply to Richard W.M. Jones from comment #9) > (In reply to Miro Hrončok from comment #7) > > + mkdir cachedir repo > > + find /var/cache/dnf /var/cache/libdnf5 /var/cache/yum -type f -name > > '*.rpm' -print0 > > + xargs -0 -n 1 cp -t repo > > find: ‘/var/cache/libdnf5’: No such file or directory > > cp: missing file operand > > Try 'cp --help' for more information. > > Where did this error come from, and is that the full output? > > As you can see from here the package built fine in Fedora's koji: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2342515 It's from Python 3.13 Copr: https://copr.fedorainfracloud.org/coprs/g/python/python3.13/build/6873426/ See https://download.copr.fedorainfracloud.org/results/@python/python3.13/fedora-rawhide-x86_64/06873426-libguestfs/builder-live.log.gz for the full build log.
I see, that's probably because of https://github.com/rpm-software-management/dnf5/pull/1148 I have pushed the following change to libguestfs so that it shouldn't try looking in directories that don't exist: https://src.fedoraproject.org/rpms/libguestfs/c/3a2a7734bd3ab7e848d8e04cf26a7f5215d6c9aa?branch=rawhide
Unfortunately this hasn't helped with the Copr build: https://download.copr.fedorainfracloud.org/results/@python/python3.13/fedora-rawhide-x86_64/06875768-libguestfs/builder-live.log.gz
Yes I wouldn't expect that to fix it. It needs https://github.com/rpm-software-management/dnf5/pull/1148
Alright, https://github.com/rpm-software-management/dnf5/pull/1148 has been merged. Pavel, is there an easy way to try a build on Copr with the latest DNF 5 nightly (from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/), or will we need to wait for a new DNF 5 release? Pavel wrote: > Good to know. Can we set `system_cachedir=/var/cache/dnf` in Mock like this? https://github.com/rpm-software-management/mock/pull/1282 I reviewed your PR, yes, that's possibly the best course of action since packages like this one would not have to switch over to looking in /var/cache/libdnf5.
Fixed mock-core-configs released: https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.4