=== Class7_ is now known as Class7
[07:33] <didrocks> good morning
[07:37] <duflu> Hey didrocks
[07:37] <didrocks> hey duflu
[07:43] <duflu> RAOF: Would egl-wayland have to start in universe even if we need it in main?
[07:43] <duflu> It's not in either yet. Just wondering
[07:44] <RAOF> Nah, but it does need a MIR done.
[07:44] <duflu> Well, I'll test it when it's uploaded. In the least another mutter patch is required to depend on it
[08:02] <tjaalton> duflu: it's uploaded but needs an AA to review from NEW
[08:02] <duflu> tjaalton, no problem, thanks
[08:02] <duflu> Not in a hurry
=== pstolowski|afk is now known as pstolowski
[08:38] <RAOF> tjaalton: how are you dealing with the file conflicts with the NVIDIA driver?
[08:39] <duflu> RAOF: Which bug do you mean? Once such fix went into nvidia-410 yesterday
[08:50] <tjaalton> RAOF: I'm not, yet
[08:50] <tjaalton> the debian upload got rejected because of those
[08:50] <tjaalton> discussing it with anbe
[08:51] <tjaalton> need to add conflicts for the ubuntu packages too
[08:52] <tjaalton> tseliot: please drop libnvidia-egl-wayland.so.* from libnvidia-gl-*
[08:52] <tjaalton> 390 and up
[08:59] <tseliot> tjaalton: in disco?
[09:00] <tjaalton> yes
[09:00] <tseliot> ok
[09:00] <tjaalton> but since it's not used anywhere, feel free to drop it universally
[09:01] <tseliot> tjaalton: what do you use for wayland then?
[09:01] <seb128> good morning desktopers
[09:01] <didrocks> hey seb128
[09:01] <seb128> hey didrocks :)
[09:02] <Laney> morning!!!!
[09:04] <seb128> hey Laney! how are you?
[09:08] <Laney> hey seb128
[09:09] <Laney> I'm doing alright!
[09:09] <Laney> was listening to people singing christmas songs last night
[09:09] <seb128> nice
[09:09] <Laney> getting in the mood
[09:09] <Laney> or something...
[09:09] <Laney> you?
[09:10] <tjaalton> tseliot: the binary & headers from egl-wayland
[09:10] <tjaalton> which is a new package
[09:10] <seb128> here is was sinterklaas (Sint-Nicolaas) yesterday, which is the dutch traditional-big-events
[09:10] <seb128> it's when kids gets presents, etc
[09:10] <tjaalton> tseliot: right now you can't use it, since the nvidia blob doesn't come with the headers
[09:10] <tjaalton> aiui
[09:11] <seb128> we had a nice diner to celebrate and the kid got some new books, he seemed to like it :)
[09:11] <didrocks> hey Laney
[09:12] <Laney> nice
[09:13] <Laney> hey didrocks
[09:13] <Laney> what's new?
[09:13] <didrocks> nothing much, looking for the sun here
[09:13] <didrocks> you?
[09:13] <didrocks> not*
[09:14] <Laney> no sun
[09:14] <Laney> a nice comforting grey blanket
[09:15] <didrocks> yeah, same here
[09:15] <seb128> ditto
[09:16] <seb128> oh, btw Will said he was feeling unwell cold/didn't sleep well/headaches so he's staying in bed a bit this morning and should be online later
[09:19]  * Laney sends vegetables
[09:20]  * seb128 sends soup
[09:21]  * didrocks sends some alcohol
[09:22] <Laney> sounds like a good care package
[09:22]  * Laney sends in the screaming children
[09:23] <didrocks> ahah
[09:39] <tseliot> tjaalton: ok
[09:48] <tseliot> tjaalton: so, no /usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json either, right? Since it the contents point to "library_path" : "libnvidia-egl-wayland.so.1"
[10:02] <willcooke> morning all
[10:03] <didrocks> hey willcooke, feeling better?
[10:04] <willcooke> hi didrocks, yeah a bit, got some more sleep and then started reading email so I figured I might as well do it properly :)
[10:04] <willcooke> No point lying in bed on my phone
[10:06] <tjaalton> tseliot: right
[10:12] <seb128> hey willcooke
[10:21] <tseliot> tjaalton: should the nvidia packages recommend egl-wayland (libnvidia-egl-wayland1)?
[10:22] <tjaalton> tseliot: no, the shell will
[10:22] <tseliot> tjaalton: great
[10:22] <tjaalton> depend on it
[10:22] <tjaalton> once the support is there
[10:25] <tseliot> right
[11:03]  * Laney sux at nm
[12:26] <Laney> jbicha: I saw https://gitlab.gnome.org/GNOME/gnome-desktop/issues/89 - are you planning to work on it?
[12:26] <gitbot> GNOME issue 89 in gnome-desktop "bwrap invocation breaks thumbnail creation on 32-bit systems" [Opened]
[12:29] <jbicha> Laney: I think I'd prefer to hand it off to you if you have time to work on it
[12:39] <Laney> guess so
[12:39] <seb128> jbicha, is that launchpad bug private/security?
[12:41] <Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1807127 that's the one I saw
[12:41] <ubot5> Ubuntu bug 1807127 in gnome-desktop3 (Ubuntu) "Fixing bug #1795668 breaks thumbnail creation on 32-bit Ubuntu" [Undecided,New]
[12:49] <jbicha> sorry, fixed my link now
[14:01] <tseliot> tjaalton: the changes for 390 and 410 are in disco-proposed
[14:06] <seb128> tseliot, is the changelog really different between the archs? or is that a bug in gzip or something producing different results using a same content?
[14:08] <tseliot> seb128: I'm not sure what caused the problem, since the same source works in cosmic and older. I am not sure why the symlinking is causing problems in disco
[14:09] <tseliot> seb128: I also think that, since only some packages are available on i386 vs amd64, the symlinking happens in packages on amd64 where it doesn't on i386. I think this is the problem
[14:10] <seb128> could be
[14:11] <tseliot> either way, I don't think it's a big tradeoff
[14:11] <seb128> no, it's just that if there is a real bug at the gzip level we should fix it
[14:12] <seb128> but gzip didn't change in disco yet, so probably not the case
[14:12] <tseliot> yes, but I think we would have noticed it with other packages. Having multiarch with limited i386 support is a little unusual
[14:12] <tseliot> right
[14:27] <kenvandine> seb128: https://bugs.launchpad.net/ubuntu/+source/xrdp/+bug/1749148
[14:27] <ubot5> Ubuntu bug 1749148 in xrdp (Ubuntu) "[MIR] xrdp" [High,Incomplete]
[14:31] <seb128> kenvandine, thx
[14:36] <tjaalton> tseliot: cool, thanks
[14:45] <tseliot> :)
[14:51] <seb128> shrug, libreoffice fails to build on ppc64el with "/<<PKGBUILDDIR>>/config_host.mk:83: *** missing separator.  Stop." now :/
[14:59] <cyphermox> Laney: so, I finally got to have a look at the NM autopkgtests failing with the new dnsmasq
[14:59] <cyphermox> I think that's actually bringing out a real bug in NM's ndisc handling
[15:00] <cyphermox> plus there are lots of ndisc changes and 1.12.6 was released a few days ago
[15:00] <cyphermox> perhaps the best thing to try would be to update to 1.12.6 and see if it likes the tests better
[15:01] <cyphermox> http://paste.ubuntu.com/p/dYXKfwCkZ9/
[15:06] <seb128> hum
[15:06] <seb128> my g-s-d cosmic SRU fails to build on armhf/arm64 (https://launchpadlibrarian.net/400457646/buildlog_ubuntu-cosmic-arm64.gnome-settings-daemon_3.30.1.2-1ubuntu3_BUILDING.txt.gz) by failing to install mutter
[15:07] <seb128> unsure how/where to debug that, does anyone has an idea?
[15:33] <Laney> cyphermox: k, I don't have any idea what ndisc is, feel free to take over the bug please :-)
[15:33] <Laney> it does reproduce properly in a cloud VM so you can verify that it fixes it locally
[15:34] <seb128> cyphermox, Laney, I can do the n-m update in the next days if you want
[15:35]  * Laney thought cyphermox was offering to do it but that might be wishful thinking :P
[15:36] <seb128> :)
[15:37] <seb128> Laney, any idea about that g-s-d build issue btw?
[15:37] <Laney> how to reproduce?
[15:37] <Laney> I would use a chdist for that normally
[15:37] <Laney> if you have snakefruit access there's a handy thing on there to do it
[15:38] <seb128> seems like I have
[15:38] <seb128> I've tried on the porter box
[15:38] <Laney> ubuntu-archive/bin/chdist apt-get cosmic-proposed-armhf --dry-run install mutter
[15:38] <seb128> Laney, it's not a "build failure" by itself, just packages not installable in proposed for some reason (https://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.30.1.2-1ubuntu3)
[15:38] <Laney> oops
[15:38] <Laney> ~ubuntu-archive/bin/chdist apt-get cosmic-proposed-armhf --dry-run install mutter
[15:38] <Laney> yeah
[15:38] <Laney> this is to check like package installability and stuff
[15:38] <seb128> ah, I didn't know about that
[15:38] <seb128> great
[15:38] <seb128> thx
[15:39] <Laney> otherwise, for everybody else, you can make those things on your system too
[15:39] <seb128>  mutter : Depends: gnome-settings-daemon but it is not going to be installed
[15:40] <seb128> shrug
[15:40] <seb128>  gnome-settings-daemon : Depends: gnome-settings-daemon-schemas (= 3.30.1.2-1ubuntu2) but 3.30.1.2-1ubuntu3 is to be installed
[15:40] <Laney> circular dep?
[15:40] <seb128> looks like it
[15:40] <seb128> unsure why that hasn't been an issue before/how to fix it (and why it impacts only armhf/arm64 and not !amd64)
[15:41] <Laney> interesting
[15:41] <cyphermox> Laney: sorry, I don't really have the time for it... already it took me days to get to run autopkgtest to debug it
[15:42] <Laney> probably they got built before amd64 was published
[15:42] <Laney> k
[15:42] <cyphermox> also, it's just a hunch, but the syslog messages look a lot like an endless loop trying to do ndisc stuff
[15:42] <Laney> what is ndisc?
[15:43] <cyphermox> it's the general network discovery code paths, a short way to say IPv6 magic to make sure the address you pick is fine to use and all of that
[15:45] <Laney> i see
[15:46] <seb128> Laney, cyphermox, k, let me do the update and see if that helps
[15:53] <Laney> merci
[15:53] <seb128> de rien
[15:54] <seb128> unsure what I can do about that g-s-d issue and why it's only an issue now in that SRU? it sounds like it should have it any build before that was slower than amd64?
[15:56] <Laney> it'd have to be built and published on amd64 before being picked up on the failing arch
[15:57] <Laney> that's probably quite unusual
[15:57] <Laney> how can we fix this circular issue though...
[15:59] <seb128> yeah, unsure why the g-s-d b-d on mutter is there?
[15:59] <seb128> is that for the tests?
[16:02] <seb128> yeah, looks like it
[16:03] <seb128> hum
[16:06] <kenvandine> sergiusens: i've determined this is a regression in snapcraft.  With 3.0.1 it pulls in meson from the archive.  I have a locally built snap of snapcraft from a few weeks back that does fetch meson directly.  I'm going to try to bisect this to see where the regression was introduced.
[16:07] <kenvandine> sergiusens: i'll file a bug
[16:16] <Laney> seb128: probably if mutter depended on the schemas instead it would be ok
[16:16] <Laney> maybe we should even do that split in debian for this reason
[16:17] <seb128> right, that makes sense
[16:17] <Laney> it's still circular but the = ${source:Version} part wouldn't be there
=== pstolowski is now known as pstolowski|afk
[17:50] <kenvandine> sergiusens: sigh... the only scenario where it wouldn't pull meson in via pip is if base isn't set
[17:50] <kenvandine> but base is set! and the same yaml builds fine with my local build of snapcraft
[18:43] <willcooke> night all
[19:26] <tkamppeter> kenvandine, hi