[07:34] <arraybolt3> Doing my first Ubuntu desktop QA test, and I've hit two bugs during the encrypted installation routine. One of the bugs was just discovered in passing, but the other one directly contradicted a testcase condition. However, the installation succeeded. Do I submit a passed or failed result on the QA tracker?
[07:50] <arraybolt3> Also, does anyone here know what package handles decrypting an encrypted disk when booting an encrypted Ubuntu installation?
[07:53] <rbasak> arraybolt3: the main package is cryptsetup, but there might be others involved
[07:54] <rbasak> arraybolt3: I'm not particularly familiar with the QA process, but it seems appropriate to submit a failed result if you think a testcase condition was directly contradicted. Since in the general case installation "succeeded" isn't the only desired result, and that's the point of the testcases being more specific I think.
[07:56] <arraybolt3> rbasak: Thank you! I hit a second, much more severe testcase contradiction at the very end of the test, so I think I'm definitely going to mark it as failed. Man, this is fun! Thank you guys for all the hard work you do!
[07:57] <rbasak> Thank you for testing!
[10:48] <rbasak> Did something change in dep8 infra recently? I'm seeing failures on arm64 that require "Internet" but is now getting a 403. AFAICT, these used to work.
[11:01] <jbicha> rbasak: https://irclogs.ubuntu.com/2022/05/09/%23ubuntu-release.html#t12:32
[11:03] <Unit193> jbicha: FYI, RC bug #1002237 still affecting gnome-packagekit.
[11:04] <jbicha> Unit193: wrong bug number?
[11:04] <Unit193> Debian #1002237
[11:09] <jbicha> Unit193: that bug was kinda low priority for me. Someone should report it to https://gitlab.gnome.org/GNOME/gnome-packagekit/-/issues though
[11:09] <Unit193> I mean, it's an RC bug, got it kicked out of testing already so it's been a time...
[11:11] <rbasak> jbicha: ah. I did see that message but failed to connect it today. Thanks!
[11:21] <mardy> bdmurray: hi! I just added a comment about the verification of https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375 ; do I also need to change the "verification-needed" tag into "verification-done", since I verified it on all releases?
[11:44] <jbicha> Eickmeyer: should we close LP: #1967020 now?
[11:49] <rbasak> mardy: if you consider the verification to be done for the entire bug (across all releases etc) then please do change verification-needed to verification-done
[11:50] <mardy> rbasak: ok, thanks, will do that now
[12:12] <ahasenack> morning
[12:28] <ahasenack> hi, can someone take a look at this ust armhf test which seems to be stuck? I don't find it in the /running page, and this upload is 6 days old: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ust
[12:36] <ahasenack> ok, I see the armhf dep8 queue is at over 13k tests :/
[13:52] <Eickmeyer> jbicha: Yeah, I got it.
[14:15] <rbasak> ginggs: o/ thank you for looking but I'm not sure you followed my icinga2 situation. I reproduced the situation locally. It occurs if I just call autopkgtest - no britney involved.
[14:17] <rbasak> And it isn't about test dependencies as such. It's that the proposed source tree is used even when testing a binary from the release pocket.
[14:17] <ginggs> rbasak: i believe that's because of the fallback "WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from kinetic-proposed"
[14:18] <rbasak> ginggs: it's still wrong though?
[14:18] <rbasak> If it's going to fall back, it should use the source tree from the thing it's falling back to.
[14:19] <ginggs> yes, the fallback is not perfect, but i think it's better than no fallback
[17:04] <bdmurray> seb128: Can you sort out canary builds for kinetic? 'E: The repository 'http://ppa.launchpad.net/ubuntu-desktop/canary-image/ubuntu kinetic Release' does not have a Release file.'
[17:28] <bdmurray> mardy: changing the non-release specific tag is not necessary for the SRU process. I saw a question about this earlier in the week too.
[17:29] <bdmurray> The idea behind the verification-needed tag is that people interested in doing sru-verification could subscribe to bugs tagged verification-needed or search for those.
[17:29] <bdmurray> Rather than searching for verification-focal-needed and verification-jammy-needed etc....
[17:30] <bdmurray> But the SRU team only cares about the per release tags.
[17:39] <dbungert> for a package that fails to build in the first place, and that I believe would build now, what's the procedure?  Ask a core-dev to trigger a new build in launchpad? (is that a thing?) https://launchpad.net/ubuntu/+source/lsvpd/1.7.14-1/+build/23585022
[17:40] <ginggs> dbungert: yes, and retried now
[17:41] <dbungert> ginggs: thanks!
[17:56] <seb128> bdmurray, I fixed the canary issue this morning I think, waiting for the next build to see if it works
[17:56] <seb128> bdmurray, could you maybe trigger a build so if there is another issue I might have a go to fix it before the weekend?
[18:03] <bdmurray> seb128: Sure, I'll kick one off now
[18:55] <sergiodj> mwhudson: hey, I'm working on https://bugs.launchpad.net/ubuntu/+source/golang-1.18/+bug/1973107 (which is affecting telegraf).  I'll likely have to do a two-stage upload to fix it, but I'll let you know when I have something ready
[18:55] <sergiodj> sarnold: ^ (re. the telegraf FTBFS)
[19:36] <mwhudson> sergiodj: ok cc jawn-smith
[19:36] <mwhudson> sergiodj: i don't really see why a two stage upload is needed but fine :)
[19:37] <jawn-smith> o/
[19:37] <sergiodj> mwhudson: golang depends on itself and fails to build on ppc64el when it tries to run its link tests
[19:37] <mwhudson> sergiodj: is it going into a point release? can you add PKG_NO_PNG_MANGLE (check spelling pls) while you're at it? for  https://bugs.launchpad.net/ubuntu/+source/golang-1.18/+bug/1972735
[19:38] <mwhudson> sergiodj: ugh, that sounds like pretty bad isolation in the test suite?
[19:38] <sergiodj> mwhudson: yeah, point release.  sure thing, I can address that as well
[19:38] <jawn-smith> sergiodj: I did a test build in this PPA with the PKG_NO_PNG_MANGLE
[19:38] <jawn-smith> https://launchpad.net/~jawn-smith/+archive/ubuntu/golang-latest
[19:39] <sergiodj> mwhudson: yeah, well, it's one of those corner cases...  very specific linking problem when dealing with PIE binaries
[19:39] <sergiodj> but I agree that the test suite could do a better job handling this
[19:40] <sergiodj> jawn-smith: ah, awesome.  thanks.  I'll use your patch then
[19:40] <sergiodj> for some reason I'm now seeing an armhf failure on my PPA (which I wasn't seeing before)
[19:40] <mwhudson> jawn-smith: you need to enable some other architectures apparently :)
[19:40] <jawn-smith> yeah, I do
[19:40] <mwhudson> sergiodj: the runtime tests are pretty flaky on arm
[19:40] <sergiodj> mwhudson: ah, that explains it.  do you just keep retriggering?
[19:41] <jawn-smith> yeah I usually have to retry armhf a couple of times
[19:41] <jawn-smith> Though when I went to submit an upstream bug I couldn't recreate it locally of course
[19:41] <sergiodj> jawn-smith: ACK, thanks.  I'll go ahead and prepare the upload, then
[19:42] <sergiodj> :)
[19:42] <jawn-smith> thanks!
[19:42] <sergiodj> just running a few more tests here; I'll let you know when I have an MP up
[19:48] <sarnold> sergiodj: woot, thanks! so, uh, brown-paper-bag moment here; a teammate noticed that the segfaulting test case was opening a listening socket without checking the error return .. my test build after moving squid-deb-proxy away from port 8000 just succeeded! :D
[19:49] <sergiodj> sarnold: ah, awesome!  I'm preparing an update to the telegraf package anyway, because that error shouldn't happen and it's been fixed upstream.  as soon as we have a fixed golang compiler, I'll go ahead with the telegraf version bump
[19:49] <sergiodj> and will let you know :)
[19:50] <sarnold> :D
[20:34] <sergiodj> jawn-smith: mwhudson: https://code.launchpad.net/~sergiodj/ubuntu/+source/golang-1.18/+git/golang-1.18/+merge/422246
[20:34] <jawn-smith> will take a look, thanks!
[20:38] <sergiodj> thanks!