GNOME is once again participating in GSoC . This year, we have contributors working on adding Debug Adapter Protocol support to GJS, incorporating vocab-style puzzles into GNOME Crosswords, creating a native GTK4/Rust rewrite of the Pitivi timeline ruler, porting gitg to GTK4, implementing app uninstallation in the GNOME Shell app grid, and enabling recovery from GPU resets.

As we onboard the contributors, we will be adding them to Planet GNOME , where you can get to know them better and follow their project updates.

GSoC is a great opportunity to welcome new people into our project. Please help them get started and make them feel at home in our community!

Special thanks to our community mentors, who are donating their time and energy to help welcome and guide our new contributors: Philip Chimento, Jonathan Blandford, Yatin, Alex Băluț, Alberto Fanjul,  Adrian Vovk, Jonas Ådahl, and Robert Mader.

Yesterday, I wanted to debug a glycin (or Shell) issue on GNOME OS. Turns out, there is currently no documentation that works or includes all necessary steps.

Here is the simplest variant if you don’t develop on GNOME OS and have an internet connection that can download 16 GB in a reasonable amount of time.

First we get a toolbox image to build our code.

$ toolbox create gnomeos-nightly -i quay.io/gnome_infrastructure/gnome-build-meta:gnomeos-devel-nightly

After entering the toolbox with

$ toolbox enter gnomeos-nightly

we can clone and build our project with sysext-utils that are included in our image:

$ meson setup ./build --prefix /usr --libdir="lib/$(gcc -print-multiarch)"
$ sysext-build example ./build

This creates a example.sysext.raw file.

Now, we need a GNOME OS to test our build. We can download the image and install it in Boxes. After logging in, we can just drag and drop the example.sysext.raw into the VM.

Before we can install it, we need to get the development tools for our VM:

$ run0 updatectl enable devel --now

After that, we need to restart the VM.

Finally, we can test our build:

$ run0 sysext-add ~/Downloads/example.sysext.raw

Adding the --persistent flag to this command will make the changes stay active across reboots.

If the changes made it impossible to boot into the VM again, we can start the VM in “Safe mode” from the boot menu. After logging in, we can manually remove the extension:

$ run0 rm /var/lib/extensions/example.raw

Happy hacking!

Recently, I have been using GNOME OS , as my daily driver.

After being a seasoned Linux for long, dabbling in distros like Alpine Linux , Arch Linux , Fedora (and even Silverblue), I tried switching to something more opinionated and that "works by default" all while being hard to break.

And given my existing relationship with GNOME , GNOME OS was a choice worth looking into.

One feature of GNOME OS is that it is immutable (i.e. system files are read-only). It also doesn't ship with a package manager, so it doesn't have functionality built-in to install extra packages.

You can install GUI Applications normally using Flathub (and Snap/AppImage), but installing non-GUI applications like development tools or CLI packages is not built-in.

There are of course several solutions you can use, such as homebrew , coldbrew , but today we will focus on mise .

What is mise?

mise pitches itself as "One tool to manage languages, env vars, and tasks per project, reproducibly."

However, I only use a fraction of it's functionality, in that I only use it to install packages.

How to install it?

The instructions are here: https://mise.jdx.dev/getting-started.html

But essentially it's as easy as running this (remember to read the source of the installer first):

curl https://mise.run | sh

Activating mise

Then you will need to "activate" mise, which essentially makes tools installed by mise available by modifying your $PATH variable

echo 'eval "$(~/.local/bin/mise activate bash --shims)"' >> ~/.bashrc

The instructions above are for bash, so you will need to consult the docs to get instructions for your shell.

You will need to re-login for the mise command to be available, or open a new shell.

A note on shims

Feel free to skip this section, as it's just an explainer

Also, note that the above command use the --shims flag, which is NOT the default. It essentially means that mise will modify the $PATH variable, instead of doing a weird thing where it will re-activate itself after each command you run.

The non-shim way to activate mise is useful when you use mise to install different package versions across different repositories, but that sometimes breaks IDEs and is our of the scope of this blog post.

Installing packages

You can start installing your first package with mise :

mise use -g java

The above command installs java globally (hence the -g flag), which you can now confirm by running:

