[07:33] Do I have to be an official Ubuntu dev to follow the SRU process or can anyone do it? I got that impression from https://wiki.ubuntu.com/StableReleaseUpdates ... [07:41] ernstp, anyone can do, you will just need a dev to sponsor the actual package upload for you [07:42] (jammy caught some bad luck with openconnect/network-manager-openconnect release timing...) [16:05] hello, i have a question about a build failure i'm getting. [16:06] i'm getting this error The following packages have unmet dependencies: [16:06]  sbuild-build-depends-main-dummy : Depends: python3-pyppeteer but it is not installable [16:06] it seems like pyppeteer is not available [16:10] hello [16:10] i'm not sure if my question went through [16:11] Guest2: it did. Are you trying to build a package from the archive? [16:12] thank you.  i'm trying to build a package from my ppa [16:13] Well, looks like your Python package depends on a package from pip that hasn't been package in Debian nor Ubuntu yet. You'll need to ship that package in your PPA as well. [16:14] ahh... ok that makes sense.  not completely sure how to do that yet. === sem2peie- is now known as sem2peie [17:46] since chown -R is frowned upon in maintainer scripts (https://lintian.debian.org/tags/recursive-privilege-change), I'm unsure how one should go about changing ownership of an unknown amount of files in postinst [17:46] i.e., "chown /var/log/frr/* > /dev/null 2>&1 | ::"? [17:46] the lintian tag also frowns upon using find() [17:52] my (uninformed) guess is that you could avoid the hardlink attack by restricting them with find (find -links 1) [18:00] debian codesearch has some hits on things like [18:00] chown $USER:$GROUP /var/lib/vdr/* > /dev/null 2>&1 || true [18:00] that lintian tag may be new [18:00] I hadn't come across it before [18:01] it was renamed from another one, which was more verbose [18:01] but was still about the same thing: recursive chown/chmod === sem2peie- is now known as sem2peie [19:37] vorlon: It doesn't look like bdr_ung was able to get to sponsoring LP: #1977320 today. Can you please take a look? [19:37] Launchpad bug 1977320 in libcloud (Ubuntu) "libcloud: autopkgtest is flaky due to racy 'test_retry_*' tests" [Undecided, In Progress] https://launchpad.net/bugs/1977320 [20:04] enr0n: sure thing [20:05] vorlon: thanks! [21:01] enr0n: do we know why these tests are running more slowly on ppc64el than on other archs, and if there's something we should be doing to improve the autopkgtest infrastructure?