Platform is SUSE Enterprise 10 SP2. Emerging sys-libs/zlib-1.2.5-r2 fails. This emerge is invoked by the `env FEATURES="-collision-protect" emerge --oneshot portage' step. The nature of the failure is that, all of a sudden, downloading is attempted without using the intended HTTP proxy. At the time of the failing emerge the proxy is declared by these lines in etc/wgetrc: http_proxy=http://some.host.se:8080/ ftp_proxy=http://some.host.se:8080/ The immediately preceding emerge is `emerge --oneshot pax-utils'. This emerge succeeds and it can be seen from the log that the intended proxy is being used. The console log does not say a lot, it just shows that downloading fails: env FEATURES="-collision-protect" emerge --oneshot portage Calculating dependencies ^H^H... done! >>> Verifying ebuild manifests >>> Emerging (1 of 27) sys-libs/zlib-1.2.5-r2 >>> Downloading 'http://distfiles.gentoo.org/distfiles/zlib-1.2.5.tar.bz2' --02:10:43-- http://distfiles.gentoo.org/distfiles/zlib-1.2.5.tar.bz2 => `/local/scratch/nightly/2010-05-19/usr/portage/distfiles/zlib-1.2.5.tar.bz2' Resolving distfiles.gentoo.org... 216.165.129.135, 140.211.166.134, 149.20.20.135, ... Connecting to distfiles.gentoo.org|216.165.129.135|:80... failed: Connection timed out. Connecting to distfiles.gentoo.org|140.211.166.134|:80... failed: Connection timed out. Connecting to distfiles.gentoo.org|149.20.20.135|:80... failed: Connection timed out. Connecting to distfiles.gentoo.org|156.56.247.195|:80... failed: Connection timed out. Connecting to distfiles.gentoo.org|199.6.1.174|:80... failed: Connection timed out. Retrying.
Isn't this the same as bug#315421? Does portage's tempdir for zlib (var/tmp/portage/sys-libs/zlib-1.2.5-r2/temp/) exist when the download fails?
There are similarities insofar as #315421 is also about bootstrapping behind proxy. However, this problem is a new one that was not present in the early (CEST) hours of 2010-05-18. Yes, the temporary directory exists.
It seems that the failing command (env FEATURES="-collision-protect" emerge --oneshot portage) executes tmp/usr/bin/wget directly, disregarding the current PATH. Apparently the http_proxy definition is also removed from the environment. As a workaround I can rename tmp/usr/bin/wget to e g tmp/usr/bin/wget-displaced and insert a wrapper named tmp/usr/bin/wget that exports http_proxy with a usable value and then "execs" tmp/usr/bin/wget-displaced. I am currently re-running this in scripted mode just to verify that I haven't got anything wrong. I really don't understand why the proxy definition in etc/wgetrc, which is present when the failing command is attempted, doesn't work.
(In reply to comment #3) > It seems that ... > executes tmp/usr/bin/wget directly > I really don't understand why the proxy definition in etc/wgetrc, which is > present when the failing command is attempted, doesn't work. Ohw, tmp/usr/bin/wget... I don't believe tmp/usr/bin/wget reads etc/wgetrc - it eventually would read tmp/etc/wgetrc or even tmp/usr/etc/wgetrc. Most likely it is only usr/bin/wget reading etc/wgetrc. But still: Whenever http_proxy becomes unset by portage, does $T for the package in question (var/tmp/portage/<category>/<package>/temp/) exist?
I had a look in one of my Prefix file trees that were not fully bootstrapped because of this issue. The first package that has problems, causing my bootstrapping script to abort, is sys-libs/zlib. If I look around in the file tree I can see the var/tmp directory, but it does not contain anything; thus no portage directory.
This problem, whatever it was, seems to have healed over time. I have removed my workarounds base on editing etc/wgetrc. All I do now is to have http_proxy=http://x.y.z:nnnn ftp_proxy=http://x.y.z:nnnn https_proxy=http://x.y.z:nnnn in the environment, and bootstrapping succeeds all the way.
thanks
