[05:38] <oSoMoN> good morning desktoppers
[05:39] <duflu> Hi oSoMoN 
[05:39] <oSoMoN> hey duflu 
[05:49] <didrocks> good morning
[05:51] <duflu> Morning didrocks 
[05:51] <didrocks> happy Friday duflu 
[05:56] <oSoMoN> salut didrocks 
[06:00] <didrocks> salut oSoMoN 
[06:49] <lissyx> oSoMoN, https://github.com/snapcore/snapd/pull/11861
[06:49] <lissyx> but CLA mess :(
[07:02] <seb128> goood morning desktopers
[07:06] <duflu> Hi seb128. How are you now?
[07:07] <seb128> duflu, hey, a bit better though my stomach is still isn't great. How are you?
[07:10] <duflu> I'm relatively good. You should rest if you need to
[07:21] <lissyx> oSoMoN, FTR for a few weeks I'm suffering https://bugzilla.mozilla.org/show_bug.cgi?id=1773624
[07:21] <lissyx> is there a way with snap to see some sandbox logs?
[07:33] <seb128> lissyx, usually snapd confirmenent problems show in the journalctl log, at least apparmor denials
[07:34] <lissyx> seb128, good catch I see some reports
[07:34] <lissyx> seb128, do you know from https://bugzilla.mozilla.org/show_bug.cgi?id=1773624#c1 whether this is a bug on our side or the xdg portal one?
[07:35] <seb128> lissyx, but file save should use the portals, you can also try to /usr/libexec/xdg-desktop-portal-gnome -rv in case that has issues
[07:35] <lissyx> from the log it looks like it's hitting the portal at least
[07:37] <seb128> lissyx, I don't sorry, if that's a recent regression I would guess firefox since the portal didnd't change
[07:38] <lissyx> ok
[07:38] <lissyx> xdg-desktop-portal-gnome -rv did nothing but xdg-desktop-portal -rv reveal the same as journalct
[07:38] <lissyx> I'm wondering if we are passing a correct dbus message ...
[07:39] <seb128> what's the error you see in the log?
[07:41] <lissyx> seb128, the one on the comment
[07:41] <lissyx> assertions about file_name != NULL
[07:41] <lissyx> except I can't find where we hit SaveFile in our codebase :)
[07:57] <lissyx> oSoMoN, any opinion on https://bugzilla.mozilla.org/show_bug.cgi?id=1770682#c2 ?
[07:58] <lissyx> oSoMoN, I can file a bug against ubuntu in launchpad if needed
[08:00] <seb128> lissyx, that's an easy snapd change needed
[08:00] <oSoMoN> lissyx, it looks like this was fixed already: https://github.com/snapcore/snapd/commit/9c94b67eb4fe64bd5fe26d8e1968f73f957d1cf0
[08:00] <lissyx> nice
[08:01] <oSoMoN> probably not released in a stable snapd yet
[08:01] <seb128> I was going to say, it's marked as snap 2.56
[08:01] <lissyx> and latest stable is 2.55.x ?
[08:01] <seb128> yes
[08:01] <lissyx> oh I have 2.56
[08:01] <oSoMoN> right, I didn't see the tag
[08:01] <lissyx> updated two days ago?
[08:02] <seb128> ah, right
[08:02] <seb128> well then it should be fixed :)
[08:02] <oSoMoN> lissyx, do you have the hardware to test?
[08:02] <lissyx> no
[08:05] <seb128> tjaalton, hey. I would like to see https://github.com/intel/media-driver/commit/e25478c4 cherrypicked and SRUed to fix bug #1962630 , I confirmed that the fix works. Do you want to handle it or should I just cherry pick + SRU?
[08:22] <lissyx> hm no debugging package for xdg-desktop-portal
[08:29] <lissyx> ok, xdg-desktop-portal-dbgsym is here with the specific apt repo
[08:39] <lissyx> oSoMoN, if it works for you, do you mind r+ on phab? thanks :)
[08:40] <oSoMoN> lissyx, yeah, I'll do that
[08:40] <oSoMoN> lissyx, FYI, I'm working on backporting a fix to xdg-desktop-portal to Ubuntu 20.04 so that OpenDirectory highlights the downloaded file as expected, see bug #1978295
[08:41] <lissyx> yeah I saw your comment
[08:41] <lissyx> oSoMoN, do you happen to know of recent changes around snap that could lead to https://bugzilla.mozilla.org/show_bug.cgi?id=1773624 ?
[08:41] <lissyx> i'm checking and what we send to the XDG portal makes sense
[08:42] <lissyx> xdg-desktop-portal receives a smb:// URI and it seems to be rather on the side of gio that it fails?
[08:44] <oSoMoN> you've already gone deeper into investigating the issue than I have
[08:45] <lissyx> the g_file_new_for_uri is kinda opaque to me
[08:54] <seb128> oSoMoN, reminds me that we should probably sponsor the changes mardy suggested on https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1851250 to 
[08:55] <seb128> oSoMoN, unsure if that would also fix your issue
[08:55] <oSoMoN> let me see
[08:55] <seb128> oSoMoN, #19 has the details
[08:56] <oSoMoN> I just checked, it's a different set of commits
[08:56] <seb128> k
[08:56] <oSoMoN> so two separate SRUs, probably
[08:56] <seb128> well if we do a SRU we should also include those I think
[08:57] <seb128> or do another round, as you prefer
[08:57] <seb128> I just had that for a while in my backlog so I mentioned it
[08:57] <oSoMoN> yes, it's relevant.
[08:57] <lissyx> oSoMoN, btw do you know what is blocking having debug symbols uploaded for snap package?
[08:57] <lissyx> https://crash-stats.mozilla.org/signature/?product=Firefox&version=103.0a1&signature=libxul.so%400x369d8d3%20%7C%20libxul.so%400x369e33c%20%7C%20libxul.so%400x2d48ee9%20%7C%20libxul.so%400x2d48343%20%7C%20libxul.so%400x2d47c66%20%7C%20libxul.so%400x2d43b9e%20%7C%20libxul.so%400x2d438dd%20%7C%20libxul.so%400x2d4a1ce%20%7C%20libxul.so%400xcbf71c%20%7C%20libxul.so%400xccefd0%20%7C%20libxul.so%400xcc9d76%20%7C%2
[08:57] <lissyx> 0libxul.so%400xc...&date=%3E%3D2022-06-08T00%3A00%3A00.000Z&date=%3C2022-06-09T23%3A59%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_columns=release_channel&_columns=distribution_id&_sort=-date&page=1
[08:58] <seb128> I also discussed it a bit with Ken, we agreed that we should probably try to roll new portal versions as SRUs since usually they had support of newer features in snaps/flatpak which aren't tired to the Ubuntu serie
[08:58] <oSoMoN> seb128, the changes mardy is proposing are even more intrusive, so there's a a non-negligible regression risk 
[08:58] <seb128> it's sort of 'enablement of newer versions to keep working on older Ubuntu series'
[08:58] <seb128> oSoMoN, right, at the same time if your portal don't support current versions of the apps you are screwed
[08:59] <oSoMoN> that would solve both issues nicely, if it's acceptable for the SRU team
[08:59] <seb128> but one problem at the time
[08:59] <seb128> I think it's going to take some more time to get the SRU team to decide on allowing those, so maybe don't le me distract you from doing that selected fix
[09:00] <oSoMoN> lissyx, that's https://bugzilla.mozilla.org/show_bug.cgi?id=1766901, I simply haven't had the time to work on it yet
[09:01] <lissyx> oSoMoN, do you have ideas to fix?
[09:01] <lissyx> maybe I can help?
[09:01] <lissyx> (also I can land the other fix as soon as you r+ it)
[09:07] <oSoMoN> accepted
[09:07] <oSoMoN> sorry for the delay
[09:07] <oSoMoN> I'm multitasking too much for my taste
[09:08] <lissyx> thankss
[09:08] <lissyx> I can sense the feeling :)
[09:08] <lissyx> last round of addressing emilio's comment and we're good
[09:09] <tjaalton> seb128: go for it :)
[09:23] <lissyx> oSoMoN, the SMB access issue might be a snap-level one: https://bugzilla.mozilla.org/show_bug.cgi?id=1773624#c3
[09:25] <lissyx> oSoMoN, I'm not sure how snapd can impact there
[09:29] <seb128> tjaalton, in fact the fix was already uploaded to Debian and synced, I did the SRU for J now, maybe you want to review it from the queue? ;-)
[09:30] <seb128> tjaalton, I would appreciate if you could also review wpa/J , it fixes another openssl3 related issue which prevents users to connect to legacy stack APs
[09:33] <tjaalton> seb128: sure thing
[09:43] <seb128> thanks!
[11:35] <KGB-0> gnome-calculator Sebastien Bacher 312634 * commented merge request !8 * https://deb.li/34yNz
[11:36] <KGB-0> gnome-calculator tags abec9ed Sebastien Bacher upstream/42.1 * Upstream version 42.1 * https://deb.li/p3JU
[11:37] <KGB-0> gnome-calculator upstream/latest cb230c7 Sebastien Bacher * pushed 9 commits (first 5 follow) * https://deb.li/iiWSc
[11:37] <KGB-0> gnome-calculator upstream/latest 1f82a7b Rūdolfs Mazurs po/lv.po * Update Latvian translation * https://deb.li/1Wa7
[11:37] <KGB-0> gnome-calculator upstream/latest 5b88d49 Nathan Follens po/nl.po * Update Dutch translation * https://deb.li/3V1Hd
[11:37] <KGB-0> gnome-calculator upstream/latest 2a50c55 Hugo Carvalho po/pt.po * Update Portuguese translation * https://deb.li/D1m2
[11:37] <KGB-0> gnome-calculator upstream/latest 9f9e95b Fabio Tomat po/fur.po * Update Friulian translation * https://deb.li/3L3QC
[11:37] <KGB-0> gnome-calculator upstream/latest 4f0f435 Robert Roth lib/math-equation.vala * Fixed undo/redo broken (#266) * https://deb.li/Tyuh
[11:37] <KGB-0> gnome-calculator pristine-tar 544a0da Nathan Pratta Teodosio gnome-calculator_42.1.orig.tar.xz.delta gnome-calculator_42.1.orig.tar.xz.id * pristine-tar data for gnome-calculator_42.1.orig.tar.xz * https://deb.li/Q5Ux
[11:40] <tjaalton> seb128: the intel-media-driver sru is also a new upstream release?
[11:40] <seb128> tjaalton, oh crap, I overlooked that, let me fix
[11:41] <tjaalton> there's also -non-free
[11:41] <tjaalton> version of it
[11:48] <seb128> tjaalton, I reuploaded
[11:48] <seb128> tjaalton, the bug impacts only -DENABLE_NONFREE_KERNELS=OFF builds from what I understand
[11:50] <KGB-2> gnome-calculator signed tags 965129a Sebastien Bacher ubuntu/1%42.1-1ubuntu1 * gnome-calculator Debian release 1:42.1-1ubuntu1 * https://deb.li/3TPNI
[12:21] <seb128> tjaalton, thanks!
[12:32] <tjaalton> ah ok
[13:39] <lissyx> hm osomon is not here :/
[13:39] <lissyx> I'm wondering where is snap/command-chain/desktop-launch coming from on firefox snap
[13:51] <diddledani> lissyx: it's coming from the `extensions: [gnome-3-38]` or similar line in the `apps:` block
[13:52] <diddledani> that tells snapcraft to insert the desktop-launch script which is housed in the snapcraft source
[13:53] <lissyx> ok
[13:53] <lissyx> so ultimately the fix is the one requested by gimp people
[13:54] <lissyx> https://bugzilla.mozilla.org/show_bug.cgi?id=1773624#c6
[13:58] <diddledani> the best fix would be to petition @kenvandine and team to add gvfsdbus into the gnome extensions
[13:58] <lissyx> yes
[13:59] <tjaalton> seb128: the wpa sru bug description isn't formatted for sru
[14:06] <seb128> tjaalton, sorry I was sure I had updated it, did that now
[14:08] <seb128> lissyx, sounds like libgvfsdbus should perhaps be in the platform snap
[14:09] <lissyx> seb128, this is something the link from the forum requests, but there has been no action since
[14:09] <lissyx> and honestly, trying to replicate the gimp workaround is starting to get very hairy
[14:10] <tjaalton> seb128: yes, better
[14:11] <seb128> lissyx, the snapcraft extension is https://github.com/snapcore/snapcraft/tree/main/extensions/desktop/common
[14:12] <lissyx> seb128, I'm not going to be able to hack more on that today unfortunately
[14:12] <diddledani> yeah the solution is to add libgvfsdbus to the platform snaps - I would push back on adding my "fix" for gimp into the extension desktop-launch script
[14:12] <lissyx> seb128, I'm leaving brain dump at https://bugzilla.mozilla.org/show_bug.cgi?id=1773624#c8
[14:12] <seb128> lissyx, ack
[14:12] <lissyx> diddledani, ah you are the one who did it?
[14:12] <diddledani> (I'm the primary maintainer of the gimp snap)
[14:12] <seb128> also gvfs in snaps is an issue
[14:12] <seb128> unsure if it is one for that particular case
[14:13] <seb128> but libgvfs needs to talk to gvfsd but that can't be allowed for security reason
[14:13] <lissyx> usecase: accessing files from my NAS from Firefox
[14:13] <seb128> since there is no mediation at this level and it would basically give a free access to the host
[14:13] <lissyx> i've already spotted at least one report, probably more linked to that
[14:13] <seb128> lissyx, the issue is that gvfs has no way today to limit the access to the one thing you request
[14:14] <lissyx> diddledani, well, thanks for that, although I'm lost on how you endup with libgvfsdbus.so
[14:14] <seb128> lissyx, also it's weird that this report make it sound like it's a regression, I would have expected that it never worked
[14:14] <lissyx> (I mean how you get it packaged in your snap)
[14:14] <lissyx> seb128, it was working a few weeks ago
[14:14] <lissyx> seb128, maybe it was using the debian package back then?
[14:14] <seb128> probably?
[14:14] <lissyx> either way, from a user perspective, it's a regression
[14:14] <seb128> yes
[14:15] <lissyx> there are at least three reports that complains about network files and snap
[14:15] <diddledani> lissyx: I've got `gvfs-backends` as a dependency (stage-packages)
[14:15] <lissyx> I'm waiting on needinfo so I can't be sure, but it sounds like it
[14:15] <seb128> diddledani, is that really fixing it?
[14:15] <lissyx> diddledani, I did that as well as the layout thigns
[14:15] <seb128> I think we are basically talking about https://github.com/flatpak/xdg-desktop-portal/issues/102
[14:15] <seb128> 'Currently, if you need access to gvfs functionality inside the sandbox, the only option is to allow access to gvfs-daemon, which makes all network mounts available.'
[14:15] <lissyx> diddledani, but I end up with nothing in my snap's usr/lib/...
[14:16] <lissyx> seb128, how do I give access to gvfs-daemon ?
[14:16] <seb128> you can't
[14:16] <lissyx> ok so it's not an option then
[14:16] <seb128> snapd doesn't allow to open random holes like flatpak do, that would make snaps unsecure
[14:16] <seb128> no
[14:17] <seb128> that's a platform problem that we need to fix, it's not trivial though
[14:17] <diddledani> seb128: I think I'm relying on gvfs mounts already being mounted - by that point they'll be in a path located at a place that removable-media allows IIRC
[14:17] <seb128> diddledani, through the fuse mounts?
[14:17] <diddledani> I forget, the change was quite a while ago now
[14:18] <lissyx> seb128, and would a hack like the one on gimp be doable?
[14:18] <lissyx> honestly, it's above my current level of snap
[14:18] <lissyx> (which was undefined two hours ago)
[14:19] <diddledani> it might be that my fix doesn't even do the job that I wanted it to do and I never reverted it ;-)
[14:20] <seb128> lissyx, by CIFS mount in that bug do we mean a smb:// location mounted through gio/nautilus?
[14:20] <lissyx> yes
[14:21] <diddledani> I think this is the issue report that I "fixed" with that change to add gvfs-backends and other related changes https://github.com/snapcrafters/gimp/issues/99
[14:21] <diddledani> no maybe not
[14:21] <diddledani> donno then :-)
[14:21] <lissyx> need to go anyway
[14:21]  * lissyx &
[14:21] <seb128> bye!