| 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] | 06:31 | |
| 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:45 |
| 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:46 | |
| seb128 | adrien, triggered | 11:49 |
| adrien | thanks! | 11:51 |
| seb128 | np! | 11:52 |
| 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:47 |
| ueberall | I think I have a workaround, but I wouldn't consider that clean (AT ALL). | 17:48 |
| 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:00 |
| 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:02 |
| cjwatson | mariogrip: done | 19:03 |
| mariogrip | cjwatson: Thanks | 19:05 |
| 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. | 19:12 |
| 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:07 |
| cjwatson | (It's possible that expectation is ... not terribly explicit.) | 20:08 |
| ueberall | cjwatson: Great example, thanks a lot! \o/ | 20:21 |
| 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:36 |
| cjwatson | mariogrip: done | 20:44 |
| mariogrip | Thanks :) It worked | 20:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!