Due to an influx of spam, we have had to temporarily disable account registrations. Please write an email to accountsupport@archlinux.org, with your desired username, if you want to get access. Sorry for the inconvenience.
GTK apps are completely broken in latest ArchLinux testing branch. (Both GTK3 and GTK4 apps and desktops are affected)
I would usually have used IRC to contact the ArchLinux testing team to figure out which exact package is causing the issue, but due to my IRC client using GTK I'm currently unable to do that, and due to the severity and emergency of the issue, I'm opening an issue here.
While I'll try to get an IRC client that doesn't use GTK, configuring it might take me precious time, if you can, please contact the ArchLinux testing team ASAP!
A bug like this must not make it's way into the regular ArchLinux repos if it's not already too late.
(I only run ArchLinux with testing repos since I'm a ArchLinux tester)
I update my system daily, I updated my system yesterday before going to bed, so it's a recent breakage.
Steps to reproduce:
Just open any GTK apps, attached is a screenshot of polari (IRC client I currently cannot use to contact ArchLinux testing team).
GTK Desktop like Cinnamon crash too with weird visual artifacts.
Qt apps/desktops like KDE and it's apps are working fine.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Doesn't seem to be related. The other person affected is running intel igpu (on Wayland), while @ptr1337 is running Nvidia (on Wayland) and isn't affected.
pango is a font rendering library, it's possible gtk4 was broken for a while and I didn't notice, I don't use Adwaita apps outside or IRC (Polari) or VR (Envision), and I haven't done either in a while as I haven't been feeling good enough to do VR during Christmas season.
Thanks for the input everyone. This is clearly not a packaging issue. Not sure if the PM of affected pkgs is aware (gtk4pangocairofontconfig) so let's cc @heftig just in case.
Ideally someone needs to come up with a reproducer then submit it upstream. FWIW, I cannot repro either...
Well, I do have old ~/.cache/fontconfig that causes it, if that's of any help. The only problem is my firefox crashes now every time file dialog window tries to open to upload it (anywhere), heh.
@zbe Can you perhaps reduce it to a single file by copying from the backup back to your cache dir one-by-one? Only the ones ending in -le64.cache-9 should be relevant.
fe7cc1d4cd57ee188e4676b65bbef367b1201118 is the first bad commitcommit fe7cc1d4cd57ee188e4676b65bbef367b1201118 (origin/reject-fileless-patterns)Author: Matthias Clasen <mclasen@redhat.com>Date: Tue Nov 26 21:15:30 2024 -0500Rewrite pango_fc_is_supported_font_formatSince we now require fontconig 2.15, we can use FC_FONT_WRAPPER,which is a much better fit. At the same time, explicitly rejectpatterns without FC_FILE, since our caching is based on thefilename.pango/pangofc-fontmap.c | 23 ++++++++---------------1 file changed, 8 insertions(+), 15 deletions(-)
Does running an affected app with Valgrind get you any complaints? The backtrace linked above seems entirely unrelated to pango, so I'm thinking this is some kind of stack or heap corruption.
Jan Alexander Steffens (heftig)changed title from All GTK apps are broken in latest ArchLinux testing branch. to Font selection broken as of pango 1.56.0
changed title from All GTK apps are broken in latest ArchLinux testing branch. to Font selection broken as of pango 1.56.0
Might be extraneous information, but my 'issue' with pango-1.56.0-1 was that sway (wayland/wl-roots) started rendering incorrect Unicode codepoints on my py3status bar (ie: U+F6ED was being rendered as U+EF03).
The fc-cache -f -v command fixed it for me as well.
Oh, I didn't notice any problems with any of my GTK{2,3,4} applications.
FWIW, I'm affected as well, using Wayland. This renders many applications unusable. For me, fc-cache -f -v fixes the issue only temporarily. It then seems to re-appear after some time until I run fc-cache -f -v again. I haven't found what exactly triggers it, will continue investigating.
I'm starting to suspect that there's another version of fontconfig (perhaps in packages such as logseq-desktop) which has the same cache version (9) but does not support the font wrapper information.
Is there anything specific you're looking for? In my case, yes, I do see LogSeq write to fontconfig cache-9 files, producing the diff in the comment above.
Note: For example it prevent Cinnamon from starting, and if peoples using Cinnamon don't have another desktop installed, the only option left for them is to use the tty.
I think from what has been discussed and my own manual research it is safe to say:
fontconig 2.15 is not correctly invalidating cache of previous versions, causing cache of the previous fontconig version being used as-is.
Pango started using FC_FONT_WRAPPER as of 1.55.0 which was added in fontconfig 2.15
So I think it is safe to assume the issue is with fontconfig no properly invalidating the cache of old version causing the FC_FONT_WRAPPER feature being broken.
The commit that added FC_FONT_WRAPPER on pango 1.55.0 is:
I think the best is just to make a PR upstream to fontconfig making recent fontconfig use cache-10 instead of cache-9 to split apart FC_FONT_WRAPPER cache and non FC_FONT_WRAPPER cache.
(The idea that FC_FONT_WRAPPER fontconfig issue has been unnoticed until pango started using FC_FONT_WRAPPER as a core part seems reasonable to me)
If I'm wrong on anything, please feel free to correct me.
I'll send the link here to the pr to fontconfig once I or someone else made it.
Updated title, as the picture I sent was not a font selector, but the issue seems to be caused by pango using a feature in fontconfig that seems to either cause segfault (gtk2/gtk3) or severe rendering issues (gtk4).
This is great, so pango 1.57.0 fixed the issue, anyway, from there it's just about waiting for upstream stuff, I still think making a PR to fontconfig would be useful.
Thank you, great find! Unless 1.57.0 is going to be released soon, we should consider cherry-picking that commit before we move pango to the stable repos. I'd be happy to test and help confirm it fully addresses the issue (and, assuming it works, we should no longer need the announcement I proposed in an earlier comment thread).