As Eugugene stated, it's because of a race condition.
Another related bug, #439031, indicated that multiple gpgv threads run on the same Releases files (once for a deb, again for deb-src line in sources.list) causes a similar stall.
I've made a trivial-style repo from dpkg-scanpages (results piped though plain gzip) and set a chrooted etch to download directly from it. It stalled on apt-get update. So that ruled out the http-proxy and mini-dinstall:python:BZ2 issues I was suspecting. What _did_ help was only using a deb-src line against that repo. And I bet that my prior report of success with my new reprepro repositiory was beacuse reprepro uses a non-trivial layout (multiple Packages files).
I guess chroots just trigger the race easily for some reason, why else the lack of reportage/fix-urgency?
joey
-- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
