[00:31] <RAOF> Aww, yeah. Looks like removing a couple of extensions has broken my desktop's GNOME Shell!
[00:32] <RAOF> Now, rather than taking 10s to unlock, it just immediately hits the “oh, no!” screen.
[00:38] <RAOF> Hmmmm. Because apparently removing an extension from the extensions.gnome.org interface does *not* tell GNOME Shell not to try to load it next time?!
[00:43] <RAOF> Soooo.
[00:44] <RAOF> How would I disable extensions?
[00:46] <RAOF> `dconf dump /org/gnome/shell/` shows `disable_user_extensions=true` and does not have an enabled-extensions key.
[00:58] <jamesh> gnome-shell-extension-prefs?
[01:00] <RAOF> Do I need to run that from a GNOME session?
[01:00] <jamesh> not sure
[01:06] <RAOF> Well, `gnome-extensions list` returns no output, so I *think* it thinks there are no enabled extensions…
[01:09] <RAOF> After a reboot it's *still* trying to open the non-existent extension.
[01:10] <RAOF> Oh. But `gnome-extensions` is failing with exit value 2, but no output.
[01:23] <jamesh> maybe there is some detritus in ~/.local/share/gnome-shell ?
[01:32] <kenvandine> RAOF: that isn't desirable :)
[01:32] <kenvandine> robert_ancell: meeting?
[01:32] <callmepk> Good morning
[01:33] <robert_ancell> callmepk, hello!
[01:34] <callmepk> Hi robert_ancell !
[01:37] <RAOF> Ooooh!
[01:37] <RAOF> There *was* some detritus, in `~/.local/share/gnome-shell/extension-updates`!
[01:38] <RAOF> It looks like if there's something in there, GNOME Shell will unconditionally try to load the extension from `~/.local/share/gnome-shell/extensions/`. Which didn't exist.
[01:38] <RAOF> And didn't respect any of the dconf settings.
[01:38] <RAOF> I wonder if I can reproduce that…
[01:53] <duflu> Oh hi callmepk, jamesh, RAOF, robert_ancell, kenvandine, world
[02:03] <kenvandine> good morning duflu 
[02:11] <callmepk> morning duflu 
[06:17] <seb128> good morning desktopers!
[06:21] <duflu> Morning seb128 
[06:21] <seb128> hey duflu, happy friday! how are you today?
[06:22] <duflu> seb128, going well I think. You?
[06:22] <seb128> I'm good! a bit tired but it's friday so it's ok :)
[06:22] <duflu> Life is so exciting these days I am looking forward to just leaving the house to check the mail
[06:24] <seb128> :-/
[06:25] <seb128> it's frustrating, we had grey sky and rain non stop until 10 days ago
[06:25] <seb128> and now that we are locked down it's sunny and nice every day :/
[06:25] <duflu> I have a lot of flowers in bloom and it's sunny still, so going outside is actually nice
[06:26] <duflu> Just not too far
[06:27] <seb128> that's something :)
[06:34] <didrocks> good morning
[06:36] <ricotz> good morning desktopers :)
[06:36] <ricotz> seb128, hi, regarding indicator-sound https://paste.debian.net/plain/1138187
[06:36] <duflu> Hi didrocks and ricotz 
[06:36] <seb128> lut didrocks, comment ça va ?
[06:36] <seb128> ricotz, hey! how are you? thanks for the fix!
[06:38] <didrocks> hey duflu, ricotz 
[06:38] <didrocks> salut seb128, ça va, et toi ?
[06:42] <seb128> didrocks, ça va bien :)
[06:44] <ricotz> seb128, I am good, yw
[07:02] <RAOF> duflu: Hopefully the gperftools trace in the GNOME Shell memory bug is helpful.
[07:03] <duflu> Sounds good. If there's an email about that it hasn't arrived yet
[07:03] <RAOF> Shell must do a lot of allocation, because gperftools absolutely murders its performance (like, 10 second pauses everywhere, minute-long login-times, and such)
[07:04] <duflu> Unless you focus only on mmaps (which I recommend)
[07:04] <duflu> HEAP_PROFILE_ONLY_MMAP
[07:24] <jibel> morning all
[07:25] <didrocks> salut jibel !
[07:25] <jibel> Salut didrocks , en forme?
[07:26] <didrocks> ça va, et toi ?
[07:26] <jibel> ça va, longue veillée pour une release qui n'est jamais arrivée
[07:26] <didrocks> ouais, j’ai vu ça :/
[07:27] <jibel> et toujours pas là apparemment
[07:29] <didrocks> nope
[07:38] <oSoMoN> good morning desktoppers
[07:39] <oSoMoN> happy Friday!
[07:43] <didrocks> hey oSoMoN 
[07:45] <duflu> Hi jibel and oSoMoN 
[07:46] <jibel> Good morning duflu 
[07:49] <seb128> lut jibel, oSoMoN
[07:50] <seb128> jibel, they have issue with the image build time still? or is that another IS problem?
[07:50] <Wimpress> Morning desktoppers
[07:50] <seb128> hey Wimpress, how are you?
[07:50] <didrocks> hey Wimpress 
[07:50] <didrocks> seb128: the image is just published
[07:51] <didrocks> seems like an issue with the network when doing the massive build tests the week of a beta
[07:51] <seb128> well done d_oko!
[07:51] <Wimpress> Bit tired, but catching up on iso build status, feeling optimistic 🙂
[07:52] <oSoMoN> salut didrocks, jibel, seb128 
[07:53] <oSoMoN> hey duflu, Wimpress 
[07:57] <duflu> Morning Wimpress 
[08:01] <Laney> moin
[08:02] <didrocks> hey Laney 
[08:03] <duflu> Hi Laney
[08:05] <seb128> hey Laney, happy friday! how is it going? had another late night waiting for ISOs that didn't come or did you manage to call it a day on time yesterday?
[08:05] <Laney> hey duflu didrocks seb128 
[08:05] <Laney> no I was online until 00:15
[08:06] <Laney> when we figured out it wasn't going to finish and decided to delay
[08:06] <seb128> :-(
[08:07] <Laney> yeah was hoping to do some other stuff today
[08:07] <Laney> but I guess not really likely now
[08:07] <Laney> oh well :p
[08:19] <oSoMoN> morning Laney 
[08:32] <marcustomlinson> morning all
[08:32] <didrocks> hey marcustomlinson 
[08:35] <Laney> hey oSoMoN marcustomlinson 
[08:49] <seb128> hey marcustomlinson, how are you?
[08:50] <marcustomlinson> seb128: tired :P but that comes with having a newborn
[08:50] <marcustomlinson> how you today?
[08:50] <seb128> indeed!
[08:51] <seb128> a bit tired as well, for me it comes from school being closed and tried to work done at the same time, proove to be challenging!
[08:52] <seb128> trying*
[08:56] <marcustomlinson> hear, hear
[08:59] <duflu> Morning marcustomlinson 
[09:00] <duflu> seb128, good news: nvidia-440 does support full plymouth graphics. Just not at initrd time. And for a new reason different to the ThinkPads
[09:01] <seb128> duflu, ah, nice! what's the reason?
[09:01] <duflu> Wish I knew
[09:02] <duflu> Nvidia keeps the kernel's efifb around and it works perfectly in testing. Just not when we want it
[09:03] <duflu> Also the Nvidia driver does not VT switch reliably, so the lack of shutdown splash is a different issue
[09:04] <seb128> I should get a nvidia machine at some point, would help testing & debugging things
[09:05] <duflu> Seems to be a common sore point in the land of Ubuntu
[09:06] <duflu> That's the main reason I still use desktops, so I can switch cards without switching machines
[09:14] <xnox> du
[09:14] <xnox> duflu: oooh. I have nvidia card.
[09:15] <duflu> xnox, any help is welcome then: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/103
[09:15] <duflu> Confusing numbers
[09:15] <xnox> duflu: "not at initrd time" how come? Surely we can do that on installer systems. Due to legal reasons, cannot do it on install media.
[09:16] <duflu> xnox: This is an *installed* system
[09:16] <duflu> Not installer related
[09:17] <xnox> Ack!
[09:56] <duflu> xnox, I don't support initrd is missing renderers/frame-buffer.so
[09:56] <duflu> ?
[09:56] <duflu> *suppose*
[09:56] <duflu> I don't suppose
[09:58] <xnox> duflu: we might have magic to force framebuffer off on Nvidia "cause it doesn't work"?!
[09:58] <xnox> In the initrd.
[09:58] <duflu> xnox, it does work after booting. Initrd never even tries it
[09:58] <duflu> It doesn't load the renderer
[09:58] <xnox> Ack. Most likely initramfs-tools bug that like blacklists framebuffer support.
[10:40] <xnox> duflu:  so, bgrt booting on bios
[10:41] <xnox> duflu:  can bgrt realiaze that there is no EFI oem logo? and can we have a stock vendor logo to show on the top? cause boot looks unbalanced with all that black space empty
[10:42] <xnox> i wonder if we can ship lenovo/dell/asus/acer logos for use in bios boot
[10:42] <xnox> horum
[10:43] <duflu> xnox, Oh I just closed that bug because I thought the Ubuntu logo is enough in that case
[10:44] <duflu> And if it bothers people, disabling legacy boot and CSM might give you back your bgrt, like my ThinkPad
[10:44] <duflu> I think black is best in that case though. Otherwise the user gets 3 logos, not just 2
[10:45] <xnox> duflu:  can you point me at the bug again?
[10:45] <duflu> ...
[10:45] <xnox> duflu:  re fsckd => i think you did everything right, and i fixed casper, and now it is pretty https://people.canonical.com/~xnox/casper-win.png
[10:45] <xnox> this is how it looks when booted under bios
[10:46] <duflu> xnox, bug 1837519
[10:46] <duflu> Oh, bigger font size?
[10:46] <Wimpress> I am on nvidia only here. Plymouth appears to working correctly.
[10:46] <duflu> Hmm
[10:46] <Wimpress> Albeit, the wrong resolution.
[10:47] <duflu> Wimpress, nvidia-440 driver?
[10:47] <Wimpress> Can't confirm the remove media prompt. But I will test a full install on another nvidia only system.
[10:47] <duflu> Nevermind I am making progress, but it's getting too late for this week
[10:47] <Wimpress> duflu: Yes 440.
[10:48] <duflu> Wimpress, yeah I know it can work because mine does after boot. Just something weird going on on my desktop
[10:48] <xnox> Wimpress:  "remove media prompt" => you are testing installer right? we are talking about post-install-booted-system plymouth not working on boot.
[10:48] <duflu> Wimpress, I verified that fix a few days ago
[10:48] <xnox> Wimpress:  installer does not use nvidia graphics, because it legally cannot.
[10:48] <duflu> it is fixed in 20200331 onward
[10:48]  * xnox is possibly confused.
[10:48] <Wimpress> Yes, I am also talking about post-install system.
[10:48] <xnox> oh, ok.
[10:48]  * xnox is confused
[10:48] <xnox> nevermind and carry on
[10:49] <Wimpress> But will do a full install test on an nvidia system later.
[10:49] <xnox> duflu:  I somehow feel we need a fallback OEM graphic, like canonical circle logo
[10:49] <xnox> (i.e. just as big as dell logo is)
[10:50] <duflu> xnox, I wouldn't because that's too many visual changes.
[10:50] <duflu> Not just because it's Friday night
[10:52] <xnox> duflu:  i wonder, if we can fix qemu firmware to ship SeaBIOS logo that works in BIOS boot in VM =)
[10:54] <duflu> It might be a problem with the structure of the bgrt, or it might be the BIOS hiding BGRT in non-pure-EFI boot modes
[10:54] <duflu> And good night
[10:54] <xnox> night!
[10:55] <duflu> Either way, we can hack SeaBIOS
[10:55] <xnox> and tianocore logo needs to improve
[10:55] <duflu> Yeah
[10:55] <duflu> Bye
[13:20] <KGB-0> gnome-shell debian/master Simon McVittie * [merge] merge request !37: WIP: 3.36.1 * https://deb.li/PVai
[13:21] <KGB-0> mutter debian/master Simon McVittie * [merge] merge request !58: WIP: 3.36.1 * https://deb.li/3cOHh
[13:27]  * Laney melts into a puddle
[13:27] <Laney> beta finally done
[13:34]  * marcustomlinson hands Laney a beer
[13:44] <Laney> thanks marcustomlinson, much required
[14:03] <hellsworth> good morning desktopers
[14:03] <marcustomlinson> hey hellsworth
[14:03] <oSoMoN> hey hellsworth 
[14:03] <kenvandine> good morning hellsworth 
[14:03] <hellsworth> hi yall
[14:04] <hellsworth> kenvandine: should i join the code and sysinternal snap meetings toay?
[14:05] <didrocks> hey hellsworth, kenvandine 
[14:06] <marcustomlinson> also hey kenvandine
[14:06] <kenvandine> feeling the love :)