On Fri, Mar 6, 2020 at 10:18 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Fri, 2020-03-06 at 21:35 +0100, Fabio Valentini wrote: > > Hi all, > > > > With the fedora 32 release drawing near, it might be a good time to > > check if any of your packages still have broken dependencies in the > > fedora 32 (+testing) repositories. I've been working on just the thing > > you need: > > > > Report without testing repos enabled: > > https://pagure.io/fedora-health-check/blob/master/f/reports/report-32.md > > > > Report with testing repos enabled: > > https://pagure.io/fedora-health-check/blob/master/f/reports/report-32-testing.md > > > > Problematic packages are listed per main maintainer (according to > > src.fedoraproject.org), and broken dependencies are listed per package > > and per architecture. > > > > The complete report data are also available in machine-readable JSON > > format. Additionally, rich diffs between updates and updates-testing > > (for non-rawhide branches) are also generated from the data. > > > > Caveats: > > - there's an infra/koji bug where ExcludeArch'ed noarch packages get > > copied to repositories for explicitly excluded architectures: > > https://pagure.io/koji/issue/1843 > > - architecture-specific BuildRequires are not tracked correctly, > > because source RPMs get built on one architecture and copied to source > > repositories for all arches, and hence might contain broken > > dependencies on foreign-arch BuildRequires > > > > However, the script that generates the data and reports has support > > for overriding false positives. If any of your packages are listed but > > should not be (because of one of the two caveats, or for another > > reason), please tell me (either with an E-Mail, or by opening a ticket > > on the pagure project). Whenever I came across any verifiable false > > positives, I already added them to the permanent overrides. The > > current list can be viewed here (JSON format): > > > > https://pagure.io/fedora-health-check/blob/master/f/overrides.json > Thanks for this! Is this going to be wired into the compose process so > we get a report every compose like we used to? I've been thinking about this lately, but doing that would require some more work: - integrating the code into a new web/cloud service that's keeping track of finished composes (or even koji buildroots?) - properly keeping track of history in a database instead of in the git history on pagure 😈️ So ... given that I've been working on this alone and have almost no experience with writing web services, I don't think it's likely to happen (at least, definitely not anytime soon). It would be nice though ... maybe I can find some time to work on this after all :) Fabio > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
