Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ Your package (tuned) Fails To Install in Fedora 40: can't install tuned: - nothing provides python3-perf needed by tuned-2.21.0-2.fc40.noarch If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. To reproduce, use the koji/local repo only, e.g. in mock: $ mock -r fedora-40-x86_64 --config-opts mirrored=False install tuned P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks!
Bug in rc0 kernel package, fixed in rc3 kernel package.
It seems kernel-6.8.0-0.rc3.26.fc40 is not tagged and rawhide still installs rc0, reassigning to kernel.
For the record, when you do this, Fedora Fails To Install will open a new bugzilla for tuned, as it does not understand this is it (as it is assigned to kernel).
(In reply to Miro Hrončok from comment #3) > For the record, when you do this, Fedora Fails To Install will open a new > bugzilla for tuned, as it does not understand this is it (as it is assigned > to kernel). NP, I expected this could happen. I will switch the new tuned bug to assigned state and I will link both bugs.
Moving back to tuned, because I suspect the automation will close it in the next round.
Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ All subpackages of a package against which this bug was filled are now installable or removed from Fedora 40. Thanks for taking care of it!
This is very much not fixed yet. Quick test: podman run -it --rm registry.fedoraproject.org/fedora:rawhide dnf install tuned It looks like this is a kernel bug, unintentionally dropping the python3-perf package, so moving back. (It still amazes me that this can even happen in Fedora..)
Probably some caching, I can still see python3-perf in the latest koji build (kernel-6.8.0-0.rc3.20240208git047371968ffc.30.fc40): https://koji.fedoraproject.org/koji/buildinfo?buildID=2400216 But unfortunately me as the TuneD maintainer cannot fix it.
Jaroslav: It's caching the other way round, not "still", but "already". Allegedly rc3 brings back the RPM (see comment #1), but that kernel isn't "visible" on the public mirrors. podman run -it --rm registry.fedoraproject.org/fedora:rawhide dnf info kernel still shows rc0. And as it has been that way for at least 4 days, it's not just the usual mirror delay (which is usually less than 1 day). And even still, Testing Farm enables the "tag repository" which makes koji builds visible to dnf pretty much instantly. So, I don't know either what's wrong. :-(
This is fixed, but the fix has not been delivered yet trough the compose. It is normal for Fedora rawhdie update to take a while before reaching the compose and the mirrors.
$ mock -r fedora-40-x86_64 --config-opts mirrored=False install tuned ... Installing: tuned noarch 2.21.0-2.fc40 local 1.3 MiB Installing dependencies: ... python3-perf x86_64 6.8.0-0.rc3.20240208git047371968ffc.30.fc40 local 300.5 KiB ...
In the container, enabling the "tag" repo: $ podman run -it --rm registry.fedoraproject.org/fedora:rawhide [root@1410905c3830 /]# cat > /etc/yum.repos.d/koji.repo << EOF [koji] name=koji baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ enabled=1 EOF [root@1410905c3830 /]# dnf install tuned Last metadata expiration check: 0:00:42 ago on Fri Feb 9 12:09:50 2024. Dependencies resolved. ================================================================================ Package Arch Version Repo Size ================================================================================ Installing: tuned noarch 2.21.0-2.fc40 rawhide 461 k Installing dependencies: ... python3-perf x86_64 6.8.0-0.rc3.20240208git047371968ffc.30.fc40 koji 267 k ...
Just for some background here...it's not quite as simple as a "bug" in the kernel package, exactly. What actually happened is that python3-perf used to be built as part of kernel-tools, but they decided to roll it (back) into the main kernel package: https://src.fedoraproject.org/rpms/kernel-tools/c/f95007956e0f6ae0aedd4c34ad973da745bf1f20?branch=rawhide https://src.fedoraproject.org/rpms/kernel/c/53455140abeb5eba3a409a4a89f2a1358362f164?branch=rawhide Unfortunately, the kernel-tools retirement went through (there are absolutely no automated checks on package retirements, which is awkward in several ways), but the kernel update to add python3-perf failed gating due to https://bugzilla.redhat.com/show_bug.cgi?id=2261842 . So the package disappeared until that bug was resolved and a kernel update made it through gating. I got here https://bugzilla.redhat.com/show_bug.cgi?id=2260395 , but the fact that package retirements aren't subject to any kind of check at all is kind of a bigger hole than the whole question of checking/enforcing dependencies on package updates that is discussed there, in a way. Unfortunately it's also very tricky resolve, because there just isn't a gating "point" for package retirements. Package updates go through Bodhi, that's the gating point. Retirements don't go through Bodhi or anything analogous do it that can currently perform any kind of gating check. We would have to address that, somehow. I don't know *exactly* what the best way would be; it kinda depends on the details of how the Koji blocking detailed in https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ works. If it cues off repos with `dead.package` files, we could possibly implement some kind of commit hook that runs a check on commits that look like retirements (i.e. commits that just replace the entire repo with a `dead.package` file), I guess. Then we just have to write the check...and make it reliable... I am at least going to file an issue for this, because it's been bugging me for a while. The other classic problem with retiring packages is when they drop something that's listed in comps or a kickstart or a workstation-ostree-config or FCOS manifest, doing that should trigger at minimum some kind of warning.
Oh, hey, fun, it seems the retirement process *actually* runs through PDC, which functions as the source of truth about whether a package is retired: https://pagure.io/releng/issue/11723 PDC always makes things more fun!
Filed https://pagure.io/releng/issue/11957
This is entirely my fault. I had been building the kernel with kernel-tools for a while before I retired kernel-tools, it just slipped my mind that gating was keeping the new kernel-tools from making it into the repository. It took me a bit to find the fix for kernel to get things through gating once I was made aware the kernel-tools subpackages were not in the repository(which turned out to not be a kernel bug). For what it's worth, I expect most package retirements are not a simple matter of moving packages to be sub-packages of a different package. Perhaps this isn't a common problem.
This specific case isn't super common, but the broader category "this package retirement screwed something up" definitely happens quite commonly. :) But we can follow-up on that over in the releng issue I guess. Thanks for cleaning it up.