Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.3 2016-12-31T01:29:20Z 2016-12-31T01:29:20Z David Kalnischkies david@kalnischkies.de 2016-12-29T10:20:18Z urn:sha1:0161280405fe5aa256dc9df6a56106dd3a1a6f38 The crude way of preparing a message to be a multiline value failed at generation valid deb822 in case the error message ended with a new line like the resolving errors from apt do. apt itself can parse these, but other tools like grep-dctrl choke on it, so be nice and print valid. Reported-By: Johannes 'josch' Schauer on IRC 2016-09-07T08:21:01Z David Kalnischkies david@kalnischkies.de 2016-09-07T08:21:01Z urn:sha1:12b201da7c1d5e2beceae796151e4ebedc5bae97 Commit b60c8a89c281f2bb945d426d2215cbf8f5760738 improved the situation, but due to inconsistency mostly for planners, not for solvers. As the idea of hiding errors if we show another error is a bit scary (as the extern error might be a followup of our intern error, rather than the reason for our intern error as it is at the moment) we don't discard the errors, but if we got an extern error we show them directly removing them from the error list at the end of the run – that list will contain the extern error which hopefully gives us the best of both worlds. The problem itself is the same as before: The externals exiting before apt is done talking to them. Reported-By: Johannes 'josch' Schauer on IRC 2016-07-29T20:09:06Z David Kalnischkies david@kalnischkies.de 2016-07-29T19:51:43Z urn:sha1:b60c8a89c281f2bb945d426d2215cbf8f5760738 If a solver/planner exits before apt is done writing we will generate write errors. Solvers like 'dump' can be pretty quick in failing but produce a valid EDSP error report apt should read, parse and display instead of just discarding even through we had write errors. 2016-07-27T20:42:24Z David Kalnischkies david@kalnischkies.de 2016-07-27T20:21:58Z urn:sha1:196d590a99e309764e07c9dc23ea98897eebf53a Reported-By: cppcheck Gbp-Dch: Ignore 2016-07-27T15:58:51Z David Kalnischkies david@kalnischkies.de 2016-07-27T15:58:51Z urn:sha1:4a97f759cd98f3b2518726b348d1b981e8a8e1d6 Simulations are frequently run by unprivileged users which naturally don't have the permissions to write to the default location for the eipp file. Either way is bad as running in simulation mode doesn't mean we don't want to run the logging (as EIPP runs the same regardless of simulation or 'real' run), but showing the warnings is relatively pointless in the default setup, so, in case we would produce errors and perform a simulation we will discard the warnings and carry on. Running apt with an external planner wouldn't have generated these messages btw. Closes: 832614 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T13:44:53Z urn:sha1:1b50bba6571661d1ddc1db808bd618bd0de3cae4 If other logs can't be written this is a warning to, so for consistency sake translate the errors to warnings. 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T13:40:23Z urn:sha1:5958c7497eea24d55ff305764f058ba1ae836200 Unlikely to happen in practice and I wonder more how I could miss these in earlier reviews, but okay, lets fix it for consistency now. 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:17:41Z David Kalnischkies david@kalnischkies.de 2016-06-29T07:16:53Z urn:sha1:8e99b22c31eb47d0422e9a69e83dc99bb315ded8 Julian noticed on IRC that I fall victim to a lovely false friend by calling referring to a 'planer' all the time even through these are machines to e.g. remove splinters from woodwork ("make stuff plane"). The term I meant is written in german in this way (= with a single n) but in english there are two, aka: 'planner'. As that is unreleased code switching all instances without any transitional provisions. Also the reason why its skipped in changelog. Thanks: Julian Andres Klode Gbp-Dch: Ignore 2016-06-27T09:57:13Z David Kalnischkies david@kalnischkies.de 2016-06-26T11:20:19Z urn:sha1:b4f91d4d150a0d9bcc77563abbc03d28da2ff4e3 In 385d9f2f23057bc5808b5e013e77ba16d1c94da4 I implemented the storage of scenario files based on enabling this by default for EIPP, but I implemented it first optionally for EDSP to have it independent. The reasons mentioned in the earlier commit (debugging and bugreports) obviously apply here, especially as EIPP solutions aren't user approved, nearly impossible to verify before starting the execution and at the time of error the scenario has changed already, so that reproducing the issue becomes hard(er).