Weeknotes 2025/2

A very Nix-heavy week. Writing a bunch of derivations to build various software components at $work. The target is an embedded industrial PC - the goal is to have a NixOS config pulling everything together, outputting a disk image that we can just flash straight to the device. We’ll cross the kettle of fish of OTA updates when we get there.

Cleaned up my Nixpkgs pull request for the Openterface host app. I had some feedback from when I initially opened this the other month, and I finally got around to addressing it. Then it got merged. Yay!

Off the back of that, I went on a bit of a goose chase after .desktop files and icons in nixpkgs. In case you don’t know, a .desktop file is a standardised file format shipped with programs to make them discoverable in Linux desktop environments in, e.g. the application launcher. They include the name of the program, the path to the icon for the program, keywords, categories, and more. You can read the spec here.

As part of the aforementioned openterface package, I had used makeDesktopItem which is a nix-specific way of creating a .desktop file as part of the build. This is placed in the derivation’s output share/applications subdirectory.

I idly wondered if I could detect and fix any nixpkgs packages which should have a .desktop file shipped with them, but don’t. So, as a rough first idea I ran:

grep -L 'makeDesktopItem\|\.desktop\|icon' $(grep -r -l qt6 --include="*.nix" ./pkgs)

from my nixpkgs checkout. This gives me a list of all .nix files which include the string qt6 (I.E. they likely use QT libraries as part of their build process) but don’t include the strings makeDesktopItem, .desktop or icon as a very rough attempt to find packages with missing desktop items/icons.

I tested whether a package had a working .desktop file by temporarily installing it with nix profile install. This results in the package being added to your per-user nix profile in /nix/var/nix/profiles/per-user/... which means the .desktop file finding machinery can pick it up. This turned out to be a bit of a mistake:

I was waylaid for quite a while thinking i’d found a dodgy .desktop file in one such package, when in reality it was my KDE install not reloading it’s cache of desktop files properly. Things I discovered in this time:

• .desktop files are scanned and cached by a program called kbuildsycoca6 (for me on plasma6 at least)
• The cache is then stored in files: $HOME/.cache/ksycoca6_en-GB_<some hash>.
• Supposedly you can run kbuildsycoca6 to update the cache, however the only reliable way I found of definitely picking up changes in your nix profile was to rm $HOME/.cache/ksycoca6*, which then seemed to cause a slight delay the next time you pop open the app launcher while it reindexes everything.

Something I then realised was that my method of finding programs with missing desktop entries/icons was totally naive, since a lot of packages automatically install their .desktop file/icons as part of their regular build process. This means that there’s nothing desktop/icon specific in the nix derivation for them, which means that they show up in my silly little grep above.

As it happens though, I did find a package which shipped a desktop file but had no icon - and it turns out this was because it didn’t install the icon file itself. So I made an upstream PR to fix it :)

What I realised is that the best way to approach this would be if I had some means to search nixpkgs based on metadata about a derivation, specifically whether:

• it uses GUI libraries as build inputs, and
• doesn’t produce any share/applications/*.desktop files I’m not aware of that existing, short of you building all of nixpkgs and looking at the filesystem!

The very structured nature of nixpkgs feels like it could lend itself very well to automated scanning for this sort of thing. There’s already a bot which automatically updates some derivations and opens a PR for them