=== dax is now known as housecat
=== helio|afk is now known as heliocastro
[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 :/
=== Woodpecker is now known as Guest806
[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:38] <ubottu> Launchpad bug 1876083 in snapd "chromium snap from focal fails DNS lookups, or delays them" [Undecided,New] https://launchpad.net/bugs/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
=== ijohnson is now known as ijohnson|lunch
[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:14] <ubottu> Launchpad bug 1876139 in cloud-init "Groovy cloud-images failing during growpart" [Undecided,Incomplete]
[17:27] <xnox> commented on the bug too. but i don't have an immediate solution
=== ijohnson|lunch is now known as ijohnson
[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] <ubottu> Debian bug 134758 in dpkg "dpkg-query: Make -S handle unowned symlinks resolving to owned pathnames" [Wishlist,Open]
[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] <ubottu> Launchpad bug 1874377 in netplan.io (Ubuntu Focal) "Netplan does not connect to Wireless after `sudo netplan apply` until reboot" [High,Fix released]
[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.