apt, branch 2.3.7 Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.7 2021-07-29T15:00:26Z Release 2.3.7 2021-07-29T15:00:26Z Julian Andres Klode julian.klode@canonical.com 2021-07-29T14:59:52Z urn:sha1:6442107478c5418cd0053eef626f53d565fda7e1 Merge branch 'pu/fetch-at' into 'main' 2021-07-29T14:56:41Z Julian Andres Klode jak@debian.org 2021-07-29T14:56:41Z urn:sha1:410a6d9d84136fc0bc8c50551313c036ae99aafa Main-process-side implementation of retry back-off See merge request apt-team/apt!181 tests (retry-downloads): Avoid delay in second test 2021-07-29T09:50:16Z Julian Andres Klode julian.klode@canonical.com 2021-07-29T09:49:05Z urn:sha1:3ca5e18b1f0bb05697ccca7c98ced1176166024a This delay of 4+2+1=7 seconds in unnecessary. Enhance test to check time spent 2021-07-29T09:49:59Z Julian Andres Klode julian.klode@canonical.com 2021-07-29T09:46:47Z urn:sha1:70ee96670bbc09e724aeeb6263ee6a3bdde8afdc This is subject to clock skew, unfortunately, as we cannot read monotonic time in shell. We check for >=5s out of the 7s it should take to reduce the risk of skew a bit. Add support for a maximum delay and testing of delay 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. Properly convert PulseInterval to timeval 2021-07-28T11:08:35Z Julian Andres Klode julian.klode@canonical.com 2021-07-27T15:14:23Z urn:sha1:51ee79e385d8ccb2f32195cc01f3f9c943197603 Fix the typo, and use the helper function to convert it, so we do not end up with 5 seconds encoded as 0s and 5*10^6 microseconds. Convert to monotonic clock 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. acquire: Automatically reduce select() timeout as needed 2021-07-28T11:08:32Z Julian Andres Klode julian.klode@canonical.com 2021-07-13T10:21:23Z urn:sha1:7e88def0548a92112f8295686c2a12379e4028be If there is an item with fetchAfter at the top of a queue, reduce sleep() timeout so we can detect it and start it, by calling Cycle() on the queue in the next iteration. For some reasons we have to call select() with a 0s timeout if we just marked an item as ready. Oh well. Previous versions of this patch only called global Bump() after a timeout from select(); this was unfortunately incorrect - it meant that we never bumped a queue that did not start yet while other queues were running, potentially significantly delaying retries. Implement exponential delay between retries 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. pkgAcqIndex::CommonFailed: Set StatIdle before calling Init() 2021-07-13T14:16:55Z Julian Andres Klode julian.klode@canonical.com 2021-07-13T14:03:06Z urn:sha1:363e3a4c91da353d99cf1af3d5089c9455d461de Enqueuing by calling Init(), and then resetting the status to idle means that the item can get enqueued twice if we call Cycle() from inside pkgAcquire::Run(). Reset the status to StatIdle before calling Init()