/srv/irclogs.ubuntu.com/2020/04/30/#ubuntu-devel.txt

=== dax is now known as housecat
=== helio|afk is now known as heliocastro
seb128ddstreet, 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 :/08:12
=== Woodpecker is now known as Guest806
RikMillsdoko: same for our toolchain now? https://lintian.debian.org/tags/debian-rules-uses-as-needed-linker-flag.html10:36
Unit193Been that way for Ubuntu for much longer.10:42
cjwatsonnatty or thereabouts I think10:44
cjwatsonhttps://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition   yes10:44
Unit193I don't have very lucid memories of it.10:44
cjwatsonthank you10:45
cjwatsonhttps://www.youtube.com/watch?v=8eXj97stbG810:45
RikMillsUnit193: I had thought so, but made me wonder!10:46
RikMillsjust wanted to make sure before I started merging changes where that option was dropped from rules10:46
Unit193(I'm sorry)  The unfortunate part for Debian is that buster doesn't, so anything destined for buster-backports...10:48
* RikMills shrugs10:50
ddstreetseb128 yep i'll upload to groovy, i was hoping it would make it to focal before the groovy copy11:07
ddstreetseb128 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 beyond11:59
xnoxdoko:  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=snap12:30
xnoxdoko:  i guess snappy / jdstrand might need to be involved to adjust policies12:30
xnoxdoko:  open a bug & also mark it as affecting snappy project?12:30
jdstranddoko: oh, zyga actually has a pr up for that12:31
* jdstrand finds it12:31
zygahmm?12:31
zygajdstrand: the docs stuff?12:31
jdstranddoko: https://github.com/snapcore/snapd/pull/857812:31
jdstrandzyga: yeah12:31
zygawe are going through failing tests and fixing some infra issues12:32
zygabut this passes12:32
jdstranddoko: once that is committed, chromium (cc oSoMoN) can plugs it and you should be good to go12:32
zygajdstrand: I'll reach out to advocacy after it lands12:32
zygajdstrand: so that all the browsers get it12:32
zygajdstrand: and that probably circles back to you for declarations12:33
jdstrandzyga: sounds like a plan12:33
jdstrandyep12:33
jdstrandzyga: thanks for doing it btw12:33
zyga:)12:33
oSoMoNnice one, looking forward to it landing12:33
dokojdstrand: thanks, but now I'm facing LP: #187608312:38
ubottuLaunchpad bug 1876083 in snapd "chromium snap from focal fails DNS lookups, or delays them" [Undecided,New] https://launchpad.net/bugs/187608312:38
jdstranddoko: I think oSoMoN will do the initial triage and followups and pull me in as needed12:39
zygadoko, jdstrand: I had a look but I lack ipv6 (nobody provides that here) and I can only guess12:39
oSoMoNdoko, could you by any chance test the google chrome deb to see if it's similarly affected?12:41
xnoxdoko:  oSoMoN:  i have google chrome deb as the default browser here. If you need i can test things.15:16
seb128ddstreet, sorry you are right, I misread the SRU comment, it's the systemd/ppc64el test failing15:16
dokoxnox: well, if you see DNS timeouts in chromium, then you can help15:16
xnoxdoko:  are you ipv6 native, with dns6to4? or like is local network dual stack?15:17
xnoxdoko:  can I see `resolvectl`  on paste.canonical.com ?15:17
dokoxnox: https://paste.ubuntu.com/p/553cMPqx69/15:18
xnoxthat look sgood15:22
xnoxdoko:  do you time out on public network resolutions or things on local network, ie.. stuff in fritz.box domain?15:23
xnoxalso 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:24
dokoxnox: no, public ones, and not only lp or ubuntu domains15:32
xnoxdoko:  interesting16:44
=== ijohnson is now known as ijohnson|lunch
Odd_Blokevorlon: 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
ubottuLaunchpad bug 1876139 in cloud-init "Groovy cloud-images failing during growpart" [Undecided,Incomplete]17:14
xnoxcommented on the bug too. but i don't have an immediate solution17:27
=== ijohnson|lunch is now known as ijohnson
rharperthe 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:30
sarnoldrharper: in debian it was filed against dpkg https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=13475818:34
ubottuDebian bug 134758 in dpkg "dpkg-query: Make -S handle unowned symlinks resolving to owned pathnames" [Wishlist,Open]18:34
rharpersarnold: ah, thanks.  looks like I get to hack on dpkg18:34
Odd_Blokexnox: 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
ubottuLaunchpad 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:32
vorlonOdd_Bloke: whee; I think we probably need fdisk added to the server seed retroactively19:39
Odd_Blokevorlon: Then it would end up in (lxd) container environments.  Was the original change scoped more specifically at Docker containers?19:41
vorlonOdd_Bloke: hmm19:42
Odd_Bloke"Hmm" was about where I ended up too.19:43
vorlonOdd_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:45
Odd_BlokeYep, I think that's reasonable.19:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!