Gnome 43 support

[NicolasDerumigny]

Add support for GNOME 43. Closes #199.

[fin-ger]

Hi Nicolas,

many thanks for your PR! First of all: are you interested in bringing this PR to a release-ready state? This includes some more effort and may consume quite some time.

If you are I can guide you through on what needs to be changed for this to be released.

[NicolasDerumigny]

Hi!
I literally wrote this at 1 am so time may be an issue, but I am willing to change whatever is needed in order to let this become mainline, given the user's demands :-)

[fin-ger]

Hi @NicolasDerumigny, thank you so much for your work. Sorry for the delayed answer. Yes, we are really eager to not break compatibility with any previous (still supported) version of Gnome, your continued work is in the right direction. This is a real pain in development but I think has contributed quite a lot to the success of this extension. The list you posted on testing this extension including Ubuntu, Debian, and Fedora releases has to be updated to match the distributions current support status (e.g. Fedora 34 and 35 are EOL by now I think, and 36 and 37 are the current old-stable and stable versions). The testing-procedure is quite up-to-date I think. Just do a quick research on what the current support and release schedule for the distros is.

There is a neat little testing helper I implemented in the past: the fake backend. It can be enabled by setting PRODUCTION to no here. This setting is very crucial. This must never be shipped enabled as it punches a security hole into your system and might enable an attacker with access to your local filesystem to gain elevated privileges through this extension (files read by bash, bash sometimes does weird stuff, better not trust it).

For testing however, the fake backend enables testing the extension in virtual machines as no pstate or cpufreq kernel driver is needed any more. You can create an installable ZIP with PRODUCTION=no and test your patch with any Linux distribution from within a VM.

Regarding the annoying stutter and high-CPU usage for frequency gathering: it's a complicated topic. Maybe we should skip fixing that one with this release. If you like to invest a lot of time, I can give you more information on that in the other PR.

Also, this PR should drop support for Gnome versions which are not shipped by the distros in the list you posted here.

Also, there is a new PR for new translations. It would be great to have them included in the next release. Also, I have to check for new translations on crowdin, maybe we got some new stuff there as well. It would be great if you can skim over it and just do sanity checking (e.g. are the most basic strings translated, any misinformation included, no trolling, no ads, no hate speech, no political statements, etc.). I tend to use a number of online translators and the tools of crowdin to do that. Ofc as (I assume) we mostly do not speak all those languages for which translations are landing, something might still slip through. But in this project I've not had any bad experience, so it should be good to go.

Also, the testing should also include the native packages for all the distros. So RPMs for Fedora, DEB for Debian, Ubuntu, and PopOS. In the past, issues only got visible when installed with the native packages. I currently can't really remember what the gotchas were with the native packaging, you may start by running make dist and see which packages you are missing and try to get an RPM and a DEB assembled. I remember that building the DEB was a real pain... Please don't put too much faith into my Makefiles for that, it's quite possible that they are incomplete.

Also, there are the Gnome Extension Review Guidelines. Those must be met for us to be able to upload the update to ego. Especially the unnecessary files part is where we got stuck in the past. But maybe, the next update will be rejected because we do not use libadwaita and Gtk4, yet. I would only want to update to libadwaita when all distros and Gnome versions supported by this extension are shipping it. This is not the case for now.

Either way, when the RPM and DEB package are building, we can distribute updates through other channels, so your work is not completely lost. Just expect trouble when we publish the update on ego.

Wow... quite a write up. I hope you can make any use of it. Please do not hesitate to ask any questions that may arise. Unfortunately, I might need a couple of days for an answer as my calendar is quite packed.

[NicolasDerumigny]

Ok, I had a quick lookup, and:

• I updated the list of distro for testing. I don't have a lot of time right now, so I don't think that I'll be able to test intensively, maybe in December
• GNOME 3.22 is still in used by the Ubuntu 18.04 so there is no need of code change dropping support for it
• I am willing to discuss the frequency CPU reporting issue in the other PR
• I went quickly through the source code changes of Finished pt_BR translation #201 an ave not found any strange thing, though I do not speak portuguese (but French / English, so most of the words are understandable to me)
• I am running on arch, for which debuild is not available (but other tools such as deboostrap are). Do you have any advice on a) switching or b) compiling in a vm / container / chroot ?
• the RPM builds flawlessly

[fin-ger]

Nice, thanks for all the work!

debuild is available in the Fedora repositories, so I just use that one. However, it ships a very outdated distro-info package. I manually updated the csvs located in /usr/share/distro-info to the content of the latest debian package. This made debuild run for me, but it always is a pain to get this running. Tbh I'm amazed how well Debian and Ubuntu are doing with such awful packaging mechanisms... Maybe the Arch wiki has some useful hints, otherwise I remember that I tried running it from within docker but that would not work because the toolchain used containerization for their build-process which was incompatible with docker. But I can't really tell if that is still the case, because I originally planned on using pbuilder, but got stuck with debuild for a reason I can't remember. Maybe debuild actually does work in docker. Nevertheless, you can still just use a plain debian VM and build the package inside the VM. That will work flawlessly.

[hopeseekr]

Great. Now how do I install it, @NicolasDerumigny ??? Your repo has no releases, no zip files.

[NicolasDerumigny]

If you use arch linux / manjaro, I can create an AUR package if you'd like. Else, you need to follow the README, section "Installing for all users". You can also (but I do not advise it) install this version, and overwrite manually the installed files.