$ java --version
openjdk 26.0.1 2026-04-21
OpenJDK Runtime Environment (build 26.0.1+8-34)
OpenJDK 64-Bit Server VM (build 26.0.1+8-34, mixed mode, sharing)

You can install much more tools, of which you can find a non-complete list here: mise-tools .

For example, you can similarly install a specific major version of nodejs

mise use -g node@22

Or install the latest LTS version of node

mise use -g node@lts

Or you can be overlay specific

mise use -g node@v25.9.0
mise use -g node@25.9.0 # this works too!

Searching

Use mise search to find packages.

mise search typ
Tool       Description                                                                                                                            
typos      Source code spell checker. https://github.com/crate-ci/typos
typst      A new markup-based typesetting system that is powerful and easy to learn. https://github.com/typst/typst
typstyle   Beautiful and reliable typst code formatter. https://github.com/Enter-tainer/typstyle
quicktype  Generate types and converters from JSON, Schema, and GraphQL provided by https://quicktype.io. https://www.npmjs.com/package/quicktype

Uninstalling

mise unuse -g node

Updating

mise self-update # updating mise itself
mise up          # updating tools installed by mise
mise outdated    # checking if you have outdated tools

Config File

Tools you install with mise globally will be saved in the file ~/.config/mise/config.toml , which you can commit to your dotfiles so you can have similar tools across different machines.

Here's an example of my mise config file at the time of writing this blog post.

# ~/.config/mise/config.toml
[tools]
bat = "latest"
btop = "latest"
bun = "latest"
caddy = "latest"
"cargo:mergiraf" = "latest"
deno = "latest"
difftastic = "latest"
doggo = "latest"
fastfetch = "latest"
fzf = "latest"
github-cli = "latest"
"github:railwayapp/railpack" = "latest"
glab = "latest"
helix = "latest"
java = "latest"
lazygit = "latest"
node = "latest"
"npm:vscode-langservers-extracted" = "latest"
oha = "latest"
pipx = "latest"
pnpm = "latest"
prettier = "latest"
rust = "latest"
scooter = "latest"
tmux = "latest"
usage = "latest"
yt-dlp = { version = "latest", rename_exe = "yt-dlp" }
zellij = "latest"
"github:patryk-ku/music-discord-rpc" = { version = "latest", asset_pattern = "music-discord-rpc" }
rclone = "latest"
mc = "latest"
go = "latest"
"go:git.sr.ht/~migadu/alps/cmd/alps" = "latest"
"npm:localtunnel" = "latest"

After the tools inside the config has changed, you can run the following comand to make mise re-install packages from the config file

mise install

Mise Backends

Mise is able to install packages from multiple sources. These sources are called "backends" by mise.

When you type mise use -g node@22 , it will resolve node against the registry and figure out that the default backend for node is core

Core

The default backend is called core and tools from this backend are usually provided from the official source.

Other tools that are available from core include Node.js, Ruby, Python, etc...

We could also have been explicit with the backend we want to use

mise use -g core:node

You can find a list of all core packages here .

Aqua

You can also install packages from the Aqua registry.

Language Package Managers

You can also install tools from their respective package managers. Here are a few examples

npm

You can install prettier, typescript, oxlint and other JavaScript/TypeScript tools published on the npm registry. Find the tools on npm

mise use -g npm:prettier

pipx

You can install black, poetry and other Python tools from pypi. Find the tools on pypi

mise use -g pipx:black
pipx:git+https://github.com/psf/black.git # from a github repo

cargo

You can install cargo packages with this backed. You need to have rust installed beforehand though, which you can do with mise

mise use -g rust

Then install your packages

mise use -g cargo:eza

There are more language package manager backends like: gem , go and more.

Github

You can install packages from Github directly, as long as the project you are trying to install from uses Github releases

mise use -g github:railwayapp/railpack

mise will usually auto-detect which asset you want to use, but you can also specify the asset glob in ~/.config/mise/config.toml

[tools]
"github:patryk-ku/music-discord-rpc" = { version = "latest", asset_pattern = "music-discord-rpc" }

I heard the news about Seth Nickell’s passing last week, and have been in a bit of a funk ever since.

Seth was brilliant, iconoclastic, fearless.

