Appreciate Your Local Linux Beta Testers

Key Takeaways

even if you don't use gestos like Arch Linux Gen 2 tumble weed or various other rolling releases you should be thankful that some people do you have absolutely no idea how many bugs are caught by these dros that are never seen by the time that package makes its way to Debian auntu and various other slower releasing projects be nice to the beta testers and this is a prime example of what I mean all gtk apps are broken in the latest Arch Linux testing Branch this is both gtk 3 and gtk 4 and desktops that use them as well I would usually have used ISC to contact the arch testing team to figure out which exact package causing the issue but due to my IFC client using gtk I'm currently unable to do that and due to the severity and emergency of the issue I'm opening the issue here a bug like this must not make its way into the regular Arch link repos if it's not already too late I only run Arch Linux with testing repos since I'm an Arch Linux tester resulting apps looking like this this is his IRC client clearly this is unusable note though that some things are still working these icons are still rendering UI menus and things like that are still rendering but all of the text is completely gone but here here is the first problem the first two replies using the exact same package versions were unable to replicate the issue so it's something a lot more subtle than just every GTA app is suddenly broken on this latest version and this makes a lot of sense it's both gtk 3 and gtk 4 gtk3 isn't exactly you know being heavily developed anymore so it's got to be something that both of these libraries rely on this was first reported against the gtk4 package but it's actually an issue with the Pango package so the issue was moved over there instead unless you're a gooey developer Pango isn't a package that most people ever really think about but it is very very important for making your Linux system actually work the way You' expect Pango is one of the primary packages involved in text rendering and that would explain exactly why the app is broken like this icons are rendering correctly UI elements like menus are rendering correctly but all of the text is completely gone so the app it's working but the text which is the main core function of an IRC client completely gone however knowing it's not a problem in gtk 3 or gtk 4 and instead in Pango the doesn't actually solve any problems because again people running the same package versions were unable to replicate the problem so it appears to be with Pango but it's not every single user so it's likely something with the data being stored with something on their system that is in some way connected to Pango now they did find some hope one person over in the arch testing IRC was able to reproduce the Pango issue somehow they don't know how but now there are two instances of the problem happening even if everybody else is still unable to do so so now it's a question of what is similar between these systems is this an Nvidia on whand issue and no the person over on IRC has an Intel igpu and then there was another person on Intel igpu that didn't have any problems so clearly it's not that maybe it could be GPU related but it seems unlikely and then a package was spotted that maybe could have been the problem mint themes 2.2.2 D1 these are the themes used on Linux Mint and this is just someone installing it on Arch Linux anytime you start dealing with third party themes if the CSS is wrong things can go really badly L but again removing the theme did not solve anything this is not a win for stop theming my apps and then some discussion must have happened outside the gitlab because someone posted a solution removing home/ docash or just cleaning ref font cache with fc-- f-v is all that is needed apparently running that command fixed all of the issues now the question is why so I guess the solution is every time a user logs in run fc-- f-v and that will solve the problem this is not the solution it is a solution it is a Band-Aid fix but for a problem that has never happened before this date and will probably never happen again maybe it happens I don't know very possible this seems a little Overkill now over a decade ago Arch actually did something along these lines the problem is it's a cache of your font right so if you have more fonts installed regenerating the cash is going to take longer so if you have 100 fonts not a big deal if you're someone that collects fonts if you do font work if you do anything involving a lot of fonts you're just someone who installs a lot of fonts this is going to add a lot of downtime for basically no benefit there is a proper solution here that doesn't involve just constantly regenerating the cash thanks for the input everyone this is clearly not a packaging issue ideally someone needs to come up with a reproducer then submit it to Upstream for what it's worth I can't reproduce it either with this whole thing being being so messy for somebody that can reproduce it now it is time to do a get BCT and work out exactly which patch is causing the issue it's somewhere between 1. 54.0 and 1. 56.0 and somebody went and found it rewrite Pango FC is supported font format since we now require font config 2.15 we can use FC font wrapper which is a much better fit at the same time explicitly reject patn without FC file since our caching is based on the file name and this comment basically lays out what is happening here font config 215 is not correctly invalidating the cach of previous versions causing the cache of the previous font con version being used as is panger started using FC font rapper as of 1.55 which was added in font config 2.15 so I think it is safe to assume the issue is with font config not properly invalidating the cash of the old version causing the FC font rapper feature being broken and with that being broken the font is not rendering I think the best is to just make a PR Upstream to font config making recent font config use cash version 10 instead of Version 9 to split apart FC font rapper cache and non FC font rapper cache the idea that FC font rapper font config has been unnoticed until pangra started using FC font rapper as a core part seems to me if I'm wrong on anything please feel free to contact me I'll send the link here to the pr to font config once I or someone else has made it and here is the link to that PR here is the pr itself now it turns out the problem didn't just affect gtk it's just the most obvious place you're going to spot it it is also going to affect electron applications on electron 29 or older but as you would know as uh someone who uses electron applications a lot of Elon developers like to ship really old versions so you know in this one situation not a big deal and in the case of chromium they just vendor an older version so it's not a problem for them and won't be for a very long time now Upstream font config slightly disagreed on which part of the project was at fault they didn't think that font config itself was the problem adding an object into the font config cache doesn't break compatibility the problem was the behavior in Pango when FC font rapper isn't available and Pango actually does have a patch addressing that problem in this case it's just not going to die if the thing is missing deal with FC font rapper more graciously if the font cache does not contain FC font rapper values because it was generated by a two old font config fall back to the old way of sorting out unsupported fonts and this part right here explains exactly why some users could not replicate the issue so what was happening here is people had systems that had been around for a while and for some people the last time the font config cache was generated was before FC font rapper was being used so for those people no mention of it but other users it was generated after that that point if FC font wrapper is missing it breaks if it's not missing it works so it's a very subtle difference in the cache that unless you know how Pango actually works you would never spot but that tiny little problem is what caused the issue now being an issue with when the font cache was generated this is a problem that is naturally going to resolve itself over time right now might have been a little bit too early but in let's say a year from now in 2 years from now the chance that you haven't regenerated your font cash in that time is very very low so there will come a point where every single font cache has FC font wrapper in it and the problem just doesn't really exist then but for now having a fullback here probably makes a lot more sense now whilst this patch was available in the git Branch initially was thought this wouldn't be aailable in a tagged version until 1. 57.0 and they' have to go and like cherry pick the patch to make sure this you know has actually been addressed thankfully though that's not the case because nobody really knew when that version was going to be coming out a version was made 1. 56.1 and in that version font config handle lack of FC font wrapper in font cache that patch has been addressed this is why it is very important for a Dro to have a testing repo this is why it is very important for dros like Arch Linux like gen like tumble weed and a bunch of others to exist to make sure that things like this actually get used by people before they make their way into stable releases be thankful that rolling release users that beta testers are out there trying things out before they make their way to your system and if you appreciate this people let me know down below and if you really so if you appreciate these people let me know down below also if you like the video go and like the video If you really like the video and you want to become one of these amazing people over here check out the patreon Subscribe s baray Linked In the description down below that's going to be it for me and I think you can tell that I forgot to record the ch [Music] [Music]