Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.9.2 2019-08-05T15:09:18Z 2019-08-05T15:09:18Z Julian Andres Klode jak@debian.org 2019-08-05T15:09:18Z urn:sha1:44f3051c56bb7fbe301625dd368c6a2fc36e64d0 Improve locking messaging - pid and name, "do not remove lock file" See merge request apt-team/apt!68 2019-07-10T14:15:30Z David Kalnischkies david@kalnischkies.de 2019-07-10T14:15:30Z urn:sha1:5cfbc5727dba2f4662d24cf4deb7cab7cdd57c14 Also in old changelogs, but nothing really user visible like error messages or alike so barely noteworthy. Reported-By: codespell Gbp-Dch: Ignore 2019-07-08T13:51:17Z David Kalnischkies david@kalnischkies.de 2019-07-08T13:48:59Z urn:sha1:2b734a7ec429825c7007c1093883229e069d36c7 Reported-By: cppcheck 2019-07-08T11:18:31Z David Kalnischkies david@kalnischkies.de 2019-06-10T12:30:32Z urn:sha1:cbe90ee516d7f747f981e423f164f99eb767240b The error messages say only which package it was trying to provide, but not which package & version tried it which can be misleading as to which package (version) is the offender. References: #930256 2019-07-08T11:18:31Z David Kalnischkies david@kalnischkies.de 2019-04-27T14:13:02Z urn:sha1:79b1a82983e737e74359bc306d9edb357c5bdd46 Work like applying patches via rred can be performed by many concurrent rred processes, but we can't just spawn new ones forever: We limit us to the number of CPUs which can drive them and reuse existing ones if they have nothing to do at the moment. The problem arises if we have reached the limit of queues and all of them are busy which is more likely to happen on "slow" machines with few CPUs. In this case we opted for random distribution, but that can result in many big files (e.g. Contents) being added to one queue while the others get none or only small files. Ideally we would ask the methods how much they still have to do, but they only know that for the current item, not for all items in the queue, so we use the filesize of the expected result. 2019-06-21T21:14:46Z Julian Andres Klode julian.klode@canonical.com 2019-06-21T20:45:13Z urn:sha1:cde8399310e56faaa6928411392184bc403eff66 We want to tell users which process is holding the lock so they can easily understand what's going on, and we want to advise users not to remove the lock file, because ugh, that's bad. Re-initalize the flock structure, in case it got mangled by previous fcntl call. 2019-06-17T16:28:52Z Julian Andres Klode julian.klode@canonical.com 2019-06-17T16:28:52Z urn:sha1:97553e635d2265ec4aad96b00b1fd72d98437f15 We are converting to std::string anyway by passing to istringstream, and this removes the need for .c_str() in callers. 2019-06-14T13:52:41Z Julian Andres Klode julian.klode@canonical.com 2019-06-14T13:50:39Z urn:sha1:d88af368d2a45bf9490fc629edbaa111da8a26cf Gbp-Dch: ignore 2019-06-14T13:45:28Z Julian Andres Klode julian.klode@canonical.com 2019-06-14T13:45:28Z urn:sha1:6b6e942da072ef5b0f5d49b16c8bf2374f8a5071 These functions do not produce any useful results anymore, so it's pointless to keep them around. 2019-06-14T12:28:35Z Julian Andres Klode julian.klode@canonical.com 2019-06-14T12:28:35Z urn:sha1:a15f2d0deeb90ce79903823e9317d4fa3e47acff This mostly turns them private and then overrides the public version with the switch, as recommended.