apt/test/libapt, branch 1.3_pre3Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_pre32016-07-19T16:05:13Zensure Cnf::FindFile doesn't return files below /dev/null2016-07-19T16:05:13ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-19T16:05:13Zurn:sha1:bbd8308cc01941e51e2cbcf88168a5560abe6042
Very unlikely, but if the parent is /dev/null, the child empty and the
grandchild a value we returned /dev/null/value which doesn't exist, so
hardly a problem, but for best operability we should be consistent in
our work and return /dev/null always.
don't do atomic overrides with failed files2016-06-29T12:46:34ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-29T12:46:34Zurn: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
avoid std::get_time usage to sidestep libstdc++6 bug2016-06-17T16:09:20ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-17T15:56:45Zurn: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
don't leak an FD in lz4 (de)compression2016-06-10T08:49:34ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-09T19:06:48Zurn:sha1:6f35be91c9e86e463bca7df6eadf05412c7b732c
Seen first in #826783, but as this buglog also shows leaked uncompressed
files as well we don't close it just yet.
accept only the expected UTC timezones in date parsing2016-05-28T09:42:20ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-28T09:03:35Zurn: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
fix and document on the fly compressor config2016-05-27T12:08:44ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-27T10:08:32Zurn: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…
properly format multiline error messages2016-04-25T13:35:52ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-12T14:49:54Zurn:sha1:82153438235144c485a8539b5c035e67bbef96e4tests: reenable basic auth test and add @ in username2016-03-19T08:48:44ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-18T10:37:31Zurn: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
Do not consider SHA1 usable2016-03-13T12:01:14ZJulian Andres Klodejak@debian.org2016-03-13T11:21:09Zurn: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.
test that seeking to a position earlier in the file works2016-02-10T12:31:12ZJulian Andres Klodejak@debian.org2016-02-10T12:29:19Zurn:sha1:5fafaf27a5f066dc15d96c03ef154fd1d59eb891
This tests the fix for #812994, #813000
Gbp-Dch: ignore