The below list contains software that users of GNU Guix would like to
see packaged. If you are interested in contributing to Guix, please
consider packaging something in this list while keeping in mind that some may have been listed because they are "difficult" or elusive. If the package you're
interested in is already listed, feel free to either add a "(+1)" next
to its name or increment the vote count, e.g. "(+1)" -> "(+2)", etc.
So Before adding a package to this list, please verify that it hasn't
already been packaged.
In addition, Guix is a distribution that follows the Free System Distribution Guidelines (GNU FSDG) and as such not only it only has free software but these guidelines also have additional requirements (like for instance not steering users toward the installation of nonfree software, no Malware, etc).
So it would be a really good idea to point if the package is already packaged by either a Free GNU/Linux Distribution or a Free Non-GNU Distribution, or at least try to see if that software is fully free software and doesn't have any nonfree dependencies (like nonfree firmwares, libraries, other nonfree packages and so on) or if not indicate if it wasn't checked in order to prevent accidental inclusion of nonfree software in Guix (that could happen for instance if each party assumes that the other people checked while no one checked).
Parabola also has a blacklist repository which contains list of nonfree software found in Arch that Parabola blacklisted and sometimes replaced. It also contains perfectly fine software which is blacklisted for other purposes, like renaming "Arch Linux" in "Parabola" in some packages, but the reason of the blacklist is specified.
OpenToonz *Note: Already available pre-packaged in Parabola GNU/Linux. So the hard work for this one is already done.*
Natron *Note: On the github releases page, recommended to use precompiled binaries with patches for qt4 and python2 are provided. That one should be used for GNU Guix.*
rtl8821cu While the firmware binary has been released under the GPLv2(+?), it lacks corresponding source code. So someone needs to do the work to reconstruct the source code from the binary. See the link in Group:Hardware/research/WiFi/Realtek for more details.
rtl88x2bu While the firmware binary has been released under the GPLv2(+?), it lacks corresponding source code. So someone needs to do the work to reconstruct the source code from the binary. See the link in Group:Hardware/research/WiFi/Realtek for more details.
mat2 (+1): wip, Parabola, most probably fully free without nonfree dependencies and FSDG compliant. Some work might still be needed to make sure test passes as we probably want to avoid bugs in software that people might rely on to stay alive.
Pijul Old version available in a community channel pijul.scm
The Tor Browser has an issue that makes it incompatible with the Free System Distribution Guidelines (GNU FSDG): it is configured to use Mozilla the addons repository.
Several strategies are possible to get it in Guix and it might be possible to combine some of them together.
The Tor Browser project might find it very interesting to use Guix instead of Ubuntu for building the Tor Browser as Guix goes way beyond reproducible builds: It has extensive work that has been done to make Guix bootstrapable. Most other distributions only care about reproducible builds and so if the compilers binaries had a backdoor, software built with such compilers could then have a reproducible backdoor.
The issue is that the Tor Browser supports several operating systems (GNU/Linux, Android, Microsoft Windows, MacOS) and currently Guix only supports building software for GNU/Linux, GNU/Hurd and Microsoft Windows (this was contributed by someone wanting to build bitcoin with Guix precisely because extensive work has been made to make Guix bootstrapable).
Adding the ability to build applications for Android should probably be doable but I've no clue at all about MacOS.
In addition Guix already supports i686 and x86_64 for both Windows and GNU/Linux, and we might gain the ability to get the Tor browser for armhf, ARM 64bit (aarch64), powerpc, powerpc64le (the architecture used in the Talos II), riscV64.
And finally Guix pack also support several formats, like tarballs and Debian packages, and more can also be added as well. That would enable the tor-browser to be installed as a regular package. That could be handy with Tails for instance as last time I checked it was just a tarball being extracted.
In any case, it would really be a good idea to make the upstream Tor Browser project switch to Guix for their releases as we would avoid having to do any Q/A to verify that our version of the tor-browser looks exactly the same on the networks and that websites can't distinguish Guix users because it has been patched or built differently. And other FSDG distributions with less strict policies on bootstrapability could either build it though Guix or ship the tor-browser installer as it would then only ship software that is FSDG compliant.
We'd also need to make sure that users don't mess up trying versions that are not exactly the same as the released one (that might happens if the dependencies gets updated in Guix for instance). In any case we could then easily package the tor-browser installer in Guix too.
In addition it could push them to fix or accept fixes for the addon repository problem as Guix is probably not going to accept a tor-browser that is not FSDG compliant.
Now with the addon repository, several approaches could be taken:
It could be removed completely. The Tor Project advise against installing addons anyway as it could de-anonymize users. That's probably the best option here.
It could also be fixed at Mozilla but I've no idea how easy it is, especially because we might need to check if the addons are really free software and can be built with free software, etc.
In any case it's probably not super important what option is chosen here as long as it's fixed.
Add more cross toolchains for more CPU architectures
armv4t looks like a good idea as many older ARM boards that boot with free software could then be supported. Debian still officially supports armv4t, so it might be possible to copy their settings and fixes.
Add an xtensa-elf target as it's probably already supported within packages for building the ath9k_htc firmware
Find if other firmwares from other architectures are being built
Add more cross toolchains for more OSes
It would be a good idea to be able to build binaries for Android, we already have a bit of Android components in Guix but they can only be used on GNU/Linux or other already officially supported toolchains or OS. It would be a good idea to add an Android / bionic target. We'd need to check how much bionic is linked to the kernel version being used on the Android device.
Add more Guix pack or guix system image formats
We could add Arch Linux packages to guix pack be able to be used on Parabola.
We could enable to ship multiple package in one Debian package (currently that works with the tarball format of guix pack but not with Debian packages)
Add a way to deploy Guix in a directory in a way compatible with LXC
LVM-Support (+5) Guix now has LVM support but it might not be fully complete. I for instance managed to boot a Guix SD system from an ext4 rootfs that is in a LVM partition that is in a LUKS encrypted partition with this guide and by following the official documentation.
Integrate better letsencrypt/certbot. Currently certbot works fine if you already have certificates: it can renew them and so on. But if you use webroot you need the web server to be started for certbot to create or update certificates, but nginx (which is the web server best supported by guixSD API) won't start without the certificates. People deploying services with Guix typically have to do workarounds because of this issue. A solution would be to add a --standalone option for certbot and once the certificate is obtained to trigger the switch to webroot and starting the web server with a hook like it's done when renewing certificates.
Add a better way to deal with secrets or external files: Currently it's up to users to do the provisioning of secrets like VPN credential files. If they package it somehow they end up being in the store and being a security risk as any users could see them. Having to manually provision such files might work in some cases but it doesn't scale well as to do it right we'd need to make a provionning method that works for all the cases (all the different types of images, etc). A solution would be to add some extra option to guix to also include extra files or tarballs. This way the files would be added for all images types (docker, qcow2 system images, disk images, with guix system init, etc).
Add generic ways to generate very small rootfs. For instance there is some support for initramfs already. Now that there is ppc64le support, if we can make images that fit into (128M?) of flash and that OpenBMC is packaged in Guix, it could probably completely support RYF computers like the Talos II. If we have a good enough abstraction like a target OS for instance, we could probably add the software we want in initramfs and/or in the BMC and configure them like a regular Guix system from the host computer. There is already support for managing VMs through a ganetti API in guix and there are also childhurds in Guix.
Cross distributions bootstrap
Enable to install Parabola and Hyperbola from Guix. Status: wip. I've got some failures with pacstrap on GuixSD because the PATH is not the same than Parabola's path. I don't know where Parabola's PATH comes from though as /etc/environment is empty by default. Note that some packages need to be refreshed to work as Parabola and/or Hyperbola don't keep many older packages and sources. But once all that lands in Guix it shound't be an issue anymore as the source should be made available though software heritage, and guix will fallback to it.
Package Guix in Parabola. Currently Guix package only worked on x86_64, so I added a guix-installer package to make sure we could still install it in a safe way (where we have some chain of trust with gpg during the installation).
There are many bugs and patches on https://issues.guix.gnu.org/, so if you want to help it might be a good idea to try to fix bugs, review patches and so on.
TODO
When libreplanet.org is upgraded to a new version of MediaWiki, use interwiki links to link to the Free Software Directory for descriptions of wishlisted software.
Sandboxes (in containers/VMs/Websites) where you can play around and learn about
packaging software (like the debian packaging tutorials)
learning the in and outs of the language which is used for packaging
how to package software which has dependencies in some language-specific artefactories (pip, crates, maven and so on), especially if you want to one-shot them, so you have them and do it properly later.
The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom.
We defend the rights of all software users. (Read more)