Bug 2262526 - F40FailsToInstall: tuned, missing python3-perf sub package
Summary: F40FailsToInstall: tuned, missing python3-perf sub package
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Whiteboard: CockpitTest
Depends On:
TreeView+ depends on / blocked
Reported: 2024-02-03 16:55 UTC by Fedora Fails To Install
Modified: 2024-02-15 22:17 UTC (History)
23 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2024-02-15 21:12:38 UTC
Type: ---

Attachments (Terms of Use)

Description Fedora Fails To Install 2024-02-03 16:55:31 UTC

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


Comment 1 Jaroslav Škarvada 2024-02-05 17:45:19 UTC
Bug in rc0 kernel package, fixed in rc3 kernel package.

Comment 2 Jaroslav Škarvada 2024-02-06 11:49:04 UTC
It seems kernel-6.8.0-0.rc3.26.fc40 is not tagged and rawhide still installs rc0, reassigning to kernel.

Comment 3 Miro Hrončok 2024-02-06 13:17:38 UTC
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).

Comment 4 Jaroslav Škarvada 2024-02-07 20:34:59 UTC
(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.

Comment 5 Miro Hrončok 2024-02-08 13:27:51 UTC
Moving back to tuned, because I suspect the automation will close it in the next round.

Comment 6 Fedora Fails To Install 2024-02-08 13:29:20 UTC

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!

Comment 7 Martin Pitt 2024-02-09 06:20:42 UTC
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..)

Comment 8 Jaroslav Škarvada 2024-02-09 10:35:12 UTC
Probably some caching, I can still see python3-perf in the latest koji build (kernel-6.8.0-0.rc3.20240208git047371968ffc.30.fc40):

But unfortunately me as the TuneD maintainer cannot fix it.

Comment 9 Martin Pitt 2024-02-09 10:44:02 UTC
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. :-(

Comment 10 Miro Hrončok 2024-02-09 12:03:40 UTC
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.

Comment 11 Miro Hrončok 2024-02-09 12:04:56 UTC
$ mock -r fedora-40-x86_64 --config-opts mirrored=False install tuned
 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

Comment 12 Miro Hrončok 2024-02-09 12:11:02 UTC
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

[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
 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

Comment 13 Adam Williamson 2024-02-15 18:51:24 UTC
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:


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.

Comment 14 Adam Williamson 2024-02-15 18:53:17 UTC
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!

Comment 15 Adam Williamson 2024-02-15 19:05:30 UTC
Filed https://pagure.io/releng/issue/11957

Comment 16 Justin M. Forbes 2024-02-15 21:12:38 UTC
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.

Comment 17 Adam Williamson 2024-02-15 22:17:11 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.