Both failures on run 31383204572, all three distributions, in the same
step, before anything was compiled.
--default-toolchain none was copied from the two fork workflows, where it
is correct: their checkout root is the crate, so rust-toolchain.toml sits
in it and rustup reads the pin. This repository's root has no pin -- it is
in cosmic-comp/, one level down, and the other 27 components have none at
all -- so `none` left no default and the first cargo invocation at the
root failed with "could not choose a version of cargo to run".
stable does not weaken the pin. rustup applies a directory-local
rust-toolchain.toml on entering that directory and installs it on demand,
so cosmic-comp still gets the 1.93 it asks for.
The same logs showed `shell: sh -e {0}`, which is the container default
and is dash on Debian. Two later steps use brace expansion, which dash
lacks and bash-as-sh disables, so the RPM build would have created a
directory literally named rpmbuild/{BUILD,RPMS,...} and failed further
along. Declared bash for the job rather than rewriting around a constraint
none of the three images impose.
Worth recording why this was not caught before pushing: the run blocks
were syntax-checked with bash, which is not what was going to run them.
Checking with dash would not have caught it either -- brace expansion
failing is runtime behaviour, not a parse error. Declaring the shell is
the fix; there is no static check that substitutes for it.
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.
Both files said `name: CI`. The concurrency group is built from
${{ github.workflow }}, which is that name, so the two workflows shared a group
and cancelled each other on every push -- whichever started second would be the
only one that ever reported a result. The compositor and session forks already
say HyprCosmic for the same reason; this one was missed when it was renamed.
Two consequences of becoming the meta-repo, neither of which the merge itself
could have caught.
The submodule URLs were written as [email protected]: because that is how they are
pushed from here. That is a working copy's business, not the repository's:
upstream names all 29 over HTTPS, a clone with no key configured is the normal
case, and CI has no key at all. The URLs are now HTTPS; each submodule's own
origin stays SSH, which is where it belongs.
The assets job asked for `submodules: recursive` back when this repository had
two of them. It now names 29, and 27 are the rest of COSMIC -- several gigabytes
fetched per run to check that some CSS is in step with its generator. It fetches
the one it needs instead.
That one is cosmic-session, because install-assets.sh also places the session
entry point that lives in that fork. The script skips those two files with a
warning when the checkout is absent rather than failing, so a fetch that
silently stopped working would quietly reduce what the job covers instead of
turning it red. Hence the `test -f` after it.
HyprCosmic started as a repository beside COSMIC holding a config compiler and a
pile of theme assets, with the two modified components hanging off it. That had
the relationship backwards. COSMIC already has a meta-repo whose whole job is to
name every component and build the desktop from them, so the honest shape for a
fork is to be that meta-repo with the components we changed pointing at our
copies -- not a separate tree that assumes the rest of COSMIC arrived some other
way.
So this merges cosmic-epoch in and repoints exactly two of its 29 submodules:
cosmic-comp -> outbackdingo/hyprcosmic-comp
cosmic-session -> outbackdingo/hyprcosmic-session
The other 27 stay on pop-os. Nothing about them needs to change, and pinning
them to copies we do not maintain would be a promise to keep 27 forks current.
`just build` and `just install` now build and install the whole desktop with our
compositor and session in it, which is what "fork COSMIC" ought to mean. The two
forks still install into /usr/libexec/hyprcosmic rather than over /usr/bin, so a
system that already has COSMIC from its distribution keeps that session on the
greeter's menu alongside this one.
Conflict resolutions worth stating:
.github/workflows/ci.yml upstream's kept as-is. It builds the entire desktop
on Arch through `just sysext`, which is precisely
the check a meta-repo wants and is not made less
useful by forking. Our per-distribution workflow
moved to hyprcosmic.yml beside it, the same way it
did in the compositor fork.
.gitmodules upstream's 29 entries, then two URLs rewritten.
cosmic-comp, cosmic-session
ours. Git reports "no merge base" because they are
unrelated to the pop-os commits recorded here,
which is expected: they are different repositories,
not newer commits of the same one.
.gitignore both sides, plus a note that the two forks are
deliberately no longer ignored.
Two jobs, shaped differently on purpose.
cosmic-conf gets the same three-distribution container matrix the forks use,
plus one check the unit tests cannot make: it resolves the cosmic.conf this
repository actually ships. A schema change that invalidated the shipped config
would pass all 143 tests in the crate and still break every user on their first
login. The binary is invoked directly rather than through `cargo run`, because
the step redirects HOME and cargo keys its registry cache on it -- `cargo run`
would re-download every dependency into a directory the cache action does not
know about.
The assets job is where the rules that were previously only remembered become
enforced. config.jsonc is regenerated and must not move, which is what stops it
being hand-edited; the template and the generator are held to pure ASCII, which
is what stops a Nerd Font glyph being pasted somewhere it will be silently
destroyed by the next person who retypes it. install-assets.sh is then run into
a staging root and asked to verify its own work, which also exercises the audit
that refuses to install at all while any file under config/ is unclassified.
The ASCII check is written as an `if` rather than `! grep`, because grep exits 1
for "no match" and 2 for "no such file" -- negating it would turn a vanished
file into a pass, and the check would quietly stop checking anything.
This runs on Arch, and shows that things build on another distro with
recent dependencies. If we want to support older versions of
dependencies, that will need to be tested on a different platform.
This also shows what dependencies are needed.
gitops
Jeremy Soller