Ok here's another one. This time I'm running against an apache http server and I don't even see any http traffic. Nothing's in the logs, no errors, no downloads. Not even a single packet to port 80 in tcpdump. But: # wget $(portageq envvar PORTAGE_BINHOST)/Packages --2011-02-10 13:11:59-- http://milan.lih.rwth-aachen.de/packages-test/pentium-m-desktop/Packages Resolving milan.lih.rwth-aachen.de... 137.226.164.4 Connecting to milan.lih.rwth-aachen.de|137.226.164.4|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1440431 (1.4M) [text/plain] Saving to: `Packages.3' 100%[=====================================================>] 1,440,431 510K/s in 2.8s 2011-02-10 13:12:02 (510 KB/s) - `Packages.3' saved [1440431/1440431] and: # ll /var/cache/edb/binhost total 12 drwxr-sr-x 3 root portage 4096 Jan 30 04:18 . drwxr-sr-x 4 root portage 4096 Jan 30 04:18 .. drwxr-sr-x 3 root portage 4096 Jan 30 04:18 wald.local wald.local was the previous binhost. Why isn't it updating anything? This applies to current stable portage as well as 2.2.0_alpha19. Reproducible: Always Steps to Reproduce:
Oh and just to be clear. On the apache server: # grep TIMESTAMP /export/packages-test/pentium-m-desktop/Packages TIMESTAMP: 1297201365 And on the client: # grep TIMESTAMP /usr/portage/packages/Packages TIMESTAMP: 1296338446
Update: I deleted /var/cache/edb/binhost, which didn't help when I did "emerge -kuDavN world". /var/cache/edb/binhost was not recreated. But when I did "emerge -guDavN --rebuilt-binaries=True world", it did recreate /var/cache/edb/binhost and correctly downloaded the package index.
Oh wait. Is this actually by design as per the -k vs. the -g option? I switched from using -g to -k, because with -g, emerge would prefer old binpkgs over newer ebuilds, which is not feasible in this case. I can work around this because I do a separate --fetchonly run beforehand, but still, some more control over preference of binpkg vs. ebuild might be nice.
Ah well. I think this is too trivial and the workaround is too easy. I guess you devs better waste your time with more important things. Closing as invalid. Sorry for the noise.
The difference between -g and -k is that -g would look at the binhost if there is no binpkg in $PKGDIR. Since you used -k in comment 2, it didn't even look at the binhost. (In reply to comment #3) >I switched > from using -g to -k, because with -g, emerge would prefer old binpkgs over > newer ebuilds, which is not feasible in this case. That doesn't sound right. What do you mean by "old"?
> (In reply to comment #3) > >I switched > > from using -g to -k, because with -g, emerge would prefer old binpkgs over > > newer ebuilds, which is not feasible in this case. > > That doesn't sound right. What do you mean by "old"? It sounds like maybe it's bug 152084. It's a common problem when the version scheme of an ebuild is changed so that current ebuilds have lower versions that older ebuilds that no longer exist.
OK, sorry for this chaos, but it seems that in fact the problem still exists as originally described in comment #1. I'm running emerge -guDavN world, and portage does not download the updated package index, although the timestamp differs. With the wget command I can download the correct package index. But this time, the problem seems to be a different one: # grep TIMESTAMP /usr/portage/packages/Packages TIMESTAMP: 1297798235 BUT: # grep TIMESTAMP /var/cache/edb/binhost/milan.lih.rwth-aachen.de/packages-test/pentium-m-desktop/Packages TIMESTAMP: 1297797659 Now that's new, isn't it?
Is it producing any warning messages? Please try with at least 2.1.9.36 or v2.2.0_alpha20 since there has been a potentially useful warning message added since those releases: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a607079b3b556de243e955cda7ae9a3defd26750
Is this still a valid issue?
haven't seen this or related issues in a long time now. Seems to be resolved somehow.
