On Thu, Oct 27, 2016 at 10:05:56PM +0200, Tollef Fog Heen wrote: > ]] David Kalnischkies > > I would kinda like to avoid encoding the entire answer and sending that > > in for display because it would be a lot of noise (and bugreporters will > > truncate it if it is too long trying to be helpful), so if people who > > actually know what they would need to deal with issues (I don't) would > > decide upon a set and report a bug against apt to implement it, we will > > see what we can do. > > It would be great if we could have all of it (dropped in a log file > would probably be ok, we can then ask for it from the user). I feared you would say that, but I would very much like to avoid that as it complicates everything: The acquire system has roughly 3 usecases: Download indexes, download packages and download "random" files (sources, changelogs, …). The later two can be done as root and as a 'normal' user. We couldn't let the individual transport log on their own as they have no idea where to. So I would need them to tell the system the stuff they want logged which also doesn't really know what it does (and especially when it switches jobs at runtime in interactive tools) so I would need the individual callers (apt, aptitude, packagekit, …) to decide where to log to (+ multiple acquires could be running at the same time all over the place which shouldn't battle for logfiles – there are even situations in which an acquire system runs as part of another one…) which pretty much rules out stretch to have it. And given the world adapts very slowly to apt changes I wouldn't hold my breath for buster either. We would also need a rotation setup as the first thing someone does on an 'update' failure is to run it again (or a process in the background does like packagekit without the user realizing that the manual invocation was superseded), … [Having "stuff" (not limited to acquire) logged to a file might be a good idea anyhow eventually, but that project is at least as boring as it is big, so…] Showing a few more lines is trivial by comparison, effects everyone instantly and is hence oh so much more appealing from an apt POV… ala: | Transport-Debug: | Connected-To: http.fastly.debian.example.org:8080 (0.0.0.0) | Via: 1.1 varnish, 1.1 varnish | Fastly-Debug-Digest: b6ea737814cc1feed0f9205c8ee1338025c8d316c1029a16c6f4365c6a7c6cdd | X-Served-By: cache-ams4141-AMS, cache-fra1222-FRA | X-Cache: MISS, MISS | X-Timer: S1477471085.983025,VS0,VE27 and | Transport-Debug: | Connected-To: http.cloudfront.debian.example.org:8080 (0.0.0.0) | X-Cache: Miss from cloudfront | Via: 1.1 b74a7a3f7ddfd685212e870d027c332d.cloudfront.net (CloudFront) | X-Amz-Cf-Id: OWWfvAJ_et1_QVyPiP07-bodyCenkWtGTz8OeRW041eyeRDuvmGgCA== (assuming these headers would tell you anything, they just look good to me) > > P.S.: Fastlys Via response header seems to be important, given that it > > is sent twice, but apart from that… > > Not really, it's just that it passes through multiple caches on the way. [Ill-attempt at humor – to the untrained eye it just looks like Via should be what X-Served-By contains. Especially merged as above it looks like a mistake but so be it.] Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature