Bug#1030149: dpkg: Fix dpkg handling of read-only filesystems/directories when they are --path-exclude'd
Package: dpkg
Version: 1.21.19
Tags: patch
Hello,
While working on a rather specific project in Ubuntu, we encountered
an issue with dpkg when trying to handle read-only directories. As we
had a read-only filesystem mounted on the system, we decided to use
dpkg's --path-exclude to willingly ignore directories on that
filesystem, as it is supported. Sadly, we saw that dpkg was still
erroring out while trying to "unable to clean up mess surrounding
(...)". After diving into the code, my colleagues noticed that the
code for checking for interrupted transactions performs a rename()
function call, but only expects ENOENT and ENOTDIR as 'expected'
errors. In case of a read-only directory the errno is EROFS.
One way would be to add EROFS to the set of expected errors in this
case, but Julian Klode made a point that we might, in some cases,
error out on a read-only filesystem indeed. Instead he proposed to
simply do a check for the .dpkg-tmp file before trying to perform the
rename. And this seems to work as expected.
Change is relatively low-risk. We will be pushing this to our Ubuntu
packages, but also wanted to make sure it ends up upstream! Can you
take a look at the patch and merge it in if all checks out?
Thank you!
Best regardsm
--
Łukasz 'sil2100' Zemczak
Foundations Team
Tools Squad Interim Engineering Manager
lukasz.zemc...@canonical.com
www.canonical.com
diff -Nru dpkg-1.21.19/src/main/archives.c dpkg-1.21.19/src/main/archives.c
--- dpkg-1.21.19/src/main/archives.c 2023-01-02 02:42:41.0 +0100
+++ dpkg-1.21.19/src/main/archives.c 2023-01-24 23:39:50.0 +0100
@@ -764,7 +764,7 @@
* However, it's possible that we were in the middle of some other
* backup/restore operation and were rudely interrupted.
* So, we see if we have .dpkg-tmp, and if so we restore it. */
-if (rename(fnametmpvb.buf,fnamevb.buf)) {
+if (access(fnametmpvb.buf, F_OK) || rename(fnametmpvb.buf,fnamevb.buf)) {
if (errno != ENOENT && errno != ENOTDIR)
ohshite(_("unable to clean up mess surrounding '%.255s' before "
"installing another version"), ti->name);
Bug#810584: needrestart: add an as-installed DEP-8 test suite
Tags: patch
Hello!
In Ubuntu we have created a very very simple sanity testing
autopkgtest (in version 3.5-2ubuntu2) for needrestart, checking for
very basic functionality as we wanted to have at least a quick smoke
test to identify any obvious breakages. It creates a dummy service
file, causes an artificial refresh of a dependent library, runs
needrestart in batch mode, checks if it succeeds, checks if the dummy
service is marked for restart and - if possible - checks if the kernel
checks are performed.
Forwarding it here in case it's of any use! And I'd love to get rid of
the delta in Ubuntu - either by getting this accepted, or having
someone prepare something much better!
Thank you!
On Sun, 10 Jan 2016 12:51:58 +0800 Paul Wise wrote:
> Package: needrestart
> Severity: wishlist
>
> It would be nice for needrestart to have a test suite that could verify
> that it is working. At the moment it appears to produce different
> results to checkrestart so I'm worried it isn't working, but I don't
> have time to write a proper bug report about this. A DEP-8 test would
> mean that users don't have to file bugs as the CI system would
> automatically and continuously test the package.
>
> http://dep.debian.net/deps/dep8/
> https://ci.debian.net/
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>
diff -Nru needrestart-3.5/debian/tests/control needrestart-3.5/debian/tests/control
--- needrestart-3.5/debian/tests/control 1970-01-01 01:00:00.0 +0100
+++ needrestart-3.5/debian/tests/control 2021-03-05 18:01:10.0 +0100
@@ -0,0 +1,3 @@
+Tests: sanity-test.sh
+Restrictions: needs-root
+Depends: needrestart, dpkg-dev
diff -Nru needrestart-3.5/debian/tests/sanity-test.sh needrestart-3.5/debian/tests/sanity-test.sh
--- needrestart-3.5/debian/tests/sanity-test.sh 1970-01-01 01:00:00.0 +0100
+++ needrestart-3.5/debian/tests/sanity-test.sh 2021-03-23 12:47:33.0 +0100
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+set -e
+
+# Create a dummy service file and emulate library change in the background
+systemd-run -u dummy-background sleep infinity 2>/dev/null
+ARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH 2>/dev/null)
+LIBC=$(realpath /lib/$ARCH/libc.so.6)
+cp "$LIBC" "${LIBC}.new"
+mv -f "${LIBC}.new" "$LIBC"
+
+OUTPUT=$(needrestart -b)
+
+echo "Check if the mandatory version number is printed"
+echo "$OUTPUT" | grep -q "^NEEDRESTART-VER:"
+
+# Kernel checks are disabled when running in a container
+if ! /usr/bin/systemd-detect-virt --container --quiet; then
+echo "Check if the correct kernel was detected"
+echo "$OUTPUT" | grep -q "^NEEDRESTART-KCUR: $(uname -r)$"
+
+echo "Check if the kernel status value is present as well"
+echo "$OUTPUT" | grep -q "^NEEDRESTART-KSTA: [0-3]$"
+fi
+
+echo "Check if outdated library was detected and dummy marked for restart"
+echo "$OUTPUT" | grep -q "^NEEDRESTART-SVC: dummy-background.service$"
Bug#966941: libpsl: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
Hello! Since we also saw the same FTBFS in Ubuntu, I have looked into it briefly today. It seems that the test-is-public-builtin data needs to be updated for the test to work as expected. This was fixed in libpsl 0.21.1 per this commit: https://github.com/rockdaboot/libpsl/commit/f364cea73e351ce62e0b337fd1fbc21e70b52d56 Cherry-picking the above commit (or simply pulling in 0.21.1) should fix this error. Cheers! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com
Bug#959180: mitmproxy incompatability
So it seems that this is indeed a runtime incompatibility - which makes sense with mitmproxy binary having a versioned dependency on python3-tornado (>= 4.3) right now. I think the best way forward would be to update mitmproxy to 5.1.1, if we don't have enough confidence that the outlined commit is enough of course. Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com
Bug#951577: Bubblewrap upstream-as-root test fails with libcap2 1:2.31-1 and later
Package: libcap2 Version: 1:2.32-1 The bubblewrap upstream-as-root test started failing after libcap2 1:2.31-1 got synced from Debian. The same failure can be seen with 1:2.32-1. I have reproduced the issue locally on focal - when using the focal-proposed version, the aforementioned test fails, where with the release version (after reverting libcap2 to 1:2.27-1) it passes. It seems to fail here already: bwrap --bind / / --tmpfs /tmp --as-pid-1 --cap-drop CAP_KILL --cap-drop CAP_FOWNER --unshare-pid capsh --print assert_not_file_has_content caps.test '^Current: =.*cap_kill' It looks like the requested caps did not get dropped, as the logs show that both cap_kill and cap_fowner are still there. This is only for the upstream-as-root test, i.e. executing tests/test-run.sh as root. This might be an issue with bubblewrap, but seeing that it all works fine with the release version, it all feels like an unintended regression. Reported on Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/1863733 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com
Bug#888107: debian-cd: Please drop dependency on the no longer existing lynx-cur transitional package
Package: debian-cd
Version: 3.1.20
Severity: normal
Tags: patch
Hello,
With the recent Debian upload of the lynx source package, the lynx-cur
transitional package has been dropped. To make all the world happy
debian-cd should stop conditionally depending on lynx-cur.
Thank you!
*** /tmp/diff
diff -Nru debian-cd-3.1.20.old/debian/control debian-cd-3.1.20/debian/control
--- debian-cd-3.1.20.old/debian/control 2017-04-29 11:20:00.0 +0200
+++ debian-cd-3.1.20/debian/control 2018-01-23 13:22:17.0 +0100
@@ -11,7 +11,7 @@
Package: debian-cd
Architecture: all
-Depends: ${misc:Depends}, curl, perl, dpkg-dev, cpp,
libdigest-md5-perl, libdigest-sha-perl, tofrodos, apt (>= 0.3.11.1),
make, xorriso | genisoimage, lynx-cur | lynx, grep-dctrl, bc,
libcompress-zlib-perl, bzip2, libdpkg-perl
+Depends: ${misc:Depends}, curl, perl, dpkg-dev, cpp,
libdigest-md5-perl, libdigest-sha-perl, tofrodos, apt (>= 0.3.11.1),
make, xorriso | genisoimage, lynx, grep-dctrl, bc,
libcompress-zlib-perl, bzip2, libdpkg-perl
Recommends: hfsutils, netpbm, isolinux, syslinux-common,
syslinux-utils, mtools, dosfstools, syslinux-utils, wget
Description: Tools for building (Official) Debian CD set
Debian-cd is the official tool for building Debian CD set since the potato
--
Łukasz 'sil2100' Zemczak
Foundations Team
lukasz.zemc...@canonical.com
www.canonical.com
Bug#859747: Fix included upstream
Hey! Just a follow-up: I have forwarded the fix upstream and the Barry Scott included it in the new 7.0.2 pycxx release. That being said, even if the package is to be updated to 7.0.2 then we still need the relevant debian/tests/buildtest changes from the debdiff above. Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com
Bug#859747: debdiff for fixing this issue
Hello! Attaching a debdiff with a patch for fixing this issue, would be grateful for someone reviewing it and - if all seems fine - sponsoring this change to Debian. I will try to submit this patch upstream as well. Thank you! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@ubuntu.com www.ubuntu.com pycxx_7.0.1-2.debdiff Description: Binary data
