Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.18 2021-01-13T15:55:55Z 2021-01-13T15:55:55Z Julian Andres Klode julian.klode@canonical.com 2021-01-13T15:55:55Z urn:sha1:569c836154e17f09c1c96231b2230c9d23a4324f 2021-01-08T16:58:44Z Julian Andres Klode julian.klode@canonical.com 2021-01-08T16:52:53Z urn:sha1:c7123bea6a8dc2c9e327ce41ddfc25e29f1bb145 People have been asking for a feature to error out on transient network errors for a while, this gives them one while keeping the door open for other modes we need, such as --error-on=no-success which we need to determine when to retry the daily update job. Closes: #594813 (and a whole bunch of duplicates...) 2021-01-08T13:48:47Z Julian Andres Klode julian.klode@canonical.com 2020-08-10T18:16:11Z urn:sha1:c5bc86d45e003905ef411146e66b414d26fb1ff8 This adds support for Phased-Update-Percentage by pinning upgrades that are not to be installed down to 1. The output of policy has been changed to add the level of phasing, and documentation has been improved to document how phased updates work. The patch detects if it is running in a chroot, and if so, always includes phased updates, restoring classic apt behavior to avoid behavioral changes on buildd chroots. Various options are added to control this all: * APT::Get::{Always,Never}-Include-Phased-Updates and their legacy update-manager equivalents to always or never include phased updates * APT::Machine-ID can be set to a UUID string to have all machines in a fleet phase the same * Dir::Etc::Machine-ID is weird in that it's default is sort of like ../machine-id, but not really, as ../machine-id would look up $PWD/../machine-id and not relative to Dir::Etc; but it allows you to override the path to machine-id (as opposed to the value) * Dir::Bin::ischroot is the path to the ischroot(1) binary which is used to detect whether we are running in a chroot. 2021-01-05T15:40:16Z Julian Andres Klode jak@debian.org 2021-01-05T15:40:16Z urn:sha1:e92cdbfda401835318600b0d0f31901701b6a675 Be compatible with Bash See merge request apt-team/apt!142 2021-01-04T09:46:48Z Julian Andres Klode julian.klode@canonical.com 2020-12-17T12:24:56Z urn:sha1:04085f46dea9a95dd86123ac00187a63cc4ba2c0 Our kernel autoremoval helper script protects the currently booted kernel, but it only runs whenever we install or remove a kernel, causing it to protect the kernel that was booted at that point in time, which is not necessarily the same kernel as the one that is running right now. Reimplement the logic in C++ such that we can calculate it at run-time: Provide a function to produce a regular expression that matches all kernels that need protecting, and by changing the default root set function in the DepCache to make use of that expression. Note that the code groups the kernels by versions as before, and then marks all kernel packages with the same version. This optimized version inserts a virtual package $kernel into the cache when building it to avoid having to iterate over all packages in the cache to find the installed ones, significantly improving performance at a minor cost when building the cache. LP: #1615381 2020-12-28T23:35:29Z Demi M. Obenour demiobenour@gmail.com 2020-12-28T23:35:29Z urn:sha1:cfd62644ec2dda4968ac65751f162932fc46761f On many distributions, /bin/sh is Bash. Bash’s `echo` builtin doesn’t interpret escape sequences, so most tests fail. Fix this by removing the escape sequence. 2020-12-18T19:45:35Z David Kalnischkies david@kalnischkies.de 2020-07-10T18:19:31Z urn:sha1:a5859bafdaa6bcf12934d0fb1715a5940965e13a This commit potentially breaks code feeding apt an encoded URI using a method which does not get URIs send encoded. The webserverconfig requests in our tests are an example for this – but they only worked before if the server was expecting a double encoding as that was what was happening to an encoded URI: so unlikely to work as expected in practice. Now with the new methods we can drop this double encoding and rely on the URI being passed properly (and without modification) between the layers so that passing in encoded URIs should now work correctly. 2020-12-18T18:31:19Z David Kalnischkies david@kalnischkies.de 2020-07-09T22:02:25Z urn:sha1:97d6c3b2d05fe0d965657197adf56cc78f9edf81 Every method opts in to getting the encoded URI passed along while keeping compat in case we are operated by an older acquire system. Effectively this is just a change for the http-based methods as the others just decode the URI as they work with files directly. 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-12-18T18:02:05Z David Kalnischkies david@kalnischkies.de 2020-07-08T15:51:40Z urn:sha1:97be873d782c5e9aaa8b4f4f4e6e18805d0fa51c Our http method encodes the URI again which results in the double encoding we have unwrap in the webserver (we did already, but we skip the filename handling now which does the first decode).