=== guiverc2 is now known as guiverc
[06:08] <seb128> goood morning desktopers!
[06:32] <luna_> morning
[06:35] <duflu> Hi seb128 and luna_ 
[08:02] <Laney> guten morgen!
[08:02] <jibel> cpaelzer_, is there anything in latest libvirtd in groovy that could affect networking? I'm trying to figure out why suddenly I've no network inside the guest.
[08:03] <jibel> the guest is a focal live session with daily from yesterday
[08:06] <duflu> Hi Laney
[08:15] <Laney> moin duflu 
[08:30] <seb128> hey duflu, Laney, jibel, how are you in a summer day?
[08:31] <duflu> seb128, it's winter but sunny. How are you?
[08:33] <seb128> duflu, I'm alright, hopefully having a 'normal' work day today and I can get some work done, though it's going to be over 30°C and melting in front of the keyboard sucks a bit
[08:33] <seb128> we have extra heat until tomorrow and then rain over the weekend :/
[08:33] <duflu> To be fair, a month into winter and we're only now below 20 degrees so it's OK
[08:35] <jibel> seb128, going well.enjoying the beach on the evening
[08:41] <seb128> jibel, :-)
[08:42] <duflu> jibel is winning June
[08:45] <Laney> moin seb128 
[08:45] <Laney> bit sad that all the nice days are during work time and then the weekend sucks
[08:46] <seb128> indeed :/
[08:48]  * Laney does the 'rm fontconfig cache' trick to get emojis back in Chromium
[08:48] <Laney> why did I switch to Chromium like a month ago? I can't even remember any more, might go back to the nice Firefox deb :>
[08:52] <Laney> dear chromium, please exit when I exit you
[08:52] <seb128> Laney, if I understand that bug correctly it's snapd screwing the font cache which breaks deb apps as well (but maybe firefox doesn't rely on fontconfig for emoji?)
[08:53] <seb128> unless you do purge snapd along chromium which would fix the problem on your system
[08:54] <Laney> I never saw broken colour emoji anywhere else
[08:54] <Laney> but actually purging the cache didn't fix it in chromium either
[08:54] <Laney> 🤷
[08:54] <Laney> (^- that one is coloured for me)
[08:54] <seb128> callmepk, hey, you mentioned you had wslu SRUs waiting for sponsoring, do you have merge requests for packages for those?
[08:55] <Laney> Firefox works
[08:55] <seb128> Laney, I was commented based on https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1858636/comments/31 also the noto-color-emoji is missing from the fontcache
[08:55] <ubot5> Ubuntu bug 1858636 in snapd (Ubuntu) "snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium" [High,Confirmed]
[08:55] <seb128> so I don't understand why it doesn't impact e.g gnome-characters
[08:55] <Laney> maybe I have a different problem then
[08:56] <seb128> speaking of that bug
[08:56] <seb128> jamesh, ^ the snapd team bounced back to us, could you maybe help and reply to some of the questions for Ian on the bug?
[08:57]  * jamesh looks
[08:59] <seb128> jamesh, start reading at comment 37
[09:00] <seb128> before it's noise of users and triager trying to understand what's going on and how to trigger the issue
[09:15] <jamesh> seb128: I suspect the problem is down to freetype versions: I think snapd is running bionic's version of fc-cache statically linked against xenial's freetype
[09:16] <seb128> :/
[09:16] <seb128> why are they not using versions from the same serie?
[09:17] <seb128> also any easy way to confirm that? would be nice if snaps logged the fc-cache output
[09:17] <jamesh> it's trying to build binaries that will run against the core snap's libraries
[09:17] <jamesh> I think they assumed the cache differences were only down to fontconfig versions
[09:18] <jamesh> I've got a general idea about how we can handle this better with private fontconfig caches for snaps, but haven't built the prototype yet
[09:18] <seb128> k
[09:19] <jamesh> this would be roughly one cache for each gnome platform snap we publish
[09:19] <seb128> jamesh, thanks, that's useful input ... can you comment that on the bug?
[09:19] <jamesh> I'm writing the comment now
[09:19] <seb128> great
[09:19] <seb128> thx again!
[09:19] <seb128> Trevinho, did you notice that the bionic SRU for bug #1793496 failed to build?
[09:19] <ubot5> bug 1793496 in Mutter "scaling changes when closing/re-opening the lid" [Undecided,New] https://launchpad.net/bugs/1793496
[09:20] <seb128> not only that bug, it's just the one reference, but that's the update to a git snapshot you did
[09:32] <jibel> Laney, is there a way to simulate an rst drive in a vm?
[09:32] <jibel> I want to test the rst code of the installer
[09:34] <seb128> jibel, ubiquity/plugins/ubi-prepare.py:        return os.environ.get('SHOW_RST_UI', '0') == '1'
[09:34] <seb128> try setting that env maybe?
[09:35] <seb128> well, depends if you just want to see the page or actually test the detection of the disk I guess
[09:36] <jibel> sounds like what I need. I'll have a look. However I want an RST drive and another that is not to verify that you can install on the second drive even if the first is bitlocker'd
[09:37] <jibel> otherwise I'll play with the code a bit
[09:41] <Laney> jibel: not that I know of, no
[09:42] <Laney> Hack the detection code to return true for one of the drives or something
[09:43] <jibel> yeah, i'll do that
[09:43] <jibel> not really sru'ish but well...
[09:46] <Laney> ah for testing instructions?
[09:46] <Laney> maybe having an env var to do that would be good
[09:47] <Laney> UBIQUITY_PRETEND_DRIVE_IS_RST=...
[09:59] <ricotz> good morning desktopers!
[10:00] <ricotz> seb128, hi :), could you process https://launchpad.net/ubuntu/+source/nodejs/12.18.0~dfsg-3ubuntu1 which is in NEW
[10:10] <seb128> ricotz, hey ricotz, k
[10:12] <ricotz> seb128, thank you
[10:12] <seb128> yw!
[10:47] <seb128> ricotz, bug #1885006 is something for you or for Olivier when he's back?
[10:47] <ubot5> bug 1885006 in firefox (Ubuntu) "Search Service broken on Ubuntu Nightly builds" [Undecided,Confirmed] https://launchpad.net/bugs/1885006
[10:52] <ricotz> seb128, thanks, this looks like an issue for both of us which would hit firefox 79 beta
[10:53] <seb128> ricotz, I will drop an email to Olivier so he saws it once he's back
[11:08] <ricotz> seb128, looks like a simple variable rename of upstream, so an easy fix
[11:08] <seb128> ricotz, great!
[11:09] <seb128> ricotz, do you have an easy way to flag that to Olivier or should I better drop him an email as a FYI?
[11:10] <ricotz> I can leave a comment in the bug report point to the fix
[11:11] <seb128> ricotz, thx
[11:32] <seb128> Laney, did you see the discussion on #debian-gnome about our geoclue delta the other day? do you have any opinion on that?
[11:32] <seb128> I'm pondering just dropping the delta and syncing back
[11:32] <Laney> seb128: I did but it seemed Simon handled it with you so I didn't think about it much
[11:33] <Laney> let me see what the delta is
[11:33] <seb128> Laney, it's making the lib depends on the service
[11:34] <Laney> this is something from me from a few years ago
[11:35] <Laney> did bigon say anything about adding it?
[11:36] <Laney> I think it still makes sense, but it could maybe be a recommends as most apps which use geoclue can work ok without it
[11:36] <Laney> that amazon launcher probably should have been made to not crash
[11:36] <Laney> ah I forgot bigon is in here :>
[11:40] <seb128> Laney, we discussed on #debian-gnome if you have the backlog of 2 days ago (iirc) but summary is that him and Simon think it's better to let the apps that need the service recommends/depends on it
[11:40] <seb128> Simon's argument was that most GNOME components that links again the lib don't really need the service
[11:41] <seb128> e.g calendar, initial setup, settings-daemon
[11:41] <Laney> the way I read that conversation they both mentioned recommends
[11:42] <seb128> from the lib to the service?
[11:42] <Laney> yes
[11:42] <seb128>  <smcv>	seb128: in cases like libdbus-1-3 Recommends dbus, we still get occasional complaints about "installing $app pulled in $service, this is GNOME bloat"
[11:42] <seb128> so yeah, that discussion has argument for ang against the recommends 
[11:43] <Laney> but libdbus still does have that recommends so ...
[11:43] <seb128> it feels like we failed to have a conclusion at the end, I will ask bigon again
[11:43] <Laney> that was a mention of what sometimes happens
[11:43] <seb128> well just did I guess :p
[11:43] <seb128> right
[11:45] <seb128> Laney, thx, I try another round to see if the recommends could be added in Debian
[11:46] <Laney> silly non team maintained packages!
[11:46] <Laney> I would have done something about it in 2017 otherwise :p
[11:46] <seb128> :-)
[11:53] <bigon> for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834176 I think I will close it as wontfix, there is no reason that the -dev pkg needs the daemon
[11:53] <ubot5> Debian bug 834176 in libgeoclue-2-dev "libgeoclue-2-dev should depend on package geoclue-2.0" [Normal,Open]
[11:54] <bigon> for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864305, I guess a patch that conditionally add the Depends/Recommends for ubuntu is fine as a 1st step
[11:54] <ubot5> Debian bug 864305 in libgeoclue-2-0 "libgeoclue-2-0 doesn't depend on geoclue-2.0" [Normal,Open]
[11:54] <bigon> was the m-a co-instability evalatuated?
[11:54] <bigon> TBH I'm way more annoyed by https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/111 not being fixed
[11:55] <Laney> geoclue-2.0 should be foreign probably
[12:19] <ricotz> is someone able to do a simple runtime test of a firefox build on s390x?
[12:21] <ricotz> https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+build/19506686/+files/firefox-trunk_79.0~a1~hg20200625r537255-0ubuntu0.20.04.1~umd3_s390x.deb
[12:28] <seb128> bigon, right, that upstream issue is annoying :/ also I got no traction when I asked on our side about the BTS bug
[12:30] <bigon> Zeeshan said he will fix it "soon" but he's not opposed if somebody is doing it https://gitlab.freedesktop.org/geoclue/geoclue/-/merge_requests/70#note_528935
[12:30] <seb128> take over :)
[12:33] <seb128> ricotz, it starts fine, compared to the archive version that segfaults
[12:34] <ricotz> seb128, that is quite something then :)
[12:36] <seb128> :-)
[12:57] <jibel> xnox, I'm verifying bug 1847898. I created a VM in legacy mode with 3 disks and selected to install on vdc. grub-install runs on the /dev/vdc. 
[12:57] <ubot5> bug 1847898 in ubiquity (Ubuntu Focal) "System doesn't boot after installation - Legacy mode / 2 disks" [High,Fix committed] https://launchpad.net/bugs/1847898
[12:57] <jibel> But after installation the machine doesn't find a bootable device.
[12:57] <jibel> xnox, my test case is correct? 
[12:57] <jibel> is there any information I should dig for?
[12:57] <jibel> ah actually wait 
[12:58] <jibel> hm, to make it boot I've to set disk3 as the first bootable device
[12:59] <jibel> not sure it's specific to VMs
[12:59] <jibel> ^ WDYT?
[14:05] <xnox> jibel:  what is the drive order set in like libvirt / virsh / qemu command line?
[14:05] <xnox> jibel:  or like can you ask to bring up the boot menu, and select the third drive, it then should boot fine.
[14:06] <xnox> jibel:  multi-disk selection in bios is a bit unpredictable.
[14:06] <xnox> jibel:  unlike UEFI where  we create ubuntu entry, and order it to be first, even though it's disk3 install.
[14:06] <jibel> xnox, yes, it boots fine when I changed the drive order. It's more a pb with libvirt/qemu which didn't try all the available drives
[14:07] <xnox> jibel:  it does, if one passes more options to it.
[14:07] <xnox> jibel:  i use virt-manager, and i can tick which drives to try, and in which order. I think there are qemu cmdline options / xml for that too
[14:08] <xnox> jibel:  <boot order="1"/> inside the <disk></disk in xml
[14:08] <xnox> and let me check qemu cmdline options
[14:09] <xnox> jibel:  ,bootindex=2 on the -device .... stanza
[14:09] <xnox> then it will try them all, in the defined order.
[14:09] <xnox> jibel:  but grub-install matches the selected drive means we did the right thing!
[14:12] <jibel> indeed
[14:24] <jibel> 5.6 didn't improve my sound issues. I keep losing hdmi output and all that remains are dummy entries
[14:53] <ricotz> seb128, please don't forget about https://launchpad.net/ubuntu/+source/nodejs/12.18.0~dfsg-3ubuntu1
[14:54] <ricotz> (it is a required build-dep for firefox 78+)
[14:56] <seb128> ricotz, I know, Olivier asked me to get it uploaded before his holidays, I did the nagging and LocustusOfBorg uploaded
[14:57] <ricotz> seb128, ok, I thought you are on ArchiveAdmin duty today
[14:58] <seb128> ricotz, I'm not really doing archive days but I'm happy to process pings between other things
[14:59] <seb128> ricotz, binaries accepted now
[14:59] <ricotz> I see, thanks!
[14:59] <seb128> yw!
[14:59] <ricotz> maybe tweak this a bit - https://wiki.ubuntu.com/ArchiveAdministration#Archive_days
[15:24] <seb128> ricotz, it has a warning 'Warning /!\ This is currently being re-assessed to a more task oriented approach, rather than regular admin days. '
[15:24] <seb128> but yeah
=== ijohnson is now known as ijohnson|lunch
[17:17] <Laney> see you monday!
[17:28] <luna_> Rolling Rhino :D
=== ijohnson|lunch is now known as ijohnson
[22:37] <callmepk> seb128 I create a MR for wslu to fix the build issue, tested on 1804 and the build should work now