Control: tags -1 = confirmed On Fri, Jun 24, 2016 at 09:22:12PM +0200, Eric Valette wrote: > Answer for: http://download.virtualbox.org/virtualbox/debian/dists/jessie/InRelease > HTTP/1.1 200 OK > Server: Apache > ETag: "1e6763f0c4df7d4582dd89e6437276e0:1466107324" > Last-Modified: Thu, 16 Jun 2016 16:39:18 GMT > Accept-Ranges: bytes > Content-Length: 7894 > Content-Type: text/plain > Date: Fri, 24 Jun 2016 19:21:14 GMT > Connection: keep-alive > > <- http:400%20URI%20Failure%0aURI:%20http://download.virtualbox.org/virtualbox/debian/dists/jessie/InRelease%0aMessage:%20Format%20de%20date%20inconnu%20[IP%c2%a0:%202.18.245.43%2080]%0aTransient-Failure:%20true No sense this makes as the "Last-Modified" date the http binary is complaining about here is a valid date and parses just fine here. Until you realize that this is a locale thing. The French have a space as thousand separator, so the parser (which I would actually consider another stdlibc++6 bug) eats the entire string on the basis that spaces aren't field but thousand separators (and 'Jun' looks very numberish for some reason…). The solution is simple – and I wonder why it wasn't in the second rewrite as it was part of the first – just ensure we parse in a locale with less ambiguous numeric formatting like all the locales apt developers operate in, or C.UTF-8 for fairness. As apt isn't really in the business of printing numbers setting LC_NUMERIC=C.UTF-8 as a workaround should keep the l10n intact. As I said the last two times already: How hard can date parsing be… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature