|
Description
Ben Kohler
2013-12-18 20:39:05 UTC
The BerliOS hosting service was shutdown on 30 April 2014. The berlios mirror group should be removed since both mirrors are now dead. SourceForge has mirrored[1] all BerliOS projects. Any ebuilds using the berlios mirror group can be switched to the sourceforge mirror group. [1] http://sourceforge.net/blog/berlios-projects-saved-moving-to-sourceforge-for-distribution/ *** Bug 537662 has been marked as a duplicate of this bug. *** + 25 Jan 2015; Jeroen Roovers <jer@gentoo.org> thirdpartymirrors: + Drop berlios.de mirrors (bug #494678). (In reply to Jeroen Roovers from comment #2) @Jonas: Did you have a list, say? Should this become a tracker bug with dependent bugs for each package using mirror://berlios or (illegally as per bug #218657) using the domain directly? /keeps/gentoo/berlios_mirror_DEAD_ebuild_list Created attachment 394886 [details]
berlios_mirror_DEAD_ebuild_list
Created attachment 394892 [details]
berlios_directly_DEAD_ebuild_list
Needless to say, some of these projects might have gone to live elsewhere and should probably not be linked to the berlios -> sourceforge dump. *** Bug 541806 has been marked as a duplicate of this bug. *** What are we planning to do about this? It's 1.5yr overdue already, and it forces me to ignore invalid mirror:// entries for gentoo-ci. Some packages have a dead upstream for years and no maintainer. At least a (proxy) maintainer would be needed to fix the ebuild. I think we can hard mask these with a long delay (90 days?). For packages with gentoo maintainer (or at least proxy maintainer), I suggest to send a last rite. To keep the package just few things are required: a) find the latest mirror (on sourceforge) b) verify, that it is the original source code and not a malicious copy in the name of the old project c) fix the URL in the ebuild. This is a little burden, if anybody is interested in keeping these packages and as usual there would be help for new motivated proxy maintainers. I suggest to hard mask these and prepare them for deletion with a long delay (> 90 days?). (In reply to Jonas Stein from comment #12) > I suggest to hard mask these and prepare them for deletion If the missing upstream is the only problem then they should not be removed. > If the missing upstream is the only problem then they should not be removed.
Jeroen, I fully agree, but to my understanding packages need a fix.
And if nobody volunteers to fix the broken packages after so long timespan we should not leave it in the main tree.
In most cases the fix will be just time consuming and not difficult like comparing the original source with SF, changing the URL to SF and testing...
Per comment #13, lastritting the packages only for the mirror issue won't probably be really welcomed :| Well, if QA team want to hardmask them *with the QA hat on*, fine for me... but I won't last rite them from treecleaners, put my mail there and, at the end, me needing to deal with all the angry people (yes, I am used to get really "nice" private mails because of that) and need to push myself the fixes to the ebuilds that people could rise Also, cannot we simply rely on our mirrors for them? Looks like in most cases (if not all) they don't have any restriction forcing us to download the sources from iriginal SRC_URI :| I don't really care who solves this and how. What I'm concerned about, is that a major QA violation (SRC_URI is *invalid*, not just unreachable but *invalid*) is live for 2 years already and nobody bothers fixing it. If people really want to keep their fancy packages, then they need to do this tremendous effort and fix them. I don't have time to fix every QA violation other developers find good to commit and that others love to keep. That said, since nobody seems to bother, I will try to mask all the involved packages and see if this is enough to silence the QA issues. I doubt this will be enough, so I will probably end up effectively masking them and commenting out SRC_URI. If someone wants to replace the URIs with spamforge, it's their choice. As far as I'm concerned, this is a move with no benefit and pointless advertisement of company whose behavior towards open source community (see: gimp) is inappropriate, saying lightly. Dead packages are dead, and read-only mirrors of dead homepages don't help much. Oh wait, I already replaced all those mirror:// entries. So all left is to drop packages that are dead with no upstream. Then, should we simply close the current opened bug reports? (as they are not relying on berlios.de anymore?) I've only wiped out SRC_URIs. Someone should still try to find new home for the packages, or lastrite them. |
