Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre1 2016-07-06T00:25:51Z 2016-07-06T00:25:51Z David Kalnischkies david@kalnischkies.de 2016-07-05T18:04:27Z urn:sha1:3465138575e1fd0d5892d9b6be1ae232eb873460 If we have files in partial/ from a previous invocation or similar such those could be symlinks created by file:// sources. The code is expecting only real files through and happily changes owner, modification times and permission on the file the symlink points to which tend to be files we have no business in touching in this way. Permissions of symlinks shouldn't be changed, changing owner is usually pointless to, but just to be sure we pick the easy way out and use lchown, check for symlinks before chmod/utimes. Reported-By: Mattia Rizzolo on IRC 2016-07-05T18:45:47Z David Kalnischkies david@kalnischkies.de 2016-07-05T18:36:15Z urn:sha1:68151307d42ed64cd6258f94a0d748abe9efb8e0 The test makes heavy use of disabling compression types which are usually available some way or another like xz which is how the EIPP logs are compressed by default. Instead of changing this test to change the filename according to the compression we want to test we just disable EIPP logging for this test as that is easier and has the same practical effect. Gbp-Dch: Ignore 2016-07-05T10:48:41Z David Kalnischkies david@kalnischkies.de 2016-07-03T08:54:25Z urn:sha1:60b48d4fc85593c9eabd8bea89fc6a7e6758410d It can be handy to set apt options for the testcases which shouldn't be accidentally committed like external planner testing or workarounds for local setups. Gbp-Dch: Ignore 2016-07-05T06:28:01Z Julian Andres Klode jak@debian.org 2016-07-05T06:28:01Z urn:sha1:2a90aa7a064047fb1c8783b31720cd345018ca4a Gbp-Dch: ignore 2016-07-05T06:22:52Z Julian Andres Klode jak@debian.org 2016-07-05T06:21:28Z urn:sha1:8823972649b0d3049c9c0d34b5f1d31160234fb4 This caused a crash because the cache was a nullptr. Closes: #829651 2016-07-02T10:01:17Z David Kalnischkies david@kalnischkies.de 2016-07-02T09:28:42Z urn:sha1:0b45b6e5de1ba4224ced67a9952e009d0f4139a0 All apt versions support numeric as well as 3-character timezones just fine and its actually hard to write code which doesn't "accidently" accepts it. So why change? Documenting the Date/Valid-Until fields in the Release file is easy to do in terms of referencing the datetime format used e.g. in the Debian changelogs (policy §4.4). This format specifies only the numeric timezones through, not the nowadays obsolete 3-character ones, so in the interest of least surprise we should use the same format even through it carries a small risk of regression in other clients (which encounter repositories created with apt-ftparchive). In case it is really regressing in practice, the hidden option -o APT::FTPArchive::Release::NumericTimezone=0 can be used to go back to good old UTC as timezone. The EDSP and EIPP protocols use this 'new' format, the text interface used to communicate with the acquire methods does not for compatibility reasons even if none of our methods would be effected and I doubt any other would (in these instances the timezone is 'GMT' as that is what HTTP/1.1 requires). Note that this is only true for apt talking to methods, (libapt-based) methods talking to apt will respond with the 'new' format. It is therefore strongly adviced to support both also in method input. 2016-07-01T20:00:52Z David Kalnischkies david@kalnischkies.de 2016-07-01T20:00:52Z urn:sha1:08fcf9628806af202e555bd02b3611e4e9a3d757 apt-key needs gnupg for most of its operations, but depending on it isn't very efficient as apt-key is hardly used by users – and scripts shouldn't use it to begin with as it is just a silly wrapper. To draw more attention on the fact that e.g. 'apt-key add' should not be used in favor of "just" dropping a keyring file into the trusted.gpg.d directory this commit implements the display of warnings. 2016-07-01T12:33:02Z David Kalnischkies david@kalnischkies.de 2016-07-01T12:00:47Z urn:sha1:cb9ac09bd6a36e73c2dce1d529acde6e4d15e32d As the volatile sources are parsed last they were sorted behind the dpkg/status file and hence are treated as a downgrade, which isn't really what you want to happen as from a user POV its an upgrade. 2016-07-01T11:36:40Z David Kalnischkies david@kalnischkies.de 2016-07-01T11:17:03Z urn:sha1:e7edb2fef8370d54a4b8e5a01266e6eda81ef84e If we have a (e.g. locally built) deb file installed and do try to install it again apt complained about this being a downgrade, but it wasn't as it is the very same version… it was just confused into not merging the versions together which looks like a downgrade then. The same size assumption is usually good, but given that volatile files are parsed last (even after the status file) the base assumption no longer holds, but is easy to adept without actually changing anything in practice. 2016-07-01T08:06:53Z David Kalnischkies david@kalnischkies.de 2016-07-01T08:06:53Z urn:sha1:a0ed43f7323b9d7976ed0ba8d437a42e24af9eaf Traditionally all providers are protected providing something as apt can't know which of them is actually really providing the functionality for the user ensuring that we don't propose the removal of used stuff, but that is of course also keeping stuff around which could be removed. That can cause the collection of multiple old providers until the provided package is itself no longer needed (e.g. out-of-tree kernel modules). We combat this by marking providers only from the newest source package version so that old providers built by older versions of the same source package can be garbage collected.