[00:59] <callmepk> good morning all
[01:37] <duflu> Morning callmepk 
[02:04] <callmepk> morning duflu 
[06:36] <seb128> goood morning desktopers
[06:38] <jamesh> seb128: I think I have the root cause for that thunderbird/portals bug, which I've filed upstream: https://github.com/flatpak/xdg-desktop-portal/issues/545
[06:38] <gitbot> flatpak issue 545 in xdg-desktop-portal "OpenURI.OpenFile() fails when used with document portal paths" [Open]
[06:38] <jamesh> no quick solution though
[06:41] <jamesh> It seems like a deficiency in xdg-document-portal: different apps' views of a file are exported with different inodes, so xdg-desktop-portal doesn't believe the file is the same
[06:55] <duflu> Morning seb128 
[06:57] <seb128> jamesh, hey, great, thanks for investigating the issue!
[06:58] <seb128> hey duflu 
[06:58] <seb128> jamesh, it's not a major issue so no hurry
[07:06] <jamesh> seb128: fyi, it looks like there was a big rewrite of the document portal code in x-d-p 1.7.0, which is newer than what we shipped in focal.  When we do have a fix, it will probably mean version upgrades rather than backporting a small fix
[07:23] <oSoMoN> good morning desktoppers
[07:23] <didrocks> salut oSoMoN 
[07:24] <oSoMoN> salut didrocks 
[07:25] <oSoMoN> happy Friday the 13th 🧟
[07:26] <didrocks> heh, indeed
[07:27] <duflu> Morning oSoMoN and didrocks 
[07:30] <didrocks> hey duflu 
[07:30] <oSoMoN> good afternoon duflu 
[08:02] <marcustomlinson> good morning desktoppers
[08:09] <jamesh> hi marcustomlinson 
[08:09] <marcustomlinson> hey jamesh
[08:15] <didrocks> hey marcustomlinson, jamesh 
[08:18] <marcustomlinson> hey didrocks
[08:28] <duflu> Hi marcustomlinson 
[08:30] <marcustomlinson> hi duflu
[08:34] <seb128> jamesh, ack
[08:34] <seb128> hey oSoMoN, didrocks, marcustomlinson, happy friday! how are you?
[08:35] <marcustomlinson> seb128: doing alright, happy friday indeed :) you?
[08:35] <jamesh> It's Friday the 13th in 2020.  What's the worst that could happen?
[08:35] <didrocks> seb128: tired, not enough sleep, but ok :)
[08:36] <seb128> marcustomlinson, I'm alright :-)
[08:36] <seb128> didrocks, I would say that it's almost the weekend, but I'm unsure that help in any way solving the tireness...
[08:37] <didrocks> yeah :)
[08:40] <GunnarHj> Good morning seb128 and everybody else!
[08:40] <GunnarHj> Today's isenkram activity on this Friday the 13th: It proved to be an appstream issue, and a proposed groovy fix of appstream is available here:
[08:40] <GunnarHj> https://launchpad.net/~gunnarhj/+archive/ubuntu/appstream
[08:40] <GunnarHj> Do you have a minute for sponsoring an upload?
[08:40] <seb128> hey GunnarHj!
[08:41] <seb128> GunnarHj, we are in sync from Debian and it's not team mainained there
[08:41] <GunnarHj> seb128: It's a groovy SRU.
[08:41] <seb128> I'm unsure that's worth SRUing on a non LTS serie, I doubt that software is popular
[08:41] <seb128> let me time to type :p
[08:41] <seb128> ^
[08:42] <seb128> there has been no report on launchpad on the issue, I wouldn't overload the SRU team with that
[08:42] <GunnarHj> seb128: Isn't a completely broken package a valid reason for an SRU?
[08:43] <seb128> my rule is that if the bug didn't get reported by any user then it's not worth spending SRU resources on, especially in a non LTS
[08:44] <seb128> also we need the fix in H first before SRUing
[08:44] <seb128> the Debian maintainer has been responsive so hopefully he does an upload which get autosynced
[08:45] <GunnarHj> seb128: The appstream fix in Debian is on its way "soonish". It's the same maintainer in Debain as upstream.
[08:45] <seb128> right
[08:45] <seb128> well, let's wait for that to land first
[08:45] <GunnarHj> ok
[08:46] <seb128> I'm quite busy today but we can rediscuss next week, or maybe you find another sponsor who likes more the idea to do a SRU to 20.10 ;-)
[09:28] <seb128> duflu, btw I saw your comment yesterday, I was the one who pushed the master bluez branch as 'ubuntu', it seemed more sense to me and more standard with what other packages are doing
[09:28] <seb128> rather than having to rename every cycle
[09:30] <duflu> seb128, The wiki on how to maintain it still says to use the series name, not ubuntu. And it also says "this is a better process than other projects use", so I would prefer to keep it
[09:30] <duflu> https://wiki.ubuntu.com/DesktopTeam/Bluetooth/BluezGit
[09:38] <seb128> shrug
[09:39] <duflu> I see it from a generic software engineering perspective, that 'hirsute' tells you more than 'ubuntu'. That doesn't require advance knowledge that other projects use 'ubuntu' to refer to the current series
[09:39] <seb128> whatever, I don't have the motivation to argue about vcs details, I just found annoying having to branch so others could contribute their fixes and also we have more branches that we need
[09:40] <duflu> It's the same number of branches either way
[09:40] <seb128> we could call it ubuntu/master if you prefer
[09:40] <seb128> no it's not
[09:40] <seb128> focal and groovy never got a SRU
[09:40] <duflu> It is, because 'ubuntu' and 'master' don't exist
[09:40] <seb128> they wouldn't have a branch
[09:41] <duflu> That's an interesting point
[09:41] <duflu> Though might create confusion too
[09:41] <seb128> that's how every single other desktop package is maintained
[09:41] <seb128> we have ubuntu/master
[09:41] <seb128> and we branch to ubuntu/<serie> when we SRU
[09:41] <duflu> Yeah, but again my goal was to invent a superior process to what came before, not to copy it
[09:42] <seb128> that would have sense if the process was baked to be rolled out and used for other packages
[09:42] <duflu> If anyone really wants to then they can start a new repo using a different process
[09:42] <seb128> it doesn't make sense to have a one off on our entire set
[09:42] <seb128> it's just confusing
[09:42] <duflu> It does if you are trying to get others to do the same in future
[09:42] <seb128> well, as said that's not worth the argument
[09:43] <seb128> I find being standard having more value than being better, let's disagree
[09:43] <seb128> it just means people who are familiar with other desktop packages are going to get confused and go through a learning exercice to be able to do change there or just to get things wrong (as I did)
[09:44] <seb128> but not a big deal
[10:45] <oSoMoN> ricotz, FYI: https://bazaar.launchpad.net/~mozillateam/firefox/firefox-beta.hirsute/revision/1382
[12:15] <ricotz> oSoMoN, great!, isn't neon enabled by default on ubuntu armhf? regarding qcms
[12:18] <oSoMoN> ricotz, no, it's not
[12:19] <ogra> there are still many ARMv7 devices without neon support, particulary in embedded ... you would not be able to run on them ... 
[12:20] <ogra> (that said, it is trivial to enable NEON for snaps at build time (i do that for a few of mine) if you know they will not be run on that low end devices)
[12:31] <ricotz> oSoMoN, ah, ok
[13:41] <oSoMoN> ogra, thanks for the precisions! in this case we are talking about the firefox deb packages, not sure how applicable that restriction is…
[13:41] <oSoMoN> out of curiosity, how do you enable NEON for snaps at build time?
[13:42] <ogra> well, by simply enabling any possible neon build time options usually
[13:43] <ogra> that indeed depends how deep yu need to go for an app ... if you have i.e. a video-decoding lib underneath you will not be able to use the deb as build-package but will have to re-build from source
[13:43] <ogra> (by adding a separate part for that specific lib)
[13:44] <ogra> https://github.com/ogra1/omxplayer-snap is an example ... but there i build most relevant bits from source
[14:00] <oSoMoN> ack. I now remember that not so long ago I enabled NEON for the armhf build of the chromium snap, and a user filed a bug that chromium would crash because it was trying to use the NEON instruction set, so I reverted that change
[14:09] <oSoMoN> ricotz, is there a reason for not pushing 83.0 beta packages for xenial to the firefox-next PPA ?
[14:10] <ogra> oSoMoN, yeah, there is likely a lib re-build needed for some depending lib then
[14:10] <ogra> for a browser that might become complex pretty quickly
[14:13] <ricotz> oSoMoN, a bunch of python related changes
[14:14] <oSoMoN> ricotz, did you manage to get a working build somewhere, or does this require work?
[14:15] <ricotz> oSoMoN, sorry, I didn't purse it further
[14:15] <ricotz> oSoMoN, https://hg.mozilla.org/releases/mozilla-beta/rev/5596a03b5334
[14:16] <oSoMoN> ok, I'll work on it this afternoon then
[14:17] <ricotz> oSoMoN, there were builds for thunderbird 68.12.0 though ;)
[14:17] <ricotz> https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+packages
[14:17] <oSoMoN> I'm glad I figured out the armhf FTBFS and failing autopkgtest yesterday, it would have been stressful otherwise
[14:18] <oSoMoN> ricotz, I prepared builds for 68.12.0 in https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages too
[14:18] <oSoMoN> need to validate them and hand over to security for sponsoring
[14:19] <ricotz> yeah, e.g. keeping xenial on firefox 78.x would have been easier, but therefore such a dependency needs to be known way earlier
[14:20] <ricotz> oSoMoN, I noticed, but there were tb builds available for a couple of months ;)
[14:20] <oSoMoN> yes, I'm lagging behind for thunderbird :/
[14:21] <ricotz> nah 68.x is easy, the 78.x transition is a pain
[14:22] <ricotz> the external gnupg support is more of my taste
[14:26] <luna_> Ubuntu and Canonical Q&A on Linux Application Summit 2020 now
[15:19] <hellsworth> good morning desktopers
[15:19] <kenvandine> hey hellsworth 
[15:19] <oSoMoN> good morning hellsworth & kenvandine 
[15:19] <hellsworth> hi there guys :)
[15:55] <oSoMoN> ricotz, https://bazaar.launchpad.net/~mozillateam/firefox/firefox-beta.xenial/revision/1384