[03:18] <RAOF> mwhudson: I see there's an upload of ubuntu-drivers-common in the bionic-unapproved queue, fixing the same set of bugs that a previous upload that failed to get verified for 100 days.
[03:19] <RAOF> (Asking you because you're likely to be in-timezone ;))
[03:26] <RAOF> Is that still something you want done? Do you know if there's anyone lined up to actually test it once it's in proposed? 🤪
[06:49] <mwhudson> RAOF: uhhh i have no idea what this is about :)
[06:50] <mwhudson> oh i see i'm in changelog
[06:50] <mwhudson> i have no interest in that change being backported to bionic i think
[06:50] <RAOF> Hah! Ok. You've an entry in the changelog
[06:50] <RAOF> Ah, fair enough
[06:50]  * mwhudson thinks
[06:50] <mwhudson> i may have done once, i suppose
[06:51] <RAOF> Well, I've left a comment on the bug for anyone who is interested.
[06:51] <mwhudson> but not really any longer, subiquity will move to core20 before we start using any of this stuff
[06:51] <RAOF> The package looks sane, I just don't particularly want to release it into -proposed only for it to languish for another 100 days before we remove it again!
[06:54] <mwhudson> maybe tseliot cares :)
[06:54] <TJ-> cpaelzer: LocutusOfBorg: have you experimented with issuing the firewalld/NM rhbz1773809.at test manually? Unless I've for something really weird here, on 20.04 with linux=5.14/NM=1.22.10-1ubuntu2.2, the test doesn't do what it appears to do. That is, the nmcli commands executed in the netns DO NOT create the dummy interface in the netns, it is created in the HOST namespace. Verify with "ip
[06:54] <TJ-> link show/ip netns exec $ns ip link show" after the "nmcli con add ..." command. The commands all succeed (in the parent namespace!) so maybe this test failure now is due to some change in namespace handling? See https://paste.ubuntu.com/p/8Vj59v9YBB/
[06:58] <cpaelzer> Thanks for the hint TJ- and LocutusOfBorg - no I have not yet looked into that, but will try to today
[06:58] <cpaelzer> So far I only saw it and wanted to make sure it isn't worked on already :-)
[07:01] <TJ-> cpaelzer: this looks like someone misunderstood things; running nmcli on the namespace doesn't seem to affect NetworkManager daemon running on the host. They communicate over Dbus. So unless nmcli is aware and passes its parent namespace it makes sense. So then the question is, why the change. Look at the NM source-code around the "Activation failed because the device is unmanaged" message  -
[07:01] <TJ-> it suggests some reasons/avenues for investigation (udev is one)
[08:10] <LocutusOfBorg> TJ-, cpaelzer looking at the diff, the test previously was exporting some DBUS_SOCKET so maybe it was meant to communicate with the host?
[12:51] <rbasak> cpaelzer: do you have PPA builds of your qemu SRU uploads available please? Writing out the maintainer script from debian/rules is...fun. I'd like to see a diff of the output :)
[12:56] <cpaelzer> hi rbasak should be linked from the bug, let me see
[12:57] <rbasak> I think I'm confused because there were multiple approaches, MPs, etc.
[12:57] <cpaelzer> yep rbasak, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4653 should have what you look for
[12:57] <rbasak> Thanks!
[12:58] <cpaelzer> let me know if it doesn't then I rebuild whatever you need