Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.10 2020-08-11T12:34:13Z 2020-08-11T12:34:13Z Julian Andres Klode julian.klode@canonical.com 2020-08-11T12:34:13Z urn:sha1:6b3fbe9d5e661a3f371eb26631b3f8b502c390a6 2020-08-11T12:26:51Z Julian Andres Klode jak@debian.org 2020-08-11T12:26:51Z urn:sha1:1e2d586703e8c0227ddb7b3705205c85e3b8507e Add better acquire debugging support See merge request apt-team/apt!130 2020-08-11T11:42:41Z Julian Andres Klode julian.klode@canonical.com 2020-08-11T11:09:14Z urn:sha1:8b35e2a3dd7b863639a8909fa2361ed4fd217bc3 The old code was fairly confusing, and contradictory. Notably, the second `if` also only applied to the Data state, whereas we already terminated the Data state earlier. This was bad. The else fallback applied in three cases: (1) We reached our limit (2) We are Persistent (3) We are headers Now, it always failed as a transient error if it had nothing left in the buffer. BUT: Nothing left in the buffer is the correct thing to happen if we were fetching content. Checking all combinations for the flags, we can compare the results of Die() between 2.1.7 - the last "known-acceptable-ish" version and this version: 2.1.7 this Data !Persist !Space !Limit OK (A) OK Data !Persist !Space Limit OK (A) OK Data !Persist Space !Limit OK (C) OK Data !Persist Space Limit OK OK Data Persist !Space !Limit ERR ERR * Data Persist !Space Limit OK (B) OK Data Persist Space !Limit ERR ERR Data Persist Space Limit OK OK => Data connections are OK if they have not reached their limit, or are persistent (in which case they'll probably be chunked) Header !Persist !Space !Limit ERR ERR Header !Persist !Space Limit ERR ERR Header !Persist Space !Limit OK OK Header !Persist Space Limit OK OK Header Persist !Space !Limit ERR ERR Header Persist !Space Limit ERR ERR Header Persist Space !Limit OK OK Header Persist Space Limit OK OK => Common scheme here is that header connections are fine if they have read something into the input buffer (Space). The rest does not matter. (A) Non-persistent connections with !space always enter the else clause, hence success (B) no Space means we enter the if/else, we go with else because IsLimit(), and we succeed because we don't have space (C) Having space we do enter the while (WriteSpace()) loop, but we never reach IsLimit(), hence we fall through. Given that our connection is not persistent, we fall through to the else case, and there we win because we have data left to write. 2020-08-11T11:09:04Z Julian Andres Klode julian.klode@canonical.com 2020-08-11T08:55:09Z urn:sha1:73780d7f664a4ea1da55527d726b4c9c7753f1fb We do not want to end up in a code path while reading content from the server where we have local data left to write, which can happen if a previous read included both headers and content. Restructure Flush() to accept a new argument to allow incomplete flushs (which do not match our limit), so that it can flush as far as possible, and modify Go() and use that before and after reading from the server. 2020-08-11T11:09:04Z Julian Andres Klode julian.klode@canonical.com 2020-08-11T09:42:15Z urn:sha1:13ab2317451931f055855f1aeaec6c8b28b14ce2 This causes some more issues, really. 2020-08-11T11:09:04Z Julian Andres Klode julian.klode@canonical.com 2020-08-11T09:40:14Z urn:sha1:af7ab7c0002ef2cdfb1a4c0a468c5dbbda3d5dd0 We have successfully finished reading data if our buffer is empty, so we don't need to do any further checks. 2020-08-11T06:57:47Z Julian Andres Klode julian.klode@canonical.com 2020-08-11T06:56:39Z urn:sha1:626b7ccc8cec120f789ef89c2d5d28b8b6d67a04 If we have errors pending, always log them with our failure message to provide more context. 2020-08-10T14:24:17Z Julian Andres Klode jak@debian.org 2020-08-10T14:24:17Z urn:sha1:23447e9b57a00482a5b26a7cb901f7bf4f28fa73 Default Acquire::AllowReleaseInfoChange::Suite to "true" See merge request apt-team/apt!128 2020-08-10T13:39:33Z Julian Andres Klode julian.klode@canonical.com 2020-08-10T13:39:33Z urn:sha1:64b45e294f0c6931a9b57ae6cc99ecded8f6a2d3 Closes: #931566 2020-08-10T12:16:47Z Julian Andres Klode julian.klode@canonical.com 2020-08-10T12:16:47Z urn:sha1:f21440f5af98e1b5987e040a8f25bc3c2d6b7831