It’s been a long while since Seth was an active part of the GNOME Community, but his influence on the project can still be seen in its DNA if you know where to look. He arrived on the GNOME scene while still in school with hundreds of ideas on how to improve things. It was an interesting time: We had just launched GNOME 1.5 and were searching for a new path towards GNOME 2.0. The Sun usability study had been published and the community had internalized the need to change directions. Seth rolled up his sleeves and did the work needed to help light that path.

Seth championed radical proposals such as instant apply, button ordering , message dialog fixes , and more. He cleaned up the control-center proposing some of the most visible changes from GNOME 1 to 2. He also did the initial designs for epiphany, pushing for a cleaner browser experience during an era of high browser complexity. He had a vision of desktops as a democratic tool, as easy and natural to use as any other tool in the human experience.

As a designer, Seth was focused on trying to understand who we were designing for and making sure we were solving problems for them. While he wasn’t beyond fixing paddings / layouts, he wanted to get the Big Picture right. He wasn’t beyond rolling up his sleeves writing code to move things forward, but was at his best as a champion and visionary, arguing for us to take risks and continue to innovate .

Spending time was Seth was a hoot. He had such a flair for the dramatic. I remember…

• …the time he sold the design for what would become NetworkManager to a bunch of engineers. He got up on the stage and announced: “We are going to make this [holding an ethernet cable] as easy to use as this [producing a power plug] !” It’s hard to describe how many steps it took to set up networking back then.
• …his vision of an improved messaging system — Project Yarrr. He used (U+2620) as the SVN repo name partially to see how many internal tools weren’t UTF-8 clean.
• …him breaking out into an operatic rendition of “ Tradition ” when  developers were pushing back on a change he was proposing.
• …the time he changed everyone’s background in the RH office to have crop circles over night. He showed up the next morning in a robe dressed as an old-testament prophet, beating a drum and carrying a “RHEL5 IS NIGH” sign.
• …hanging  printouts of hate mail he got for various design choices outside of the Mega Cube (a group activity)!
• And everyone who was around for the Dark Princess Incident will always remember it.

Being one of the public faces of GNOME2 was hard, and he moved on. Later, he worked on OLPC and Sugar, and made his mark there. After that, he seemed to travel a lot. We lost touch, though he’d reappear every couple of years to say hi. I hope he found what he was looking for.

Farewell, my friend. The world now has less color in it.

I got myself a Yubikey recently, and I wanted to use it as a nice convenience to:

1. Grant me sudo privileges
2. Unlock my session
3. Decrypt my LUKS-encrypted disk

I've only managed to do the first two, since they both rely on Linux Pluggable Authentication Modules (PAM). Luckily for me, one of PAM's modules supports U2F, the standard Yubikeys rely on.

First I need to install pam-u2f to add U2F support to PAM, and pamu2fcfg to configure my key.

$ sudo rpm-ostree install pam-u2f pamu2fcfg

Since I'm running an immutable OS I need to reboot, and then I can create the correct directory and file to dump an U2F key into it.

$ mkdir -p ~/.config/Yubico
$ pamu2fcfg > ~/.config/Yubico/u2f_keys

Then I make sure to have a root session open in case I lock myself out of sudoers.

$ sudo su
#

In a different terminal, I can edit the sudoers file to add this line

#%PAM-1.0
auth       sufficient   pam_u2f.so cue openasuser
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so
session    include      system-auth

I save this file and open a new terminal. I type in sudo vi and it asks me to touch my FIDO authenticator before opening vi! If I touch the Yubikey, it indeed opens vi with root privileges.

Let's break down the line:

