Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok). Your package (kubernetes) Fails To Install in Fedora 38: can't install kubernetes-kubeadm: - nothing provides cri-tools needed by kubernetes-kubeadm-1.24.4-1.fc38.x86_64 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-38-x86_64 --config-opts mirrored=False install kubernetes-kubeadm 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!
cri-tools-1.24.2-1.fc38 has been built in rawhide. It was available in f37, but it seems not to have been branched properly.
Thanks for the assist. If I understand the cri-o module correctly, cri-tools is packaged as part of the cri-o module, although as far as I can tell cri-tools is not modularized per se. Will the cri-o module need to be refreshed to pick up the cri-tools update?
(In reply to Brad Smith from comment #2) > Thanks for the assist. If I understand the cri-o module correctly, cri-tools > is packaged as part of the cri-o module, although as far as I can tell > cri-tools is not modularized per se. Will the cri-o module need to be > refreshed to pick up the cri-tools update? I did not see this comment before I wrote my comment about modules on the other issue. The modular and non-modular packages are built separately. I only touched the non-modular package. I'm not sure about the history of these packages or why they were built as modules in the first place. I am not really a maintainer of this package. I saw it pop up on the list of Go packages that failed to build from source in the F37 Rebuild and performed the latest update as a member of the Go SIG.
(In reply to Maxwell G from comment #3) > I did not see this comment before I wrote my comment about modules on the > other issue. > > The modular and non-modular packages are built separately. I only touched > the non-modular package. I'm not sure about the history of these packages or > why they were built as modules in the first place. I am not really a > maintainer of this package. I saw it pop up on the list of Go packages that > failed to build from source in the F37 Rebuild and performed the latest > update as a member of the Go SIG. Much appreciated! Hopefully Peter will have a spare cycle soon and provide clarity on what is needed. I added a comment on https://bugzilla.redhat.com/show_bug.cgi?id=2045288 that reflects my understanding of versioning for cri-tools, cri-o and kubernetes (basically they should be in sync on majrr:minor versions).