Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre2 2016-07-06T00:25:51Z 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-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T13:05:56Z urn:sha1:cc9745a0d81a3e1aa5ef6f99f7ad638d26bdb950 If libapt has builtin support for a compression type it will create a dummy compressor struct with the Binary set to 'false' as it will catch these before using the generic pipe implementation which uses the Binary. The catching happens based on configured Names through, so you can actually force apt to use the external binaries even if it would usually use the builtin support. That logic fails through if you don't happen to have these external binaries installed as it will fallback to calling 'false', which will end in confusing 'Write error's. So, this is again something you only encounter in constructed testing. 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-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-29T10:23:02Z David Kalnischkies david@kalnischkies.de 2016-06-29T09:00:04Z urn:sha1:cfc6566d5097ef5518e12f5c1e5f15a8f5b182cf This reverts commit 2b8221d66a8284042fc53c7bbb14bb9750e9137f. Avoiding the use of GCC >= 5 stuff lets use go back to 4.8 simplifying the travis setup again as well as reducing the backport requirements in general. This is possible because the std::get_time use requiring GCC >= 5 in 9febc2b238e1e322dce1f94ecbed46d595893b52 was replaced by handrolling it in 1d742e01470bba27715a8191c50adde4b39c2f19, so the remaining uses are just small conviniences we can do without. Gbp-Dch: Ignore 2016-06-25T07:02:07Z David Kalnischkies david@kalnischkies.de 2016-06-25T07:02:07Z urn:sha1:3bdff17c894d0c3d0f813d358fc45d7a263f3552 Rewritten in 9febc2b238e1e322dce1f94ecbed46d595893b52 for c++ locales usage and rewritten again in 1d742e01470bba27715a8191c50adde4b39c2f19 to avoid a currently present stdlibc++6 bug in the std::get_time implementation. The later implementation uses still stringstreams for parsing, but forgot to explicitly reset the locale to something sane (for parsing english dates that is), so date and especially the parsing of a number is depending on the locale. Turns out, the French (among others) format their numbers with space as thousand separator so for some reason the stdlibc++6 thinks its a good idea to interpret the entire datetime string as a single number instead of realizing that in "25 Jun …" the later parts can't reasonably be part of that number even through there are spaces there… Workaround is hence: LC_NUMERIC=C.UTF-8 Closes: 828011 2016-06-20T11:49:31Z David Kalnischkies david@kalnischkies.de 2016-06-20T11:49:31Z urn:sha1:9515ed7bcdb32c7985ca83d309beda7155d02136 There is a subtile difference between an empty setting and "DIRECT" in the configuration as the later overrides the generic settings while the earlier does not. Also, non-zero exitcodes should really be reported as an error rather than silently discarded. 2016-06-20T11:22:22Z David Kalnischkies david@kalnischkies.de 2016-06-20T09:23:09Z urn:sha1:cad1877559f3e1703c3fea4d081978e1b4bb4a0e Regression introduced in 8f858d560e3b7b475c623c4e242d1edce246025a. Commands are probably better of always having output through as the fall through to the generic proxy settings is likely not intended. As documenting and implementing this more consistently is kind of a regression through, it is split off into the next commit. Closes: 827713 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-14T12:32:14Z David Kalnischkies david@kalnischkies.de 2016-06-14T12:32:14Z urn:sha1:90f2a7a0f66cfc259883490a5fcf40f7d0696cfe We usually use absolute paths to specific the location of dpkg, apt-key and the like, but there is nothing wrong with using just the command name and instead let exec(3) make the lookup in PATH. We had a wild mixture before, so opting for the more accepting option out of the two seems about right especially as it makes no difference in the default case as apt uses absolute paths.