Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.11 2020-10-21T10:01:33Z 2020-10-21T10:01:33Z Julian Andres Klode julian.klode@canonical.com 2020-10-21T10:01:04Z urn:sha1:5d4a9e4b595ec145cdbe30b4f43d6bcdf9f26b2e 2020-10-21T09:47:29Z Julian Andres Klode julian.klode@canonical.com 2020-10-21T09:47:29Z urn:sha1:998a17d7e6f834c341f198ca5b6df2f27e18df38 We are seeing more and more installations fail due to immediate configuration issues related to libc6. Immediate configuration is supposed to ensure that an essential package is configured immediately, just in case some other packages use a part of the essential package that only works if that package is configured. This used to be a warning, it was turned into an error in some commit I can't remember right now, but importantly, the error missed a return, which means that ordering completed succesfully and packages were being installed anyway; and after all that happened successfully, we'd print an error at the end and exit with an error code, which is not super useful. Revert the error back to a warning such that the behavior stays the same but we do not fail (unless we mess up ordering which then gets caught by a consistency check later on. Closes: #953260 Closes: #972552 LP: #1871268 2020-09-10T20:32:16Z Frans Spiesschaert Frans.Spiesschaert@yucom.be 2020-09-10T18:27:07Z urn:sha1:766b24b7f7484751950c76bc66d3d6cdeaf949a5 Closes: #970037 [jak: Fix typo extended_status -> extended_states] 2020-09-09T09:28:59Z Julian Andres Klode julian.klode@canonical.com 2020-09-09T09:28:43Z urn:sha1:9207142bdad78a969bd803f19dfbc739bf4068d7 2020-08-27T12:47:25Z JCGoran jcgoran@protonmail.com 2020-08-27T12:00:57Z urn:sha1:57356d5795ff841ebbacfce63cf48e97fde80682 Closes: #969086 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.