Seeding the config gets the bar and the keybindings up, and then leaves
you looking at a black screen, because the autostart line that sets the
wallpaper named ~/.local/share/wallpapers/hyprcosmic/current directly.
That is a symlink import-theme --assets maintains, so it does not exist
until a theme has been imported -- which on a machine that has just
installed the package it has not.
The same line waited for the daemon with an unbounded loop:
until awww query >/dev/null 2>&1; do sleep 0.2; done
awww is a Recommends and lives in a COPR, so on a machine that never
enabled that repository nothing ever answered and the loop spun at 5 Hz
for the length of the session.
Both now live in hyprcosmic-wallpaper, which falls back to the
distribution's own images when there is no link yet, gives up on the
daemon after ten seconds, and exits 0 on every path so autostart is never
left supervising a process that cannot finish. Fedora recommends
cosmic-wallpapers so the fallback has something to find; nothing in the
dependency chain pulled it in before.
Verified against all five paths: no awww at all, a daemon that never
answers, a fresh machine with no link, a link pointing at a real file,
and a link left dangling by a deleted theme.
Two things anyone installing v0.1.0 would have hit.
The per-user files were listed in install-assets.sh as installed 'by
hand', which meant a clean machine logged in to a bare compositor with
nothing drawn on it and no binding that opened anything. They are now
installed as a skeleton under share/hyprcosmic/skel, laid out exactly as
they sit under ~/.config, and the session copies what is missing at
login. The audit still forces every file under config/ into exactly one
list, so this could not be quietly skipped again.
theme.css, theme.rasi and local.rasi are new and deliberately empty. They
are the relative @imports of style.css and config.rasi, and a missing
@import is fatal to both consumers rather than a warning they skip: GTK
fails the whole stylesheet, and rofi reports the error in place of the
launcher. Every colour they could define already has a default from
palette.css and palette.rasi, so empty is the correct content until
import-theme writes them. style.css's own header has promised 'a sibling
file we create at install time' since it was written; now there is one.
Recommends: nerd-fonts named a package that is in no Fedora repository,
so it could never be satisfied and the font never arrived -- silently,
which is what Recommends does when it cannot resolve. Fedora has no Nerd
Font at all: texlive-inconsolata-nerd-font lands under texmf-dist and
kitty's SymbolsNerdFont under /usr/lib64/kitty, and fontconfig scans
neither. Recommend font(notosansmono) instead, the fallback rules.rasi
already names, and say in the README how to install the glyphs by hand.
The packages could not be installed. Claiming the cosmic-* names put 62 files
in conflict with 25 distribution packages -- something dnf's depsolve never
reports, because it shows up only in rpm's transaction check -- and the only
way to satisfy that was Conflicts against all 25, which erases cosmic-greeter.
On a stock Fedora COSMIC that is the display manager, so the machine comes
back to a text console with no way to log in and no session to fall back to.
So the fork ships what it actually forks. The three changed binaries take
hyprcosmic-comp, hyprcosmic-session and hyprcosmic-conf, the workflow reduces
the staged tree to those plus this fork's own assets, and cosmic-settings, the
portal, the OSD and the rest come from the distribution at the version it
tested them at. No Conflicts, no Provides, nothing erased, and the stock
COSMIC entry stays on the greeter's menu to fall back to.
Debian is the exception and keeps the whole desktop, because COSMIC is not
packaged there in any suite: there is nothing to depend on and nothing to
install beside. Its stock session entry is dropped instead, since start-cosmic
execs the cosmic-session this rename takes away.
`Provides: cosmic-comp = %{version}-%{release}` reads as the obvious thing to
write and is wrong in a way that only shows up at the next boot.
cosmic-greeter requires `cosmic-comp >= 1.5.0`. A Provides of 0.1.0 does not
satisfy that, so dnf's resolution of `install hyprcosmic` is to remove
cosmic-greeter -- which on a stock Fedora COSMIC is the display manager. The
transaction succeeds, nothing warns, and the machine comes back to a text
console.
Verified against the installed set on a Fedora 44 COSMIC machine, where the
same transaction removed cosmic-greeter (`>= 1.5.0`) and cosmic-config-fedora
(`>= 1.0.0~alpha.3`) while leaving cosmic-workspaces alone. Workspaces depends
on a bare `cosmic-comp` with no version, so it is the control: the Provides
mechanism works, only the comparison was failing.
Arch and Debian are not affected and are left alone. Arch's cosmic-greeter
depends on a bare `cosmic-comp` with no constraint, so its provides at $pkgver
resolves; Debian has no cosmic-comp package at all, so its Conflicts and
Provides are precautionary and have nothing to compare against.
Separately, and not a packaging matter: cosmic-session is listed in
/etc/dnf/protected.d/fedora-cosmic.conf on a Fedora COSMIC install. Protected
packages are locked in the solver, so the transaction is unsolvable and
--allowerasing has no effect on it. Installing over a stock COSMIC needs
`--setopt=protected_packages=` on the command line. That is the distribution
declining to let its desktop be removed by accident, which is reasonable, and
overriding it is the operator's call to make explicitly.
Run 31394740824 compiled all 27 components on all three distributions --
two and a half hours each -- staged them, passed the completeness
assertions, and then failed in the packaging step on every one. Three
separate causes, none of them the desktop.
desktop-file-validate rejects DesktopNames (fedora, arch)
hyprcosmic.desktop: error: file contains key "DesktopNames" in group
"Desktop Entry", but keys extending the format should start with "X-"
DesktopNames is the key a display manager reads to set
XDG_CURRENT_DESKTOP, so a session entry needs it, but the Desktop Entry
Specification registers keys for application launchers and the validator
has no entry for it. This is not something the fork introduced:
cosmic.desktop is upstream cosmic-session's file, unchanged apart from the
Exec path, and the copy already installed on this machine as
cosmic-session-1.5.0-1.fc44 fails the identical check. Dropping the key
would satisfy the validator and break the session.
So the validation moves out of the three packaging recipes into one step
against the staged tree, and checks what desktop-file-validate would not
have caught anyway: that Exec is absolute and names an executable this
package actually installs. A wrong Exec puts an entry on the greeter's
menu that dies silently when it is chosen, which is the failure that
matters here; a key the validator has not heard of is not.
The check was run against a staged tree built from the real desktop files
before committing: it passes clean, and it rejects an Exec naming a binary
that is not in the tree, an Exec that exists but is not executable, a
relative Exec, a missing DesktopNames, a missing Name, a missing [Desktop
Entry] header and Type=Link, each with a message saying which file and
what.
SIGPIPE under pipefail (debian, and arch next)
dpkg-deb: error: tar subprocess was killed by signal (Broken pipe)
The Debian package built: 217 MB, correct control, Depends computed by
dpkg-shlibdeps across 17 libraries. It failed on `dpkg-deb --contents
dist/*.deb | head -20` in the verify step -- head closes the pipe after
twenty lines, dpkg-deb dies of SIGPIPE, and Actions runs these steps with
pipefail. Both now write to a file and head the file. The Arch verify step
had the same line waiting for it and is fixed in the same way.
bogus date in %changelog (fedora)
10 August 2026 is a Monday.
Also: the PKGBUILD still pointed at tools/make-packages.sh, which was
deleted when packaging moved to Actions. It now names the two commands
that stage a tree and build from it by hand.
Bumps both forks to the commits that install at upstream's paths, and adds
the packaging that follows from it.
packaging/ holds one definition per distribution -- an RPM spec, a PKGBUILD
and a Debian control template -- and each wraps a tree that `just install`
has already staged rather than compiling again inside the packaging tool.
Building 27 Rust components a second time to produce bytes that already
exist costs hours and creates a way for the packaged desktop and the built
one to drift apart.
One package per distribution, not one per component. Fedora splits COSMIC
into 27 packages, which is right for a distribution tracking upstream. This
is a fork that replaces the desktop as a unit: there is no supported
combination in which you take the HyprCosmic cosmic-comp and the
distribution's cosmic-session, and one package says so accurately.
All three declare a conflict with the distribution's cosmic-comp and
cosmic-session, and stop rather than resolve it. Obsoletes would let a
routine install quietly remove the desktop the machine is currently
running; removing COSMIC stays a decision a person makes.
.github/workflows/packages.yml builds all three, each inside a container of
the distribution it targets, because nothing here is statically linked and
a package built elsewhere records sonames the installing machine will not
have. It runs on tags and on demand rather than on every push -- three full
desktop builds is hours of runner time for artifacts nobody downloads --
and a tag opens a draft release, not a published one.
The RPM file list is generated from the staged tree, and claims a directory
only when no package already owns it. A naive list would have the package
own /usr, /usr/bin and /usr/share, which belong to `filesystem`.
README follows the same reframe: the install goes to /usr/bin, the package
route is documented first, and the conflict is explained where a reader
meets it rather than left to be discovered.
gitops