[02:16] <mwhudson> Err:241 http://archive.ubuntu.com/ubuntu focal/main amd64 librtmp1 amd64 2.4+20151223.gitfa8646d.1-2build1
[02:16] <mwhudson>   Undetermined Error [IP: 91.189.91.39 80]
[02:17] <mwhudson> hnnngh
[05:37] <RAOF> Bah. What was the incantation to get autopkgtest.ubuntu.com to rerun a test with a different set of packages? Mir 2.12.0 and wlcs 1.5.0 are entangled and need to migrate together.
[05:38] <RAOF> (Specifically, wlcs 1.5.0 adds new tests, which the existing mir 2.9.0 fails and so wlcs 1.5.0 regresses -release mir, but mir 2.12.0 exposes a bug in wlcs 1.4.0 resulting in mir FTBFSing against 1.4.0)
[05:40] <arraybolt3> For some reason I thought there's a command in ubuntu-archive-tools that does something helpful here, but my copy of ubuntu-archive-tools has gone missing somewhere on my SSD and I have enough files that "find | grep ubuntu-archive-tools" is taking its sweet time :-P
[05:41] <RAOF> retry-autopkgtest-regressions, yeah.
[05:41] <RAOF> I don't need to run it against all proposed, though. I know there's a way to futz with the query string on test resubmission to add a package...
[05:42] <RAOF> Alternatively, I can use the script and have the followup question of "how do I get the autopkgtest.ubuntu.com cookie out of my browser?" :)
[05:42] <arraybolt3> Ugh.
[05:45] <arraybolt3> RAOF: This what you were looking for? https://autopkgtest.ubuntu.com/request.cgi?release=RELEASE&arch=ARCH&package=SRCPKG&ppa=LPUSER/PPA&trigger=SRCPKG/VERSION
[05:46] <ginggs> RAOF: i'll do it now
[05:46] <RAOF> Yeah. It's *possible* I just want to have multiple &package fields.
[05:47] <liushuyu> Hi, I would like to request the removal of https://launchpad.net/ubuntu/+source/rustc/1.67.1+dfsg0ubuntu1-0ubuntu1/ from LL-proposed due to a critical issue described in https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2007642/comments/7 . Is there any AA currently awake?
[05:47] -ubottu:#ubuntu-devel- Launchpad bug 2007642 in rustc (Ubuntu) "Upgrade Rust to 1.67.1" [Undecided, In Progress]
[05:47] <RAOF> ginggs: Cool, thanks. Can I also learn how, so that next time I can self-service? :)
[05:48] <RAOF> Am I right in my vague memory that you can just append extra &package=$FOO/$VERSION query parameters to add those to the set?
[05:48] <ginggs> https://autopkgtest.ubuntu.com/request.cgi/?release=lunar&arch=amd64&package=mir&trigger=mir%2F2.12.0-0ubuntu2&trigger=wlcs%2F1.5.0-1ubuntu1
[05:48] <ginggs> and i'll repeat for the other architectures
[05:49] <RAOF> Ah, almost correct :)
[05:49] <RAOF> TYVM
[05:49] <arraybolt3> Sigh. Found my ubuntu-archive-tools copy finally. In a painfully obvious location, hiding in plain sight.
[05:49] <ginggs> you just add extra &trigger= as needed
[05:54] <RAOF> Yeah, I had the polarity reversed.
[05:54] <RAOF> Thanks again!
[05:54] <ginggs> yw!
[08:48] <schopin> If I have a package P that build-depends on itself (with fairly tight version requirements), is it possible to upload a new version of P that build depends on a version of P that's currently building (and thus not published yet)?
[09:09] <ricotz> schopin, restoring the existing build of rustc 1.66.1 would have been possible
[09:10] <schopin> Oh well.
[09:10] <schopin> Live and learn, as they say.
[09:11] <ricotz> schopin, I guess you can still ask in #ubuntu-release
[09:11] <ricotz> get 1.66.1+dfsg0ubuntu1-0ubuntu2 stopped and removed and reinstate 1.66.1+dfsg0ubuntu1-0ubuntu1
[09:14] <ricotz> schopin, of course the 1.66.1+dfsg0ubuntu1-0ubuntu1 binaries are still in -proposed
[09:14] <ricotz> so you can build dep on them as is
[09:14] <schopin> Which means I should be able to upload 1.67 with the patch!
[09:15] <ricotz> yes
[09:15]  * schopin goes get some coffee before making any more of a mess
[09:15] <ricotz> schopin, see https://launchpad.net/ubuntu/+source/rustc/1.66.1+dfsg0ubuntu1-0ubuntu2
[09:16] <ricotz>  Missing build dependencies: rustc (<= 1.65.0++)
[09:16] <ricotz> looks like a missing bump
[09:16] <schopin> I saw :)
[09:16] <schopin> Hence my coffee remark
[09:16] <ricotz> so don't miss it in 1.67
[09:16] <ricotz> << 1.67.0++
[09:17] <ricotz> even << 1.67.1++
[10:47] <bigon> hey, has anyone already looked at writing an apparmor module for geoclue?
[10:48] <bigon> on debian I'm ending up with https://paste.debian.net/hidden/b26a72ee/
[10:48] <bigon> but IIRC debian kernel has no D-Bus nor network mediation
[10:58] <danilogondolfo> Hi all, I'm looking for someone to review/sponsor a merge. Let me know if you have few spare minutes today :) https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2008123
[10:58] -ubottu:#ubuntu-devel- Launchpad bug 2008123 in curl (Ubuntu) "Please merge 7.88.1-1 into lunar" [Undecided, New]
[12:03] <zhsj> could someone retry these autopkgtests https://paste.ubuntu.com/p/n6TrH3f3Rt/
[12:06] <schopin> zhsj: on it.
[12:07] <zhsj> schopin: ta
[12:21] <bluesabre> vorlon: Who should I ping to take a look at livecd-rootfs/ubuntu-image? It looks like the package is blocked by a failing test: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#livecd-rootfs (trying to move Xubuntu Minimal along)
[12:40] <cpaelzer> dannf: do you happen to know or have an idea about https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/s390x/e/edk2/20230223_114100_288d2@/log.gz ?
[12:41] <cpaelzer> dannf: that works fine if I run it on s390x myself, but seems to reliably fail in the autopkgtest environment
 "vorlon: Who should I ping to..." <- He's out this week, I've pinged bdmurray about it before, we agreed it's a bad test and something should probably be done about it, but I don't know what.
 "He's out this week, I've..." <- Gotcha. Thanks for the follow-up!
