RAOFOoof. 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]06:31
adrienhey, 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:45
adrienand 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:46
seb128adrien, triggered11:49
ueberallHi. 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 points17:47
ueberallto 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:47
ueberallI think I have a workaround, but I wouldn't consider that clean (AT ALL).17:48
mariogripNow that the dpkg bug has been fixed (yay) can anyone retry arm64 and amd64 builds on this? https://launchpad.net/ubuntu/+source/biometryd19:00
cjwatsonueberall: 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
cjwatsonmariogrip: done19:03
mariogripcjwatson: Thanks19:05
ueberallcjwatson: 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.19:12
cjwatsonueberall: 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; fi20:07
cjwatson(It's possible that expectation is ... not terribly explicit.)20:08
ueberallcjwatson: Great example, thanks a lot! \o/20:21
mariogripCan 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 also20:36
cjwatsonmariogrip: done20:44
mariogripThanks :) It worked20:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!