[01:21] good morning === callmepk is now known as callmepk[away] [02:56] gnome-shell signed tags e242b25 Marco Trevisan ubuntu/40.5-1ubuntu2 * gnome-shell Debian release 40.5-1ubuntu2 * https://deb.li/sKtG [02:56] gnome-shell ubuntu/master 6e18ad3 Daniel van Vugt debian/patches/ series ubuntu/main-Avoid-meta-finalize.patch * debian/patches: Avoid full meta context finalization * https://deb.li/3nmBM [02:56] gnome-shell ubuntu/master b312dc1 Marco Trevisan (Treviño) debian/changelog * Update changelog * https://deb.li/cGw1 [02:56] gnome-shell ubuntu/master c905fe2 Marco Trevisan (Treviño) debian/changelog * Upload to impish * https://deb.li/394YN [02:57] gnome-shell Marco Trevisan 271305 * commented merge request !57 * https://deb.li/3wNrV [03:34] gnome-shell-extension-appindicator tags 9ca66c5 Marco Trevisan upstream/41 * Upstream version 41 * https://deb.li/36dui [03:35] gnome-shell-extension-appindicator upstream/latest b98ee86 Marco Trevisan * pushed 18 commits (first 5 follow) * https://deb.li/6TXy [03:35] gnome-shell-extension-appindicator upstream/latest 4463b84 Marco Trevisan (Treviño) (9 files in 3 dirs) * build: Use meson to configure, test and install the extension * https://deb.li/ixhd4 [03:35] gnome-shell-extension-appindicator upstream/latest 3a4a046 Ivan Mironov metadata.json * Add support for GNOME 41 * https://deb.li/49aU [03:35] gnome-shell-extension-appindicator upstream/latest 9af5266 Marco Trevisan (Treviño) prefs.js * prefs: Add ability to run it as standalone app with both Gtk 3 and 4 * https://deb.li/3WUHF [03:35] gnome-shell-extension-appindicator upstream/latest 4878539 Andreas Angerer appIndicator.js prefs.js schemas/org.gnome.shell.extensions.appindicator.gschema.xml * appIndicator: Add option to change indicator icons with a custom icon * https://deb.li/3KfkN [03:36] gnome-shell-extension-appindicator upstream/latest 02d7cd1 Marco Trevisan (Treviño) locale/ (13 files) * Locale: Update PO files as per new strings * https://deb.li/vh5V [06:14] good morning desktoppers [06:21] Morning oSoMoN [06:24] hey duflu [06:27] Good morning all [06:33] Morning jibel [06:36] salut jibel [06:36] jibel, I gladly accept your offer to review/merge https://code.launchpad.net/~osomon/ubiquity/+git/ubiquity/+merge/409584 :) [06:36] goood morning desktopers [06:36] salut seb128 [06:36] hey jibel duflu oSoMoN [06:43] good morning :) [06:44] salut duflu oSoMoN seb128 ricotz [06:45] Hi seb128 [07:01] good morning [07:03] good morning [07:04] Hi jpnurmi and didrocks [07:06] hey duflu, jpnurmi [07:11] salut didrocks [07:15] salut jibel [07:18] hey duflu didrocks jibel [07:18] hi jpnurmi === callmepk is now known as callmepk[away] === callmepk[away] is now known as callmepk [07:45] didrocks, thx for the libportal MIR followup ! [08:01] yw seb128 [08:41] oSoMoN, LGTM, but what do you think of moving the helper to misc.py? [08:47] juergh, bug 1945842 suggests the proposed raspi kernel still has no display (?!) [08:47] Bug 1944397 in linux-firmware-raspi2 (Ubuntu Impish) "HDMI does not display anything with Impish RPi desktop image" [Undecided, Confirmed] [duplicate: 1945842] https://launchpad.net/bugs/1944397 [08:51] seb128, thank you for dealing with vala :) [08:52] duflu, using the kms overlay instead of fkms is insane ... there is one thing the Pi is really good at and that is HW video decoding, the kms overlay forces all decoding in teh driver off ... [08:53] I've been away from Pi for a while, but last I checked everyone had stopped using fkms [08:53] we'd lose a lot of customers in IoT if Ubuntu Core did such a switch [08:54] ogra, it happened in 21.04 already AFAIK [08:54] (wheer the Pi is mainly used in digital signage ... mainly for video playback ...) [08:54] duflu, yes, for desktop and it is awful ... cant use kodi anymore, can't play vlc video without eating all cores etc etc [08:54] and is what the Pi Foundation does and recommends. So if there's a problem then it should be reported... that said I am about to cancel the next meeting because it clashes too much [08:55] well, it is a known fact ... and afaik the foundation tells so as well [08:55] oh, and it makes the Pi camera interface unusable too [08:55] oSoMoN, seb128, https://ftp.mozilla.org/pub/thunderbird/candidates/91.2.0-candidates/build1/ [08:57] Oh, actually it doesn't clash so doesn't need cancelling. [08:58] duflu, it isnt like decoding doesnt work at all, the Pi4 has enough CPU boom to do it in SW ... but this is not what most people expect from it (since you can play video without any CPU utilization with fkms) [08:59] ogra, sounds worse than I expected and decoding is something I've never looked at. I suggest you get waveform to add you to the meeting with Pi Foundation on 21 October to get answers [09:01] duflu, you can test with my vlc-pi snap, it is linked against the pi libs and runs find on our desktop for me (i also have a GBM based kodi-pi-standalone snap but that wont work with desktops (GBM completely claims the graphice HW here) [09:02] *fine [09:03] it works with and without fkms but you will find 60-80% utilization for all 4 cores on the device when using kms [09:04] Kodi is not something I would recommend making part of formal discussions because it's usually associated with piracy... unless the Pi guys also care about it [09:04] kodi is just a player 😛 [09:04] Yeah I know [09:05] (and given the foundation offers a patches version in their PiOS archive i guess they care about it too 🙂 ) [09:05] *patched [09:05] (i'm using their patches in my snap) [09:30] ricotz, great [10:07] ricotz, ack [10:20] jibel, done [10:32] duflu, ogra, just to weigh in here: the pi foundation are generally recommending we move to kms as that's the supported stack for the future; fkms is considered legacy and (eventually) won't be supported. However, with the current issues we're experiencing with the impish kernel I'm strongly considering switching the image (and upgraders) to fkms at least until things are stabilized under kms [10:32] waveform, 👍 [10:33] That said, in experiments with the current upstream kernel (to determine whether kms was fully working there), we did note that fkms didn't boot at all (and we have been warned there is likely to be breakage with fkms in the near future) [10:34] I'm well aware that kms doesn't operate with the picamera interface; likewise that's considered legacy and libcamera is considered the future there (although at the time of writing there's no equivalent "high level" library on top libcamera available -- if I ever get the time it's something on my list to correct) [10:36] as for hardware H.264 decoding that's something I need to quiz the foundation about -- they *do* care about kodi (and video playback generally, as demonstrated by their recent move regarding distribution of libwidevine), but it's not their core business, and I'm not sure whether the lack of GPU-accelerated decode (given the CPU decode works, albeit with CPU load) would be enough to divert them from their current course of pouring resources [10:36] into kms (which also opens up the vast majority of the graphics stack) [10:36] anyway, enough waffle from me :) [10:37] Aside from decoding, if you want smooth graphics without tearing KMS, not fake KMS, is the solution that seemed to work for 21.04. I would be sad if we regressed to FKMS but also my work here is done, so do what you gotta do [10:39] indeed -- tearing is an issue with FKMS, but at the moment the impish kernel with KMS results in crashes of the video stack (display freezes; everything else keeps running happily, you can SSH in, but obviously a frozen display is a big deal on the desktop!). Upstream appears equally afflicted, and we almost certainly don't have time to implement a fix before release, hence why I'm considering the (admittedly not ideal) move to FKMS at least [10:39] until we can get the kernel issues sorted [10:44] o/ [11:22] seb128: hey [11:22] I've some bugfix release for appindicator extension at https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-appindicator [11:22] I'm undecided whether I should sync it or no :) [11:27] Trevinho, hey, the changelog mentions new strings, it can probably wait for next cycle, probably better to cherry pick specific fixes if you think there is anything important for impish (but it doesn't sound like?) [11:40] seb128: ok, strings are mostly used by the settings which are quite advanced usage (not the extension itself), but I'm fine to wait for the same reason [11:42] waveform, my personal fear is that we switch to kms on Ubuntu Core too early ... there h264 decoding is a main reason for most customers to go for the pi ... as long as MMAL (or any future replacement) doesnt work with kms we should clearly refrain from switching ... (i also see (well, hear) audio issues when switching to kms on UC20 ... pulse doesnt find any devices anymore (fkms works just fine)) [11:47] ogra, my understanding is there's no plan to migrate MMAL to kms (it's also seen as a broadcom-specific legacy API), though I'm not 100% clear on what the future APIs are there beyond v4l. For audio, we've had no (kms specific) issues on the desktop under hirsute, so I'm not sure what's happening there, but there are no plans to switch core20 over to kms. Core22 though is up for debate (and will likely depend on what happens during the impish [11:47] cycle with the kernel and kms) [11:49] waveform, yeah, i dont particulary care for MMAL, as long as there is any other way to have accel and make use of the one feature the Pi is really good in 🙂 [11:50] if they do some sgtreamer integration that allows using the HW codecs, provide their own libs or whatnot, would be fine ... the point is that UC is a paid for product and we can not/should not regress there [11:50] *gstreamer [11:51] (particulary for that feature) [11:51] i doubt Pi desktops are used a lot commercially 🙂 [11:57] I agree we shouldn't regress, but if fkms is going to have support issues going forward (and it's looking that way from our experiments with the upstream kernel) we'll have to make a choice sooner or later [11:59] waveform, well, i assume people like popcornmix have a plan going forward ? [12:05] Hi oSoMoN! Am I on the right track at , or is there any secret with snaps and fonts that I haven't figured out yet? [12:05] seb128, do you reckon uploading thunderbird 91.2.0 to impish is reasonable at this stage? (taking into account that it's a RC, but it should become a proper release before impish is released) [12:06] oSoMoN, yes, attach a bug reference in case the release team wants to keep it as 0 day SRU instead [12:08] GunnarHj, it would help if you opened bug reports with specific of something not working as intended, reading your post it's not clear to me what issue you are trying to adress [12:13] seb128: The background is that I started to look at bug #1945817, and discovered that the Firefox snap seems to ignore the extra font configs provided by language-selector-common. It means that neither those files not config files shipped with additional fonts packages installed by the user will work. [12:13] Bug 1945817 in ubuntu-meta (Ubuntu) "Change default Amharic font from Abyssinica SIL to Noto Serif Ethiopic" [Wishlist, In Progress] https://launchpad.net/bugs/1945817 [12:14] GunnarHj, reading your post, I think you have a much deeper understanding of fontconfig than I do :) james_h has done quite some work on fonts and snaps, can you try tagging him in your post. We definitely want firefox to be using the right fonts. [12:16] it doesn't seem specific to firefox though, is it? [12:16] sounds a bit similar to https://forum.snapcraft.io/t/snap-package-cannot-read-fonts-conf [12:17] oSoMoN, though you suggested '/etc/fonts/conf.d ' there but that seems a workaround rather than a fix? I mean it suggests that it's still going to ignore the configuration? [12:18] oSoMoN: Ok, I'll tag james_h. [12:18] please move to a new topic, probably best on forum.snapcraft.io [12:18] seb128: Yes, indeed it affects snaps in general. But Firefox is most urgent to deal with ATM, right? [12:18] we can't discuss every single snap issue in the same past as we are doing on that firefox one [12:19] GunnarHj, well, my point is that the fix is probably not be in firefox [12:19] so if it's snapd or the desktop helper that the fix is needed we should post in a place where the right people will see it [12:19] which is not in the ubuntu discourse in an endless discussion about firefox [12:20] it's fine cross referencing to the new post though [12:24] seb128: One theory is that it can be fixed in fonts.conf in gnome-x-xx-xxxx. But I'll read the forum.snapcraft.io thread you pointed at to start with. [12:24] ack [12:52] kenvandine: I see that you merged https://github.com/ubuntu/snapcraft-desktop-helpers/commit/ec861254 very recently. Is there a way yet to test if that is effective for the Firefox snap? [12:52] Commit ec86125 in ubuntu/snapcraft-desktop-helpers "fix font render for modified fonts (#213)" [13:09] GunnarHj, firefox doesn't use the helper, unsure how the extensions are synced with such changes though [13:13] seb128: Then I'm lost. :( [13:14] GunnarHj, my recommendation would be for you to start providing an example of what isn't workin [13:15] like a website you browse which is rendered wrongly, and pointing out what config should make it work and isn't read [13:17] seb128: Sure, that's precisely what I did yesterday before posting to discourse. I can document some Chinese or Arabic example for instance. [13:21] seb128, what was the workaround for running `snap pack` on impish? running mksquashfs? [13:23] seb128: Just for my understanding: Is the helper something else than gnome-3-38-2004? [13:24] oSoMoN, they suggested refreshing snapd to edge, but otherwise what I did was to call /snap/snapd/current/usr/bin/mksquashfs [13:24] ack, thanks [13:24] GunnarHj, right, your post explain your conclusion but now what you tried so it's difficult to try locally [13:25] GunnarHj, yes, the helper was a standalone script which could be used as a part before that was adding to snapcraft as extensions [13:25] GunnarHj, I think https://github.com/snapcore/snapcraft/blob/master/extensions/desktop/common/desktop-exports is the modern equivalent [13:27] seb128: Ok, thanks. I'll edit my discourse post (again) and include a step by step description how to reproduce the problem. [14:02] kenvandine, hey, ready for another round of rls triaging? [14:02] seb128: yes [14:03] great [14:03] jibel, ^ [14:03] o/ [14:03] should I drive? [14:03] please do [14:03] yes [14:04] alright, let's go [14:04] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-incoming-bug-tasks.html [14:04] only triaging to do there [14:05] the gstreamer one is fixed, the others are assigned and being worked on [14:05] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-tracking-bug-tasks.html [14:06] those are assigned [14:07] kenvandine, note that jibel added some content to bug #1933828 since last week [14:07] Bug 1933828 in OEM Priority Project "NTP servers from DHCP are not propagated to timesyncd" [Critical, New] https://launchpad.net/bugs/1933828 [14:07] unsure if you want to revisit [14:08] it still feels like that's not a rls issue for impish, we can SRU a fix there as we target focal [14:08] still would be nice to see progress so maybe to check with hellsworth where we stands? [14:08] yeah, it's too late for impish anyway [14:08] but I'd like to have it done sooner than later when jj opens [14:09] i think hellsworth has her test environment setup for that [14:09] so yeah, should be able to do it early in jj [14:09] alright [14:09] moving to hh [14:09] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-incoming-bug-tasks.html [14:09] no desktop one [14:10] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-tracking-bug-tasks.html [14:10] either assigned or being worked on [14:10] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html [14:10] no desktop ones [14:10] seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839 is assigned to laney [14:10] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html [14:10] Launchpad bug 1922839 in gnome-terminal (Ubuntu Hirsute) "Opening new tab in gnome-terminal launched from nautilus loses most environment variables" [Medium, Confirmed] [14:10] should it be reassigned? [14:11] I'm sure laney still wants to fix that :) [14:12] we should probably fix it by updating to the current 3.38 [14:12] GunnarHj, maybe you would be interested to check that one? ^ you had been dealing with g-t or vte in past cycles, it's jut a patch to cherry pick [14:13] k, moving on meanwhile [14:13] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html [14:14] i have a bug on there i should really re-assign :) [14:15] bug #1933168 unsure why I nominated it, doesn't seem important for focal [14:15] Bug 1933168 in gnome-shell-extension-ubuntu-dock (Ubuntu Focal) "Show Applications button does not bring up application after setting show-favorites to false" [Low, Incomplete] https://launchpad.net/bugs/1933168 [14:16] I'm going to wontfix, it's a non default gsettings, would be nice to fix but not a rls tracking one [14:16] seb128: I can look at it, but probably only tomorrow. I.e. under one condition: That the FF fonts issue gets the priority it deserves. :) [14:16] GunnarHj, alright :) [14:17] FF fonts? [14:17] firefox fonts, see backlog [14:17] the snap isn't reading the language-selector config snippets needed for arabic or other languages [14:18] kenvandine, Gunnar pinged you earlier about https://github.com/ubuntu/snapcraft-desktop-helpers/commit/ec86125 , wonder if we need something similar for firefox [14:18] Commit ec86125 in ubuntu/snapcraft-desktop-helpers "fix font render for modified fonts (#213)" [14:18] or rather in the snapcraft extensions [14:18] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html [14:18] no desktop entry [14:18] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html [14:19] nothing unassigned (we still don't track that things are being working on once assigned but that's not a new issue) [14:19] and that's it for rls I think? [14:20] GunnarHj: ah, yes the same fix needs to be made in snapcraft then firefox needs to be rebuilt with that version of snapcraft [14:21] seb128: yeah, that's it [14:26] GunnarHj: https://github.com/snapcore/snapcraft/pull/3586 [14:26] Pull 3586 in snapcore/snapcraft "Ported font rendering fix from the desktop helpers." [Open] [14:32] please retry https://autopkgtest.ubuntu.com/packages/a/automake-1.16/impish/s390x for vala/0.52.6-0ubuntu1 [14:32] kenvandine: That sounds promising. Any chance it can be accomplished before the 21.10 release? [15:15] ricotz, retried === muktupavels_ is now known as muktupavels [15:54] seb128, thanks, could you check if you actually retried it? [15:54] https://autopkgtest.ubuntu.com/running#pkg-automake-1.16 [16:05] ricotz, it went to a authpage I think, should have worked now [16:08] seb128, there is it now, thanks :) [18:35] seb128: kenvandine ack. i'll update the nm bug today. [18:36] thanks