Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3.1 2016-07-06T13:53:59Z 2016-07-06T13:53:59Z David Kalnischkies david@kalnischkies.de 2016-07-06T13:10:52Z urn:sha1:b50dfa6b2dd2d459e0c2746ac9367982b96ffac0 If we don't give a specific error to report up it is likely that all error currently in the error stack are equally important, so reporting just one could turn out to be confusing e.g. if name resolution failed in a SRV record list. 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-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-01-26T14:32:15Z David Kalnischkies david@kalnischkies.de 2016-01-25T21:13:52Z urn:sha1:2651f1c071927b7fc440ec7a638ecad7ccf04a2e Reported-By: cppcheck Git-Dch: Ignore 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-17T07:29:00Z urn:sha1:6c55f07a5fa3612a5d59c61a17da5fe640eadc8b Doing this disables the implicit copy assignment operator (among others) which would cause hovac if used on the classes as it would just copy the pointer, not the data the d-pointer points to. For most of the classes we don't need a copy assignment operator anyway and in many classes it was broken before as many contain a pointer of some sort. Only for our Cacheset Container interfaces we define an explicit copy assignment operator which could later be implemented to copy the data from one d-pointer to the other if we need it. Git-Dch: Ignore 2015-06-16T14:22:46Z David Kalnischkies david@kalnischkies.de 2015-06-16T14:22:46Z urn:sha1:c8a4ce6cbed57ae108dc955d4a850f9b129a0693 To have a chance to keep the ABI for a while we need all three to team up. One of them missing and we might loose, so ensuring that they are available is a very tedious but needed task once in a while. Git-Dch: Ignore 2015-06-09T10:57:36Z David Kalnischkies david@kalnischkies.de 2015-06-06T17:16:45Z urn:sha1:3679515479136179e0d95325a6559fcc6d0af7f8 rred is responsible for unpacking and reading the patch files in one go, but we currently only have hashes for the uncompressed patch files, so the handler read the entire patch file before dispatching it to the worker which would read it again – both with an implicit uncompress. Worse, while the workers operate in parallel the handler is the central orchestration unit, so having it busy with work means the workers do (potentially) nothing. This means rred is working with 'untrusted' data, which is bad. Yet, having the unpack in the handler meant that the untrusted uncompress was done as root which isn't better either. Now, we have it at least contained in a binary which we can harden a bit better. In the long run, we want hashes for the compressed patch files through to be safe. 2015-06-09T10:57:35Z David Kalnischkies david@kalnischkies.de 2015-06-06T10:28:00Z urn:sha1:448c38bdcd72b52f11ec5f326f822cf57653f81c Having every item having its own code to verify the file(s) it handles is an errorprune process and easy to break, especially if items move through various stages (download, uncompress, patching, …). With a giant rework we centralize (most of) the verification to have a better enforcement rate and (hopefully) less chance for bugs, but it breaks the ABI bigtime in exchange – and as we break it anyway, it is broken even harder. It shouldn't effect most frontends as they don't deal with the acquire system at all or implement their own items, but some do and will need to be patched (might be an opportunity to use apt on-board material). The theory is simple: Items implement methods to decide if hashes need to be checked (in this stage) and to return the expected hashes for this item (in this stage). The verification itself is done in worker message passing which has the benefit that a hashsum error is now a proper error for the acquire system rather than a Done() which is later revised to a Failed(). 2014-10-13T09:29:39Z David Kalnischkies david@kalnischkies.de 2014-10-13T06:05:57Z urn:sha1:862bafea48af2ceaf96345db237b461307a021f6 Reimplementing an inline method is opening a can of worms we don't want to open if we ever want to us a d-pointer in those classes, so we do the only thing which can save us from hell: move the destructors into the cc sources and we are good. Technically not an ABI break as the methods inline or not do the same (nothing), so a program compiled against the old version still works with the new version (beside that this version is still in experimental, so nothing really has been build against this library anyway). Git-Dch: Ignore 2014-10-08T06:37:01Z Michael Vogt mvo@ubuntu.com 2014-10-08T06:37:01Z urn:sha1:0c158e03ceb509a08d3d4ded79c3151237f669dd