Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.0 2021-03-07T01:55:07Z 2021-03-07T01:55:07Z David Kalnischkies david@kalnischkies.de 2021-03-06T23:47:26Z urn:sha1:59933938f51105066161a6eb88253006826336a2 Especially in small sections of an archive it can happen that an index returns to a previous state (e.g. if a package was first added and then removed with no other changes happening in between). The result is that we have multiple patches which start from the same hash which if we perform clientside merging is no problem although not ideal as we perform needless work. For serverside merging it would not matter, but due to rred previously refusing to merge zero-size patches but dak ignoring failure letting it carry these size-zero patches until they naturally expire we run into a problem as these broken patches won't do and force us to fall back to downloading the entire index. By always starting from the last patch instead of the first with the starter hash we can avoid this problem and behave optimally in clientside merge cases, too. 2021-03-07T01:55:07Z David Kalnischkies david@kalnischkies.de 2021-03-06T18:55:09Z urn:sha1:246f66561e23911b9615bd337b3b6f6f25b6cd31 The rred method expects the patches to have a certain name, which we have to rename the file to before calling the method, but by delaying the rename we ensure that if the download of one of them fails and a successful fallback occurs they are all properly cleaned up as no longer useful while in the error case the next apt run can potentially pick them up as already downloaded. Our test-pdiff-usage test was encountering this every other run, but did not fail as the check for unaccounted files in partial/ was wrapped in a subshell so that the failure produced failing output, but did not change the exit code. 2018-12-03T16:21:39Z Julian Andres Klode julian.klode@canonical.com 2018-12-03T08:16:20Z urn:sha1:f35601e5d2b9fe8b99c6178cb9b160f1a42f432f Try 10 times in a row 2018-05-11T16:28:29Z David Kalnischkies david@kalnischkies.de 2018-01-15T11:04:45Z urn:sha1:ed0e9eadeb3003f4f150da3c463b28cfa5e54b6f Individual items shouldn't concern themselves with these alternative locations, we can deal with this more efficiently within the infrastructure created for other alternative URIs now avoiding the need to implement this in each item. 2018-05-11T16:28:19Z David Kalnischkies david@kalnischkies.de 2018-01-13T23:07:20Z urn:sha1:2d6c6c8809c7b4c1a009df48387ba15066fda7e2 If we got a file but it produced a hash error, mismatched size or similar we shouldn't fallback to alternative URIs as they likely result in the same error. If we can we should instead use another mirror. We used to be a lot stricter by stopping all trys for this file if we got a non-404 (or a hash-based) failure, but that is too hard as we really want to try other mirrors (if we have them) in the hope that they have the expected and correct files. 2018-01-03T17:55:41Z David Kalnischkies david@kalnischkies.de 2017-08-09T21:26:19Z urn:sha1:02567e3084d2faec92e8bf248e89fda6452e634b The format isn't too hard to get right, but it gets funny with multiline fields (which we don't really have yet) and its just easier to deal with it once and for all which can be reused for more messages later. 2017-07-26T17:07:56Z David Kalnischkies david@kalnischkies.de 2017-07-26T16:35:42Z urn:sha1:f2f8e89f08cdf01c83a0b8ab053c65329d85ca90 Failing on too much data is good, but we can do better by checking for exact filesizes as we know with hashsums how large a file should be, so if we get a file which has a size we do not expect we can drop it directly, regardless of if the file is larger or smaller than what we expect which should catch most cases which would end up as hashsum errors later now a lot sooner. 2017-07-26T17:07:55Z David Kalnischkies david@kalnischkies.de 2017-07-23T23:15:55Z urn:sha1:8df85a4fb91bed6c79a3cb9c2000881cc5b42ea7 The comment says this is intended, but looking at the history reveals that the comment comes from a different era. Nowadays we don't really need it anymore (and even back then it was disputeable) as we haven't used that file for our update in the end and nothing really needs this file after the update. Triggered is this by 188f297a2af4c15cb1d502360d1e478644b5b810 which moves various error conditions forward including this code expecting the file to exist – but it doesn't need to as download could have failed. We could fix that by simple checking if the file exists and only stage it if it does, but instead we don't stage it and instead even rename it out of the way with our conventional FAILED name (if it exists). That restores support for partial mirrors (= in this case mirrors which don't ship pdiff files). Note that apt heals itself even if only such a mirror is used as the update is successful even if that error is shown. Closes: 869425 2017-06-26T21:31:15Z David Kalnischkies david@kalnischkies.de 2017-05-28T20:26:17Z urn:sha1:188f297a2af4c15cb1d502360d1e478644b5b810 Moving the code responsible for parsing the Index file from ::Done into the slightly earlier ::VerifyDone allows us to still "fail" the download if we can't make use of the Index for whatever reason, so that the progress log correctly displays "Ign" instead of "Get" for the file. This also makes quiet a few debug messages proper error messages (but those are still hidden by default for Ign lines). 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T14:14:19Z urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian