Fluxgui's install steps still fetch the binary that stopped working in 2016

Two warnings come before any description

The first line of the file is a heading in capitals saying the package is barely maintained, and the paragraph under it recommends a different project, an indicator applet for Redshift, with a note that this is what the maintainer uses.

The second heading, also in capitals, says the program the project is named after does not work on most modern systems. The explanation underneath is precise. The xflux program that Fluxgui traditionally used to change the screen colour has not worked on most modern systems since 2016. It is a closed source program. It is not part of this project. And there are no plans to fix it.

The consequence is stated in the same paragraph: because of that, Fluxgui now defaults to using Redshift instead, which the file says should be supported everywhere. A link to an issue explains why xflux probably will not work on your system and how to test whether it can.

So the project's own headline is that it is a panel applet for one program, kept around for people who still have a working copy of a different, closed-source one. The rest of the file is the install documentation for that.

The manual install still downloads the dead program

The manual install instructions are the most complete part of the file, and the first command in them fetches the program the warnings just told you is broken:

# Download fluxgui
cd /tmp
git clone "https://github.com/xflux-gui/fluxgui.git"
cd fluxgui
./download-xflux.py

A script in the repository downloads the closed-source binary, and the running-without-installing section for developers says the same thing with the comment that you only need to do this once.

After that the instructions branch into a system-wide install and a per-user install, marked as mutually exclusive, both recording the files they touch into a text file. The per-user branch installs into a local bin directory that has to be on your path, and the file spells out the consequence: autostarting the applet from the desktop will not work if the locally installed program is not on your path.

So the documented install path has a step whose only purpose is to obtain software the project has given up on. The step is harmless and the failure mode is a wasted download, but it is also the clearest sign of how the instructions have aged.

The Ubuntu fix asks you to claim an older release

The archive route is marked as one you probably do not want, and the reason is given in italics in the heading itself: the archive was last updated in 2019 and the last supported Ubuntu version is the 18.04 release, code-named bionic.

The commands themselves are ordinary: add the archive as a source, update, install.

sudo add-apt-repository ppa:nathan-renniewaldock/flux
sudo apt-get update
sudo apt-get install fluxgui

Then there is a workaround section for Ubuntu 20.04 and later. The symptom is an error saying the archive for the focal release does not have a release file. The fix is three steps: open the source list file the archive added, replace the word focal with bionic or whatever your distribution is called, save it, and repeat the update and install from the second line.

Read plainly, that is telling the package manager you are running an older distribution than you actually are, so that a stale archive will hand you packages. The file offers it as the solution rather than as a caveat, and it is also why the section heading tells you to do the manual install instead.

The Fedora list is Python 2 for a Python 3 project

One section is a single sentence: there is no Fedora package provided yet, so please use the manual install. Then the file proceeds to give Fedora dependencies anyway.

That list is the interesting part, because it does not match the rest of the project. It installs the old application indicator binding, a Python 2 version of the desktop specification library, PyGTK 2, the PyGTK 2 libglade module, and a Python 2 GConf binding. Every one of those is from the generation the project moved away from.

The project says only Python 3 is supported, and the dependency list for the other distribution family exists because of an upgrade to GTK 3. So the Fedora list is a Python 2 and GTK 2 stack for a codebase that is Python 3 and GTK 3.

The file carries a warning about exactly this. Above the Fedora list it says the dependencies may be out of date after that upgrade, and invites a pull request if you find the correct ones. The Debian family list carries the same invitation and is described as partial.

So both lists are labelled incomplete by the project that ships them, and one of the two is internally inconsistent with the project's own stated requirements.

Installing chmods your entire working copy

The install script does three things before it installs anything, and the third is worth knowing about.

It first refuses to run unless it is executed from the directory containing it, printing a message and exiting if not. It then sets a restrictive mask so that files installed globally are not left unreadable to anyone but the owner. And then it recursively makes every file in the current directory readable by everyone.

That last one runs as a subprocess against the whole tree, not against the files the installer is about to copy. The comments in the file explain why: the install command preserves permissions on copied files, which causes problems for a global install, and a link points at a fancier solution that would only adjust the files the installer actually touched by subclassing the install command.

The current workaround therefore mutates the permissions of your git clone, which is why the file links to a better approach rather than claiming this one is right. It is the kind of side effect that surprises people the first time they run an installer from a directory they care about.

An archive that stopped in 2019, and a release process with no releases

The repository has no GitHub releases at all, and the release process is described in the contributing section rather than in a release page.

What that section says is that changes go in a changelog inside the Debian packaging directory, and that a version carries a pre-release suffix until it is ready, at which point the suffix is removed from the version strings and committed. The instructions for what to copy at that point are cut off in the part of the file visible here.

So releases are made by hand, from a changelog file inside a Debian directory, and none of them has produced a tag on the repository. The last commit is dated 2026-08-17 and the repository is not archived.

The layout supports the manual process. There is a Debian packaging directory, a schema definition file for the desktop settings at the root, a desktop entry directory, icons at several sizes, a resources directory, a source directory, and a small script whose only job is to fetch the closed-source program.

The coding style section, in the same file, is worth a line of its own because it is unusually specific: match the style of the file you are editing, do not restyle code you are not otherwise changing, because style changes make the history noisy and the blame output misleading.

Uninstalling depends on a file the install generates, and one line has a typo

The uninstall instructions are built on the text file the install recorded, and they pipe it into a removal command:

# EITHER uninstall globally
#
# The 'installed.txt' is generated when you install. Reinstall first if you
# as described above if you don't have an 'installed.txt' file.
sudo xargs rm -vr < installed.txt
sudo glib-compile-schemas "$(dirname "$(grep apps.fluxgui.gschema.xml installed.txt)")"

Two things are wrong with that comment. It tells you to reinstall in order to be able to uninstall, which is a strange sequence, and the sentence itself has a missing word: it reads as if you did as described above if you do not have the file, when what it means is the opposite.

The second command is the more technical half. It finds the schema file in the record, takes its directory, and recompiles the schema cache there, because deleting a schema without recompiling leaves the desktop environment reading a cache that no longer matches what is on disk.

The per-user branch repeats both commands without the privilege escalation. So the uninstall path is correct in shape and depends entirely on a file the installer wrote, which is the reason a package manager install cannot use it and the manual one can.

Editorial conclusion

Fluxgui only makes sense if you want an indicator applet in the desktop panel specifically and your system already has Redshift installed, because that is the only backend the file says works on modern systems. Two things to check before you start. Read the top of the file rather than the install section, because the two warnings above it are the project's own assessment of itself and they change what the instructions are for. And if you are on Fedora or a recent Ubuntu, skip the package manager instructions entirely: the project's own text says there is no Fedora package, that the Ubuntu archive stopped at an unsupported release in 2019, and that the documented fix for newer Ubuntu involves editing a source list to name a different distribution.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. xflux-gui/fluxgui on GitHub