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 (iaito) Fails To Install in Fedora 34: can't install iaito: - nothing provides libr_anal.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_asm.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_bin.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_bp.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_config.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_cons.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_core.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_crypto.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_debug.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_egg.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_flag.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_fs.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_hash.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_io.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_parse.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_reg.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_search.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_syscall.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.x86_64 - nothing provides libr_util.so.5.3.1()(64bit) needed by iaito-5.2.2-3.fc34.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. 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!
I guess this a false notification due to the radare2-5.4.0 buildroot override? If it's preferred to always use side-tags for dependent package updates then maybe the contributor documentation should be updated to deprecate buildroot overrides and solidly point to side-tags instead? https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages Note: the link to Package Update Guide in the Fails_to_build_from_source_Fails_to_install referenced from your bug description also needs an update, right now points to the wiki which refers back to docs. In this case there is a buildroot override of radare2 to 5.4.0, and a pending update of radare2-5.4.0+iaito-5.3.1 https://bodhi.fedoraproject.org/updates/FEDORA-2021-d206891379 All in compliance with both https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages and https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages I also remember seeing some other contributor document that is a bit ambivalent about side-tags vs buildroot overrides, recommending buildroot overrides for simple updates of a small amount of packages and site-tags for larger updates affecting many packages.
(In reply to Henrik Nordström from comment #1) > I guess this a false notification due to the radare2-5.4.0 buildroot > override? Possibly, yes. To mostly avoid them, expire your override when done. > If it's preferred to always use side-tags for dependent package updates then > maybe the contributor documentation should be updated to deprecate buildroot > overrides and solidly point to side-tags instead? > > https://docs.fedoraproject.org/en-US/package-maintainers/ > Package_Update_Guide/#updating_inter_dependent_packages Ack. Will discuss this on the mailing list. > Note: the link to Package Update Guide in the > Fails_to_build_from_source_Fails_to_install referenced from your bug > description also needs an update, right now points to the wiki which refers > back to docs. Will do, thanks. > In this case there is a buildroot override of radare2 to 5.4.0, and a > pending update of radare2-5.4.0+iaito-5.3.1 > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-d206891379 > > All in compliance with both > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter- > dependent-packages > and > https://docs.fedoraproject.org/en-US/package-maintainers/ > Package_Update_Guide/#updating_inter_dependent_packages Indeed you are correct, sorry for the noise. As said, expiring the override when done should prevent this bugzilla or at least close it once the script runs again. > I also remember seeing some other contributor document that is a bit > ambivalent about side-tags vs buildroot overrides, recommending buildroot > overrides for simple updates of a small amount of packages and site-tags for > larger updates affecting many packages. Maybe it was about releng-operated side-tags?
(In reply to Miro Hrončok from comment #2) > sorry for the noise No worry. But at first got me worried that I had messed up something. The current process is a bit tedious for an otherwise very small change (version bump of one package, radare2 in this case), and easy to miss a step. I am lucky there is just one dependent package and do not envy those that need to maintain packages with many dependent packages that need to be rebuilt without change every version bump. 1. Update actual updated package spec and sources 2. Build and fix any issues if any. 3. Create override (or side-tag) 4. Bump rev of dependent package spec to allow it to be rebuilt 5. Wait for buildroot 6. Build dependent package 7. Create update with both packages and repeat up to 4 times (rawhide, F35, F34, F33) (well, no override in rawhide) > As said, expiring the override when done should prevent this > bugzilla or at least close it once the script runs again. buildroot overrides expire by default in one week (fedpkg) or when the package gets pushed to stable. So it's not much to gain from adding yet another step in the process.
Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok). All subpackages of a package against which this bug was filled are now installable or removed from Fedora 34. Thanks for taking care of it!