[06:07] <oSoMoN> good morning desktoppers
[06:47] <luna> morning
[06:53] <jibel> Good morning folks
[06:58] <duflu> Hi oSoMoN, luna, jibel 
[07:01] <didrocks> good morning
[07:02] <duflu> Hi didrocks 
[07:03] <seb128> goood morning desktopers
[07:03] <seb128> lut didrocks, hey duflu, how are you?
[07:04] <didrocks> hey duflu, seb128. Good, and you?
[07:05] <luna> https://cdimage.ubuntu.com/daily-live/20220511.1/ Kinetic Daily images starts rolling
[07:05] <luna> gonna install and test later today
[07:10] <duflu> seb128, going OK. You?
[07:11] <seb128> duflu, I'm already thanks! went to tennis yesterday but had to stop after being rained on for an hour, which is frustrating because it was quite nice and sunny during the day, and we are back to blue sky this morning
[07:11] <seb128> already->alright
[07:12] <seb128> (and not awake yet it seems, I had to wake up earlier to prepare a bunch of fruit skewers for a kid's party)
[07:23] <luna> doing a test install in Virtualbox now
[08:09] <rastersoft_> hi again
[08:27] <duflu> Hi Rastersoft 
[08:45] <bittin> hi
[08:51] <duflu> Hi bittin 
[08:53] <bittin> my 22.10 daily install went well in Virtualbox, but not much changed from 22.04 yet :p
[10:28] <sil2100> Hey desktop-team! I saw the canary image FTBFS today, due to the fact that ppa:ubuntu-desktop/canary-image has no kinetic packages in it
[10:29] <sil2100> Could someone push a dummy package there to get a Release file generated for the archive?
[10:29] <sil2100> This should unblock the build
[10:36] <seb128> sil2100, hey, thanks for pointing that out, it should be fixed now ... can you trigger an ISO build to check?
[10:47] <KGB-2> gnome-remote-desktop Sebastien Bacher 308402 * commented merge request !2 * https://deb.li/HPyx
[11:04] <jbicha> good morning
[11:16] <nteodosio> jbicha, good morning
[11:17] <jbicha> nteodosio: hi, how is it going?
[11:18] <nteodosio> jbicha pretty well, thanks!, same with you?
[11:19] <jbicha> pretty good, gnome-remote-desktop has been frustrating me this week but I'm making progress 🙂
[11:20] <nteodosio> Good to hear that!
[11:20] <nteodosio> Well, the last part of that anyway :)
[14:24] <Trevinho> oSoMoN: reviewing that portal situation is quite bad all over the places... While one option is to make the shell, mutter and probably other places to handle the `.snap` prefix, we're still not handling well the snaps case with multiple apps, so I'm assuming that portals have many broken functionalities when it comes to cross-apps / shell interactions, as everyone is assuming to have a desktop-ID == applicationId
[14:28] <oSoMoN> Trevinho, so the proper solution is to modify all the portals to pass a desktop ID to the access requests they issue, right?
[14:28] <Trevinho> this is also an huge problem when it comes to GApplications because the application ID should also be used to figure out the application's `org.freedesktop.Application`'s path/iface, and so  lots of assumptions around simply don't work
[14:28] <Trevinho> yeah, I'm playing with something like that, but then we've still the GApplication case mentioned above, that won't never work.
[14:31] <Trevinho> I started from looking at GIO notifications some days ago, trying to figure out how to make them play nicely... And those are an easy case because we could just provide a different module implementation for the GNOME-sdk based snaps, but there may be other tons of places were we'll be just broken
[14:33] <Trevinho> so I basically opened a can of worms... We definitely need to find a way to make GApplication's play nicely in snaps without loosing their expected path, unless we want to be evil and change GLib implementation to use something like snap.snap_name.snap_instance as their well known name
[14:33] <Trevinho> this is relevant because a portal may want request to activate an  application Action... Now if we don't know how to reach it through dbus, we're screwed