[00:59] good morning all [01:37] Morning callmepk [02:04] morning duflu [06:36] goood morning desktopers [06:38] 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] flatpak issue 545 in xdg-desktop-portal "OpenURI.OpenFile() fails when used with document portal paths" [Open] [06:38] no quick solution though [06:41] 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] Morning seb128 [06:57] jamesh, hey, great, thanks for investigating the issue! [06:58] hey duflu [06:58] jamesh, it's not a major issue so no hurry [07:06] 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] good morning desktoppers [07:23] salut oSoMoN [07:24] salut didrocks [07:25] happy Friday the 13th šŸ§Ÿ [07:26] heh, indeed [07:27] Morning oSoMoN and didrocks [07:30] hey duflu [07:30] good afternoon duflu [08:02] good morning desktoppers [08:09] hi marcustomlinson [08:09] hey jamesh [08:15] hey marcustomlinson, jamesh [08:18] hey didrocks [08:28] Hi marcustomlinson [08:30] hi duflu [08:34] jamesh, ack [08:34] hey oSoMoN, didrocks, marcustomlinson, happy friday! how are you? [08:35] seb128: doing alright, happy friday indeed :) you? [08:35] It's Friday the 13th in 2020. What's the worst that could happen? [08:35] seb128: tired, not enough sleep, but ok :) [08:36] marcustomlinson, I'm alright :-) [08:36] didrocks, I would say that it's almost the weekend, but I'm unsure that help in any way solving the tireness... [08:37] yeah :) [08:40] Good morning seb128 and everybody else! [08:40] 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] https://launchpad.net/~gunnarhj/+archive/ubuntu/appstream [08:40] Do you have a minute for sponsoring an upload? [08:40] hey GunnarHj! [08:41] GunnarHj, we are in sync from Debian and it's not team mainained there [08:41] seb128: It's a groovy SRU. [08:41] I'm unsure that's worth SRUing on a non LTS serie, I doubt that software is popular [08:41] let me time to type :p [08:41] ^ [08:42] there has been no report on launchpad on the issue, I wouldn't overload the SRU team with that [08:42] seb128: Isn't a completely broken package a valid reason for an SRU? [08:43] 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] also we need the fix in H first before SRUing [08:44] the Debian maintainer has been responsive so hopefully he does an upload which get autosynced [08:45] seb128: The appstream fix in Debian is on its way "soonish". It's the same maintainer in Debain as upstream. [08:45] right [08:45] well, let's wait for that to land first [08:45] ok [08:46] 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] 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] rather than having to rename every cycle [09:30] 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] https://wiki.ubuntu.com/DesktopTeam/Bluetooth/BluezGit [09:38] shrug [09:39] 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] 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] It's the same number of branches either way [09:40] we could call it ubuntu/master if you prefer [09:40] no it's not [09:40] focal and groovy never got a SRU [09:40] It is, because 'ubuntu' and 'master' don't exist [09:40] they wouldn't have a branch [09:41] That's an interesting point [09:41] Though might create confusion too [09:41] that's how every single other desktop package is maintained [09:41] we have ubuntu/master [09:41] and we branch to ubuntu/ when we SRU [09:41] Yeah, but again my goal was to invent a superior process to what came before, not to copy it [09:42] that would have sense if the process was baked to be rolled out and used for other packages [09:42] If anyone really wants to then they can start a new repo using a different process [09:42] it doesn't make sense to have a one off on our entire set [09:42] it's just confusing [09:42] It does if you are trying to get others to do the same in future [09:42] well, as said that's not worth the argument [09:43] I find being standard having more value than being better, let's disagree [09:43] 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] but not a big deal [10:45] ricotz, FYI:Ā https://bazaar.launchpad.net/~mozillateam/firefox/firefox-beta.hirsute/revision/1382 [12:15] oSoMoN, great!, isn't neon enabled by default on ubuntu armhf? regarding qcms [12:18] ricotz, no, it's not [12:19] there are still many ARMv7 devices without neon support, particulary in embedded ... you would not be able to run on them ... [12:20] (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] oSoMoN, ah, ok === acheronuk is now known as RikMills [13:41] 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] out of curiosity, how do you enable NEONĀ for snaps at build time? [13:42] well, by simply enabling any possible neon build time options usually [13:43] 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] (by adding a separate part for that specific lib) [13:44] https://github.com/ogra1/omxplayer-snap is an example ... but there i build most relevant bits from source [14:00] 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] ricotz, is there a reason for not pushing 83.0 beta packages for xenial to the firefox-next PPA ? [14:10] oSoMoN, yeah, there is likely a lib re-build needed for some depending lib then [14:10] for a browser that might become complex pretty quickly [14:13] oSoMoN, a bunch of python related changes [14:14] ricotz, did you manage to get a working build somewhere, or does this require work? [14:15] oSoMoN, sorry, I didn't purse it further [14:15] oSoMoN, https://hg.mozilla.org/releases/mozilla-beta/rev/5596a03b5334 [14:16] ok, I'll work on it this afternoon then [14:17] oSoMoN, there were builds for thunderbird 68.12.0 though ;) [14:17] https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+packages [14:17] I'm glad IĀ figured out the armhf FTBFS and failing autopkgtest yesterday, it would have been stressful otherwise [14:18] ricotz, IĀ prepared builds for 68.12.0 in https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages too [14:18] need to validate them and hand over to security for sponsoring [14:19] 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] oSoMoN, I noticed, but there were tb builds available for a couple of months ;) [14:20] yes, I'm lagging behind for thunderbird :/ [14:21] nah 68.x is easy, the 78.x transition is a pain [14:22] the external gnupg support is more of my taste [14:26] Ubuntu and Canonical Q&A on Linux Application Summit 2020 now [15:19] good morning desktopers [15:19] hey hellsworth [15:19] good morning hellsworth & kenvandine [15:19] hi there guys :) [15:55] ricotz, https://bazaar.launchpad.net/~mozillateam/firefox/firefox-beta.xenial/revision/1384