[06:56] <didrocks> good morning
[06:56] <oSoMoN> good morning desktoppers, happy Friday!
[06:58] <duflu> Morning didrocks and oSoMoN 
[07:02] <didrocks> hey oSoMoN, duflu 
[07:03] <oSoMoN> hey duflu, salut didrocks 
[07:27] <jibel> Good morning
[07:27] <duflu> Morning jibel 
[07:30] <didrocks> salut jibel 
[07:30] <jibel> Hi duflu didrocks 
[07:32] <oSoMoN> salut jibel 
[07:32] <jibel> hi oSoMoN 
[08:00] <jamesh> oSoMoN: hi. Is there anything you need to know (or would like to discuss) about the native messaging portal work?
[08:03] <seb128> goood morning desktopers
[08:17] <didrocks> salut seb128 
[08:17] <seb128> lut didrocks, en forme ?
[08:22] <duflu> Morning seb128. How goes?
[08:24] <didrocks> ça va, et toi seb128 ?
[08:27] <seb128> ça va :)
[08:28] <seb128> duflu, hey, it's going well, a bit tired but it's friday!
[09:33] <oSoMoN> salut seb128, hey jamesh 
[09:34] <oSoMoN> jamesh, I understand it's still a draft, but I think it would be useful to build packages with your PR as a patch in a PPA, so we can start testing integration with browsers
[09:36] <RikMills> do we know yet if there is some UI needed?
[09:36] <RikMills> or still TBD?
[09:38] <oSoMoN> this is still in discussion at https://github.com/flatpak/xdg-desktop-portal/pull/705
[09:40]  * RikMills subscribes
[09:46] <seb128> oSoMoN, salut!
[09:48] <jamesh> oSoMoN: I think the application facing API is basically right.  When testing things, I've generally just built it locally and run "./xdg-desktop-portal -rv" to replace the running instance
[09:50] <jamesh> oSoMoN: the part that is incomplete is the access control to restrict the API to just web browsers, so I'm not sure how widely we'd want it distributed yet
[09:54] <oSoMoN> jamesh, right, if we build packages to test integration in a PPA, it has to remain confidential
[09:55] <oSoMoN> I mean it can be public, but there should be a big fat warning that says "use at your own risk, or better yet do not use"
[09:55] <jamesh> not necessarily confidential (the PR is public after all), but also not something people will accidentally install
[11:02] <oSoMoN> ricotz, have you seen https://forum.snapcraft.io/t/missing-dutch-interface-language-in-libreoffice-snap/28603 ?
[11:05] <ricotz> oSoMoN, hi, I haven't seen it, although I am expecting such reports
[11:06] <ricotz> oSoMoN, is there some guideline for snaps for some coordinated l10n support?
[11:07] <ricotz> adding all supported languages will increase the snap size even further, 650MB+ is already something
[11:25] <oSoMoN> ricotz, there's no guideline that I know of
[11:26] <oSoMoN> it might be interesting to investigate splitting language support into separate content snaps, although I'm not sure exactly how that would work
[11:29] <ricotz> oSoMoN, that would be helpful, I am not that familiar with snaps
[11:31] <oSoMoN> for this to be useful, each language would have to be in its own content snap, and the libreoffice snap would need some logic to download the relevant languages on first run or after the language preferences were changed
[11:32] <ricotz> I see
[11:33] <oSoMoN> but having a strictly confined snap install other snaps requires the snapd-control interface, which is unlikely to be granted to a "normal" snap
[11:33] <ricotz> adding languages on demand is not a viable solution, this already happened multiple times in the past for libreoffice
[11:33] <oSoMoN> so I'm not sure this would even be possible
[11:33] <ricotz> does firefox ship all languages in its snap?
[11:34] <oSoMoN> and having all languages in one separate content snap doesn't really resolve anything
[11:34] <oSoMoN> yes, firefox ships all the language extensions in the snap
[11:34] <ricotz> ok
[12:59] <jbicha> happy Friday
[13:10] <jbicha> seb128: looks like we get to do the gstreamer uploads again 😁
[13:11] <seb128> jbicha, indeed, 1.20 is out
[13:11] <seb128> unless we want to let .90 migrate first?
[13:11] <seb128> well, 1.20 was uploaded to unstable to it will autosync
[13:12] <jbicha> I need to do a new -bad upload anyway for s390x and I think I'll just drop qtwayland build-depends for i386 for -good for now
[13:13] <seb128> yes, let's get 1.20 migrating without it and then add it back
[13:37] <jbicha> I'm working on the February poppler update now
[13:46] <seb128> 👍
[14:43] <oSoMoN> hey jbicha, happy Friday!
[17:54] <jbicha> seb128: found in the build logs "C++17 is the minimum C++ standard since poppler 22.01.0" :(
[21:15] <seb128> jbicha, you mean rebuilding reverse depends?
[21:20] <jbicha> yeah, we need to fix the reverse dependencies to finish the transition
[21:28] <seb128> right, well something for next week at this point
[21:28] <seb128> which ones show that error? I checked a few of the failed build but those didn't have that error
[21:31] <jbicha> scribus did but that's fixed now
[21:35] <seb128> 👍
[21:35] <seb128> I will try to help with the other build issues next week
[21:37] <jbicha> cool, have a good weekend
[21:42] <seb128> thanks, same to you!