[02:14] <randall> Hi, Debian ansible maintainer here. I'm looking for the git repo that contains Ubuntu's packaging of ansible. Can someone point me to the right URI?
[02:20] <jbicha> randall: Ubuntu's ansible packaging generally is synced directly from Debian. https://launchpad.net/ubuntu/+source/ansible What are you looking for?
[02:32] <randall> jbicha: There's one version in bionic that I'd like to see: https://changelogs.ubuntu.com/changelogs/pool/universe/a/ansible/ansible_2.5.1+dfsg-1ubuntu0.1/changelog
[02:33] <randall> I guess one way is to just download and unpack the source package but that would loose any comments there might be in git.
[02:38] <jbicha> randall: there is https://code.launchpad.net/~git-ubuntu-import/ubuntu/+source/ansible/+git/ansible/+ref/applied/ubuntu/bionic-updates
[02:38] <jbicha> I don't think the original uploader actually used git for that upload but it's a git representation of what was done. No actual comments though
[02:40] <jbicha> here's all the other branches: https://code.launchpad.net/ubuntu/+source/ansible
[02:42] <randall> jbicha: That's something. Interesting, they used gbp pq for patch management. Thanks!
[02:43] <randall> I'm backporting some security fixes for Debian LTS, and noticed some things are already patched in Ubuntu. This will help me save time on a patch or two. Thanks a bunch!
[02:44] <jbicha> I think that's just an automated import
[10:49] <paride> Hi! It seems to me that britney didn't run or finish running in the last days and (as a conseguence?) the autopkgtest triggers are stuck
[10:49] <paride> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says:
[10:49] <paride> Generated: 2021.11.27 18:16:12 +0000
[10:51] <paride> and many "Test in progress" tests are neither running nor enqueued, take for example ganeti (under qemu): it's not running and not in the queue (according to https://autopkgtest.ubuntu.com/running)
[10:51] <paride> and has not recent test runs: https://autopkgtest.ubuntu.com/packages/g/ganeti/jammy/amd64
[10:55] <paride> sil2100 ^^ is this something you can check?
[11:22] <GunnarHj> paride: Maybe the #launchpad channel is better to bring up that issue.
[11:28] <laney> paride: Looking at https://people.canonical.com/~ubuntu-archive/proposed-migration/log/jammy/2021-11-29/ I would say someone might have smacked it back into life this morning and the 09:00:11 run should update the things
[11:29] <laney> If there are still missing runs after that they might be lost and need to be requeued
[11:34] <paride> laney, thanks!
[11:34] <paride> isn't it taking a loong time compared to the previous runs?
[11:34] <paride> maybe it has more work to do due to the previous failures
[11:41] <laney> seems like there are a lot of tests to request
[12:36] <paride> laney, indeed I think some triggers did get lost... Taking again ganeti as an example, it is a "Test in progress" under qemu, but it as no queued run with triggers=qemu, not recent runs with trigger=qemu in https://autopkgtest.ubuntu.com/packages/g/ganeti/jammy/amd64
[12:37] <paride> do those need manual retriggering? or will britney figure it out at some point and retrigger?
[13:12] <laney> paride: it won't, if it believes it is waiting for the results it'll wait forever
[13:12] <laney> someone could fiddle with retry-autopkgtest-regressions to retry all the missing ones
[13:12] <laney> did something bad happen to rabbitmq or the network?
[13:18]  * paride no idea
[14:16] <paride> one strange thing: liburing triggered an autopkgtest run for mariadb-10.5, but there are no relationships between the two packages in d/control
[14:16] <paride> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liburing
[14:16] <paride> my theory is that the test run should be triggered against mariadb-10.6, but binary packages are missing for mariadb-10.6 (it ftbfs everywhere but in risvc)
[14:18] <paride> so the reverse dependency is wrongly resolved to mariadb-10.5 because it builds (some) binary packages with the same name as mariadb-10.6
[14:19] <schopin> Looking for a sponsor for LP: #1946193 (OpenSSL 3 transition)
[16:30] <GunnarHj> schopin: Where is that extra CFLAG you mentioned in the bug report?
[16:31] <schopin> Good question. I must have selected the wrong debdiff version :/
[16:35] <schopin> GunnarHj: fixed, thanks!
[16:39] <GunnarHj> schopin: Sponsored.
[16:39] <schopin> Thanks!
[18:41]  * ginggs runs 'retry-autopkgtest-regressions --state RUNNING --min-age 0.5'
[19:01] <sil2100> !dmb-ping
[19:01] <rafaeldtinoco> o/
[19:46] <sarnold> mwhudson: re the glibc crasher, I'm scared of efforts to try to keep some subset of people on 2.31-0ubuntu9.3 indefinitely -- they *should* get security and bug fixes same as everyone else. the trouble is, we absolutely know that the next update is going to cause regressions for those people, it's basically already happened. it's just a matter of when we rip the bandaid off. :/
[19:49] <sarnold> mwhudson: and living life on packages that can't be found on the archive mirrors isn't great fun -- apt install --reinstall is a useful thing, debug symbols are a useful thing, and maybe they'll need to install another binary package from the glibc source package.. using curl or wget from launchpad to solve those isn't a great look for an LTS
[19:50] <sarnold> mwhudson: I see no alternative besides pushing yet another breaking update and doing our best to message that *some* users are going to need a reboot asap :(
[19:57] <mwhudson> https://code.launchpad.net/~mwhudson/ubuntu-seeds/+git/ubuntu/+merge/411897 <- can i get someone to look at this?
[19:58] <mwhudson> sarnold: yeah, i think it starts by seeing how bad it is
[19:58] <mwhudson> paride: re excuses/autopkgtests rabbitmq had a little lie down i think
[20:12] <bdmurray> bryceh: php8.1 isn't producing i386 packages correct?
[20:18] <sarnold> oh hey, that reminds me ... if we're not building browsers for new releases any more, do we *need* to kill i386? not being able to offer i386 users security updates for packages we shipped was my main reason for thinking we should kill it
[20:20] <sarnold> mwhudson: re "how bad it is", reminds me of https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1674532 when an nss abi break caused similar-feeling problems..
[20:20] <mwhudson> yeah well we're not going to do that :)
[20:22] <mwhudson> sarnold: glibc 2.34+ embeds the commonest nss modules into libc itself which reduces the scope for this sort of hilariousness going forward
[20:23] <mwhudson> sarnold: i wish i understood what was actually going on with the bug you reported
[20:24] <mwhudson> i can see by experiment that using the ld.so from 0ubuntu9.3 with the libc.so from 0ubuntu9.2 breaks really badly
[20:24] <mwhudson> (although trying to debug _why_ mostly involved getting angry with and occasionally crashing gdb)
[20:27] <sarnold> mwhudson: it's a real shame we didn't shove a new 0ubuntu9.4 update out the door immediately and get it over with :( confining all the sadness to one week would have been nice
[20:27] <mwhudson> sarnold: yeah
[20:28] <sarnold> mwhudson: when my own system got into this, it was *really* hard to understand what the heck was going on -- so much just plain didn't work right. I'm not surprised that it's not easy to sort out, because once you've installed it, things don't work right..
[20:28] <mwhudson> sarnold: well the thing is, i made a lxc container (with 9.2), installed 9.3 and things were ... mostly ok?
[20:29] <sarnold> mwhudson: I've become so addicted to tab completion that when that goes sideways, I have immense trouble using the machine at all :)
[20:35] <mwhudson> heh my test container is now _extremely_ wedged
[21:19] <bdmurray> mwhudson: Can we just close out bug 1860942 now?
[21:20] <mwhudson> bdmurray: oh yes, surely
[21:22] <mwhudson> bdmurray: done
[23:15] <mwhudson> sarnold: ah ha i sort of figured out what is going on in https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379
[23:16] <sarnold> mwhudson: yeah? :D woo!
[23:36] <mwhudson> sarnold: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379/comments/8
[23:37] <mwhudson> sarnold: do / did you have any non-default nss config?
[23:40] <sarnold> mwhudson: https://termbin.com/zycj -- and ls -l says it hasn't changed since 2020, so it might even be the same as what I had back then
[23:40] <sarnold> mwhudson: impressive digging
[23:40] <sarnold> mwhudson: what would keep this from happening on any / every upgrade?
[23:41] <sarnold> mwhudson: I mean, new tunables aren't added daily, obviously :) but this is probably not the last
[23:56] <mwhudson> sarnold: hm even installing libnss-mdns and libnss-mymachines doesn't let me reproduce your failure :(