| callmepk | good morning all | 00:59 |
|---|---|---|
| duflu | Morning callmepk | 01:37 |
| callmepk | morning duflu | 02:04 |
| seb128 | goood morning desktopers | 06:36 |
| 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:38 |
| 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:41 |
| duflu | Morning seb128 | 06:55 |
| seb128 | jamesh, hey, great, thanks for investigating the issue! | 06:57 |
| seb128 | hey duflu | 06:58 |
| seb128 | jamesh, it's not a major issue so no hurry | 06:58 |
| 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:06 |
| oSoMoN | good morning desktoppers | 07:23 |
| didrocks | salut oSoMoN | 07:23 |
| oSoMoN | salut didrocks | 07:24 |
| oSoMoN | happy Friday the 13th š§ | 07:25 |
| didrocks | heh, indeed | 07:26 |
| duflu | Morning oSoMoN and didrocks | 07:27 |
| didrocks | hey duflu | 07:30 |
| oSoMoN | good afternoon duflu | 07:30 |
| marcustomlinson | good morning desktoppers | 08:02 |
| jamesh | hi marcustomlinson | 08:09 |
| marcustomlinson | hey jamesh | 08:09 |
| didrocks | hey marcustomlinson, jamesh | 08:15 |
| marcustomlinson | hey didrocks | 08:18 |
| duflu | Hi marcustomlinson | 08:28 |
| marcustomlinson | hi duflu | 08:30 |
| seb128 | jamesh, ack | 08:34 |
| seb128 | hey oSoMoN, didrocks, marcustomlinson, happy friday! how are you? | 08:34 |
| 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:35 |
| 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:36 |
| didrocks | yeah :) | 08:37 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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 ;-) | 08:46 |
| 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:28 |
| 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:30 |
| seb128 | shrug | 09:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| seb128 | but not a big deal | 09:44 |
| oSoMoN | ricotz, FYI:Ā https://bazaar.launchpad.net/~mozillateam/firefox/firefox-beta.hirsute/revision/1382 | 10:45 |
| ricotz | oSoMoN, great!, isn't neon enabled by default on ubuntu armhf? regarding qcms | 12:15 |
| oSoMoN | ricotz, no, it's not | 12:18 |
| ogra | there are still many ARMv7 devices without neon support, particulary in embedded ... you would not be able to run on them ... | 12:19 |
| 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:20 |
| ricotz | oSoMoN, ah, ok | 12:31 |
| === acheronuk is now known as RikMills | ||
| 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:41 |
| ogra | well, by simply enabling any possible neon build time options usually | 13:42 |
| 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:43 |
| ogra | https://github.com/ogra1/omxplayer-snap is an example ... but there i build most relevant bits from source | 13:44 |
| 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:00 |
| oSoMoN | ricotz, is there a reason for not pushing 83.0 beta packages for xenial to the firefox-next PPA ? | 14:09 |
| 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:10 |
| ricotz | oSoMoN, a bunch of python related changes | 14:13 |
| oSoMoN | ricotz, did you manage to get a working build somewhere, or does this require work? | 14:14 |
| ricotz | oSoMoN, sorry, I didn't purse it further | 14:15 |
| ricotz | oSoMoN, https://hg.mozilla.org/releases/mozilla-beta/rev/5596a03b5334 | 14:15 |
| oSoMoN | ok, I'll work on it this afternoon then | 14:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| ricotz | nah 68.x is easy, the 78.x transition is a pain | 14:21 |
| ricotz | the external gnupg support is more of my taste | 14:22 |
| luna_ | Ubuntu and Canonical Q&A on Linux Application Summit 2020 now | 14:26 |
| hellsworth | good morning desktopers | 15:19 |
| kenvandine | hey hellsworth | 15:19 |
| oSoMoN | good morning hellsworth & kenvandine | 15:19 |
| hellsworth | hi there guys :) | 15:19 |
| oSoMoN | ricotz, https://bazaar.launchpad.net/~mozillateam/firefox/firefox-beta.xenial/revision/1384 | 15:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!