Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1 2015-11-05T11:21:33Z 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T20:08:55Z urn:sha1:258b9e512c4001e806c5c0966acecd3d742ec6e9 Reported-By: cppcheck Git-Dch: Ignore 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T17:01:35Z urn:sha1:9fb4e6510faaa9c84b88d4cb567bf3deebf8e0b7 A slightly unlikely bug, but lets fix it while slightly reworking this whole function to be slightly saner to look at, even if still not good. Git-Dch: Ignore 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T17:49:52Z urn:sha1:ce1f3a2c616b86da657c1c796efa5f4d18c30c39 Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore 2015-11-04T17:04:05Z David Kalnischkies david@kalnischkies.de 2015-10-30T15:34:25Z urn:sha1:294a80209a0c6ea617a14fb2ae650d4fd329eab5 This was discussed a while ago on #debian-apt and now that I see myself making this mistake lets bite the bullet and fix it in the easy way out version: Using a new name which fits with a similar named setter and deprecate the old method instead of 'hostily' changing API. Closes: #803471 2015-11-04T14:02:36Z David Kalnischkies david@kalnischkies.de 2015-09-15T10:44:53Z urn:sha1:8d6d3f00b14217e69ecabd68379b1e29bf4a3ccd Some codepaths need to check if the system (in our case usually dpkg) supports MultiArch or not. We had copy-pasted the check so far into these paths, but having it as a system check is better for reusability. 2015-10-30T14:35:13Z Julian Andres Klode jak@debian.org 2015-10-23T18:36:03Z urn:sha1:42285f827b6a28becc2d47d82f82f74f6ca68a11 The former is not thread-safe, whereas the latter is. Gbp-Dch: ignore 2015-10-30T13:20:43Z Julian Andres Klode jak@debian.org 2015-10-23T19:17:25Z urn:sha1:2a0cae347a058f0cc5d81477f75ed0c12b1e54e3 This function only exists on a limited number of platforms, so we add a configure check to make sure it exists. Gbp-Dch: ignore 2015-10-30T13:20:24Z Julian Andres Klode jak@debian.org 2015-10-23T18:45:21Z urn:sha1:2609e7cea39fb32a999acef014ea9ce6e9b3d141 ctime() is not thread-safe, ctime_r() is. Gbp-Dch: ignore 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-10T17:00:51Z urn:sha1:95278287f4e1eeaf5d96749d6fc9bfc53fb400d0 Our error reporting is historically grown into some kind of mess. A while ago I implemented stacking for the global error which is used in this commit now to wrap calls to functions which do not report (all) errors via return, so that only failures in those calls cause a failure to propergate down the chain rather than failing if anything (potentially totally unrelated) has failed at some point in the past. This way we can avoid stopping the entire acquire process just because a single source produced an error for example. It also means that after the acquire process the cache is generated – even if the acquire process had failures – as we still have the old good data around we can and should generate a cache for (again). There are probably more instances of this hiding, but all these looked like the easiest to work with and fix with reasonable (aka net-positive) effects. 2015-08-17T10:01:45Z Michael Vogt mvo@debian.org 2015-08-17T10:01:45Z urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba