Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 513168 - repoman: SRC_URI.mirror should not be a fatal error
Summary: repoman: SRC_URI.mirror should not be a fatal error
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Repoman (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 484436
  Show dependency tree
 
Reported: 2014-06-14 02:53 UTC by Mike Gilbert
Modified: 2015-02-15 05:28 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Make SRC_URI.mirror non-fatal (0001-repoman-Make-SRC_URI.mirror-non-fatal.patch,570 bytes, patch)
2014-07-06 16:33 UTC, Mike Gilbert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gilbert gentoo-dev 2014-06-14 02:53:46 UTC
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.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-07-06 13:21:44 UTC
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.
Comment 2 Mike Gilbert gentoo-dev 2014-07-06 16:33:07 UTC
Created attachment 380314 [details, diff]
Make SRC_URI.mirror non-fatal
Comment 3 Rick Farina (Zero_Chaos) gentoo-dev 2014-07-06 19:11:48 UTC
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
Comment 4 Mike Gilbert gentoo-dev 2014-07-06 19:15:51 UTC
(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.
Comment 5 Rick Farina (Zero_Chaos) gentoo-dev 2014-07-06 19:31:45 UTC
(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.
Comment 6 Ulrich Müller gentoo-dev 2014-07-06 19:32:10 UTC
(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.
Comment 7 Mike Gilbert gentoo-dev 2014-07-06 19:36:23 UTC
(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.
Comment 8 Rick Farina (Zero_Chaos) gentoo-dev 2014-07-06 19:50:27 UTC
(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.
Comment 9 Mike Gilbert gentoo-dev 2014-07-06 19:54:34 UTC
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.
Comment 10 Mike Gilbert gentoo-dev 2014-07-12 07:24:23 UTC
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.
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-02-08 08:35:37 UTC
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?
Comment 12 Mike Gilbert gentoo-dev 2015-02-08 16:19:37 UTC
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.
Comment 13 Brian Dolbec gentoo-dev 2015-02-08 16:22:48 UTC
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.
Comment 14 Sergey Popov gentoo-dev 2015-02-09 07:23:37 UTC
<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>
Comment 15 Ulrich Müller gentoo-dev 2015-02-09 10:17:08 UTC
(In reply to Sergey Popov from comment #14)
> This check should be non-fatal.

I second this.
Comment 16 Zac Medico gentoo-dev 2015-02-09 20:35:02 UTC
(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
Comment 17 Brian Dolbec gentoo-dev 2015-02-15 01:05:29 UTC
Released in portage-2.2.17.