I am really sick of seeing errors like this when making trivial, non-related changes to an ebuild. SRC_URI.mirror 2 media-libs/x265/x265-0.8.ebuild: 'https://bitbucket.org/' found in thirdpartymirrors, use 'mirror://bitbucket/multicoreware/x265/get/0.8.tar.bz2' media-libs/x265/x265-1.0.ebuild: 'https://bitbucket.org/' found in thirdpartymirrors, use 'mirror://bitbucket/multicoreware/x265/get/1.0.tar.bz2' Please change this from an error to a warning.
Not to mention that this makes it pretty much impossible to get rid of a mirror. Either you remove it completely and break overlays, or you keep it and people keep reverting it because of repoman's stupidity.
Created attachment 380314 [details, diff] Make SRC_URI.mirror non-fatal
From a QA perspective I don't know why it's so hard for people to follow the instructions here. I'm not going to close it invalid, but that is what my vote is for. use repoman || die
(In reply to Rick Farina (Zero_Chaos) from comment #3) > From a QA perspective I don't know why it's so hard for people to follow the > instructions here. I'm not going to close it invalid, but that is what my > vote is for. The problems occur when people update thirdpartymirrors after valid ebuilds are in the tree. Also, mgorny raises a good point: this makes it very difficult to remove lines from the thirdpartymirrors file.
(In reply to Mike Gilbert from comment #4) > (In reply to Rick Farina (Zero_Chaos) from comment #3) > > From a QA perspective I don't know why it's so hard for people to follow the > > instructions here. I'm not going to close it invalid, but that is what my > > vote is for. > > The problems occur when people update thirdpartymirrors after valid ebuilds > are in the tree. > > Also, mgorny raises a good point: this makes it very difficult to remove > lines from the thirdpartymirrors file. If we are going to use thirdpartymirrors like this, then we should use it, or not use it. Half using it is retarded. Also no, he doesn't make a good point, I'm sure everyone on this bug knows how to use grep.
(In reply to Mike Gilbert from comment #4) > Also, mgorny raises a good point: this makes it very difficult to remove > lines from the thirdpartymirrors file. 1. Remove the line from thirdpartymirrors in CVS checkout. 2. Fix all ebuilds. 3. Commit the change from 1. But I agree that a repoman warning might be more appropriate as severity level here.
(In reply to Rick Farina (Zero_Chaos) from comment #5) > If we are going to use thirdpartymirrors like this, then we should use it, > or not use it. Half using it is retarded. That doesn't mean we should treat it as a serious problem that must be addressed before committing. Nothing is broken so long as SRC_URI points at a valid location.
(In reply to Mike Gilbert from comment #7) > (In reply to Rick Farina (Zero_Chaos) from comment #5) > > If we are going to use thirdpartymirrors like this, then we should use it, > > or not use it. Half using it is retarded. > > That doesn't mean we should treat it as a serious problem that must be > addressed before committing. Nothing is broken so long as SRC_URI points at > a valid location. From my perspective it does. If it's a warning instead of an error then people won't update, case-in-point, this bug. So let's either use this stuff as intended or purge it, there is no point in having a nice advanced mirroring system that no one uses.
I consider it a waste of my time update fully working SRC_URI entries when making unrelated changes, like adding an ~x86 keyword to a package I do not maintain. If you care, then please fix the ebuilds which currently throw this error in the tree, and force people who modify thirdpartymirrors to fix all ebuilds when they commit changes. Don't push that workload onto random developers.
A bit of insanity to demonstrate the removal point: 12 Jul 2014; Mike Gilbert <floppym@gentoo.org> thirdpartymirrors: Drop bitbucket. Sorry overlays, you're on your own. 12 Jul 2014; Brian Evans <grknight@gentoo.org> thirdpartymirrors: Revert change to mirror://bitbucket as wget fails to download due to mismatched certificate. 06 Jul 2014; Michał Górny <mgorny@gentoo.org> thirdpartymirrors: Use a little different FQDN for mirror://bitbucket to silence out the repoman false positives.
In the meantime, we got another hard failure. kudzu is found on one of the many Fedora mirrors, so repoman complains. When I replace that with mirror://fedora, all I get is a long round of 404s. Awesome, isn't it?
Can I get the QA lead to weigh-in on this? I see mgorny and ulm seem to think a warning is more appropriate, but I think a more solid decision would be good.
While this is assigned to the portage team, decision for this is a QA responsibility. Last time I made a small change like this I was in big shit over it... So far I see a 2:1 vote for it from QA members. I need an official ruling on this before merging a pending patch to change this.
<QA team lead> This check should be non-fatal. Having proper working SRC_URI without using mirror:// is an issue, but it's non critical if users still can download tarball using that link. </QA team lead>
(In reply to Sergey Popov from comment #14) > This check should be non-fatal. I second this.
(In reply to Mike Gilbert from comment #2) > Created attachment 380314 [details, diff] [details, diff] > Make SRC_URI.mirror non-fatal This is in the master branch now: https://github.com/gentoo/portage/commit/d43cc91db8ae54f48a91576c175a2a49f7b8b11c
Released in portage-2.2.17.
