[05:58] <didrocks> good morning
[06:16] <jibel> Good morning all
[06:16] <duflu> Morning didrocks and jibel 
[06:21] <jibel> HEy duflu 
[06:42] <seb128> goood morning desktopers
[06:45] <didrocks> salut jibel, duflu, seb128 
[06:45] <duflu> Hi seb128 
[06:47] <tsimonq2> Hey Desktop Team, I hope y'all are well :)
[06:50] <duflu> Hi tsimonq2 
[06:58] <KBar> hi. is there a specific reason for not installing all binaries of gnome-session? https://git.launchpad.net/ubuntu/+source/gnome-session/tree/debian/gnome-session-bin.install
[07:01] <seb128> KBar, specifically? which ones would you expect there?
[07:02] <KBar> seb128: gnome-session-selector, for example
[07:03] <KBar> looks like debian installs all of them: https://salsa.debian.org/gnome-team/gnome-session/-/blob/debian/master/debian/gnome-session-bin.install
[07:04] <seb128> KBar, gnome-session-selector doesn't exist in Debian either
[07:05] <seb128> KBar, https://packages.debian.org/sid/all/gnome-session-bin/filelist
[07:06] <KBar> interesting. looks like the 'enable_session_selector' isn't enabled
[07:06] <KBar> seb128: in that case, 'gnome-session-custom-session' is redundant and potentially destructive, as it depends on 'gnome-session-selector'
[07:08] <seb128> KBar, I've no idea what gnome-session-custom-session is doing but it sounds like an upstream issue if they allow to build that without building other components it needs
[07:10] <KBar> seb128: its just a two-line shell script: `g-s-s; exec gnome-session` you're right, i'll report this on salsa. thanks
[07:10] <seb128> KBar, np!
[07:12] <lissyx> seb128, so including the debug symbols within the snap package bumps ~30MB: https://bugzilla.mozilla.org/show_bug.cgi?id=1766901#c21
[07:12] <ubottu> Mozilla bug 1766901 in Toolkit "Scrape symbols from Ubuntu snap builds" [S1, New]
[07:13] <seb128> lissyx, those don't need to be in the snap do they? just to be exported somehow at the end of the build right?
[07:14] <lissyx> seb128, they dont need but my understanding from launchpad buildsystem we have no other choice than to keep them in the snap package so we can extract from taskcluster
[07:15] <seb128> because we can't have a secret to do the upload from the launchpad side?
[07:16] <lissyx> it seems so
[07:17] <seb128> right, I think the 30M are an acceptable workaround until launchpad allows us to solve it differently
[07:17] <seb128> let me check with other people in the team today
[07:18] <seb128> and brb, need to change location and drop from IRC for a bit, I will read the backlog if I miss anything
[07:45] <seb128> and back online
[07:47] <seb128> didrocks, jibel, hey, I'm asking in case you have some tips for ubiquity UI hacking, on did some more recently that me ... is there a dry-mode/load one plugin directly kind of hack available? I don't remember
[07:52] <lissyx> seb128, I need to verify the flow on github actions, it could be that we can avoid this on at least nightly
[07:54] <seb128> lissyx, right, the ones built on github should be able to have a secret and handle the upload from the build and strip at the end
[07:55] <lissyx> I dont know how much of the users are on nightly, but it's still 30MB saved for transfer and storage ...
[07:56] <lissyx> unrelated, https://bugzilla.mozilla.org/show_bug.cgi?id=1773316#c2
[07:56] <ubottu> Mozilla bug 1773316 in Core "Can't see my printer with firefox 101 on Ubuntu 22.04 (snap)" [--, Unconfirmed]
[07:56] <lissyx> I am unsure I understand his statement
[07:56] <lissyx> > The option print documents was set to a dash which implies that cups is not accessible I guess. By selecting "cups:cups-server" i could then see my printers with firefox. Problem solved.
[07:56] <lissyx> would snap require specifics for cups?
[08:00] <seb128> lissyx, snap have interfaces to grant access to resources, the cups one is connected by default (auto-connection to some specific interfaces can be granted from the store side after a review process)
[08:00] <jibel> seb128, there used to be plugin-viewer-gtk.py but I just tested and it needs some love to port it to recent gtk and python.
[08:00] <lissyx> seb128, so there might be a real issue here that it was not done by default
[08:01] <jibel> ./plugin-viewer-gtk.py ubi-language to test the language page for example
[08:01] <seb128> lissyx, yes, that would be a bug on the snapd/store side though, not in firefox. Note that local built don't have the auto-connection, so we would need to learn more about it
[08:02] <seb128> jbicha, thanks, I will try to play with that
[08:02] <seb128> lissyx, I meant it could be the user fault, a local built or a snap installed with snap install <downloaded_snap>
[08:15] <ricotz> hello desktopers!
[08:19] <KBar> good day/morning!
[08:20] <seb128> hey ricotz, how are you?
[08:24] <ricotz> seb128, hey, could be better, corona finally got me, how are you?
[08:24] <seb128> ricotz, oh, no :-( I hope you only have mild symptoms?
[08:24] <ricotz> seb128, is osomon out today?
[08:24] <seb128> I'm already, a small cold but which isn't covid
[08:24] <seb128> ricotz, yes, until monday
[08:25] <ricotz> seb128, I wouldn't call the symptoms mild, but the worse part should be over :)
[08:26] <seb128> k, well I hope you will have recovered soon!
[08:26] <ricotz> seb128, I see, regarding firefox, upstream finally caught up with the armhf build failures
[08:26] <seb128> ah, nice
[08:27] <ricotz> still a lot of cherry picking since only the 102esr branch will be get fixed
[08:28] <ricotz> seb128, thank you, I hope so, a week without sports isn't much fun :(
[08:31] <KBar> get well soon! 
[08:31] <seb128> jibel, thanks for the suggestion, I push a trivial fix for the viewer, it's working now :)
[08:37] <jibel> Excellent, thanks!
[09:12] <lissyx> seb128, is it safe to assume that dependencies packed within snap will have the same debug symbols as the distro one?
[09:12] <lissyx> seb128, i.e., pulling jammy's debug symbol is enough to cover snaps on jammy?
[09:12] <lissyx> or "core20" means I should also pull 20.04 symbols ?
[10:23] <seb128> lissyx, you should pull the symbols matching the deb bundled if it brings ubuntu package, but some things might be built from source
[10:23] <seb128> like in the gnome-3-38 snap
=== bittin__ is now known as bittin_
=== bittin_ is now known as bittin
[11:48] <jbicha> ricotz: I hope you recover soon
[11:48] <jbicha> happy Friday y'all
[11:51] <seb128> hey jbicha, happy friday to you!
[12:23] <KGB-2> rhythmbox signed tags a04c810 Jeremy Bicha ubuntu/3.4.6-2ubuntu1 * rhythmbox Debian release 3.4.6-2ubuntu1 * https://deb.li/3bzBd
[12:23] <KGB-2> rhythmbox ubuntu/master a1725db Jeremy Bicha * pushed 493 commits (first 5 follow) * https://deb.li/3gEfF
[12:23] <KGB-2> rhythmbox ubuntu/master 1b14819 Jonathan Matthew NEWS README data/org.gnome.Rhythmbox3.appdata.xml.in meson.build * Rhythmbox 3.4.6 * https://deb.li/ixa31
[12:23] <KGB-2> rhythmbox ubuntu/master b2033ef Jeremy Bicha debian/changelog * Update debian/changelog * https://deb.li/kjDe
[12:23] <KGB-2> rhythmbox ubuntu/master e6159d8 Jeremy Bicha (47 files in 26 dirs) * New upstream version 3.4.6 * https://deb.li/3Wzs0
[12:23] <KGB-2> rhythmbox ubuntu/master 902a6bc Jeremy Bicha (47 files in 26 dirs) * Update upstream source from tag 'upstream/3.4.6' * https://deb.li/eEzA
[12:23] <KGB-2> rhythmbox ubuntu/master 439d238 Jeremy Bicha debian/changelog * New upstream release * https://deb.li/3Aawi
[12:39] <rbasak> Does anyone else have issues with gnome-shell leaking on Jammy? After just a few days the RSS is up to nearly 1G, and performance gets increasingly sluggish. A logout/in (or reboot as I often have an outstanding kernel update by then) usually fixes it.
[12:40] <lissyx> seb128, assuming I have had ~0 chance when commenting on launchpad issues that were marked as "fixed", what can I do to get attention on https://bugs.launchpad.net/ubuntu/+source/gtk4/+bug/1973219/comments/5 
[12:40] <ubottu> Launchpad bug 1973219 in gtk4 (Ubuntu Jammy) "Update gtk4 to 4.6.3" [High, Fix Released]
[12:40] <lissyx> seb128, this is about https://bugzilla.mozilla.org/show_bug.cgi?id=1768492
[12:40] <ubottu> Mozilla bug 1768492 in Core "[Snap] File Open dialogue window size enlarges incrementally on repeated invocations" [--, Unconfirmed]
[12:40] <rbasak> I don't think I have any extensions enabled. I did disable the desktop icon extension as that was causing issues too. Maybe there's a common underlying cause somewhere.
[12:43] <rbasak> Idle CPU use of gnome-shell is ~10-15% as well. And it's only been four days.
[12:46] <jbicha> lissyx: that should be fixed with LP: #1971112 . It's currently in jammy-proposed. It took a little longer than usual for the SRU to reach jammy-proposed this time
[12:46] <ubottu> Launchpad bug 1971112 in gtk4 (Ubuntu Jammy) "File picker gets bigger more and more each time!" [High, Fix Committed] https://launchpad.net/bugs/1971112
[12:47] <lissyx> jbicha, am I reading right it hit proposed two days ago?
[12:48] <jbicha> yes
[12:48] <lissyx> ok
[12:48] <lissyx> so it's consistent with my VM not having it
[12:49] <lissyx> hm
[12:50] <lissyx> of course if I dont enable proposed ...
[12:50] <seb128> lissyx, what Jeremy said, it was another issue which was just fixed in the newest SRU
[12:51] <jbicha> proposed isn't enabled by default. The important part is that the fix is in progress and is expected to be released to jammy-updates within 2 weeks
[12:51] <lissyx> yeah but I usually enable it always
[12:52] <lissyx> let's reboot to make sure.
[12:54] <lissyx> jbicha, indeed looks like it finally fixes for stable with xwayland
[12:55] <jbicha> feel free to comment on that bug with the results of your testing 😉
[13:03] <lissyx> seb128, olivier is on pto? I dont see him connected
[13:03] <lissyx> seb128, maybe you can answer this? https://bugzilla.mozilla.org/show_bug.cgi?id=1749771#c2
[13:03] <ubottu> Mozilla bug 1749771 in Core "[Snap] Remove home folder access if the OS supports the xdg-desktop-portal feature" [--, Unconfirmed]
[13:04] <seb128> lissyx, yes, he's off today, back on monday
[13:04] <seb128> lissyx, $ snap connections firefox | grep home
[13:04] <seb128> home                      firefox:home                    :home           
[13:04] <seb128> so we still connect the home interface
[13:06] <lissyx> yes, but what I fail to understand is whether we still need it
[13:06] <seb128> lissyx, that's probably still wanted to get 'firefox ~/Documents/something.html' working since firefox doesn't go through portals for cmdline arguments
[13:06] <lissyx> right
[13:06] <lissyx> do we want to go through portal for those?
[13:06] <seb128> ideally yes
[13:06] <lissyx> having worked on the CLI parsing, I have my opinion
[13:06] <lissyx> and it's different from yours :)
[13:07] <seb128> because without that you have ~ working but not '$ firefox /usr/share/nicetoy/documentation.html' working
[13:07] <seb128> or we need another solution at the snap level
[13:08] <seb128> there are discussion around apparmor prompting to grant access, maybe that would be another way to solve that one
[13:08] <lissyx> seb128, snap will block arbitrary /usr/share anyway
[13:08] <seb128> trying to access a file would give you an apparmor prompt to give the permission
[13:08] <lissyx> seb128, I've had to land a few PR to fix some issues reported to us around gimp and others doc that are not within /usr/share/doc/
[13:08] <seb128> lissyx, well, not if you were going through the portal
[13:09] <seb128> but yes direct access is denied
[13:09] <lissyx> so we'd need to intercept any file:/// and go through the portal for those?
[13:09] <lissyx> but the portal will prompt user
[13:09] <seb128> that would be one solution I could imagine, I'm not saying that's the right one
[13:09] <seb128> it would be better if we could get that through apparmor prompting
[13:18] <ricotz> jbicha, hey :), thank you!
[17:17] <lissyx> :(
[17:17] <lissyx> https://github.com/lissyx/firefox-snap/actions/runs/2556748879
[17:17] <lissyx> looks like I'm  too limited on GitHub Actions
=== ahasenack__ is now known as ahasenack