[08:12] <seb128> ddstreet, the n-m/ppc64el fix, do you plan to upload to g-serie? (by SRU rules it should have been there first), also seems like autopkgtests are still unhappy with the SRU on focal :/
[10:36] <RikMills> doko: same for our toolchain now? https://lintian.debian.org/tags/debian-rules-uses-as-needed-linker-flag.html
[10:42] <Unit193> Been that way for Ubuntu for much longer.
[10:44] <cjwatson> natty or thereabouts I think
[10:44] <cjwatson> https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition   yes
[10:44] <Unit193> I don't have very lucid memories of it.
[10:45] <cjwatson> thank you
[10:45] <cjwatson> https://www.youtube.com/watch?v=8eXj97stbG8
[10:46] <RikMills> Unit193: I had thought so, but made me wonder!
[10:46] <RikMills> just wanted to make sure before I started merging changes where that option was dropped from rules
[10:48] <Unit193> (I'm sorry)  The unfortunate part for Debian is that buster doesn't, so anything destined for buster-backports...
[10:50]  * RikMills shrugs
[11:07] <ddstreet> seb128 yep i'll upload to groovy, i was hoping it would make it to focal before the groovy copy
[11:59] <ddstreet> seb128 the n-m autopkgtests for focal (and groovy) seem fine?  well, except for i386, but pretty much all the tests are broken for i386 in focal and beyond
[12:30] <xnox> doko:  that's a very good question. $ snap info --verbose chromium says to open bugs on https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
[12:30] <xnox> doko:  i guess snappy / jdstrand might need to be involved to adjust policies
[12:30] <xnox> doko:  open a bug & also mark it as affecting snappy project?
[12:31] <jdstrand> doko: oh, zyga actually has a pr up for that
[12:31]  * jdstrand finds it
[12:31] <zyga> hmm?
[12:31] <zyga> jdstrand: the docs stuff?
[12:31] <jdstrand> doko: https://github.com/snapcore/snapd/pull/8578
[12:31] <jdstrand> zyga: yeah
[12:32] <zyga> we are going through failing tests and fixing some infra issues
[12:32] <zyga> but this passes
[12:32] <jdstrand> doko: once that is committed, chromium (cc oSoMoN) can plugs it and you should be good to go
[12:32] <zyga> jdstrand: I'll reach out to advocacy after it lands
[12:32] <zyga> jdstrand: so that all the browsers get it
[12:33] <zyga> jdstrand: and that probably circles back to you for declarations
[12:33] <jdstrand> zyga: sounds like a plan
[12:33] <jdstrand> yep
[12:33] <jdstrand> zyga: thanks for doing it btw
[12:33] <zyga> :)
[12:33] <oSoMoN> nice one, looking forward to it landing
[12:38] <doko> jdstrand: thanks, but now I'm facing LP: #1876083
[12:39] <jdstrand> doko: I think oSoMoN will do the initial triage and followups and pull me in as needed
[12:39] <zyga> doko, jdstrand: I had a look but I lack ipv6 (nobody provides that here) and I can only guess
[12:41] <oSoMoN> doko, could you by any chance test the google chrome deb to see if it's similarly affected?
[15:16] <xnox> doko:  oSoMoN:  i have google chrome deb as the default browser here. If you need i can test things.
[15:16] <seb128> ddstreet, sorry you are right, I misread the SRU comment, it's the systemd/ppc64el test failing
[15:16] <doko> xnox: well, if you see DNS timeouts in chromium, then you can help
[15:17] <xnox> doko:  are you ipv6 native, with dns6to4? or like is local network dual stack?
[15:17] <xnox> doko:  can I see `resolvectl`  on paste.canonical.com ?
[15:18] <doko> xnox: https://paste.ubuntu.com/p/553cMPqx69/
[15:22] <xnox> that look sgood
[15:23] <xnox> doko:  do you time out on public network resolutions or things on local network, ie.. stuff in fritz.box domain?
[15:24] <xnox> also the current dns server is the ipv4 one, instead of ipv6 one. Interesting. (both should return both A & AAAA records, but i wonder if things go weird)
[15:32] <doko> xnox: no, public ones, and not only lp or ubuntu domains
[16:44] <xnox> doko:  interesting
[17:14] <Odd_Bloke> vorlon: We're getting reports that cloud-init is failing to grow disks in groovy, and I think https://launchpad.net/ubuntu/+source/util-linux/2.34-0.1ubuntu3 is what's causing the problem (fdisk is no longer installed in images); what's the intended way for cloud images to end up with fdisk installed?  Could you weigh in on https://bugs.launchpad.net/cloud-images/+bug/1876139?
[17:27] <xnox> commented on the bug too. but i don't have an immediate solution
[18:30] <rharper> the switch of /sbin to a symlink to usr/sbin  breaks dpkg -S `which <command>`  as dpkg-query output does not record both the the install path (/sbin/<pkg>) and the real location (/usr/sbin/<pkg>) ;    what package should I file a bug against?
[18:34] <sarnold> rharper: in debian it was filed against dpkg https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=134758
[18:34] <rharper> sarnold: ah, thanks.  looks like I get to hack on dpkg
[19:32] <Odd_Bloke> xnox: sil2100: We have a cloud-init user who is (still) hitting https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1874377 which I believe has just had a better fix land in groovy-proposed.  Are there plans to SRU that?  (If so, do we need a new bug for the SRU process, as that focal task is Fix Released already?)
[19:32] <Odd_Bloke> (The user is keen to help, so I'd like to point them somewhere they can watch to validate the hopefully-eventual SRU.)
[19:39] <vorlon> Odd_Bloke: whee; I think we probably need fdisk added to the server seed retroactively
[19:41] <Odd_Bloke> vorlon: Then it would end up in (lxd) container environments.  Was the original change scoped more specifically at Docker containers?
[19:42] <vorlon> Odd_Bloke: hmm
[19:43] <Odd_Bloke> "Hmm" was about where I ended up too.
[19:45] <vorlon> Odd_Bloke: I think we want it on both bare metal installs and cloud images, by default.  I think we don't particularly care about it being in lxd containers, but it's not completely unusable in lxd, you can still partition things within lxd (even if it's just for loopback files that you might not be able to mount after)
[19:47] <Odd_Bloke> Yep, I think that's reasonable.