Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.1 2024-02-20T12:49:04Z 2024-02-20T12:49:04Z Julian Andres Klode julian.klode@canonical.com 2024-02-20T12:43:08Z urn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49 This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces. 2021-07-28T11:08:35Z Julian Andres Klode julian.klode@canonical.com 2021-07-28T10:43:56Z urn:sha1:4001af8920389e2bb2672b673b181c4e92515872 This is very basic support on the testing side, we just test the debug output but not how long it actually took. Would be nice to check time really. 2021-07-28T11:08:35Z Julian Andres Klode julian.klode@canonical.com 2021-07-27T14:40:38Z urn:sha1:48a7ece8d0e065240153a85089f544383e16137f This yields more accurate delays and avoids issues with clock skew. 2021-07-28T11:04:10Z Julian Andres Klode julian.klode@canonical.com 2021-07-08T14:49:20Z urn:sha1:121ccd0e0c2612bab9ba5383d5599b54e29e4643 Add a new Item field called FetchAfter, which determines the earliest time the item should be fetched at. Adjust insertion into queue to take it into account alongside priority, and only fill pipelines with items that are ready. 2020-12-18T18:31:19Z David Kalnischkies david@kalnischkies.de 2020-07-09T14:38:49Z urn:sha1:e6c55283d235aa9404395d30f2db891f36995c49 We do not deal a lot with URIs which need encoding, but then we do it is a pain that we store it decoded in the acquire system as it means we have to decode and reencode URIs eventually which is potentially giving us slightly different URIs. We see that in our own testing framework while setting up redirects as the config options are effectively double-encoded and decoded to pass them around successfully as otherwise %2f and / in an URI are treated the same. This commit adds the infrastructure for methods to opt into getting URIs send in encoded form (and returning them to us in encoded form, too) so that we eventually do not have to touch the URIs which is how it should be. This means though that we have to deal with methods who do not support this yet (aka: all at the moment) for which we decode and encode while communicating with them. 2020-02-26T13:10:47Z Julian Andres Klode julian.klode@canonical.com 2020-02-26T13:04:51Z urn:sha1:da18eb10188a22fc1698a9b8466272f2826447db 2019-04-30T15:43:56Z Julian Andres Klode julian.klode@canonical.com 2019-04-30T10:32:54Z urn:sha1:af74a9e2d55d6a9532eb3fbb9b96c65b7ddc1e4d This needs a fair amount of changes elsewhere in the code, hence this is separate from the previous commits. 2019-04-30T15:40:38Z Julian Andres Klode julian.klode@canonical.com 2019-04-29T18:05:38Z urn:sha1:cccef6ca60c2775e918d964fdad1afc1dcad4d0e These status fields belong to the current item, move them there. This prepares us for eventually having multiple current items. 2019-01-31T15:21:04Z Julian Andres Klode julian.klode@canonical.com 2019-01-30T12:43:29Z urn:sha1:80282d1830fe31d87c1b67437f17df9a9001c633 These methods are not supposed to be used anymore, they are not actively maintained and may hence contain odd bugs. Fixes !49 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.