Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre3 2016-07-22T14:05:10Z 2016-07-22T14:05:10Z David Kalnischkies david@kalnischkies.de 2016-07-21T13:54:22Z urn:sha1:84255101ee38693aea2fd456cf0da174434afa01 Hardcoding /var/crash means we can't test it properly and it isn't really our style. 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-20T16:09:46Z urn:sha1:e5c3f3ccd98e926b91693d961db4d338fd144301 The existing cleanup was happening only for packages which had a status change (install -> uninstalled) which is the most frequent but no the only case – you can e.g. set autobits explicitly with apt-mark. This would leave stanzas in the states file declaring a package to be manually installed – which is the default value for a package not listed at all, so we can just as well drop it from the file. 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-20T12:56:06Z urn:sha1:c1e202d225eea6838acd65ea81266996ee6bb9a2 Otherwise calls like "apt -q install" end up calling "aptautotest_apt_q" instead of "aptautotest_apt_install" Gbp-Dch: Ignore 2016-07-19T16:20:38Z David Kalnischkies david@kalnischkies.de 2016-07-19T16:20:38Z urn:sha1:475f75506db48a7fa90711fce4ed129f6a14cc9a Theoretically it should be enough to change the Dir setting and have apt pick the dpkg/status file from that. Also, it should be consistently effected by RootDir. Both wasn't really the case through, so a user had to explicitly set it too (or ignore it and have or not have expected sideeffects caused by it). This commit tries to guess better the location of the dpkg/status file by setting dir::state::status to a naive "../dpkg/status", just that this setting would be interpreted as relative to the CWD and not relative to the dir::state directory. Also, the status file isn't really relative to the state files apt has in /var/lib/apt/ as evident if we consider that apt/ could be a symlink to someplace else and "../dpkg" not effected by it, so what we do here is an explicit replace on apt/ – similar to how we create directories if it ends in apt/ – with dpkg/. As this is a change it has the potential to cause regressions in so far as the dpkg/status file of the "host" system is no longer used if you set a "chroot" system via the Dir setting – but that tends to be intended and causes people to painfully figure out that they had to set this explicitly before, so that it now works more in terms of how the other Dir settings work (aka "as expected"). If using the host status file is really intended it is in fact easier to set this explicitely compared to setting the new "magic" location explicitely. 2016-07-15T19:59:10Z David Kalnischkies david@kalnischkies.de 2016-07-15T19:17:11Z urn:sha1:87f99f6fa701d2557811134380c1f232cf07a422 Most tests are either multiarch, do not care for the specific architecture or do not interact with dpkg, so really effect by this is only test-external-installation-planner-protocol, but its a general issue that while APT can be told to treat any architecture as native dpkg has the native architecture hardcoded so if we run tests we must make sure that dpkg knows about the architecture we will treat as "native" in apt as otherwise dpkg will refuse to install packages from such an architecture. This reverts f883d2c3675eae2700e4cd1532c1a236cae69a4e as it complicates the test slightly for no practical gain after the generic fix. 2016-07-08T10:43:56Z David Kalnischkies david@kalnischkies.de 2016-07-08T09:57:56Z urn:sha1:b327c569de774177f1505e52a378396250c975f2 The setup didn't prepare the directories as expected by newer version of tthe external tests in an autopkgtests environment. 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-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-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.