[00:55] <mwhudson> LocutusOfBorg, xnox: did either of you managed to figure out why the ghc/armhf build took so very long?
[01:38] <mwhudson> what https://launchpad.net/ubuntu/+source/binutils64/1+c3
[04:01] <RAOF> I agree. Wat?
[04:17] <mwhudson> it doesn't list any architecures ubuntu builds for
[04:17] <mwhudson> which is fairly special
=== paride|off is now known as paride
[08:16] <LocutusOfBorg> mwhudson, yes, sure
[08:17] <LocutusOfBorg> I did https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa
[08:17] <LocutusOfBorg> upload 8.8.4 to groovy, and 8.6.5 (no change rebuild) to focal
[08:17] <LocutusOfBorg> the groovy build is still ongoing, while the no-change rebuild to focal of the focal version took ~1 day
[08:17] <LocutusOfBorg> now, I backported 8.8.4 to focal, and I'm trying to see if it makes any difference
[08:17] <LocutusOfBorg> building 8.8.4 to groovy with gcc-9 didn't help in speeding it up
[08:29] <Laney> !dmb-ping
[08:29] <ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
[08:30] <Laney> If someone has time, can you please make the "canonical-oem-metapackage-uploaders" team, add it to the ACL for the "canonical-oem-metapackages" packageset, and then transfer ownership of that set to ~ubuntu-archive?
[08:30] <Laney> all per https://lists.ubuntu.com/archives/devel-permissions/2020-August/001555.html
[08:30] <Laney> I'm just mentoring FourDollars through writing the required script
[08:32] <Laney> Ah, the team will also need a PPA, can that be created, something like "oem-metapackage-staging"
[08:34] <LocutusOfBorg> mwhudson, unfortunately looks like armhf still sucks at remaining up and running for some days... so retry button is being hit hard
[09:03] <sem2peie> hello, may I ask again about my WiFi problem? maybe someone can see if I filled out the ticket correctly, I wasn't sure which packages are relevant
[09:04] <sem2peie> https://bugs.launchpad.net/ubuntu/+bug/1895333
[09:04] <ubottu> Launchpad bug 1895333 in linux-hwe-5.4 (Ubuntu) " cannot change the regulatory domain ath10k, QCA9984 (QNAP QWA-AC2600)" [Undecided,New]
[09:37] <mwhudson> LocutusOfBorg: hmmm
[09:42] <rbasak> Laney: https://launchpad.net/~canonical-oem-metapackage-uploaders
[09:42] <rbasak> Sorry I thought I reported back to the thread that I'd done that, but it looks like I didn't
[09:43] <Laney> rbasak: ah, cheers, that's step 1 and 2 already done then
[09:46] <rbasak> Laney: I have no objection in principle to hand the packageset over to ~ubuntu-archive to maintain. However the DMB hasn't moved to do that yet. I'd personally like to see some reference documentation on that first, and for ~ubuntu-archive and the DMB to then agree to whatever gets documented.
[09:46] <rbasak> Laney: separately I think the DMB need uploader applicants for the new team?
[09:49] <Laney> Yeah.
[09:49] <Laney> Is the script reference documentation enough for you, or something else?
[09:50] <Laney> I was just looking at code, that's why I asked, because if we run it currently then it won't have permissions of course
[09:50] <Laney> but I guess not a real issue until we're signed off
[09:55] <Laney> (I'm going to poke FourDollars to apply once we're done with the script)
[09:55] <rbasak> I don't mind where the documentation lives
[09:57] <rbasak> I'd like the social bits documented - what the DMB and ~ubuntu-archive respectively agree to do, what limitations to their actions apply, etc.
[09:58] <Laney> alright
[09:58] <Laney> I think the emails contain most of that already, and we can turn that into a wiki page
[09:58] <rbasak> For the DMB I documented the existence of the packageset at https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Canonical_OEM_metapackage_packageset but that's DMB-specific. The script would be a good place to document the detail of the AA/DMB relationship I guess - then both teams can link there
[09:58] <rbasak> Or the wiki, sure :)
[10:25] <Laney> slyon: hey, for your info, I just noticed that netplan.io's ppc64el test runs are failing to complete - have just deployed a fix that will make this soon report as a regression instead of endlessly retrying
[10:25] <Laney> looks like it never comes back after the "cloud_init_generate" reboot
[10:28] <slyon> Thanks Laney! I already talked with Steve and Balint about this problem and I'm currently trying to properly fix this "cloud_init_generate" reboot test... Could you point me to the fix you deployed?
[10:30] <Laney> k
[10:30] <Laney> you might not be very impressed by it :-)
[10:30] <Laney> https://git.launchpad.net/autopkgtest-cloud/commit/?id=2260be83beb6928e74da09df69f0b12c9ecf5194
[10:42] <slyon> thank you!
=== Wryhder is now known as Lucas_Gray
[12:22] <xnox> slyon:  somehow i feel instead of reboot test, it should start lxd container and do things to it.
[12:23] <xnox> or something like that.
[12:23] <xnox> slyon:  cause it looks like we are destroying the VM's networking, and it never comes back.
[12:26] <slyon> xnox: yes... maybe that would be more robust. The broken network/SSH is fixed already in -0ubuntu3 (from my PPA): https://launchpad.net/~slyon/+archive/ubuntu/netplan – But now it fails with "tar: This does not look like a tar archive; autopkgtest-virt-ssh [23:27:12]: copyup destination failed, status 2". I am not yet able to reproduce this locally..
[12:26] <slyon> (see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-slyon-netplan/groovy/amd64/n/netplan.io/20200911_232730_31b98@/log.gz)
[12:27] <slyon> xnox: For an LXD test I would need to modify the base test-class, tho, as the netplan testsuite is playing with several kernel modules, which is not possible inside containers.
[13:32] <ahasenack> didrocks: hi, I updated realmd last week in groovy, with many patches from fedora/upstream
[13:32] <ahasenack> didrocks: adcli is waiting on an FFe
[13:40] <didrocks999> ahasenack: nice! I’ll do some checks on them. thanks for letting me know
[17:01] <bdmurray> waveform: Is there a good spot for bug 1895550?
[17:01] <ubottu> bug 1895550 in Ubuntu "Ubuntu 18.04.5 release for Raspberry Pi 4 does not boot" [Undecided,New] https://launchpad.net/bugs/1895550
[17:02] <waveform> bdmurray, I can take a look at replicating that
[17:05] <bdmurray> waveform: I'm more concerned about what bucket to put raspberry pi bugs in
[17:08] <waveform> bdmurray, hmmm - it might be related to either the kernel (which'd be linux-raspi2 for bionic) or firmware (linux-firmware-raspi2 for all releases)
[17:09] <bdmurray> waveform: I thought I'd heard of a forthcoming raspi meta package. Am I remembering correctly?
[17:12] <waveform> bdmurray, yes, although as far as I know that's only for groovy; there'll be a raspi-common seed, and others depending on that but I forget what meta-package gets generated from that
[23:58] <mwhudson> can anyone explain to me why golang-goprotobuf is still in main?
[23:58] <mwhudson> nothing else in main depends on it afaics and it's not seeded
[23:59] <mwhudson> oh it's on component-mismatches :)