FYI, the patch located @ https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.11-rt8.patch.xz has moved to https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/older/patch-3.8.11-rt8.patch.xz and the latest patch is for patch-3.8.13-rt11.patch.xz
$ ebuild rt-sources-3.8.11_p8.ebuild install Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY... >>> Downloading 'http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.8.11.xz' --2013-06-21 14:39:12-- http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.8.11.xz Resolving www.kernel.org (www.kernel.org)... 149.20.4.69, 198.145.20.140 Connecting to www.kernel.org (www.kernel.org)|149.20.4.69|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.8.11.xz [following] --2013-06-21 14:39:13-- https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.8.11.xz Connecting to www.kernel.org (www.kernel.org)|149.20.4.69|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 241620 (236K) [application/x-xz] Saving to: ‘/world/distfiles/patch-3.8.11.xz’ 100%[==========================================================================================>] 241,620 256KB/s in 0.9s 2013-06-21 14:39:15 (256 KB/s) - ‘/world/distfiles/patch-3.8.11.xz’ saved [241620/241620] * patch-3.8.11.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * linux-3.8.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Downloading 'http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.11-rt8.patch.xz' --2013-06-21 14:39:20-- http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.11-rt8.patch.xz Resolving www.kernel.org (www.kernel.org)... 198.145.20.140, 149.20.4.69 Connecting to www.kernel.org (www.kernel.org)|198.145.20.140|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.11-rt8.patch.xz [following] --2013-06-21 14:39:20-- https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.11-rt8.patch.xz Connecting to www.kernel.org (www.kernel.org)|198.145.20.140|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2013-06-21 14:39:21 ERROR 404: Not Found. !!! Couldn't download 'patch-3.8.11-rt8.patch.xz'. Aborting.
OK... no volunteer... I'll... risk myself : My opinion : This bug highlights a serious problem in the way sys-kernel/rt-sources package is maintained. (Note that I do not mean that it is (x,y,z)'s fault.) - It is a fact that upstream initially uploads their last patches in the directory SRC_URI points to. - It is a fact that, when releasing a new patch for a given branch, the n-1 patch is moved into the "older" subdirectory. - This makes so that ebuilds, as made available in portage, incidentally become obsolete if not completely broken. => My opinion is that the maintenance of this highly particular package should be oriented in one of the two following directions : Either : A/- "We" (this includes me) constrain "ourself" (this includes myself) to strictly follow upstream and update the tree at a pace that "we" (this includes me) have never proven being capable to follow. B/- We restrict the ebuilds to the releases already dropped in the "older" url. - I can help on option A/ but only partly. Because I am convinced that an rt-sources ebuild just cannot be fired and forgotten and that kernels must be heavily tested before submitted to users, I just cannot do that job on all available branches. Because the stable branch (3.4 at the time of this post) is the preferred choice for real rt users, I can commit myself in following the 3.4 branch at upstream's pace, but not the others. - Option B/ is of course far less constraining but offers the drawback to never be up to date. (The situation in which we actually are de facto anyway) => My opinion based on what I am capable to provide is Option A for the stable branch + option B for > 3.4 But that would at least imply proxy-maint's complicity. Real devs, real owners of gentoo's portage tree, please decide exactly what YOU want !
I would ask the devs if they could put the patch in older, and just make a link from the one above to the one in older-- that way we have a consistent naing always based on the archival version. Just a thought.
Sorry for the late response. The rt patch is mirrored automatically by Gentoo infra and Portage (afaik) will try to fetch it from the Gentoo mirrors (distfiles) by default. So, you shouldn't be having any problems fetching the rt patch, even if upstream changed its location / URL. I bumped rt-sources today, and added the 'older' URL in SRC_URI, which I'm not sure if it's 'semantically' correct, but it seems to do the trick. For example: # GENTOO_MIRRORS="" ebuild rt-sources-3.4.36_p50.ebuild manifest fetched the rt patch successfully from the upstream 'older' directory. And it also fetches the latest rt patch from the 'parent' directory successfully. So, I think you shouldn't been having this problem in the first place (due to the Gentoo mirroring infra), but the new ebuilds should resolve the issue, even in the case that you, for some reason, bypass Gentoo mirrors. If nobody has an objection with the above, I can resolve the bug as INVALID or FIXED.
I think FIXED is the right choice here, cause we have problems from both side(upstream and ebuild ones)
