v0.5.5 — The window, built where it will run

Roadmap item 0.5.5. The one package that cannot be built once and carried.

sudo rpm -i flowlight-gui-0.5.5-1.fedora41.x86_64.rpm

OK: on Fedora Linux 41 the window compiles, names that distribution's own libraries, installs, and runs
OK: on openSUSE Tumbleweed the window compiles, names that distribution's own libraries, installs, and runs

Why this one is different

The daemon is statically linked: the machine that compiles it has nothing to do with the machine that runs it. The window is the opposite — GTK, libadwaita and glibc, all the system's — so one built on Ubuntu 24.04 does not start where glibc is older. v0.5.2 said so and shipped no window outside Debian and Ubuntu, rather than shipping one that installs and does not start.

So it is compiled inside a container of each distribution it is packaged for, and RPM's own dependency scan records what it found there:

Requires: libadwaita-1.so.0()(64bit) libgtk-4.so.1()(64bit) libgio-2.0.so.0()(64bit)
          libc.so.6(GLIBC_2.34)(64bit) … flowlight = 0.5.5

Not one of those lines is written down anywhere in this repository. AutoReqProv is left alone in this spec for exactly the reason it is turned off in the daemon's: there, there is nothing to find; here, the scan is the entire point.

The package names the distribution that built it

Two files called flowlight-gui-0.5.5-1.x86_64.rpm that link against different libraries would be two files nobody can tell apart, so the release tag is filled in from /etc/os-release inside the container that did the building. The daemon's package deliberately has no such tag — the same file installs everywhere, and a .fc41 in its name would claim otherwise.

What is checked, in the order that matters

1. It compiles there at all.
2. libadwaita is at least 1.5 — asked before the build, so a distribution whose libadwaita is too old is named as exactly that in one sentence rather than arriving as a wall of compiler output.
3. The scan named GTK, and named the daemon the window talks to.
4. Installed, ldd finds every library it asks for. not found is the failure this release exists to prevent.
5. It runs as far as --version, which is before GTK wants a display. A loader error happens before a display is ever wanted, so a container with no screen catches it.

The window learnt --version and --help on the way, answered before GTK is touched: a window that can only be asked its version by opening it is a window nobody can check from a script.

The compiler comes from rustup; the libraries come from the distribution

Fedora 41's packaged rustc is 1.91 and this workspace asks for 1.92, so the first attempt stopped before it reached a library at all — and the failure message blamed the distribution's libadwaita, which was a guess and was wrong.

The split that matters is narrower than "build it on Fedora": the point is that the window finds Fedora's GTK, libadwaita and glibc, not that Fedora's rustc compiled it.

Fedora and openSUSE Tumbleweed, and why not Leap

Leap 15.6's libadwaita is older than this window needs. That is a finding, so it is written down rather than left as a silence — and the daemon's rpm still installs on Leap, which CI has proven since v0.5.2, because it is static.

Two smaller things

• The tarball checksums are attached now. The tarball build writes a .sha256 beside each archive and the release was not uploading it, which left the only published hash inside the PKGBUILD — fine for Arch, no use to anybody checking a download by hand.
• Arch's window and a desktop entry are the next item. Arch's is a source PKGBUILD, which is what the AUR is for; and no package yet ships a .desktop file, which means the window does not appear in a launcher anywhere. Both recorded rather than half-done.