Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_exp2 2016-06-10T08:49:34Z 2016-06-10T08:49:34Z David Kalnischkies david@kalnischkies.de 2016-06-09T19:06:48Z urn:sha1:6f35be91c9e86e463bca7df6eadf05412c7b732c Seen first in #826783, but as this buglog also shows leaked uncompressed files as well we don't close it just yet. 2016-06-10T08:48:25Z David Kalnischkies david@kalnischkies.de 2016-06-09T18:41:58Z urn:sha1:bdc42211700ef0f6f40e4ef3f362e52d684d70fb This effects only compressors configured on the fly (rather then the inbuilt ones as they use a library). 2016-06-08T15:31:45Z David Kalnischkies david@kalnischkies.de 2016-06-08T15:31:45Z urn:sha1:b4450f1dd6bca537e60406b2383ab154a3e1485f We end our operation by calling "dpkg --configure -a", so instead of running a (big) configure run with all packages mentioned explicitly before this, we simply skip them and let them be handled by this call implicitly. There isn't really an observeable gain to be had here from a speed point, but it helps in avoiding an (uncommon) problem of having a too long commandline passed to dpkg, which we would split up (probably incorrectly). 2016-06-08T15:27:19Z David Kalnischkies david@kalnischkies.de 2016-06-08T11:44:29Z urn:sha1:007d8b488787f4c33ced5937f22f99f1b759088a Most (if not all) solvers should be able to run perfectly fine without root privileges as they get the entire state they are supposed to work on via stdin and do not perform any action directly, but just pass suggestions on via stdout. The new default is to run them all as _apt hence, but each solver can configure another user if it chooses/must. The security benefits are minimal at best, but it helps preventing silly mistakes (see 35f3ed061f10a25a3fb28bc988fddbb976344c4d) and that is always good. Note that our 'apt' and 'dump' solver already dropped privileges if they had them. 2016-06-08T11:07:21Z David Kalnischkies david@kalnischkies.de 2016-06-07T15:01:33Z urn:sha1:385d9f2f23057bc5808b5e013e77ba16d1c94da4 For bugreports and co it could be handy to have the scenario and all the settings used in it around later for inspection for EDSP like protocols. EDSP might not be the most interesting as the user can still interrupt the process before the solution is applied and users tend to have an opinion on the "rightness" of a solution, so it is disabled by default. 2016-06-04T16:45:01Z David Kalnischkies david@kalnischkies.de 2016-06-04T16:45:01Z urn:sha1:307d9eb2d13ee59191b86ffec2f36ba3fffc5c20 Currently an EDSP solver gets send basically all versions which means the absolute count is the same, but that might not be true forever (and with the skipping of rc-only versions it kinda is already) and even if it were true, segfaulting on bad input seems wrong. 2016-06-02T11:35:28Z David Kalnischkies david@kalnischkies.de 2016-06-02T09:12:39Z urn:sha1:0cfec3ab589c6309bf284438d2148c7742cdaf10 First seen on hurd, but easily reproducible on all systems by removing the 'execution' bit from the current working directory and watching some tests (mostly the no-output expecting tests) fail due to find printing: "find: Failed to restore initial working directory: …" Samuel Thibault says in the bugreport: | To do its work, find first records the $PWD, then goes to | /etc/apt/trusted.gpg.d/ to find the files, and then goes back to $PWD. | | On Linux, getting $PWD from the 700 directory happens to work by luck | (POSIX says that getcwd can return [EACCES]: Search permission was denied | for the current directory, or read or search permission was denied for a | directory above the current directory in the file hierarchy). And going | back to $PWD fails, and thus find returns 1, but at least it emitted its | output. | | On Hurd, getting $PWD from the 700 directory fails, and find thus aborts | immediately, without emitting any output, and thus no keyring is found. | | So, to summarize, the issue is that since apt-get update runs find as a | non-root user, running it from a 700 directory breaks find. Solved as suggested by changing to '/' before running find, with some paranoia extra care taking to ensure the paths we give to find are really absolute paths first (they really should, but TMPDIR=. or a similar Dir::Etc::trustedparts setting could exist somewhere in the wild). The commit takes also the opportunity to make these lines slightly less error ignoring and the two find calls using (mostly) the same parameters. Thanks: Samuel Thibault for 'finding' the culprit! Closes: 826043 2016-06-02T11:35:28Z David Kalnischkies david@kalnischkies.de 2016-06-02T10:44:58Z urn:sha1:62600666d21aacea63cece3b4ec64f0ffb40168b In 8b79c94af7f7cf2e5e5342294bc6e5a908cacabf changing to usage of C++ way of setting the locale causes us to be terminated in case of usage of an ungenerated locale as LC_ALL (or similar) – but we don't want to fail here, we just want to carry on as before with setlocale which we call in that case just for good measure. 2016-05-28T09:42:20Z David Kalnischkies david@kalnischkies.de 2016-05-28T09:03:35Z urn: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 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