[15:31] <Eickmeyer[m]> bluesabre: It affects Edubuntu as well, so we're highly interested in getting this one through!
[15:55] <bdmurray> jawn-smith: Have you looked at the ubuntu-image failure blocking the migration of livecd-rootfs? mwhudson was talking about it yesterday
[15:57] <jawn-smith> bdmurray: looks to be a failure in live-build
[15:57] <jawn-smith> ideally we'll be removing that package from the archive soon and then problem solved
[15:57] <jawn-smith> ubuntu-image, not livecd-rootfs
[15:59] <bdmurray> jawn-smith: Failure in live-build? When finally getting to a "good" log I see it timing out - https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/u/ubuntu-image/20230222_163615_eac4a@/log.gz
[16:03] <jawn-smith> bdmurray: Both of the retriggers that mwhudson did yesterday had the following error: Did not expect an error, got Error running command "/usr/bin/lb build": exit status 1
[16:08] <bdmurray> jawn-smith: before that there is a network issue getting a package though
[16:09] <jawn-smith> network issues could definitely cause failures in lb
[16:09] <bdmurray> E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-idna/python3-idna_2.8-1_all.deb  Undetermined Error [IP: 91.189.91.39 80]
[16:09] <bdmurray> That's why I went back further
[16:09] <jawn-smith> Could it be the infrastructure having network problems?
[16:27] <nteodosio> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=edk2&trigger=libisoburn%2F1%3A1.5.4-4ubuntu1 please?
[16:29] <nteodosio> Nevermind that, seems it was already retriggered but excuses page is slow.
[17:09] <danilogondolfo> May I ask someone to retry this autopkgtest for me, please? https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=glibc&trigger=glibc/2.37-0ubuntu1&trigger=libcap2/1%3A2.66-3ubuntu2
[17:12] <schopin> danilogondolfo: .
[17:12] <danilogondolfo> schopin: thanks!
[19:44] <vpa1977> Hi, would it be possible to retry https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=openjdk-lts&trigger=harfbuzz%2F6.0.0%2Bdfsg-3build1 ? The failure is in jtreg test timeout (which happens occasionally). Long term solution is limiting the test run to tier1/2 tests of the openjdk.
[19:47] <enr0n> Can a core dev please retry this test? https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=update-manager&trigger=ubuntu-release-upgrader%2F1%3A23.04.2
[19:55] <bdmurray> I'm clicking both of those
[20:00] <enr0n> thanks!
[20:13] <vpa1977> bdmurray: Thank you !!!!
[20:18] <arraybolt3> https://dpaste.com/FVVSMW4GB The apport autopkgtest triggered by qterminal is failing on these errors it appears. However no changes to the packaging were made that I would think could cause this, and it looks like something's timing out and causing the failure. I don't know hardly anything about the guts of apport, so I don't know if this is actually qterminal's fault or not.
[20:20] <bdmurray> I'm not sure it would fix it but there is a new version of apport which passed its own tests
[20:22] <arraybolt3> I see tons of "warning: Memory read failed for corefile section, 4096 bytes at 0xffffffffff600000." in the logs.
[20:22] <arraybolt3> https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/a/apport/20230223_023204_c2321@/log.gz
[20:23] <arraybolt3> Idk. I'll try and reproduce locally to see if it's just a slow tester causing a timeout or something.
[21:35] <arraybolt3> bdmurray: Well I can't reproduce the autopkgtest failure locally with the version in -proposed, and I can't seem to get pull-lp-source to give me the version that's in the -release, so I guess I'll just wait for the new version to migrate and then try again.
[21:36] <arraybolt3> Hah, the newer version is failing on the same test on a different arch with a timeout!
[21:40] <bdmurray> It looks dbungert triggerd apport with qterminal and something else
[21:47] <dbungert> I ran a few tests earlier, all the things that retry-autopkgtest-regressions were suggesting for trigger=lsb