mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Server stats:

9.4K
active users

#freedesktop

1 post1 participant0 posts today

FreeDesktop GitLab migrated to Hetzner from Equinix

Starting this year, Equinix have decided to end their operations with the FreeDesktop infrastructure after support of almost five years has passed. They have set the tentative deadline of April 30th for migration to other services, and the FreeDesktop team have chosen Hetzner as the server provider. This GitLab instance was also affected, because it hosted a lot of great open source projects, such as X.Org Server, Mesa GL library, and much more.

This migration is now complete, with most (if not all) of the work being done according to the plan outlined in this issue reported against the main FreeDesktop project (Issue 2076). It caused the GitLab server to be much faster than before, which is important for anyone contributing to the FreeDesktop project, especially the developers who contribute a lot of great work to different projects.

The SSH connection has also changed thanks to this migration, along with Fastly CDN, and the new hostname to connect to the FreeDesktop Git instance using SSH has now become ssh.gitlab.freedesktop.org from gitlab.freedesktop.org. You can configure your SSH client to make an alias for the old hostname to point to the new one using the following configuration file created on ~/.ssh/config:

Host gitlab.freedesktop.org    HostName ssh.gitlab.freedesktop.org

The team has prepared a maintenance tracker site, which showed a lot of green lights as you can see here. Alongside this, the untagged runners for the CI workflow have become privileged without support for KVM, and anyone who requires this support must tag them with the kvm tag.

If you’re suffering from slow speeds while working on a FreeDesktop project, this migration is now complete, and you should be able to interact with it faster.

Okay, so hear me out...

Auto updating mechanism made by the #FreeDesktop org for #AppImage apps... no, srsly.

Think of every electron app out there that automatically updates itself. You do know how that's done, right?

Each of these apps have to check a website for a file - and a hash. It then "confirms" that this package is the latest and greatest version of App - your favourite app.

But now you've suddenly got like 10 different updaters, one of which can be an attack vector... yes.

I've finally filed a bug report about the "0% backlight on resume" heisenbug with laptops and docking stations (or port replicators, or external displays), which has been annoying me for decades on #Linux with any #ThinkPad model I've used (also reportedly affects #Framework laptops too): gitlab.freedesktop.org/upower/

I'm not even sure I filed it in the right place. Which #FreeDesktop component might be causing this is completely arcane knowledge.

GitLabWhen resuming from suspend after undocking a laptop that had its lid closed, display panel backlight sometimes resets to zero / minimum (#304) · Issues · upower / upower · GitLabI hope this is the correct place to report this, as I haven't been able to [find] a bug report about this in gnome-settings-daemon or upower, and it...

After GNOME 48's dynamic double/triple buffering, what I'm really looking forward to see, eventually, is #Mutter being able to recover from GPU state resets: gitlab.gnome.org/GNOME/mutter/

On Linux, the open source AMDGPU graphics drivers in #Mesa are infamous for making everything lock up in your face like that.

I'm just crossing my fingers and hoping this will happen by the time distros collectively ditch X11 in favor of #Wayland.

gitlab.gnome.orgMaking sure you're not a bot!
Replied to Børge

@forteller #AppImage support is still done on a per-distro basis, and it really isn't much more than setting permission and executing certain environment variables... I think.

But mayhaps this is a job for ... #FREEDESKTOP

Hello. I'm free desktop... gief money,
We craves it, WE NEEDS IT!!

But yeah, maybe xdg-open should handle that problem. Then distros wouldn't need to do anything to get first rate AppImage support by removing those annoyances.

One can only hope.

So... I wanted to package my Python app using tkinter UI library (it is just good enough for my purpose) as a flatpak. Flatpaks are based on "runtimes" similar to docker base images.

As I did obviously not use any "big" UI framework (Gnome or KDE) and it already provides Python with tkinter, I decided to use the org.freedesktop.Platform as a runtime for my flatpak. The first challenge was to get the dbus-python package to compile, as it requires a dbus binary for compiling it. So I added the freedesktop DBus implementation. I need dbus functionallity, as it allows me to use the "XDG Desktop Portals" to interactively open files when running in the flatpak sandbox. After this, everything worked! :neocat_happy:

Unfortunately, the application cannot load any proper font, so it falls back to the 90s era fonts compiled statically into Tcl/Tk (which tkinter is based on). After some trial and error, and finding out how add custom fonts to Tk, I disovered that the freedesktop runtime does not ship freedesktop fontconfig. And also I can't add it that easily to the build step, too, as the bundled Tk installation does not link to it anyway… :neocat_angry: