An automatic way to do this that scales up and requires little manual intervention is really needed. It works by scraping extensions.gnome.org with a python script,
that writes all relevant information into the `extensions.json`. Every attribute of besaid file can be built into a package using `buildShellExtension`.
Extensions are grouped by Gnome shell version for practical reasons. Only extensions for Gnome 3.36 and 3.38 were added, as we don't support legacy Gnome versions.
The extensions are exposed as an attrset, `pkgs.gnome36Extensions` and `pkgs.gnome38Extensions` respectively. The package name of each extensions is generated automatically
from its UUID.
The attribute `pkgs.gnomeExtensions` contains the officially packaged and supported extensions set. It contains all the automatically packaged extensions for the current
Gnome Shell version, which are overwritten by manually packaged ones where needed. Unlike gnomeXYExtensions, the names are not UUIDs, but automatically generated human-
friendly names. Naming collisions – which are tracked in collisions.json – need to be manually resolved in the `extensionRenames` attrset.
`nix-build -A gnome2.gtksourceview` fails to build with autoconf 2.70 with the following error:
...
autoreconf: running: intltoolize --copy --force
You should update your 'aclocal.m4' by running aclocal.
autoreconf: running: gtkdocize --copy
Can't exec "gtkdocize": No such file or directory at /nix/store/hm8xfxprfk4l1msb9hpjwgydilbqlvl5-autoconf-2.70/share/autoconf/Autom4te/FileUtils.pm line 293.
autoreconf: error: gtkdocize failed with exit status: 2
gnome2.gtksourceview builds successfully with autoconf 2.69.
I don't use these tools anymore, so it makes sense I shouldn't have an
opinion on PRs that change/update them. I know it's always unfortunate
losing a reviewer, but I'm not very active anymore anyway,
unfortunately. Apologies.
From now on, I'm trying not to add too many packages into nixpkgs, since
flakes are available. I guess when I first started using Nix I got
overexcited by how easy it was to contribute, so I added things for the
sake of adding things (not because I necessarily used them).
As `kinfocenter`'s implementation consists of only KCMs, which are
actually just displayed using `systemsettings5`' KCM shell, the
`kinfocenter` binary is just a symlink to `systemsettings5`.
In traditional FHS environments, having a relative symlink to the
`systemsettings5` binary within the same `bin/` directory works just
fine, whereas this is broken on NixOS where `systemsettings5` resides in
a completely different `bin/` directory of the corresponding store item.
Usually CMake's `find_package` should be able to locate the
`systemsettings5` binary, but fails for reasons unknown to do so on
NixOS - so for now fixing the symlink manually as part of the `preFixup`
phase will do the job of making `kinfocenter` work again.
