Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre1 2016-06-29T12:46:34Z 2016-06-29T12:46:34Z David Kalnischkies david@kalnischkies.de 2016-06-29T12:46:34Z urn:sha1:fc5db01bb7d1546944200d197866b0b5c378f100 We deploy atomic renames for some files, but these renames also happen if something about the file failed which isn't really the point of the exercise… Closes: 828908 2016-06-17T16:09:20Z David Kalnischkies david@kalnischkies.de 2016-06-17T15:56:45Z urn:sha1:1d742e01470bba27715a8191c50adde4b39c2f19 As reported upstream in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556 the implementation of std::get_time is currently not as accepting as strptime is, especially in how hours should be formatted. Just reverting 9febc2b238e1e322dce1f94ecbed46d595893b52 would be possible, but then we would reopen the problems fixed by it, so instead I opted here for a rewrite of the parsing logic which makes this method a lot longer, but at least it provides the same benefits as the rewrite in std::get_time was intended to give us and decouples us from the fix of the issue in the standard library implementation of GCC. LP: 1593583 2016-06-10T08:49:34Z David Kalnischkies david@kalnischkies.de 2016-06-09T19:06:48Z urn:sha1:6f35be91c9e86e463bca7df6eadf05412c7b732c Seen first in #826783, but as this buglog also shows leaked uncompressed files as well we don't close it just yet. 2016-05-28T09:42:20Z David Kalnischkies david@kalnischkies.de 2016-05-28T09:03:35Z urn:sha1:9febc2b238e1e322dce1f94ecbed46d595893b52 HTTP/1.1 hardcodes GMT (RFC 7231 §7.1.1.1) and what is good enough for the internet must be good enough for us™ as we reuse the implementation internally to parse (most) dates we encounter in various places like the Release files with their Date and Valid-Until header fields. Implementing a fully timezone aware parser just feels too hard for no effective benefit as it would take 5+ years (= until LTS's are out of fashion) until a repository could use non-UTC dates and expect it to work. Not counting non-apt implementations which might or might not only want to encounter UTC here as well. As a bonus, this eliminates the use of an instance of setlocale in libapt. Closes: 819697 2016-05-27T12:08:44Z David Kalnischkies david@kalnischkies.de 2016-05-27T10:08:32Z urn:sha1:124e6916b7b02984803ff8217e8163947aae2882 libapt allows to configure compressors to be used by its system via configuration implemented in 03bef78461c6f443187b60799402624326843396, but that was never really documented and also only partly working, which also explains why the tests weren't using it… 2016-04-25T13:35:52Z David Kalnischkies david@kalnischkies.de 2016-03-12T14:49:54Z urn:sha1:82153438235144c485a8539b5c035e67bbef96e4 2016-03-19T08:48:44Z David Kalnischkies david@kalnischkies.de 2016-03-18T10:37:31Z urn:sha1:28b2efcb190edd97b802ac9055eaf417f141f724 On launchpad #1558484 a user reports that @ in the authentication tokens parsing of sources.list isn't working in an older (precise) version. It isn't the recommended way of specifying passwords and co (auth.conf is), but we can at least test for regressions (and in this case test at all… who was that "clever" boy disabling a test with exit……… oh, nevermind. Git-Dch: Ignore 2016-03-13T12:01:14Z Julian Andres Klode jak@debian.org 2016-03-13T11:21:09Z urn:sha1:51c04562559d0924aa52cc8c9b69901bc8a5c945 SHA1 is not reasonably secure anymore, so we should not consider it usable anymore. The test suite is adjusted to account for this. 2016-02-10T12:31:12Z Julian Andres Klode jak@debian.org 2016-02-10T12:29:19Z urn:sha1:5fafaf27a5f066dc15d96c03ef154fd1d59eb891 This tests the fix for #812994, #813000 Gbp-Dch: ignore 2016-01-31T22:24:59Z David Kalnischkies david@kalnischkies.de 2016-01-31T21:32:45Z urn:sha1:5025879e3fdd705bb0607ff8f51a680749c5972a APT has a different understanding than dpkg (#748936) what matches and what doesn't match an architecture specification as it isn't converting back (and forward) to Debian triplets. That has to eventually be solved some way or the other, but until that happens we change the matching in apt so that porters can continue their work on non-gnu libc-ports even if policy doesn't specify that yet (and dpkg just supporting it "by accident" via triplets). The initial patch was reformatted, fixed in terms of patterns containing "any-any", dealing with expanding an arch without libc to gnu while a pattern expands libc to any, the parsedepends test was fixed (the new if's were inserted one step too early) and another test just for the specifications added. Closes: #812212 Thanks: Bálint Réczey for initial patch