[06:31] <RAOF> Ooof. Launchpad, why can't I add a jammy task to https://bugs.launchpad.net/ubuntu/+source/python-qpageview/+bug/1993213 ? 😠
[06:31] -ubottu:#ubuntu-devel- Launchpad bug 1993213 in python-qpageview (Ubuntu) "Please upgrade Frescobaldi package to 3.2 in Jammy" [Undecided, New]
[11:45] <adrien> hey, I'm trying to make coreutils migrate and there are a couple tests that need to be re-triggered: https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=ppc64el&package=uqm&trigger=coreutils%2F9.1-1ubuntu2 (often flaky), https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=dgit&trigger=coreutils%2F9.1-1ubuntu2 (network issue while running apt), thanks :)
[11:46] <adrien> and then xpra is stuck because of python, and datefudge is buggy ( https://bugs.launchpad.net/ubuntu/+source/datefudge/+bug/2002803 )
[11:46] -ubottu:#ubuntu-devel- Launchpad bug 2002803 in datefudge (Ubuntu) "64-bit time_t functions are not implemented/exposed" [Undecided, New]
[11:49] <seb128> adrien, triggered
[11:51] <adrien> thanks!
[11:52] <seb128> np!
[17:47] <ueberall> Hi. Is there a *clean* way to remove a "pre-invoke" hook in /etc/dpkg/dpkg.cfg.d/ which points to a file which is part of the package to be removed/upgraded? In the case of an upgrade, the user is told that the previous file in said directory has been removed and asked whether s/he wants to see a diff comparing the now-nonexistent old with the new file (although the file containing the hook does not really change between releases as it only points
[17:47] <ueberall> to a script). If you keep the hook in place (by not removing it in time in the "prerm" script), you'll get an error because the script to be called has (temporarily) been removed.
[17:48] <ueberall> I think I have a workaround, but I wouldn't consider that clean (AT ALL).
[19:00] <mariogrip> Now that the dpkg bug has been fixed (yay) can anyone retry arm64 and amd64 builds on this? https://launchpad.net/ubuntu/+source/biometryd
[19:02] <cjwatson> ueberall: perhaps it's a bit late, but this is exactly why Debian policy says that scripts in /etc should check for whether programs exist before executing them (unfortunately it only says this explicitly for some particular types of scripts, but the principle holds more widely: https://www.debian.org/doc/debian-policy/ch-opersys.html#writing-the-scripts,
[19:02] <cjwatson> https://www.debian.org/doc/debian-policy/ch-opersys.html#cron-jobs)
[19:03] <cjwatson> mariogrip: done
[19:05] <mariogrip> cjwatson: Thanks
[19:12] <ueberall> cjwatson: I will have a look, thanks. Apparently, dpkg hooks don't perform checks (the scripts specified on the right-hand-side simply get called) by default, though. Will need to look at the source and/or test whether something like "pre-invoke=sh -c '[ -x <script> ] && <script>' / "pre-invoke=[ -x <script> ] && <script>" works--that would INDEED be clean.
[20:07] <cjwatson> ueberall: Indeed, hooks are IMO expected to do that themselves.  I found one example of that: /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config:post-invoke=if { test "$DPKG_HOOK_ACTION" = add-architecture || test "$DPKG_HOOK_ACTION" = remove-architecture; } && test -x /usr/share/pkg-config-dpkghook; then /usr/share/pkg-config-dpkghook update; fi
[20:08] <cjwatson> (It's possible that expectation is ... not terribly explicit.)
[20:21] <ueberall> cjwatson: Great example, thanks a lot! \o/
[20:36] <mariogrip> Can we also try a retry of the two arches failing here? https://launchpad.net/ubuntu/+source/dbus-cpp/5.0.3-4 I suspect flaky tests again since i cannot seem to reproduce it, it works on ppa also
[20:44] <cjwatson> mariogrip: done
[20:52] <mariogrip> Thanks :) It worked