Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4_beta2 2016-11-11T22:40:39Z 2016-11-11T22:40:39Z James Clarke jrtc27@jrtc27.com 2016-11-11T16:33:25Z urn:sha1:a658ffbf1911ae9b9838615d0a60f4613e642553 This also changes Acquire-By-Hash to be "yes" rather than "true", so it is consistent with dak's output. Closes: #272557 2016-08-17T05:55:46Z David Kalnischkies david@kalnischkies.de 2016-08-16T05:47:44Z urn:sha1:77e274f5ad23d79294f28ecc9868fc6f534214a4 In af81ab9030229b4ce6cbe28f0f0831d4896fda01 by-hash got implemented as a special compression type for our usual index files like Packages. Missing in this scheme was the special .diff/Index index file containing the info about individual patches for this index file. Deriving from the index file class directly we inherent the compression handling infrastructure and in this way also by-hash nearly for free. Closes: #824926 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-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-05-28T10:46:37Z David Kalnischkies david@kalnischkies.de 2016-05-28T10:41:12Z urn:sha1:e0b01a85bd8395449a88e1806ea4a4e3acdbac33 Using C++ here avoids calling setlocale here which never really was that ideal, but needed to avoid locale specific weekday/month names. 2016-05-27T17:14:38Z David Kalnischkies david@kalnischkies.de 2016-05-27T16:10:39Z urn:sha1:b58e2c7c56b1416a343e81f9f80cb1f02c128e25 Setting the C++ locale via std::locale::global(std::locale("")); which would otherwise default to the default C locale (aka: unaffected by setlocale) effects the formatting of numeric types in IO streams, which for output for humans is perfectly sensible, but breaks our many text interfaces used and parsed by us and others without expecting the numbers to be formatted. Closes: #825396 2016-05-01T09:38:44Z Julian Andres Klode jak@debian.org 2016-05-01T09:38:44Z urn:sha1:79fe74283ca8c941806085a3ae1bacfac2287d1c 2016-04-25T13:35:52Z David Kalnischkies david@kalnischkies.de 2016-04-05T18:37:57Z urn:sha1:6d9b79dd961242702f0079e3dab2dd1c62bbc61e 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-02T22:15:15Z urn:sha1:83758aed35c3eec66008b2ec01957c8e1cb129b5 Having a hardcoded list of compression types here doesn't really provide us with anything beside added complexity each time someone adds a new compression type. That we don't need to be that specific is evident by Contents and Translation-* matchers which are a lot more generic and didn't generate problems anyhow. 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