• auth for authentication
• sufficient passing this authentication challenge is enough (it's not an additional factor of authentication)
• pam_u2f.so the module we load is for U2F, the standard Yubikeys use
• cue print "Please touch the FIDO authenticator." when the user needs to authenticate
• openasuser to fetch the authentication file without root privileges

It's also possible to use it to unlock my session, but it would be a bit reckless to allow anyone with my Yubikey to log into my laptop. If my backpack gets stolen and it has both my Yubikey and my laptop, anyone can log in.

It's possible to make the login screen require either my user password, or all of

• The Yubikey itself
• The PIN of the Yubikey
• Me to touch the Yubikey

If someone fails more than three times to enter the correct PIN, the Yubikey will lock itself and require a PUK to be unlocked. This gives me an additional layer of security, and it's more convenient than having to type a full length passphrase.

I've added the following line to /etc/pam.d/greetd (the greeter I use):

#%PAM-1.0
auth       sufficient  pam_u2f.so cue openasuser pinverification=1 userpresence=1
auth       substack    system-auth
[...]

[!warning] I can lose my Yubikey

I use my Yubikey as a nice convenience to set up a weaker PIN while not compromising too much on security. I use it instead of a password, no in addition to it.

Since I can lose or break my Yubikey and I don't want to buy two of them, I make the U2F login sufficient but not required . This means I can still fallback to password authentication if I lose my Yubikey.

Finally, DankMaterialShell uses its own lockscreen manager too. I still want to be able to fallback to password authentication if need be, so I'll configure it to accept U2F OR the password, not both.

This means that the lockscreen will call /etc/pam.d/dankshell-u2f to know what to do when the screen is locked. Since this file doesn't exist, I can create it with the following content.

#%PAM-1.0
auth sufficient pam_u2f.so cue openasuser pinverification=1 userpresence=1

I need a fallback for when I don't have my Yubikey, so I also create the one for this occasion

#%PAM-1.0
auth include system-auth

Finally, I have a consistent setup where both my login and lock screen require me to plug my key, enter its PIN and touch it, or enter my full password. When it comes to sudo, I can only touch my key without requiring an PIN.

My next quest will be to use my Yubikey to unlock my LUKS-encrypted disk.

At the start of the month, Bilal gave us all a giant gift with Goblint . On the first week it was already impressive. Now it’s an invaluable tool for anyone that ever interfaced with GObject, glib or GTK. It will catch leaks, bugs, or even offer to auto fix and modernize your code to the modern paradigms we use. It’s one of those things that is going to save countless hours of debugging and more importantly, prevent the issues before they even get committed. Jonathan Blandford wrote about using it two days ago, and I suggest you read the post .

Everyone is trying to use goblint, and we are all stumbling upon the same issues integrating it into our tooling. Initially, it was only able to produce Sarif reports, which GitLab still has behind a feature flag , in addition to only  be available in GitLab Enterprise Editions.

I added support for GitLab’s Code Quality format which has some support in the non-proprietary Community Edition we use in the GNOME and Freedesktop.org instances. Sadly, almost everything nice is still only available in the enterprise editions, but at least there is this little Widget in the Merge Requests page.

Additionally, we now have CI templates for Goblint. One is adding a job to the existing gnomeos-basic-ci component we use everywhere. Simply go to your latest pipeline and look for the job .

The report will also show up in Merge Requests that have been updated since yesterday.  The gnomeos-basic-ci has other goodies like sanitizers, static analyzers, test coverage, etc wired out of the box, so you should give it a try if you are not using it yet.

If you do but don’t want the goblint job, you can disable it easily with inputs: goblint: "disabled" similar to all the other tools the component provides.

include:
  - project: "GNOME/citemplates"
    file: "templates/default-rules.yml"
  - component: "gitlab.gnome.org/GNOME/citemplates/gnomeos-basic-ci@26.1"

If you want only a goblint job, I’ve also added a standalone template that you can use. (Or copy-paste from it).

include:
  - component: "gitlab.gnome.org/GNOME/citemplates/goblint@26.1"
    inputs:
      job-stage: "lint"

In order for the Code Quality report to work, you will need to have a report uploaded from your target branch, so GitLab will have something to compare the one from the merge request with. The template rules will handle that for you, but keep it in mind.

At this moment all the lints are warnings so the job will never be fatal. This is why we can enabled it by default without worrying about breaking pipelines for now. You can further configure its behavior to your needs, and error out if you want to, through the configuration file.

min_glib_version = "2.76"

[rules.g_declare_semicolon]
level = "ignore"

[rules.untranslated_string]
level = "error"
ignore = ["**/test-*.c"]

It’s also very likely that we are going to add goblint and its LSP server to the GNOME SDK Flatpak runtime, along with GNOME OS, so it will always be available for use with tools like Builder and foundry.

Enjoy

A few years back I did a quick exploration of what GNOME app icons might look like in an alternate universe where we kept on using VGA displays. Chiselling pixels away is therapeutic. So while there is absolutely no use for these, I keep on making them if only to bring some attention to what really matters for GNOME, having nice apps.

Here's a batch of mostly GNOME Circle app icons, with some 3rd party ones thrown in.

If you're reading this on my site rather than Planet GNOME or some flickering terminal in an abandoned Vault, then congratulations. You've stumbled upon a working Pip-Boy module! Found it half-buried under irradiated rubble, its phosphor display still humming with that familiar green glow. Enjoy these icons the way the dwellers of Vault 101 were always meant to, one glorious scanline at a time.

If you work with patches and git am , then you’re probably used to seeing patches fail to apply. For example:

$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
error: patch failed: gio/gfileattribute.c:166
error: gio/gfileattribute.c: patch does not apply
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

This is sad and frustrating because the entire patch has failed, and now you have to apply the entire thing manually. That is no good.

Here is the solution, which I wish I had learned long ago:

$ git config --global am.threeWay true

This enables three-way merge conflict resolution, same as if you were using git cherry-pick or git merge . For example:

$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
Using index info to reconstruct a base tree...
M	gio/gfileattribute.c
Falling back to patching base and 3-way merge...
Auto-merging gio/gfileattribute.c
CONFLICT (content): Merge conflict in gio/gfileattribute.c
error: Failed to merge in the changes.
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Now you have merge conflicts, which you can handle as usual. This seems like a better default for pretty much everybody, so if you use git am , you should probably enable it.

I’ve no doubt that many readers will have known about this already, but it’s new to me, and it makes me happy, so I wanted to share. You’re welcome, Internet!

I was excited to see Bilal’s announcement of goblint, and I’ve spent the past week getting Crosswords to work with it. This is a tool I’ve always wanted and I’m pretty convinced it will be a great boon for the GNOME ecosystem. I’m posting my notes in hope that more people try it out:

• First and most importantly, Bilal has been so great to work with. I have filed ~20 issues and feature requests and he fixed them all very quickly. In some cases, he fixed the underlying issue before I completed adding annotations to the code.
• Most of the issues flagged were idiomatic and stylistic, but it did find real bugs. It found a half-dozen leaks, a missing g_timeout removal, and five missing class function chain ups. One was a long-standing crasher. There’s a definite improvement in quality from adopting this tool.
• I’m also excited about pairing this with new GSoC interns. The types of things goblint flags are the things that students hit in particular (when they don’t write it all their code with AI). I think goblint will be even more important to our ecosystem as a teaching tool to our C codebase. It’s already effectively replaced my styleguide.
• In a few instances, the use_g_autoptr rule outstripped static-scan’s ability to track leaks. Ultimately, I ended up annotating and removing the g_autoptr() calls as I couldn’t get the two to play nicely together.
• Along the same lines, cairo, pango, and librsvg all lack G_DEFINE_AUTOPTR_CLEANUP_FUNC . It would be really great if we could fix these core libraries. In the meantime, you can add the following to your project’s goblint.toml file:

[rules.use_g_autoptr_inline_cleanup]
level = "error"
ignore_types = ["cairo_*", "Pango*", "RsvgHandle"]

• I had some trouble getting the pipeline integrated with GNOME’s gitlab. The gitlab recipe on his page uses premium features unavailable in the self hosted version. If it’s helpful for others, here’s what I ended up using:

goblint:
  stage: analysis
  extends:
    - "opensuse-container@x86_64.stable"
    - ".fdo.distribution-image@opensuse"
  needs:
    - job: opensuse-container@x86_64.stable
      artifacts: false
  before_script:
    - source ci/env.sh
    - cargo install --git https://github.com/bilelmoussaoui/goblint goblint
  script:
    # Goblint is fast. We run it twice: Once to generate the report,
    # and a second time to display the output and triger an error
    - /root/.cargo/bin/goblint . --format sarif > goblint.sarif || true
    - /root/.cargo/bin/goblint . --format text
  artifacts:
    reports:
      sast: goblint.sarif
    when: always

YMMV