apt/apt-pkg/deb/debsystem.cc, branch 2.4.4Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.4.42021-06-10T17:25:17ZRestore dpkg::chroot-directory functionality2021-06-10T17:25:17ZDavid Kalnischkiesdavid@kalnischkies.de2021-06-10T16:06:14Zurn: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
dpkg: fix passing readonly /dev/null fd as stdout/stderr2021-01-22T15:41:12ZYoufu Zhangzhangyoufu@gmail.com2021-01-22T09:41:22Zurn: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
Add basic support for the Protected field2020-06-29T15:32:17ZJulian Andres Klodejulian.klode@canonical.com2020-06-29T15:31:06Zurn:sha1:ddd8fc3d28cd8e668868158049ced7fa3c8c71b8
This will be mapped to Important for the time being.
Silence clang warning -Wstring-plus-int2020-05-25T10:05:00ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-24T14:36:03Zurn: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
Show absolute time while waiting for lock instead of %, rework message2020-03-06T12:14:37ZJulian Andres Klodejulian.klode@canonical.com2020-03-06T12:10:04Zurn: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.
apt(8): Wait for frontend and cache lock2020-02-26T19:36:52ZJulian Andres Klodejulian.klode@canonical.com2020-02-26T19:31:03Zurn: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.
pkgsystem: Drop more virtual workaround shenanigans2020-02-26T13:30:03ZJulian Andres Klodejulian.klode@canonical.com2020-02-26T13:29:06Zurn:sha1:da7de99f8473ae0ac90c90fad3eee80f5f72889aUnlock dpkg locks in reverse locking order2019-05-21T12:53:13ZJulian Andres Klodejulian.klode@canonical.com2019-05-10T10:14:59Zurn:sha1:ab14e19c6171b1f5fb84ae14ebfccb3a3c1c186b
We need to unlock in the reverse order of locking in order
to get useful behavior.
LP: #1829860
Set PATH=/usr/sbin:/usr/bin:/sbin:/bin when running dpkg2018-12-10T16:31:24ZJulian Andres Klodejulian.klode@canonical.com2018-12-10T15:52:59Zurn: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]
Set DPKG_FRONTEND_LOCKED as needed when doing selection changes2018-08-08T13:20:44ZJulian Andres Klodejulian.klode@canonical.com2018-08-08T13:19:20Zurn: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