Debian Bug report logs - #784310
apt update always fails on experimental/non-free

Full log

🔗 View this message in rfc822 format

X-Loop: [email protected]
Subject: Bug#784310: apt update always fails on experimental/non-free
Reply-To: David Kalnischkies <[email protected]>, [email protected]
Resent-From: David Kalnischkies <[email protected]>
Resent-To: [email protected]
Resent-CC: APT Development Team <[email protected]>
X-Loop: [email protected]
Resent-Date: Thu, 07 May 2015 11:33:02 +0000
Resent-Message-ID: <[email protected]>
Resent-Sender: [email protected]
X-Debian-PR-Message: followup 784310
X-Debian-PR-Package: apt
X-Debian-PR-Keywords: 
X-Debian-PR-Source: apt
Received: via spool by [email protected] id=B784310.143099819331604
          (code B ref 784310); Thu, 07 May 2015 11:33:02 +0000
Received: (at 784310) by bugs.debian.org; 7 May 2015 11:29:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02
	(2014-02-07) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-11.8 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER,
	PGPSIGNATURE,RCVD_IN_DNSWL_LOW autolearn=ham autolearn_force=no
	version=3.4.0-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 16; hammy, 149; neutral, 137; spammy,
	1. spammytokens:0.990-+--favorite hammytokens:0.000-+--H*c:pgp-sha256,
	0.000-+--H*u:2014-03-12, 0.000-+--H*UA:2014-03-12, 0.000-+--H*u:1.5.23,
	0.000-+--H*UA:1.5.23
Received: from puppis.uberspace.de ([95.143.172.214])
	by buxtehude.debian.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <[email protected]>)
	id 1YqK01-0008DU-8t
	for [email protected]; Thu, 07 May 2015 11:29:53 +0000
Received: (qmail 31935 invoked from network); 7 May 2015 11:29:49 -0000
Received: from localhost (HELO localhost) (127.0.0.1)
  by puppis.uberspace.de with SMTP; 7 May 2015 11:29:49 -0000
Date: Thu, 7 May 2015 13:29:46 +0200
From: David Kalnischkies <[email protected]>
To: [email protected]
Cc: Cesare Leonardi <[email protected]>
Message-ID: <20150507112946.GD31607@crossbow>
References: <20150505074353.5247.44090.reportbug@etna>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="8w3uRX/HFJGApMzv"
Content-Disposition: inline
In-Reply-To: <20150505074353.5247.44090.reportbug@etna>
User-Agent: Mutt/1.5.23 (2014-03-12)

[Message part 1 (text/plain, inline)]

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… ;)

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.