apt/test/libapt, branch 1.3_rc1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_rc12016-08-10T21:20:15Zallow user@host (aka: no password) in URI parsing2016-08-10T21:20:15ZDavid Kalnischkiesdavid@kalnischkies.de2016-08-01T19:45:29Zurn:sha1:a1f3ac8aba0675321dd46d074af8abcbb10c19fd
If the URI had no password the username was ignored
Get rid of the old buildsystem2016-08-10T14:17:19ZJulian Andres Klodejak@debian.org2016-08-09T15:40:01Zurn:sha1:c85c4bed0a4b32ee2dcbd86ea819e39f3d8beb84
Bye, bye, old friend.
CMake: Add unit tests2016-08-10T14:11:43ZJulian Andres Klodejak@debian.org2016-08-07T16:22:14Zurn:sha1:06c2b40b9b9094f4f6391bd1d17cfc3725313070
Add support for our GTest based unit tests. By default, CMake will
look in /usr/src/gtest for the external GTest project, but this can
be overriden by defining GTEST_ROOT when invoking cmake.
Gbp-Dch: ignore
ensure 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:82153438235144c485a8539b5c035e67bbef96e4