Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.1 2024-02-20T12:49:04Z 2024-02-20T12:49:04Z Julian Andres Klode julian.klode@canonical.com 2024-02-20T12:43:08Z urn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49 This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces. 2022-09-02T14:55:45Z David Kalnischkies david@kalnischkies.de 2022-09-01T13:14:52Z urn:sha1:f52c1ce9b31befb71016a20759b96b4946034fcb Not having a dpkg/status file used to be a hard error which from a boostrap perspective is suspect as in the beginning, there is no status so you would need to touch it into existence. We make a difference between factual non-existence and inaccessibility to catch mistakes in which the file is not readable for some reason, the testcase test-bug-254770-segfault-if-cache-not-buildable is an example of this. Note that apt has already figured out at this point that this is a Debian-like system which should have a dpkg/status file. This change does not effect the auto-detection and is not supposed to. 2022-09-02T14:55:45Z David Kalnischkies david@kalnischkies.de 2022-08-31T14:26:48Z urn:sha1:49f9cfba5567cd034bf729a63b3f6e9badd9bc35 Failing to properly create the status file class should be reported back to the caller so it can proceed accordingly instead of proceeding into more failures. This gives us: E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: The package lists or status file could not be parsed or opened. instead of: E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. and valgrind reporting actions on uninitialised values. 2021-06-10T17:25:17Z David Kalnischkies david@kalnischkies.de 2021-06-10T16:06:14Z urn:sha1:8083d4019844f764058efa2a950ed16975178bff If we call dpkg inside a chroot we have to ensure that the temporary directory we construct to call dpkg --recursive is inside the chroot and that we strip the path to the chroot from the directory name we pass to dpkg. Note that the added test succeeds before and (hopefully) after as we can't really chroot here or fiddle with the needed settings as we are already setting up apt to work with a quasi-chroot. The test perhaps helps in ensuring we don't break it too much in the future though. (Broken five years (and one day) ago this seems to have an immense user base at the moment, but it might in the future via mmdebstrap) References: f495992428a396e0f98886c9a761a804aa161c68 Reported-By: Johannes Schauer Marin Rodrigues on IRC Tested-By: Johannes Schauer Marin Rodrigues 2021-01-22T15:41:12Z Youfu Zhang zhangyoufu@gmail.com 2021-01-22T09:41:22Z urn:sha1:acbe227d50178657d98a609221b1caa5b128d7bb The read-only /dev/null was duplicated to stdout and stderr, causing writes to those descriptors to fail: [pid 260] openat(AT_FDCWD, "/dev/null", O_RDONLY) = 7 [pid 260] dup2(7, 0) = 0 [pid 260] close(5) = 0 [pid 260] dup2(6, 1) = 1 [pid 260] dup2(7, 2) = 2 [pid 260] write(2, "Chrooting into ", 15) = -1 EBADF (Bad file descriptor) [pid 260] chroot("/chroot/") = 0 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