[05:17] <mwhudson> https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/snapd/20210903_160300_25a41@/log.gz <- if glibc 2.34 is making go from the snap segfault something really odd is going on
[06:02] <amurray> mwhudson: the previous run didn't segfault - this got triggered to include openssh/1:8.4p1-6ubuntu1 as well - but it then failed anyway due to a different reason... https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/snapd/20210903_212605_77c0b@/log.gz
[07:36] <mwhudson> amurray: hmmmpf
[07:46] <nibbon_> o/ are there plan to port containerd 1.5.5 to Focal or it'll remain 1.5.2?
[07:48] <mwhudson> nibbon_: it usually gets backported
[07:51] <mwhudson> grumble grumble i think valgrind needs some glibc 2.34 patches
[07:56] <nibbon_> mwhudson: so can I expect that it'll keep backporting till the end of Focal support (April 2025)?
[08:10] <mwhudson> nibbon_: i'm not going to commit to anything myself :)
[08:11] <nibbon_> :)
[08:30] <mwhudson> does git-ubuntu have anything like gbp pq import / export ?
[08:42] <juliank> cpaelzer: Seems qemu really hates me now, I'm not sure what's going on
[08:42] <juliank> kvm -smp 2 -m 8192 -cpu host -M q35 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,id=rng-device0 -smbios type=1,product=UBUNTUQEMUTEST -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=/run/
[08:42] <juliank> user/1000/OVMF_VARS.fd -drive if=virtio,format=raw,file=/dev/ubuntu-vg/vm-centos -display gtk,gl=on -cdrom ubuntu-18.04.5-live-server-amd64.iso -vga virtio -cdrom ubuntu-18.04.5-live-server-amd64.iso
[08:42] <juliank> kvm: -cdrom ubuntu-18.04.5-live-server-amd64.iso: drive with bus=2, unit=0 (index=2) exists
[08:42] <juliank> cpaelzer: oh nevermind, cdrom is twice
[08:42] <schopin> A good soul to sponsor LP: #1939707 ? Upstream cherrypick to work around a GCC11 / LTO FTBFS
[08:42]  * juliank was wondering how he broke that :D
[08:43] <juliank> schopin: lookin
[08:43] <schopin> thanks :)
[08:43] <schopin> For such an upload, I don't have to file a FFe, right?
[08:43] <juliank> right
[08:54] <cpaelzer> juliank: :-) I've not seen "if user = juliank" recently
[09:00] <mwhudson> does anyone have a canned way of running an autopkgtest that can only access the internet via proxy, like our runners?
[09:01] <cpaelzer> mwhudson: IIRC --env='no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,ppa.launchpad.net' --env='http_proxy=http://squid.internal:3128'
[09:01] <mwhudson> cpaelzer: i mean locally
[09:01] <cpaelzer> I used that a long time ago, but sure if there was another ingredient to it
[09:01] <mwhudson> or can you access squid.internal over the vpn?
[09:01] <cpaelzer> yes
[09:02] <mwhudson> ah ha
[09:02] <mwhudson> this doens't prevent the vm form accessing the internet not via proxy, i guess we need some iptables for that
[09:02] <mwhudson> but it's probably good enough
[09:02] <cpaelzer> yes I'm sure in the real environments there are some rules set up that block all-else
[09:06] <mwhudson> tjaalton: do you know what's going on here? https://launchpad.net/ubuntu/+source/libepoxy/1.5.8-1/+build/21997947
[09:28] <rbasak> mwhudson: the "applied" branches (not hash stable yet) are the equivalent of "pq import". There is no export yet. But you can just use gbp pq import/export; that works.
[09:33] <seb128> mwhudson, hey, could you poke at golang-github-containers-buildah this week during your +1 maybe? I don't understand go enough to figure out what's going on there, it errors out on resolvconf missing which wasn't an issue before. Are go packages allowed to download from internet or should that be in the depends? (seems like the github url for the project changed but updating that didn't make a difference)
[09:34] <mwhudson> rbasak: yeah, so i checked out the applied branch, cherry-picked some changes from upstream and then failed to figure out how to make pq export work
[09:34] <mwhudson> gbp always has these expectations around branch layout that i fail to live up to
[09:34] <mwhudson> seb128: sure
[09:34] <seb128> mwhudson, thanks
[09:34] <mwhudson> seb128: it's probably the change to default behaviour in 1.16 that's tripping things up (from your description, anyway)
[09:44] <rbasak> mwhudson: ah I'm not sure gbp pq export will work against an unapplied branch, sorry
[09:44] <rbasak> You can use git-format-patch, stick them into debian/patches/ and add them to series I guess.
[09:44] <mwhudson> rbasak: yeah, it wasn't hard at all to do it by hand
[09:44] <rbasak> Sorry it's not a smoother experience right now
[09:45] <mwhudson> no worries
[09:45] <schopin> hmm, I'm confused. I've received a mail saying the s390x build of libuv1 failed, but all the various links within the mail tell me that the build was a success.
[09:45] <schopin> Anyone knows what could have caused this?
[09:45] <mwhudson> i just wish we had imports for every package (and they were all already on my system)
[09:46] <rbasak> I'm focusing on letting everyone push rich history right now
[09:46] <rbasak> After that, I intend to get the applied branches hash stable, which I'm treating as blocking importing all packages
[09:46] <rbasak> Then I intend to import all packages
[09:47] <rbasak> It's slow going since I'm not able to spend much of my time on it right now :-/
[09:48] <mwhudson> schopin: a retry could do that?
[09:48] <mwhudson> seems unlikely on a fresh upload
[09:48] <rbasak> However the importer itself is in much better shape right now - lots of invisible work refactoring and getting a comprehensive test suite going.
[09:49] <schopin> mwhudson: whoever retried it must have been damned fast, as there's been at most 10mn between the mail and my checking out the results.
[09:50] <mwhudson> schopin: yeah, sounds strange
[09:51] <mwhudson> schopin: is the time of the email before the build started time on https://launchpad.net/ubuntu/+source/libuv1/1.40.0-2ubuntu1/+build/22045701 ?
[09:52] <tjaalton> mwhudson: caused by mesa from proposed
[09:53] <schopin> mwhudson: email sent ~1mn before the start of the successful build. I'll be damned. But this means that a retry doesn't change the build ID?
[09:54] <tjaalton> speaking of which, I need a ppc64el instance..
[09:54] <mwhudson> schopin: yeah rebuilds are destructive like that
[09:54] <mwhudson> (yay bad design decisions from 15+ years ago)
[09:55] <schopin> (live and learn, as they say)
[09:55] <mwhudson> schopin: my guess is some infrastructure issue killed the build and it got automatically or batch restarted
[09:56] <mwhudson> tjaalton: me too, i want to understand what's going on here https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/snapd/20210903_160300_25a41@/log.gz
[09:56] <mwhudson> tjaalton: there is a power8 maas still you might be able to get access to
[09:59] <tjaalton> yeah
[10:07] <juliank> schopin: I retried the build after it failed, and it passed
[10:08] <juliank> schopin: I got the email too :D
[10:08] <juliank> schopin: sorry I forgot to communicate that
[10:09] <schopin> juliank: np, I got to learn new things as a result :)
[11:07] <tjaalton> I need an example package that runs upstream tests as autopkgtest
[11:08] <tjaalton> and if using meson, even better
[11:12] <cjwatson> openssh runs upstream tests as autopkgtest, but (a) not meson (b) if it's actually a useful example for you, my sympathies
[11:13] <cjwatson> I resorted to adding a binary package just for the upstream tests as it was otherwise annoyingly slow to have to rebuild part of the source again
[11:14] <tjaalton> ah, right.. I'm thinking of running what dh_auto_test does
[11:15] <tjaalton> if it means building the whole source, so be it.. it's small
[11:32] <laney> note that autopkgtests should run againt the installed package, so if you're building it, you'll probably have to do some work to convince the testsuite to do that rather than the thing you just built
[11:34] <tjaalton> hmm right
[11:34] <laney> gnome has a pattern called 'installed tests' which gets this right, the tests can be shipped in a foo-tests package then
[11:36] <tjaalton> ok thanks, I'll think about it..
[15:21] <ItzSwirlz> cjwatson: No luck. Debootstrap team hasn't responded, and I'm starting to get worried they basically don't care about what they've did with ubuntu building. I'm experimenting with livecd-rootfs options but something sinister is going on
[15:21] <ItzSwirlz> I've figured out that all the conflicting packages are the ones with ubuntu patches (-ubuntu1, -ubuntu2, etc).
[15:21] <ItzSwirlz> Adding a PPA to livecd-rootfs in a fork wouldn't really be a good idea
[15:28] <ItzSwirlz> Update: They did, I just didn't receive it for whatever reason.
[15:28] <ItzSwirlz> however, due to the customization/patches we do to lb it's suggested to talk to the ubuntu folks, is there a specific channel for ubuntu livecd-rootfs and ISO image devs?
[15:33] <cjwatson> I can't help you, sorry - I chimed in once with some ideas but I'm not able to give further help
[15:34] <cjwatson> (I used to be involved with this stuff in Ubuntu but it was years ago)
[15:41] <ItzSwirlz> No problem buddy, sorry. I'm literally going through every option and tweaking things as a last-ditch attempt
[15:42] <cjwatson> FWIW I doubt there's any particular malice from the Debian installer team (who maintain debootstrap), they might just be hideously overworked and not have seen your contacts
[15:43] <cjwatson> They also can't be expected to test with Ubuntu
[15:53] <ItzSwirlz> true, i'm just losing my mind
[19:00] <rbasak> !dmb-ping
[19:01] <teward> US holiday is US holiday :|
[19:01] <rafaeldtinoco> im here but not in a computer right now
[19:01] <rafaeldtinoco> holidays here as well
[19:02] <teward> (Labor Day means a day off here in the USA)
[22:55]  * mwhudson looks at golang-github-containers-buildah, considers step 4 of https://twitter.com/IanColdwater/status/1400009551156592640