Steam's autoscroll worked, except when it didn't. Every report of that came
down to the same thing: Steam started in a way that carried no -noverifyfiles,
noticed the patched web helper script, put its own copy back, and spent the
session without the flag. There is no way to make every possible way of
starting Steam carry an argument - a game launcher, a shortcut, a terminal,
another program calling `steam steam://` - so the patch stops depending on it.
The check is on size and timestamp, not on content, so the patch is now written
to look untouched: the bytes the flag costs come back out of the script's own
comments, and the timestamp of the untouched copy is restored afterwards. The
file Steam finds is exactly as long and exactly as old as the one it wrote. A
client that verifies its files finds nothing to repair. -noverifyfiles stays as
the fallback for a script with no comments left to pay for the flag.
Two things fall out of that. A patch that keeps the size no longer has to wait
for Steam to close, because there is no size mismatch for the client to chase;
only the growing one still defers. And an installation patched by the earlier
version is quietly redone at the original size on the next apply, so the fix
arrives without anyone having to know about it.
Then the launch paths that were never covered:
- Shortcuts on the desktop itself. Nothing in the XDG search path looks at
that folder, so nothing had ever seen them - and Steam writes one there for
every game somebody asks for a shortcut to. Its name is translated, so it is
read from user-dirs.dirs and handed to the watcher in a drop-in.
- Steam as a Flatpak was never recognised as Steam, so its entry got nothing
while its script got patched - the worst of both. The switch goes after the
application id there, where flatpak passes it on rather than reading it.
- steam-native and steam-jupiter, which are ordinary Steam starts under
another name, and Flatpak and snap entries in ~/.config/autostart.
Two things found on the way: a client update left the undo copy holding the
script from before the update, so undoing would have put an old version back;
and a shortcut edited in place and later deleted would have been recreated by
`disable`.
The branch is created by the first release, and a branch that does not exist
cannot be selected in the Pages settings - so telling somebody to set Pages
first sends them into a wall. Release first, point Pages at it second.
Also says what happens if Pages is left on main: the source tree gets served
at the address the install instructions name, and every one of them 404s.
The publish job had never run. It is the part that produces the apt and dnf
repositories, which is to say it is the whole update mechanism, and finding
out whether it works when a tag is already pushed is the wrong time.
A dry run now builds both repositories with a key generated on the spot,
verifies the three signatures it wrote, and then installs the packages back
out of them - apt on the runner, dnf in a Fedora container - so the thing
being tested is the thing that runs. Nothing is pushed and no release is
created.
The runners force actions/checkout@v4 and the artifact actions onto Node 24
already and warn about it on every run. Current majors instead, so the
annotation goes away and the pin says what is actually running.
The code works on those distributions now; there was still nothing to
install. This adds the two packages and, more to the point, somewhere for
them to live that hands out updates - a package a user has to notice a new
version of and download again is not much better than a checkout.
Both are built from `make install` and nothing else. A packaging script that
lists the installed files a second time is a second description of the
layout, and the two drift the first time a file moves; here the Makefile
stays the only place that says where anything goes. The .deb is staged and
wrapped with dpkg-deb, the .rpm goes through a spec whose %install is the
same make invocation. Both are architecture-independent, so one file each
covers Debian, Ubuntu and their derivatives on one side and Fedora, RHEL and
openSUSE on the other.
The version is not written down twice either. The Makefile has it, the
control file and the spec take it as a placeholder, and check-version.sh
refuses a tag that disagrees - otherwise a v1.0.4 release quietly ships a
program that reports 1.0.3.
The release workflow builds both in a Debian and a Fedora container, signs
the RPM where there is a native rpm-sign, attaches both to the GitHub
release, and then adds them to an APT and a DNF repository on gh-pages,
regenerating the indexes over every version ever published so that pinning
and going back to one still work. Missing the signing key is not an error:
it builds, it says in the log that the repositories were left alone, and the
packages are still on the release.
There is also a check workflow, which is the first time shellcheck actually
runs on this.
Neither package carries a maintainer script. The units are enabled per user
by the program itself, so there is nothing for a package to do as root - and
nothing it could do about the changes in a user's home either, which is why
both descriptions say to run `disable` before removing.
packaging/README.md has the two things that cannot be automated: making the
signing key, and pointing Pages at the branch.
The README asked for "Arch or an Arch derivative" and the code had two
reasons for it. Neither of them was the mechanism, which is why this is
mostly a matter of not assuming.
The first was the flag file. Arch wraps Electron and Chromium in launchers
that read $XDG_CONFIG_HOME/<name>-flags.conf, and that route is the good
one - it survives upgrades and applies to a launch from a terminal. Debian,
Ubuntu, Fedora and openSUSE keep the equivalent under /etc, where it is the
system's file and not the user's, so there is nothing to write and those
applications have to go through their desktop entry instead. That already
worked, because a launcher is read rather than assumed - but only if the
launcher was recognised as Chromium at all, and it was not:
APPNAME=chromium
LIBDIR=/usr/lib/chromium
exec -a "$APPNAME" "$LIBDIR/$APPNAME" $CHROMIUM_FLAGS "$@"
is the shape every one of those wrappers has, and following it needs the
assignments above resolved and -a understood as renaming the process rather
than naming the program. Both are done now, and the wrappers that still
cannot be followed are caught by CHROMIUM_FLAGS and CHROME_WRAPPER, which
nothing but a Chromium launcher sets. Two applications on the machine this
was written on turn out to have been missed for the same reason: Helium,
whose wrapper is followed to a payload full of markers, and ONLYOFFICE,
which ships libcef.so.
Resolving more wrappers made an old inference dangerous. Any launcher that
could be followed also had "<target>-flags.conf" invented for it, on the
theory that a wrapper builds that name from a variable at runtime. For an
application that simply execs its own binary that file is read by nobody:
the flag would have gone to ~/.config/DesktopEditors-flags.conf and the
desktop entry that would have worked was skipped. The name is now derived
only once the target has shown it reads a flag file at all.
The second reason was snaps. /snap/bin/<name> is a symlink to snapd, so
following it lands on /usr/bin/snap and says nothing; the payload is in the
mounted revision, and that tree takes the same marker check as anything
else. They get a settings switch of their own next to Flatpak, and the
launcher entry as their only way in.
Packaging is now a gate in front of the category rather than a category
beside it. A Chromium installed as a snap or a Flatpak was filed as neither
an application nor a browser, so turning browsers off did not reach it -
which on Ubuntu means the default browser. It is a browser that happens to
be packaged as a snap, and both switches apply.
The rest is the same not-assuming: Steam is found in Debian's
~/.steam/debian-installation and in the snap's private tree, the Flatpak
and snap export directories are scanned even when a session started before
they were installed left them out of XDG_DATA_DIRS, /usr/lib/x86_64-linux-gnu
counts as a shared directory the way /usr/lib does, the watcher covers
snapd's export directory and the NixOS and Guix profiles, LANG is read from
/etc/default/locale as well as /etc/locale.conf, and the systemd user unit
directory is asked of systemd instead of guessed - while still following a
PREFIX that was asked for.
Steam writes a desktop entry for every game somebody asks for a shortcut
to, and it starts the same program the client's own entry does:
Exec=steam steam://rungameid/3527290
The scan only ever looked at the first token, found steam there, and filed
the game under the same kind as the client. So PEAK sat in the applications
list reading "on (Steam)", counted towards the applications covered, and
offered a space bar to switch it off again - as though it were something
this program had anything to offer. It is not: a game is whatever engine it
was built with, and none of them reads a Chromium argument.
An entry carrying a steam:// address of its own is not a program, it is one
more way of starting Steam. The client's own entry never has one - it takes
an address from the outside, through %U - and that is what tells the two
apart. Those entries go to the Steam module now instead of into the list.
They keep -noverifyfiles, for the same reason the rest of the Steam handling
has it: starting a game with the client closed is a Steam start like any
other, and without the switch it finds the patched web helper script, puts
its own copy back, and the interface loses autoscroll for the rest of the
session.
Steam compares its installed files against its manifest at every start and
restores whatever differs, which is why its launcher entry carries
-noverifyfiles. The entry in ~/.config/autostart never got it: it points at
/usr/bin/steam, a shell script, so it fell through the Chromium filter in
mca_autostart_apply and was left alone.
A Steam started at login therefore verified, found the web helper script 46
bytes larger than the manifest says, restored it, and the path unit patched
it straight back - an update dialog that begins again every few seconds and
never finishes. The same client started from the menu was fine, which is
what made it look like a problem of Steam's own.
The autostart entry now carries the switch as well. It follows the Steam
setting rather than the autostart one, because leaving it out while Steam is
patched is exactly what causes the loop.
That covers the entry that exists; a terminal or a script still starts Steam
without the switch. So the patch no longer fights back either: a script that
was patched before, is not patched now, and belongs to a client that is
still running has just been restored by Steam, and doing it again would only
have the two of them undoing each other. It waits for the next apply with
Steam closed - the helper is started once, at the start, so patching it now
would not have helped that session anyway.
Also: Steam does not checksum that script, it compares sizes - the log says
"Verifying file sizes only" - while the comments and the documentation
claimed otherwise. And the status screen now tells a patch that is waiting
from one that is missing, instead of reporting both as not patched yet.
"Apply now" had nothing to do in the normal case. Enabling applies, the
watcher handles everything installed afterwards, and the settings and
applications screens apply on their way out - so pressing it answered
"already applied to 14 applications" and that was the whole interaction.
It is now "Re-apply everything": the state is taken back and written again
from scratch. That is the answer to the question the status block can raise
but nothing could act on - Steam showing as not patched after a client
update, an application that drifted, a flag file edited by hand.
Uninstalling an application used to leave the entry shadowing it behind, in
the user home where the package manager cannot see it, offering to start a
program that is gone. A plain apply only looks at what exists now, so the
watcher never noticed either. Those are removed on every apply now, not just
when rebuilding.
A list of names reads like a compatibility list, invites the question of
whether the one you care about is on it, and is out of date the moment
something new turns up. The point is that there is no list: every launcher
is examined and the Chromium-based ones are identified by what they ship.
A desktop entry that already lives in ~/.local/share/applications is the
user's own file, patched in place with the original kept aside. It used to
get the same X-MCA-Generated marker as a shadow copy, which made the next
scan skip it, fall back to the system entry, and overwrite the user's file
with a shadow - and then delete it on revert instead of restoring it.
The two cases now carry different markers. Only a shadow is skipped by the
scan and deleted when undoing; an entry patched in place stays in the scan
and is restored from its backup.
Also: resolve the applications screen's labels once instead of per row per
keypress, and drop code nothing calls.
Middle-click autoscroll for every Chromium-based application on the system:
Electron and CEF applications, Chromium-based browsers, Flatpaks, Spotify and
Steam, plus anything installed later.
The flag goes into an Arch wrapper's <name>-flags.conf where one exists, and
into a shadowing desktop entry where it does not. Steam gets its web helper
script patched and -noverifyfiles on its launcher, because it restores its own
files otherwise. Every change is recorded so it can be taken back exactly.
Felitendo