Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.11 2020-06-29T15:32:17Z 2020-06-29T15:32:17Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T15:31:06Z urn:sha1:ddd8fc3d28cd8e668868158049ced7fa3c8c71b8 This will be mapped to Important for the time being. 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-24T14:36:03Z urn:sha1:c3bfdbfa3ae868515a67142d2df6200a3cb34d35 ../apt-pkg/init.cc:137:39: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] Cnf.CndSet("Dir::State", STATE_DIR + 1); ../apt-pkg/init.cc:137:39: note: use array indexing to silence this warning We have a few instances of that & it should be reasonably clear that we are not actually trying to append here, but ignoring or silencing this warning with an override is far more costly than just using what clang suggests here. Reported-By: clang Gbp-Dch: Ignore 2020-03-06T12:14:37Z Julian Andres Klode julian.klode@canonical.com 2020-03-06T12:10:04Z urn:sha1:1b81f6bd13bb31e59da3f53cfdc7caab43abf887 Showing a percentage for a timeout is pretty non-standard. Rework the progress class so it can show an absolute progress (currently hardcoded to use seconds as a unit). If there is a timeout (aka if it's not the maximum long long unsigned -1llu), then show the timeout, otherwise just count up seconds, e.g. Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1/120s or Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1s Also improve the error message to use "Waiting for cache lock: %s" instead of "... (%s)", as having multiple sentences inside parenthesis is super weird, as is having two closing parens. We pass the information via _config, as that's reasonably easy and avoids ABI hackage. It also provides an interesting debugging tool for other kinds of progress. 2020-02-26T19:36:52Z Julian Andres Klode julian.klode@canonical.com 2020-02-26T19:31:03Z urn:sha1:93e1565796b61eb44bec39f50e09a34cbe090178 This is a rework of !6 with additional stuff for the frontend lock, so we can lock the frontend lock and then keep looping over dpkg lock. 2020-02-26T13:30:03Z Julian Andres Klode julian.klode@canonical.com 2020-02-26T13:29:06Z urn:sha1:da7de99f8473ae0ac90c90fad3eee80f5f72889a 2019-05-21T12:53:13Z Julian Andres Klode julian.klode@canonical.com 2019-05-10T10:14:59Z urn:sha1:ab14e19c6171b1f5fb84ae14ebfccb3a3c1c186b We need to unlock in the reverse order of locking in order to get useful behavior. LP: #1829860 2018-12-10T16:31:24Z Julian Andres Klode julian.klode@canonical.com 2018-12-10T15:52:59Z urn:sha1:806e94dcd8dbdf7bf1909657fd4331cfe17b4ab0 This avoids a lot of problems from local installations of scripting languages and other stuff in /usr/local for which maintainer scripts are not prepared. [v3: Inherit PATH during tests, check overrides work] [v2: Add testing] 2018-08-08T13:20:44Z Julian Andres Klode julian.klode@canonical.com 2018-08-08T13:19:20Z urn:sha1:55489885b51b02b7f74e601a393ecaefd1f71f9c We forgot to set the variable for the selection changes. Let's set it for that and some other dpkg calls. Regression-Of: c2c8b4787b0882234ba2772ec7513afbf97b563a 2018-08-07T13:07:52Z Julian Andres Klode jak@debian.org 2017-01-29T12:05:18Z urn:sha1:c2c8b4787b0882234ba2772ec7513afbf97b563a The dpkg frontend lock is a lock dpkg tries to acquire except if the frontend already acquires it. This fixes a race condition in the install command where the dpkg lock is not held for a short period of time between different dpkg invocations. For this reason we also define an environment variable DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows not to try to acquire the frontend lock because it's held by a parent process. We can set DPKG_FRONTEND_LOCKED only if the frontend lock really is held; that is, if our lock count is greater than 0 - otherwise an apt client not using the LockInner family of functions would run dpkg without the frontend lock set, but with DPKG_FRONTEND_LOCKED set. Such a process has a weaker guarantee: Because dpkg would not lock the frontend lock either, the process is prone to the existing races, and, more importantly, so is a new style process. Closes: #869546 [fixups: fix error messages, add public IsLocked() method, and make {Un,}LockInner return an error on !debSystem] 2018-06-13T21:36:08Z Julian Andres Klode julian.klode@canonical.com 2018-06-13T16:45:12Z urn:sha1:79f012bd09ae99d4c9d63dc0ac960376b5338b32 debSystem uses a reference counted lock, so you can acquire it multiple times in your applications, possibly nested. Nesting locks causes a fd leak, though, as we only increment the lock count when we already have locked twice, rather than once, and hence when we call lock the second time, instead of increasing the lock count, we open another lock fd. This fixes the code to check if we have locked at all (> 0). There is no practical problem here aside from the fd leak, as closing the new fd releases the lock on the old one due to the weird semantics of fcntl locks.