[01:03] good morning [01:03] Hi callmepk [01:07] hey duflu [06:21] goood morning desktopers [06:46] Morning seb128 [07:17] good morning desktoppers [07:19] Hi oSoMoN [07:19] It's quiet here [07:31] hey duflu [07:32] quiet is good :) [07:53] morning seb128 oSoMoN [08:04] good morning [08:18] Morning didrocks [08:21] hey duflu [08:27] morning didrocks [08:38] hey callmepk [08:53] hey duflu oSoMoN callmepk how are you? [08:53] didrocks, salut! en forme ? [08:54] seb128, going well. It was an early morning but good sleep followed by pilates. And making good progress. You? [08:54] seb128: ça va, et toi ? [08:54] wondering how far I’ll be able to start running tomorrow :) [08:54] have to plan for some tracks [08:55] I'm alright, usual lack of sleep but otherwise izfine [08:55] didrocks, on the news they had a guy who did a marathon distance on his balcony, go round in the garden? ;-) [08:58] good afternoon callmepk, salut didrocks & seb128 [08:58] seb128 i am okay, just busy [09:00] seb128: well, the garden isn’t runnable TBH yet :p [09:01] salut oSoMoN [09:02] ;-) [09:04] heyyyYYYYY [09:06] hey Laney [09:09] Hi Laney [09:16] hey Laney, how are you? [09:21] hey didrocks duflu seb128 [09:21] not too bad thanks [09:24] hey ho Laney [10:19] yo oSoMoN [11:03] huh why do graphical snaps work for me on wayland without the SRU [11:04] Laney, wayland native apps? [11:05] Morning o/ [11:05] * Try to run "chromium" from the terminal. Without the fix, it will fail [11:05] with the error "Unable to open X display". With the fix applied, it [11:05] hey Wimpress [11:05] will launch as normal. [11:05] I did that [11:08] hey Wimpress [11:08] Laney, weird :/ [11:10] heh [11:11] I think maybe I'm running a super old mutter and haven't restarted in ages [11:11] * Laney does that [11:17] indeed [11:20] and works with the sru :> [11:24] Trevinho: you should copy that mutter to hirsute-proposed btw [11:24] do you know how? [11:24] Laney: yeah, I was wondering that yesterday [11:24] Laney: well copy-package will work no? [11:25] yes [11:25] that's what I was checking you knew how to use [11:26] Laney: yep, even though the hardest part is now remembering the H codename :D [11:26] nothing will beat oneiric [13:32] oSoMoN, thanks for the apport tb review, I'm unsure now how the profile to use is choosed :/ [13:33] seb128, yeah, no worries, I'll take a closer look and see if I can come up with something that works in all situations [13:34] seb128, mind sharing privately your profiles.ini ? [13:34] oSoMoN, https://paste.ubuntu.com/p/77MRVmcvnw/ [13:35] oSoMoN, in that config default-release is the one in use, despite default having Default=1 [14:13] oSoMoN, do you know how firefox contacts an existing instance? [14:14] I was trying to poke a bit at bug #1835024 [14:14] bug 1835024 in snapd "Links triggered within most snap apps open in a separate browser session" [Medium,Confirmed] https://launchpad.net/bugs/1835024 [14:16] seb128, I think the problem is in the slack snap, or maybe the fact that it's a classic snap [14:18] oSoMoN, it's classic but I'm trying to see why [14:18] if I do 'snap run --shell code' (a classic snap I've installed) [14:18] according to comment #5 in that bug the problem is not slack itself, indeed, but classic confinement [14:18] and 'firefox http://something' [14:18] it has the same issue [14:19] it'd be interesting to know whether there's the same problem with chromium (or another browser) [14:20] chromium doesn't have the issue [14:36] oSoMoN, it's weird, I tried to strace the firefox command into the classic snap env and outside [14:37] .mozilla/firefox/profiles.ini is being read similarly [14:38] but then they don't open the same profile [14:38] also the normal env one stat /tmp/firefox/.parentlock and /tmp/firefox which the other doesn't [14:40] the one inside the snap env end up displaying a 'Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile.' [14:46] good morning desktopers === cpaelzer__ is now known as cpaelzer [14:56] oSoMoN, ok, found it! [14:57] * seb128 does an happy dance [15:03] videos or it didnt happen ! [15:06] https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1835024/comments/20 has the details [15:06] Ubuntu bug 1835024 in snapd "firefox fails to use the default profile from classic snaps" [Medium,Confirmed] [15:06] but basically firefox disables the profile selection logic when SNAP_NAME is set [15:07] $ SNAP_NAME=bug firefox is an easier way to trigger the bug [15:07] (the env is set from inside classic snaps and those call directly to $webbrowser, not through the xdg-open proxy) [15:08] Wimpress, popey, ogra, ^ that's an issue I saw mentioned a few times impacting classic snaps, the details might be interesting to you [15:08] seb128, good catch! so the fix would be to check for the value of $SNAP_NAME, not just whether it's set, right? [15:08] IIRC Sergio already submitted a similar fix to upstream firefox a while back [15:09] it must have been in another part of the codebase, I guess [15:10] right [15:11] unsure if they use different names for different channels though [15:11] yes, that was here: https://sources.debian.org/src/firefox/82.0-1/browser/components/shell/nsGNOMEShellService.cpp/?hl=77#L74 [15:11] but probably 'includes firefox'? [15:11] well, thats a gross hack in FF ... it should simply use the /current dir instead of the versioned one for searching the profile [15:12] using SNAP_NAME at all seems like a very poor workaround [15:12] regardless, that's two functions that do the same thing, but differently, and with different results, resulting in a bug, so that code should be factored out [15:12] ogra, their code probably resolve the symlink and they end up with ~/snap/? [15:12] might be [15:13] i only read the comment above the SNAP_NAME thing [15:13] oSoMoN, can you handle the upstreaming part? I don't have a mozilla account and I'm not familiar with their tools and workflow, would probably take me much longer [15:13] seb128, I was about to ask about that :) sure, I'll file an upstream bug and will submit a patch [15:13] oSoMoN, thanks a lot! [15:14] tbh their workflow is horribly and unnecessarily complicated, I always have to go back and read the doc to remember how to submit a PR… [15:14] while also ugly "$SNAP_USER_DATA/../current" might work around the root cause [15:15] (in a beter way than checking for SNAP_NAME at least) [15:27] seb128, https://bugzilla.mozilla.org/show_bug.cgi?id=1674150 [15:27] Mozilla bug 1674150 in Untriaged "snap detection code disables profile management even when not packaged/run as a snap" [--,Unconfirmed] [15:27] oSoMoN, thanks! [15:37] oSoMoN, kenvandine, I opened https://forum.snapcraft.io/t/request-autoconnect-of-interfaces-for-thunderbird/20816 btw if you guys have an opinion or comment, that's my first request to autoconnect so I'm not sure I did it right (also if gnupg by default is something we should do or not?) [15:44] seb128, the request doesn't appear to be in any category? it should be in store-requests [15:45] seb128, also, I think the store reviewers are going to ask you to file separate requests for each interface [15:45] so that they can vote and track them separately [15:45] the request itself seems reasonable to me [15:46] oSoMoN, thanks, I forgot there was a category, fixed that [15:47] (that's a mistake I made several times, and it delayed the review of my requests significantly) [15:48] oSoMoN, I saw https://forum.snapcraft.io/t/interface-auto-connect-request-for-the-telegram-desktop-snap-camera/20383 recently which discussed several requests in one place so I will see if that works for tb as well or if they bounce be asking to open different requests [15:49] yeah, it might work [15:49] perhaps I'm being overly strict/cautious [15:55] being cautious often helps at least to low the delays [16:01] does anyone understand fonts explain me the issue described on https://gitlab.gnome.org/GNOME/pango/-/issues/483 ? [16:02] GunnarHj, ^ you could maybe help me there :) [16:02] basically it's bug #1900729 [16:02] bug 1900729 in gnome-terminal (Ubuntu) "gnome-terminal font settings show only italic version of ubuntu mono" [Low,Confirmed] https://launchpad.net/bugs/1900729 [16:02] g-t changed to filter the fonts and include only monospace ones [16:03] but seems like the Ubuntu one doesn't qualify? but I don't understand why e.g [16:04] 'Ubuntu Mono Regular' isn't considered as a monotype? [16:29] seb128, https://phabricator.services.mozilla.com/D95171 [16:29] oSoMoN, excellent, thanks again! [16:29] np, you did the hard work === ijohnson is now known as ijohnson|lunch [18:37] oSoMoN oh, that is cool... sergio will be happy. He had fixed that in isRunningAsASnap but was asking recently about it [19:35] seb128: No, I have no insight on that gnome-terminal font setting issue. It does the right thing in focal AFAICT. OTOH, isn't "Ubuntu Mono" used by default anyway due to: [19:35] gsettings get org.gnome.desktop.interface monospace-font-name [19:39] GunnarHj, the issue is that pango doesn't consider the Ubuntu fonts to be monotype ones, unsure how that's defined and what's the fontconfig command equivalent to query or check the types === ijohnson|lunch is now known as ijohnson [20:34] seb128: The issue I see is not specific to Ubuntu Mono. In focal gnome-terminal lets me select between Regular/Bold/Italic/Bold Italic for all the listed font families. In groovy there is only one style per family, and in the case of Ubuntu it happens (for me) to be Italic (or possibly Bold Italic). But the issue with only showing one style is present for the other font families as well. [20:39] GunnarHj, it's unclear to me what's wrong there [20:39] is that the api used to filter 'mono fonts'? [20:39] or the way the filtering is done [20:39] or the way the font lists the variants? [20:42] seb128: I can just tell you what I see. The filter seems to pick only one monospace font per family instead of all the available monospace fonts (regular, bold etc.). [20:42] GunnarHj, that's what https://gitlab.gnome.org/GNOME/pango/-/issues/483 is about no? [20:42] GNOME issue 483 in pango "pango_fc_family_is_monospace only looks at first file in family" [Closed] [20:43] seb128: So it seems. And it was incorrectly closed because Matthias thought it was Ubuntu specific. [20:43] could you maybe comment there with your findings? [20:44] seb128: Sure, I can do that later. [20:44] GunnarHj, thanks! [21:17] [21:17] [21:17] [21:17] seb128: I added a comment on the pango [21:17] issue. [21:19] seb128: Sorry, something weird was happening with my HexChat... [21:26] GunnarHj, thanks for the upstream comment! [21:27] seb128: You're welcome. Hope it helps to move it forward. [21:28] I hope it does as well [21:28] if we can't get traction upstream I think we should distro patch revert the commit [21:33] seb128: But which commit is that? The one you pointed at on the Ubuntu bug seems to be rather old. [21:36] GunnarHj, indeed, I hadn't noticed, so maybe it's something else than changed behaviour and broke? [21:37] though in focal it seemed to list other fonts [21:37] I need to do another round of testing, but that's not going to be for today [21:37] seb128: No. Only monospace, but with all the styles. [21:37] k, so maybe it is a pango regression [21:37] or gtk [21:37] thanks for pointing that out! [21:38] Sweet dreams. :) [21:43] 'night!