[00:06] <rbasak> ubuntu-devel-announce@ moderation please
[00:52] <cjwatson> rbasak: .
[01:07] <sarnold> rbasak: hmm, 20220316000000.GK13826@mal.justgohome.co.uk  seems to be missing in both my imap folder and in https://lists.ubuntu.com/archives/ubuntu-devel/2022-March/thread.html#start
[01:08] <sarnold> rbasak: hah, figures, I hadn't made it to my ubuntu-devel-announce folder yet. never mind :)
[13:48] <mvo> jawn-smith: I noticed you did the last passwd upload to jammy, I would like to upload a bugfix for ubuntu core (https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375) - I assume that is ok? do you want to review the diff or can I go ahead (this was tested by mardy already)
[13:48] <ubottu> Launchpad bug 1959375 in shadow (Ubuntu Jammy) "[SRU] Please support group manipulation with 'extrausers'" [Undecided, New]
[13:56] <jawn-smith> mvo: I trust you :)
[14:19] <mvo> jawn-smith: thank you (and "famous last words" ;)
[15:15] <enr0n> hi, I am looking for sponsors for a couple of fixes (LP: #1965132, and LP: #1965134). I would appreciate if anyone has time to review. TIA
[15:15] <ubottu> Launchpad bug 1965132 in python-pecan (Ubuntu) "python-pecan: FTFBS: build tests are failing on python 3.10" [Undecided, New] https://launchpad.net/bugs/1965132
[15:15] <ubottu> Launchpad bug 1965134 in golang-github-valyala-fasthttp (Ubuntu) "golang-github-valyala-fasthttp 1:1.31.0-3: autopkgtest regression on s390x" [Undecided, New] https://launchpad.net/bugs/1965134
[15:58] <slyon> bluca: after briefly checking the individual changes, I uploaded 249.11. It's now in jammy-release, thanks for the heads up!
[16:01] <bluca> woop woop, thank you
[16:06] <jawn-smith> kanashiro: you maintain containerd correct?
[16:15] <kanashiro> jawn-smith, uyep
[16:15] <jawn-smith> I'm working on the Go 1.18 transition and have come across an oddity in containerd
[16:16] <jawn-smith> the logic to replace github.com/containerd/containerd with the .empty-mod is causing problems
[16:16] <jawn-smith> Is that still needed? Removing it allows it to build with go 1.18 and doesn't break builds with go 1.17
[16:16] <jawn-smith> which seems more straightforward than re-vendoring everything
[16:17] <jawn-smith> but if it's still needed for any reason I can work on re-vendoring to see if that also resolves the FTBFS with Go 1.18
[16:19] <kanashiro> jawn-smith, tbh I did not have time to take a look at Go 1.18, I need some time to check this out, but I believe the removal should not be an issue
[16:19] <jawn-smith> Great thanks! I don't want to step on your toes so if I create a bug and a patch for this would you mind reviewing it?
[16:20] <kanashiro> jawn-smith, that'd be great :)
[17:15] <jawn-smith> kanashiro: bug 1965157
[17:15] <ubottu> Bug 1965157 in containerd (Ubuntu) "containerd is FTBFS with Go 1.18" [Undecided, New] https://launchpad.net/bugs/1965157
[17:15] <jawn-smith> contains the patch and build logs against 1.17 and 1.18
[17:21] <bdmurray> jbicha: Out of curiousity how did you requeue all the zlib tests?
[17:24] <jbicha> retry-autopkgtest-regressions --only-unknown --blocks zlib   piped to my web browser
[17:25] <jbicha> I don't have the cookie set up that the tool suggests
[17:26] <bdmurray> I tried adding in --log-regex "amss.bin" and it didn't return the urls I'd expected but maybe that's because I was missing --only-unknown
[17:27] <jbicha> I didn't know (remember) only-unknown existed until yesterday but I guess it's been there a while
[17:40] <bdmurray> Well that's just weird https://pastebin.ubuntu.com/p/qCx8STtqFP/
[17:55] <juliank> bdmurray: so it does some queue parsing and then not produce items already queued
[17:56] <juliank> bdmurray: see where it queries running_url = 'https://autopkgtest.ubuntu.com/static/running.json'
[17:56] <juliank> I think that explains the difference because some stuff got queued in between
[17:59] <bdmurray> juliank: ah neat, thanks for finding that
[18:45] <kanashiro> jawn-smith, thanks, I'll take a look at the bug
[18:46] <jawn-smith> thanks!
[19:31] <kanashiro> jawn-smith, I am a bit busy with other stuff today, is it okay if I reply to the containerd bug tomorrow?
[19:37] <jawn-smith> sure thing!
[19:37] <jawn-smith> kanashiro: no huge hurry, I'm still slogging through lots of other Go 1.18 issues and then I still need to pester a release team member for the FFE
[19:38] <kanashiro> great then
[19:51] <sbeattie> Hey, so can someone give me some advice re: symbol versions?
[19:51] <sbeattie> I'm attempting to add a debian symbols file to nftables for libnftables1.
[19:51] <sbeattie> Generating a symbols file was pretty straightforward, following https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols got me https://paste.ubuntu.com/p/968bkr5P2z/
[19:51] <sbeattie> However, upstream attempts to version its symbols, but it's not working correctly, for reasons I am not entirely sure I understand, but "fixing" it results in the build failing due to LTO vs symbol versioning conflicts.
[19:52] <sbeattie> If it were working correctly in the upstream build, the symbols would look like https://paste.ubuntu.com/p/b4S5DpWqpp/
[19:52] <sbeattie> (Note the @LIBNFTABLES_1 etc there vs @Base versions in the generated debian symbols.)
[19:52] <sbeattie> My question is this: if I add the debian symbols based on the versions as they are now, is that seting up for problems in the future if the upstream symbol versions get fixed?
[19:52] <sbeattie> I don't want to do something here that might result in a future gratuitous SO version bump.
[19:52] <bryceh> bdmurray, do you know if someone's already made a python script or module that could parse apt history.log and/or dpkg.log?
[20:09] <bdmurray> bryceh: I don't know of one
[20:14] <bryceh> bdmurray, thanks.  I found I'd written one a decade ago in xdiagnose.  Looks in need of a serious rewrite though.
[20:17]  * bdmurray shakes head at decade
[20:20] <bryceh> IKR?
[21:52] <bdmurray> mwhudson: are the pam tasks in bug 1892825 valid?
[21:52] <ubottu> Bug 1892825 in glibc (Ubuntu) "update-locale not perform correctly sanity checks" [Medium, In Progress] https://launchpad.net/bugs/1892825
[21:53] <mwhudson> bdmurray: imo yes, although perhaps that isn't very clear from the description
[21:57] <bdmurray> mwhudson: okay, and were you able to recreate the failure in bug 1899800?
[21:57] <ubottu> Bug 1899800 in glibc (Ubuntu Bionic) "Runtime deadlock: pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing" [Medium, Confirmed] https://launchpad.net/bugs/1899800
[21:57] <mwhudson> bdmurray: ah doh, no i have not but i have not tried amazingly hard to