Hi, On Tue, May 05, 2015 at 09:43:53AM +0200, Cesare Leonardi wrote: > root@etna:~# apt update > Get:1 http://httpredir.debian.org unstable InRelease [204 kB] > Hit http://httpredir.debian.org experimental InRelease […] > Err http://httpredir.debian.org experimental/non-free amd64 Packages > > Hit http://httpredir.debian.org experimental/non-free amd64 Packages > Fetched 298 kB in 4s (66,2 kB/s) Would be nice if you could run apt update -o Debug::Acquire::http=1 (This enables a lot of output resembling the messages send between server(s) and the apt client(s). Probably best to redirect the output to a file with e.g.: 2>&1 | tee apt-update.log as the different interactions happen in parallel, so the output can be a confusing mix of stuff on first look). We are working in /experimental on revamping the acquire system at large which is what is behind downloading stuff and shared between all package managers based on libapt, so apt and aptitude do exactly the same here. I am in particular working currently in my branch on the behavior of getting a 'Hit' for a (In)Release(.gpg) file currently, which is what you got in your example and likely most of the time as non-free experimental isn't changing a lot. Note that this Err isn't critical, apt happily recovers from many 'errors' as getting them is "normal". apt implements an HTTP1.1 client which tries to use many features of HTTP1.1, but many servers running on mirrors implement only a subset of the features. And many different subsets. Not to mention that some downright refuse to implement them correctly (one of the sillier examples is e.g. #778375 or pipelining, my personal favorite). Unfortunately the internet isn't implemented based on specs, but based on what popular browsers use and support (which isn't much – its pretty ironic that our selfwritten test webserver supports more of HTTP1.1 than most 'real' webservers. And its only getting worse)… Usually you are not told about such errors, but it looks like one slipped through here. I haven't looked at the 'old' source, but I have a suspicion, which the debug output hopefully confirms: The server is supporting Range-requests, but not If-Range and hence answers with a 416, but not with Content-Range set. I at least have a faint memory of encountering such a server recently with these symptoms. So, summary: If the debug output isn't proofing me horribly wrong (possible), I am going to close this bugreport (if unreproducible with our forthcoming new acquire system) as this is a 'display issue' and the fix is basically our 'webservers are idiots' rewrite^Wrework… ;)
Attachment:
signature.asc
Description: Digital signature