Re: Reducing broken dependencies in fedora (32) repositories
On Wed, Mar 11, 2020 at 2:17 PM Igor Gnatenko wrote: > > We could if somebody will commit on maintaining those packages in stable > releases, keep them always updated, insert proper Obsoletes and create compat > packages all the time. I volunteered to work on stable-release rust packages, and to create compat packages as necessary. I probably won't be able to do this alone, but given the interest in this thread, I think we should be able to do it. > The good news are that Koji maintainers implemented necessary configuration > and when new version will be released and deployed in infra, anybody will be > able to update them in stable using SOP. I don't think rust packages should be treated in any special way here. Every other language ecosystem is dealing with this problem already, so Rust should manage as well. I am not against improving infrastructure, I'm just against making Rust a special case here (since it's actually more nicely behaved as an ecosystem than, for example, Go). Fabio > On Mon, Mar 9, 2020, 18:40 Zbigniew Jędrzejewski-Szmek > wrote: >> >> On Mon, Mar 09, 2020 at 04:53:25PM +0100, Fabio Valentini wrote: >> > On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek >> > wrote: >> > > >> > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: >> > > > 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 >> > > >> > > I see a lot of rust packages on this list, but I can't quite figure out >> > > what is wrong: >> > > >> > > For rust-zram-generator, mock says: >> > > Problem 1: nothing provides requested (crate(failure/default) >= 0.1.0 >> > > with crate(failure/default) < 0.2.0) >> > > Problem 2: nothing provides requested (crate(failure_derive/default) >= >> > > 0.1.0 with crate(failure_derive/default) < 0.2.0) >> > > Problem 3: nothing provides requested (crate(rust-ini/default) >= >> > > 0.13.0 with crate(rust-ini/default) < 0.14.0) >> > > >> > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has >> > > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has >> > > Provides: crate(failure/derive) = 0.1.6. >> > > >> > > I'm confused why it's not getting picked up. >> > > >> > > Oh, I see now: >> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 >> > > has Tags: f31-build-side-17673 f31-build-side-17691 >> > > f31-build-side-17821 f31-build-side-19481 f32-build-side-19483 >> > > f33 >> > > but not f32. >> > > >> > > Igor, Josh? >> > >> > Source-only rust packages (those only shipping noarch -devel >> > subpackages) have been untagged from f32 on purpose by Igor. For >> > reasons I disagree with :) >> > So all the missing dependencies in rust packages (that are shipping >> > binaries) on f32 are there because there are no source-only rust >> > packages on f32 at all ... >> >> Hi Igor, >> >> can we please revisit this decision? We need rust-*-devel to do package >> reviews, rebuilds, and whatnot. >> >> Zbyszek >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
No. All dependencies and such are in Fedora Build System and kept there as any other package. On Wed, Mar 11, 2020, 14:10 Peter Robinson wrote: > On Wed, Mar 11, 2020 at 12:58 PM Randy Barlow > wrote: > > > > On 3/9/20 11:53 AM, Fabio Valentini wrote: > > > Source-only rust packages (those only shipping noarch -devel > > > subpackages) have been untagged from f32 on purpose by Igor. For > > > reasons I disagree with:) > > > > I too wish that we kept the Rust devel packages in stable releases. I am > > unable to build updates for my Rust packages by myself since their > > dependencies have been untagged. I recently noticed that a license tag > > was wrong in my Rust packages, and I had to ask for administrator help > > to get it fixed since I don't have permissions to set up the side tags > > and get the crates tagged into them. > > > > I will admit that I don't understand the reasoning behind the decision > > to remove these packages from non-rawhide releases. Igor, could you tell > > us why this is done? > > Is there also a possible license issue here, license depending, that > it's not a reproducible build? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
We could if somebody will commit on maintaining those packages in stable releases, keep them always updated, insert proper Obsoletes and create compat packages all the time. The good news are that Koji maintainers implemented necessary configuration and when new version will be released and deployed in infra, anybody will be able to update them in stable using SOP. On Mon, Mar 9, 2020, 18:40 Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Mar 09, 2020 at 04:53:25PM +0100, Fabio Valentini wrote: > > On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > > > > > 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 > > > > > > I see a lot of rust packages on this list, but I can't quite figure out > > > what is wrong: > > > > > > For rust-zram-generator, mock says: > > > Problem 1: nothing provides requested (crate(failure/default) >= > 0.1.0 with crate(failure/default) < 0.2.0) > > > Problem 2: nothing provides requested (crate(failure_derive/default) > >= 0.1.0 with crate(failure_derive/default) < 0.2.0) > > > Problem 3: nothing provides requested (crate(rust-ini/default) >= > 0.13.0 with crate(rust-ini/default) < 0.14.0) > > > > > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has > > > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has > > > Provides: crate(failure/derive) = 0.1.6. > > > > > > I'm confused why it's not getting picked up. > > > > > > Oh, I see now: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 > > > has Tags: f31-build-side-17673 f31-build-side-17691 > > > f31-build-side-17821 f31-build-side-19481 > f32-build-side-19483 f33 > > > but not f32. > > > > > > Igor, Josh? > > > > Source-only rust packages (those only shipping noarch -devel > > subpackages) have been untagged from f32 on purpose by Igor. For > > reasons I disagree with :) > > So all the missing dependencies in rust packages (that are shipping > > binaries) on f32 are there because there are no source-only rust > > packages on f32 at all ... > > Hi Igor, > > can we please revisit this decision? We need rust-*-devel to do package > reviews, rebuilds, and whatnot. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Wed, Mar 11, 2020 at 12:58 PM Randy Barlow wrote: > > On 3/9/20 11:53 AM, Fabio Valentini wrote: > > Source-only rust packages (those only shipping noarch -devel > > subpackages) have been untagged from f32 on purpose by Igor. For > > reasons I disagree with:) > > I too wish that we kept the Rust devel packages in stable releases. I am > unable to build updates for my Rust packages by myself since their > dependencies have been untagged. I recently noticed that a license tag > was wrong in my Rust packages, and I had to ask for administrator help > to get it fixed since I don't have permissions to set up the side tags > and get the crates tagged into them. > > I will admit that I don't understand the reasoning behind the decision > to remove these packages from non-rawhide releases. Igor, could you tell > us why this is done? Is there also a possible license issue here, license depending, that it's not a reproducible build? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On 3/9/20 11:53 AM, Fabio Valentini wrote: Source-only rust packages (those only shipping noarch -devel subpackages) have been untagged from f32 on purpose by Igor. For reasons I disagree with:) I too wish that we kept the Rust devel packages in stable releases. I am unable to build updates for my Rust packages by myself since their dependencies have been untagged. I recently noticed that a license tag was wrong in my Rust packages, and I had to ask for administrator help to get it fixed since I don't have permissions to set up the side tags and get the crates tagged into them. I will admit that I don't understand the reasoning behind the decision to remove these packages from non-rawhide releases. Igor, could you tell us why this is done? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Tue, Mar 10, 2020, 16:08 Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > > 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 > > It the -testing report getting updated properly? > I'm seeing the same 4 entries under my name as in the non-testing one, > and three of those packages were fixed over the weekend, with bodhi > updates submitted. The page says "generated on 2020-03-09". > I am aware. It's probably a dnf (repoclosure plugin) bug. See: repoclosure's "--newest" flag doesn't seem to have any effect, https://bugzilla.redhat.com/show_bug.cgi?id=1811456 Sorry that the data is currently not as useful as it could be. Fabio > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > 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 It the -testing report getting updated properly? I'm seeing the same 4 entries under my name as in the non-testing one, and three of those packages were fixed over the weekend, with bodhi updates submitted. The page says "generated on 2020-03-09". Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 9, 2020 at 11:54 AM Fabio Valentini wrote: > > On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > > > 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 > > > > I see a lot of rust packages on this list, but I can't quite figure out > > what is wrong: > > > > For rust-zram-generator, mock says: > > Problem 1: nothing provides requested (crate(failure/default) >= 0.1.0 > > with crate(failure/default) < 0.2.0) > > Problem 2: nothing provides requested (crate(failure_derive/default) >= > > 0.1.0 with crate(failure_derive/default) < 0.2.0) > > Problem 3: nothing provides requested (crate(rust-ini/default) >= 0.13.0 > > with crate(rust-ini/default) < 0.14.0) > > > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has > > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has > > Provides: crate(failure/derive) = 0.1.6. > > > > I'm confused why it's not getting picked up. > > > > Oh, I see now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 > > has Tags: f31-build-side-17673 f31-build-side-17691 > > f31-build-side-17821 f31-build-side-19481 f32-build-side-19483 f33 > > but not f32. > > > > Igor, Josh? > > Source-only rust packages (those only shipping noarch -devel > subpackages) have been untagged from f32 on purpose by Igor. For > reasons I disagree with :) > So all the missing dependencies in rust packages (that are shipping > binaries) on f32 are there because there are no source-only rust > packages on f32 at all ... > Rust SIG has been using OBS to rationalize the crate set[1] since we don't have good tools in Fedora infra to do this, so we can use the resolved set of source package commits to build for stable releases now. I don't know if we will, but it is at least reasonably possible now. [1]: https://build.opensuse.org/project/show/home:ignatenkobrain:rust -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, 2020-03-09 at 18:11 +0100, Fabio Valentini wrote: > On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III wrote: > > On Fri, Mar 06, 2020 at 21:35:52 +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: > > (snip) > > > Is there interest in also reporting packages that should be conflicting > > but aren't? These are annoying because they fail after the transaction > > is set and have to be manually dealt with. > > This is currently out of scope, because it's not reported by DNF > repoclosure / repoquery. > > I'm also not sure how you would detect that from the package metadata > ... query all packages for their file contents, and then show > conflicts when two packages own the same file, but do not explicitly > Conflict? I think that's probably too simplistic ... Approximately like this: https://pagure.io/fedora-qa/qa-misc/blob/master/f/potential_conflict.py -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
Le lundi 09 mars 2020 à 12:11 -0500, Bruno Wolff III a écrit : > On Mon, Mar 09, 2020 at 18:11:32 +0100, > Fabio Valentini wrote: > > On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III > > wrote: > > > > I'm also not sure how you would detect that from the package > > metadata > > ... query all packages for their file contents, and then show > > conflicts when two packages own the same file, but do not > > explicitly > > Conflict? I think that's probably too simplistic ... > > I don't think that practice is banned currently, but it would > probably > cut down on mistakes if it were. Having two sources of truth that > are > supposed to be identical, makes it easy for people to make a mistake. That works fine as long as the packages are generated from the same srpm. Here you have a case where files were moved from one project to another, so the maintainers need to decide which is the canonical truth from now on. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 09, 2020 at 12:11:42PM -0500, Bruno Wolff III wrote: > On Mon, Mar 09, 2020 at 18:11:32 +0100, > Fabio Valentini wrote: > >On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III wrote: > > > >I'm also not sure how you would detect that from the package metadata > >... query all packages for their file contents, and then show > >conflicts when two packages own the same file, but do not explicitly > >Conflict? I think that's probably too simplistic ... > > I don't think that practice is banned currently, It is, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/. Files should be renamed to remove the conflict, and if not possible, explicit Conflicts must be added. > but it would probably cut down on mistakes if it were. Having two > sources of truth that are supposed to be identical, makes it easy > for people to make a mistake. Yes, it is super annoying to users, because the error is not reported in the initial stage, but only after all packages have been downloaded. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 09, 2020 at 04:53:25PM +0100, Fabio Valentini wrote: > On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > > > 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 > > > > I see a lot of rust packages on this list, but I can't quite figure out > > what is wrong: > > > > For rust-zram-generator, mock says: > > Problem 1: nothing provides requested (crate(failure/default) >= 0.1.0 > > with crate(failure/default) < 0.2.0) > > Problem 2: nothing provides requested (crate(failure_derive/default) >= > > 0.1.0 with crate(failure_derive/default) < 0.2.0) > > Problem 3: nothing provides requested (crate(rust-ini/default) >= 0.13.0 > > with crate(rust-ini/default) < 0.14.0) > > > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has > > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has > > Provides: crate(failure/derive) = 0.1.6. > > > > I'm confused why it's not getting picked up. > > > > Oh, I see now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 > > has Tags: f31-build-side-17673 f31-build-side-17691 > > f31-build-side-17821 f31-build-side-19481 f32-build-side-19483 f33 > > but not f32. > > > > Igor, Josh? > > Source-only rust packages (those only shipping noarch -devel > subpackages) have been untagged from f32 on purpose by Igor. For > reasons I disagree with :) > So all the missing dependencies in rust packages (that are shipping > binaries) on f32 are there because there are no source-only rust > packages on f32 at all ... Hi Igor, can we please revisit this decision? We need rust-*-devel to do package reviews, rebuilds, and whatnot. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 09, 2020 at 18:11:32 +0100, Fabio Valentini wrote: On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III wrote: I'm also not sure how you would detect that from the package metadata ... query all packages for their file contents, and then show conflicts when two packages own the same file, but do not explicitly Conflict? I think that's probably too simplistic ... I don't think that practice is banned currently, but it would probably cut down on mistakes if it were. Having two sources of truth that are supposed to be identical, makes it easy for people to make a mistake. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III wrote: > > On Fri, Mar 06, 2020 at 21:35:52 +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: (snip) > Is there interest in also reporting packages that should be conflicting > but aren't? These are annoying because they fail after the transaction > is set and have to be manually dealt with. This is currently out of scope, because it's not reported by DNF repoclosure / repoquery. I'm also not sure how you would detect that from the package metadata ... query all packages for their file contents, and then show conflicts when two packages own the same file, but do not explicitly Conflict? I think that's probably too simplistic ... Fabio > For example: > > Running transaction test > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: Transaction test error: > file /usr/bin/slideshow from install of racket-7.4-2.fc32.x86_64 conflicts > with file from package batik-slideshow-1.11-3.fc32.noarch > file /usr/share/man/fr/man1/blackbox.1.gz from install of > blackbox-0.76-1.fc33.x86_64 conflicts with file from package > man-pages-fr-3.70-20.fc32.noarch > file /usr/share/man/fr/man1/bsetroot.1.gz from install of > blackbox-0.76-1.fc33.x86_64 conflicts with file from package > man-pages-fr-3.70-20.fc32.noarch > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, 2020-03-09 at 11:40 -0500, Bruno Wolff III wrote: > On Fri, Mar 06, 2020 at 21:35:52 +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: > > Is there interest in also reporting packages that should be conflicting > but aren't? These are annoying because they fail after the transaction > is set and have to be manually dealt with. > > For example: > > Running transaction test > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: Transaction test error: > file /usr/bin/slideshow from install of racket-7.4-2.fc32.x86_64 conflicts > with file from package batik-slideshow-1.11-3.fc32.noarch > file /usr/share/man/fr/man1/blackbox.1.gz from install of > blackbox-0.76-1.fc33.x86_64 conflicts with file from package > man-pages-fr-3.70-20.fc32.noarch > file /usr/share/man/fr/man1/bsetroot.1.gz from install of > blackbox-0.76-1.fc33.x86_64 conflicts with file from package > man-pages-fr-3.70-20.fc32.noarch Yes, these are bugs and should be reported. All conflicts between packages are required to be explicitly specified in one or both specs. Note that if both packages involved in such a conflict are present on the Server DVD, this is actually a release-blocking bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Fri, Mar 06, 2020 at 21:35:52 +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: Is there interest in also reporting packages that should be conflicting but aren't? These are annoying because they fail after the transaction is set and have to be manually dealt with. For example: Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/bin/slideshow from install of racket-7.4-2.fc32.x86_64 conflicts with file from package batik-slideshow-1.11-3.fc32.noarch file /usr/share/man/fr/man1/blackbox.1.gz from install of blackbox-0.76-1.fc33.x86_64 conflicts with file from package man-pages-fr-3.70-20.fc32.noarch file /usr/share/man/fr/man1/bsetroot.1.gz from install of blackbox-0.76-1.fc33.x86_64 conflicts with file from package man-pages-fr-3.70-20.fc32.noarch ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > > 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 > > I see a lot of rust packages on this list, but I can't quite figure out > what is wrong: > > For rust-zram-generator, mock says: > Problem 1: nothing provides requested (crate(failure/default) >= 0.1.0 with > crate(failure/default) < 0.2.0) > Problem 2: nothing provides requested (crate(failure_derive/default) >= > 0.1.0 with crate(failure_derive/default) < 0.2.0) > Problem 3: nothing provides requested (crate(rust-ini/default) >= 0.13.0 > with crate(rust-ini/default) < 0.14.0) > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has > Provides: crate(failure/derive) = 0.1.6. > > I'm confused why it's not getting picked up. > > Oh, I see now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 > has Tags: f31-build-side-17673 f31-build-side-17691 > f31-build-side-17821 f31-build-side-19481 f32-build-side-19483 f33 > but not f32. > > Igor, Josh? Source-only rust packages (those only shipping noarch -devel subpackages) have been untagged from f32 on purpose by Igor. For reasons I disagree with :) So all the missing dependencies in rust packages (that are shipping binaries) on f32 are there because there are no source-only rust packages on f32 at all ... Fabio > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > 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 I see a lot of rust packages on this list, but I can't quite figure out what is wrong: For rust-zram-generator, mock says: Problem 1: nothing provides requested (crate(failure/default) >= 0.1.0 with crate(failure/default) < 0.2.0) Problem 2: nothing provides requested (crate(failure_derive/default) >= 0.1.0 with crate(failure_derive/default) < 0.2.0) Problem 3: nothing provides requested (crate(rust-ini/default) >= 0.13.0 with crate(rust-ini/default) < 0.14.0) But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has Provides: crate(failure/derive) = 0.1.6. I'm confused why it's not getting picked up. Oh, I see now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 has Tags: f31-build-side-17673 f31-build-side-17691 f31-build-side-17821 f31-build-side-19481 f32-build-side-19483 f33 but not f32. Igor, Josh? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 9, 2020 at 11:14 AM Fabio Valentini wrote: > On Mon, Mar 9, 2020 at 12:06 PM Ian McInerney > wrote: > > > > On Fri, Mar 6, 2020 at 8:37 PM 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: > >> > > (snip) > > > It would be interesting to also extend this to allow querying based on > broken "requires" tags, since those can make packages uninstallable. > > That's exactly what's already listed in the report. For source > packages, it shows broken dependencies that make them non-buildable > (FTBFS - fails to build from sources), and for binary packages, it > shows broken dependencies that make then non-installable (FTI - fails > to install). > > Fabio > > Ah, I missed the part about FTI. I thought it was only FTBFS. Sorry for the noise. -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 9, 2020 at 12:06 PM Ian McInerney wrote: > > On Fri, Mar 6, 2020 at 8:37 PM 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: >> (snip) > It would be interesting to also extend this to allow querying based on broken > "requires" tags, since those can make packages uninstallable. That's exactly what's already listed in the report. For source packages, it shows broken dependencies that make them non-buildable (FTBFS - fails to build from sources), and for binary packages, it shows broken dependencies that make then non-installable (FTI - fails to install). Fabio > -Ian > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Fri, Mar 6, 2020 at 8:37 PM 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: > > It would be interesting to also extend this to allow querying based on broken "requires" tags, since those can make packages uninstallable. -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
Dokuwiki has broken dependencies because one of them got retired recently due to no upstream activity. There is an open Review Request for a still-maintained fork of the original package: https://bugzilla.redhat.com/show_bug.cgi?id=1809097 If anyone has a moment to review it (it's a PHP library + command-line tools), I'd be grateful. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Sat, Mar 7, 2020 at 4:42 PM Fabio Valentini wrote: > > On Sat, Mar 7, 2020, 15:05 Richard Shaw wrote: >> >> Are the broken source dependencies real? >> >> python-pyside2 (src): >> >> qt5-qtwebengine-devel > 5.13 >> >> I just checked koji and qt5-qtwebengine 5.13.2 is in f32 which should meet >> the requirement. > > > This looks like a case of either Caeat 1 or Caveat 2 listed above. Is > python-pyside2 a "noarch package with imported dependencies"? I tried to > whitelist all qtwebengine related false positives, but I might have missed > this one. I am at my PC now, and I verified that python-pyside2 is in fact a false positive (Caveat 2 from my first email). I'll whitelist this package. Fabio > Fabio > > >> >> Thanks, >> Richard >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Sat, Mar 7, 2020, 15:05 Richard Shaw wrote: > Are the broken source dependencies real? > > >- python-pyside2 (src): > - qt5-qtwebengine-devel > 5.13 > > I just checked koji and qt5-qtwebengine 5.13.2 is in f32 which should meet > the requirement. > This looks like a case of either Caeat 1 or Caveat 2 listed above. Is python-pyside2 a "noarch package with imported dependencies"? I tried to whitelist all qtwebengine related false positives, but I might have missed this one. Fabio > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
Are the broken source dependencies real? - python-pyside2 (src): - qt5-qtwebengine-devel > 5.13 I just checked koji and qt5-qtwebengine 5.13.2 is in f32 which should meet the requirement. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On 06. 03. 20 21:35, Fabio Valentini wrote: 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 The second most common problem is PostgreSQL 11. I have checked and there seem to be no attempted rebuilds of the packages since PostgreSQL was updated to 12. I'm including the change owner in this conversation and I've reopend the tracking Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1801396 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Fri, Mar 6, 2020 at 10:18 PM Adam Williamson 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
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? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
