The summary pretty much says it all... >>> Emerging (3 of 155) x11-proto/xextproto-7.0.2 to / >>> Downloading http://xorg.freedesktop.org/releases/individual/lib/xextproto-7.0.2.tar.bz2 --18:44:47-- http://xorg.freedesktop.org/releases/individual/lib/xextproto-7.0.2.tar.bz2 => `/usr/portage/distfiles/xextproto-7.0.2.tar.bz2' Resolving xorg.freedesktop.org... 131.252.208.36 Connecting to xorg.freedesktop.org|131.252.208.36|:80... connected. HTTP request sent, awaiting response... 404 Not Found 18:44:47 ERROR 404: Not Found. !!! Couldn't download xextproto-7.0.2.tar.bz2. Aborting. !!! Fetch for /usr/portage/x11-proto/xextproto/xextproto-7.0.2.ebuild failed, continuing... It should be trying to download from http://xorg.freedesktop.org/releases/individual/proto instead.
I cannot reproduce your issue. donnie@comet ~ $ emerge -f xextproto Calculating dependencies... done! >>> Emerging (1 of 1) x11-proto/xextproto-7.0.2 to / >>> Downloading http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.0.2.tar.bz2 --16:39:38-- http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.0.2.tar.bz2 => `/usr/portage/distfiles/xextproto-7.0.2.tar.bz2' Resolving xorg.freedesktop.org... 131.252.208.36 Connecting to xorg.freedesktop.org|131.252.208.36|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 68,323 (67K) [application/x-tar] 100%[====================================>] 68,323 --.--K/s 16:39:38 (981.13 KB/s) - `/usr/portage/distfiles/xextproto-7.0.2.tar.bz2' saved [68323/68323] >>> xextproto-7.0.2.tar.bz2 MD5 ;-) >>> xextproto-7.0.2.tar.bz2 RMD160 ;-) >>> xextproto-7.0.2.tar.bz2 SHA1 ;-) >>> xextproto-7.0.2.tar.bz2 SHA256 ;-) >>> xextproto-7.0.2.tar.bz2 size ;-) >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking xextproto-7.0.2.tar.bz2 ;-) Do you have a weird old x-modular.eclass lying around? I'm on Portage 2.1.1_pre2-r4 FWIW.
Post your emerge --info please. I have a feeling you have a bad x-moduler.eclass sitting around somewhere, perhaps in an overlay. Try re-syncing as well.
No overlays... This was happening during a catalyst build. I can get you the emerge --info there, but it's all defaults for 2006.1. The snapshot was taken on July 3rd.
Portage 2.1.1_pre2-r5 (and maybe earlier versions) had some sort of cache generation bug, if you're using it. I don't know how else you can manage to get the download from the completely wrong place -- the location is determined using $CATEGORY.
It's 2.1-r1, and as you can see from the other bugs, I got it repeatedly.
(In reply to comment #4) > Portage 2.1.1_pre2-r5 (and maybe earlier versions) had some sort of cache > generation bug That $CATEGORY bug only existed in that one release. This problem is different because the $CATEGORY bug would cause the SRC_URI to be empty. The cache containing the bad SRC_URI must have been generated with the older version x-modular.eclass. The cache that's currently available via the master rsync mirrors has the correct SRC_URI, so a fresh `emerge --sync` should correct the problem. If not, try `rm -rf /var/cache/edb/dep && emerge --metadata`.
OK. YOu're missing that this is a catalyst build. I can't do a fresh sync. If there was an issue with the eclass, then I need to inject the newer version into the snapshot. I can look into the metadata thing, but I'm not sure that we have any metadata in the stages or the portage snapshots, so that might be a moot point. Again, this didn't cause SRC_URI to be empty, at all. However, I have hit that bug, even with a fresh sync this morning. I was actually going to file a bug about it, but it isn't as urgent to me since it doesn't affect the release stuff.
(In reply to comment #7) > OK. YOu're missing that this is a catalyst build. I can't do a fresh sync. > If there was an issue with the eclass, then I need to inject the newer version > into the snapshot. I can look into the metadata thing, but I'm not sure that > we have any metadata in the stages or the portage snapshots, so that might be a > moot point. There was never an issue with the eclass in this regard, it's entirely a cache/portage problem.
(In reply to comment #6) > mirrors has the correct SRC_URI, so a fresh `emerge --sync` should correct the > problem. If not, try `rm -rf /var/cache/edb/dep && emerge --metadata`. Will this fix the metadata under /usr/portage/metadata?
(In reply to comment #9) > Will this fix the metadata under /usr/portage/metadata? Yes, `emerge --sync` will update all of that metadata so that it matches whatever is on the rsync mirrors.
Zach, I understand that you aren't reading everything in this bug when answering, so I'm going to say this very plainly. I can not and will not perform an emerge --sync as it will set back the release by a few weeks. Now, how *else* can I ensure that the metadata will be correct, for the 2006.1 release snapshot? With emerge --metadata work, or does that just do /var/cache/edb/dep? Do I need to do an emerge --regen instead?
*** Bug 139613 has been marked as a duplicate of this bug. ***
*** Bug 139614 has been marked as a duplicate of this bug. ***
*** Bug 139615 has been marked as a duplicate of this bug. ***
*** Bug 139616 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Now, how *else* can I ensure that the metadata will be correct, for the 2006.1 > release snapshot? > > With emerge --metadata work, or does that just do /var/cache/edb/dep? Do I > need to do an emerge --regen instead? Well, emerge doesn't actually have the ability to update $PORTDIR/metadata/cache, but I have a separate tool that you can use. Here are the steps: rm -rf /var/cache/edb/dep/$PORTDIR cache-tools.py --generate # same thing as --regen cache-tools.py --transfer --reverse # the reverse of --metadata You can get the separate tool here: http://dev.gentoo.org/~zmedico/public_html/portage/branches/2.1/bin/cache-tools.py
404 Error... =[
Chris, remove the /public_html.
Err... yeah... that helped... Anyway, I've run this on my metadata... so here's hoping it fixes the problem. I'm not sure what you want to do with this bug. I'm still not sure if I really was hitting the CATEGORY bug, as you say it, since SRC_URI wasn't empty in this case, but if you think that's what it was, then I'm cool with it. I just want to make sure whatever we have now in the tree and whatever I have for release are both going to be good.
Are we fixed up here?
I believe so
k
