Receiving objects: 18% (416740/2234946), 230.64 MiB | 126 KiB/s [...] So it wants to fetch a huge number of uncompressed files, store those uncompressed locally, say more than a gigabyte, from an apparently slow / bandwidth limited server? How about a mirror://gentoo 3.0 tarball with a diff to 3.0.6?
Should be fixed now.
$ ebuild vanilla-sources-3.0.6.ebuild unpack Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY... >>> Downloading 'http://www.uk.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2' --2011-10-19 13:39:21-- http://www.uk.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2 Resolving www.uk.kernel.org (www.uk.kernel.org)... failed: Name or service not known. wget: unable to resolve host address `www.uk.kernel.org' >>> Downloading 'http://www.fr.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2' --2011-10-19 13:39:22-- http://www.fr.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2 Resolving www.fr.kernel.org (www.fr.kernel.org)... failed: Name or service not known. wget: unable to resolve host address `www.fr.kernel.org' >>> Downloading 'http://www.us.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2' --2011-10-19 13:39:22-- http://www.us.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2 Resolving www.us.kernel.org (www.us.kernel.org)... failed: Name or service not known. wget: unable to resolve host address `www.us.kernel.org' >>> Downloading 'http://www.de.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2' --2011-10-19 13:39:22-- http://www.de.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2 Resolving www.de.kernel.org (www.de.kernel.org)... failed: Name or service not known. wget: unable to resolve host address `www.de.kernel.org' >>> Downloading 'http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2' --2011-10-19 13:39:22-- http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2 Resolving www.kernel.org (www.kernel.org)... 149.20.4.69 Connecting to www.kernel.org (www.kernel.org)|149.20.4.69|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-10-19 13:39:23 ERROR 404: Not Found. >>> Downloading 'http://www.at.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2' --2011-10-19 13:39:23-- http://www.at.kernel.org/pub/linux/kernel/v3.0/patch-3.0.6.bz2 Resolving www.at.kernel.org (www.at.kernel.org)... failed: Name or service not known. wget: unable to resolve host address `www.at.kernel.org' !!! Couldn't download 'patch-3.0.6.bz2'. Aborting. Yes, now SRC_URI points to mirror://kernel, most of which do not seem to be available right now. What happened to the suggestion of using our own mirrors?
I added the patches to distfiles-local, so that they'll get mirrored. And I thought this would work, since Portage would check the mirrors first, before falling back to the SRC_URI. And I think that's the way it works. Otherwise all the vanilla-sources ebuilds should be broken (and any other ebuild that needs patches from kernel.org), since kernel-2.eclass uses mirror://kernel for the URIs, and mirror://gentoo only for the genpatches.
Allow me to clarify. I'll add myself to CC if you have questions. (In reply to comment #3) > I added the patches to distfiles-local, so that they'll get mirrored. And I > thought this would work, since Portage would check the mirrors first, before > falling back to the SRC_URI. True, if a user has a proper GENTOO_MIRRORS entry. So, since I can donwload these distfiles from gentoo.org and Jeroen cannot, it shows me that he is using the SRC_URI to prove a point because he clearly knows about GENTOO_MIRRORS. > And I think that's the way it works. Otherwise all the vanilla-sources ebuilds > should be broken (and any other ebuild that needs patches from kernel.org), > since kernel-2.eclass uses mirror://kernel for the URIs, and mirror://gentoo > only for the genpatches. If you want to make a better user experience, then you would lie in thirdpartymirrors and point to something that works (you shouldn't leave broken mirror in there anyway).
(In reply to comment #4) > True, if a user has a proper GENTOO_MIRRORS entry. So, since I can donwload > these distfiles from gentoo.org and Jeroen cannot, it shows me that he is using > the SRC_URI to prove a point because he clearly knows about GENTOO_MIRRORS. It sounds like his GENTOO_MIRRORS setting doesn't contain distfiles.gentoo.org, as discussed in bug 354555.
(In reply to comment #5) > It sounds like his GENTOO_MIRRORS setting doesn't contain distfiles.gentoo.org, > as discussed in bug 354555. s/distfiles.gentoo.org/a valid, up2date mirror/ - yes.
Ok, currently there are a lot of ebuilds using mirror://kernel/ URIs. Are all of these to be considered 'broken'? There's no way to fix the mirror://kernel/. Even if gentoo distfiles mirrors currently have all these files mirrored (correct me if I'm wrong here), mirror://kernel/ had a certain hierarchy, and thus just changing mirror://kernel/ to point to our mirrors won't work. Maybe changing all the ebuilds to point directly to mirror://gentoo/, will work. But, I don't think it's a realistic solution to the problem. So, what I did with vanilla-sources-3.0.6 and 3.0.7, is what every other ebuild in the tree, that uses mirror://kernel/ URIs, does. They all fetch the files from our mirrors. I mean, you'll get the same results (if you're not using GENTOO_MIRRORS), with vanilla-sources-3.0.3, and with over 50 packages currently in the tree, which fetch fetch files from kernel.org mirrors. Anyway, for vanilla-sources, we can just use the git ebuild, and remove the stabilization request. But, the problem with mirror://kernel/ is more general, probably.
(In reply to comment #7) > There's no way to fix the mirror://kernel/. Then you should remove that entry from thirdpartymirrors. There is no sense in keeping broken stuff. > mirror://kernel/ had a certain hierarchy, and thus just changing > mirror://kernel/ to point to our mirrors won't work. It would be a temp workaround (as I explained in irc), the caveat being that everyone *must* upload the distfile to the mirrors before committing their ebuild. Given that there is 314 ebuilds (not including eclasses), this is not a very good long-term workaround. > Maybe changing all the > ebuilds to point directly to mirror://gentoo/, will work. But, I don't think > it's a realistic solution to the problem. It is becoming clear that this is the only solution. 1) changing the ebuilds to mirror://gentoo/, 2) remove mirror://kernel from tpm, 3) add back mirror://kernel once we know what the k.org admins are going to do. The bottom line, mirror://kernel is broken and the kernel team needs to come up with a plan to fix it. Sadly, it has taken much more time than expected for k.org to return to sanity... =/
(In reply to comment #8) > > mirror://kernel/ had a certain hierarchy, and thus just changing > > mirror://kernel/ to point to our mirrors won't work. > > It would be a temp workaround (as I explained in irc), the caveat being that > everyone *must* upload the distfile to the mirrors before committing their > ebuild. Given that there is 314 ebuilds (not including eclasses), this is not a > very good long-term workaround. Right. I mis-spoke. Due to the directory hierarchy, this wouldn't work without touching every ebuild as well. Sigh.
I propose to close this bug report, reopen bug #382381, and continue this there. It was my bad decision to reopen this one for an issue already reported.
(In reply to comment #8) > (In reply to comment #7) > > > There's no way to fix the mirror://kernel/. > > Then you should remove that entry from thirdpartymirrors. There is no sense in > keeping broken stuff. Eventually, they'll fix it, so we can as well keep it. As I said above, some files are back online (eg linux tarballs). (In reply to comment #8) > The bottom line, mirror://kernel is broken and the kernel team needs to come up > with a plan to fix it. Sadly, it has taken much more time than expected for > k.org to return to sanity... =/ I don't think this is a kernel-team only issue, but I guess it affects us more. (In reply to comment #10) > I propose to close this bug report, reopen bug #382381, and continue this > there. +1 for reopening 382381. As far as vanilla-sources are concerned, is it ok to keep the ebuilds as they are (ie fetching files from mirrors instead of cloning the repo, when installing for the first time)? And what about the STABLEREQ?
Closing as per comment #10 *** This bug has been marked as a duplicate of bug 382381 ***
