[05:30] <didrocks> good morning
[05:43] <duflu> Hi didrocks 
[05:58] <didrocks> hey duflu 
[06:24] <oSoMoN> good morning desktoppers
[06:26] <didrocks> salut oSoMoN 
[06:34] <duflu> Hi oSoMoN 
[06:41] <oSoMoN> salut didrocks, hey duflu 
[08:04] <seb128> goood morning desktopers!
[08:05] <duflu> Hi seb128 
[08:06] <lissyx> oSoMoN, thanks for all the needinfo :)
[08:16] <oSoMoN> good morning seb128 
[08:54] <seb128> duflu, lissyx, oSoMoN, Hey, how are you?
[08:55] <duflu> seb128, not bad. Feel like I've made good progress and soon EOW. How are you?
[08:58] <oSoMoN> I'm doing good, thanks!
[08:58] <lissyx> seb128, at high speed on the train :)
[08:59] <oSoMoN> lissyx, I still have a few needinfo to go through, and I've just fixed the nightly builds, so I'm going to proceed with merging your debug symbols branch and do a test build
[08:59] <lissyx> oSoMoN, can't you perform a test without merging?
[08:59] <lissyx> in case there are things we need to further fix, so we dont clutter the history too much
[09:00] <lissyx> i'm tracking a bug where someone sets /dev/shm as download folder on the snap package
[09:00] <lissyx> and it's triggering EACCES on XDG Document Portal ...
[09:00] <oSoMoN> I'd need to set up another branch, another workflow, and that would end up being more clutter than testing in the nightly branch itself I think
[09:00] <lissyx> right
[09:00] <lissyx> so let's hope I forgot nothing :)
[09:01] <oSoMoN> we shall see very soon :)
[09:01] <lissyx> oSoMoN, can you also do a test run on gnome-sdk patches?
[09:01] <lissyx> or do we need kenvandine to merge before
[09:07] <seb128> lissyx, I will give a try to the gnome-sdk debug change today
[09:08] <seb128> duflu, ah, nice, on what changesets are you working atm?
[09:11] <duflu> seb128, https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/946
[09:17] <seb128> duflu, ah, great!
[09:17] <seb128> also I can't wait for the day we will replace IRC by something modern which handle disconnects and timeouts
[09:20] <seb128> duflu, do you know if adding an extension to org.gnome.shell disabled-extensions should be an ok-is way to prevent it to be loaded even if it's part of the session?
[09:21] <seb128> it's for the new desktop installer, we want to disable ding and dashtodock by default for the 'installer only' mode
[09:23] <seb128> I hacked the systemd job which start the installer to do 'gnome-extensions disable ubuntu-dock@ubuntu.com' which works but it's a bit late so the launcher displays for a second before being unloaded
[09:23] <seb128> the idea was that we would disable the extensions and re-enable them when the installer closes (which the 'try ubuntu' item would also trigger)
[09:25] <duflu> seb128, not familiar with that command but if it sets gsettings org.gnome.shell disabled-extensions ... then yes
[09:54] <luna> how to tell apt in ubuntu to not upgrade a package?
[10:09] <guiverc> luna, this isn't support, please use #ubuntu & don't post the same in multiple rooms
[10:09] <luna> ok
[10:17] <luna> oh well too lazy to fight with that now, atleast Spotify still works on FreeBSD thats what i use the compat layer/jail for
[13:11] <lissyx> seb128, oSoMoN by chance you dont know where this struct _PermissionDbEntry is defined? https://github.com/flatpak/xdg-desktop-portal/blob/main/document-portal/permission-db.h#L32
[13:16] <oSoMoN> lissyx: a PermissionDbEntry is just a GVariant, see https://github.com/flatpak/xdg-desktop-portal/blob/main/document-portal/permission-db.c#L1100
[13:20] <lissyx> ok, and what does the struct contains?
[13:20] <lissyx> I think I need to deserialize etc
[13:28] <lissyx> https://github.com/flatpak/xdg-desktop-portal/issues/835
[13:30] <oSoMoN> lissyx, setting the download folder to /dev/shm seems really convoluted, is there a valid use case for it?
[13:30] <lissyx> oSoMoN, who am I to judge what people are doing ?
[13:31] <lissyx> oSoMoN, and it was working without snap
[13:31] <lissyx> oSoMoN, and I dont see why even weird, it would not work
[13:33] <oSoMoN> I don't mean to judge, just saying that if there isn't a sensible use case, it's probably fine to ignore
[13:33] <oSoMoN> (and focus on real issues instead)
[13:34] <lissyx> the ones I filed upstream issues that are not moving? :D
[13:35] <lissyx> oSoMoN, is this still valid ? https://bugzilla.mozilla.org/show_bug.cgi?id=1297524
[13:37] <oSoMoN> nope, let me comment
[16:50] <lissyx> seb128, so the pkcs#11 issue links to https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1967632, there seems to be no activity, did it just fall through the cracks (it happens often on bugzilla, so I would not be surprised) ?
[17:29] <oSoMoN> seb128, first successful firefox snap build with debug symbols: https://launchpad.net/~osomon/firefox/+snap/firefox-snap-stable-dbgsyms/+build/1828055
[19:16] <seb128> lissyx, I guess oSoMoN shared that with you but he got a firefox snap test build which .debug generated on launchpad
[19:19] <lissyx> seb128, :)
[19:22] <lissyx> seb128, and I had a small mistake in my code but it is fixed now: https://treeherder.mozilla.org/jobs?repo=try&revision=6495bdf1f62d123e44e0101a0462b619848471fd&selectedTaskRun=AY3eZDyCSeKu6bXG9-qbZw.0
[19:22] <lissyx> so symbol upload test succeeds: https://treeherder.mozilla.org/jobs?repo=try&revision=6495bdf1f62d123e44e0101a0462b619848471fd&selectedTaskRun=PrbhR5NCRbuCqwMOxxvIYw.0
[19:28] <seb128> lissyx, great!
[19:30] <lissyx> seb128, so now, just have to cherry pick on all branches
[19:30] <lissyx> and we just need gnome-sdk also :)
[19:33] <seb128> right :)
[19:50] <seb128> lissyx, and I will check the pkcs#11 bug details later
[20:12] <lissyx> :)