Every AppImage came out as "cannot tell" because the payload is a
compressed filesystem and none of the Chromium markers is on disk to be
found. The names are reachable, though: squashfs keeps the name of
everything it holds in one table of a few kilobytes, and a name is all
this question needs. That table is now read and inflated in place -
nothing is unpacked, and the image is never run, which a scan started by
the path unit has no business doing anyway.
So a Tauri AppImage such as Modrinth is recognised as WebKitGTK and
dropped from the list instead of being offered as something that could be
switched on - there is no autoscroll in WebKit to ask for - and an
Electron one is covered like any other application.
Left as "cannot tell": lzo and lz4, which squashfs stores as bare blocks
no tool will read without their own framing, and the original ISO9660
layout.
Alongside:
- The detect cache carries a format line. Its entries are keyed on size
and mtime, so an AppImage that has not changed would otherwise keep
answering the way an older version decided it did, forever.
- A marker list for whole-tree searches, which is what a Flatpak, a snap
and an AppImage need. icudtl.dat, snapshot_blob.bin and resources.pak
are out of it: Flutter ships an icudtl.dat in data/, and next to a
binary those names are evidence while four directories down they are
not. The Flatpak and snap searches now share that list.
KDE's own middle-click paste is turned off along with everything else. Inside a
Chromium application the flag already settles it - with autoscroll on, Blink
stops pasting the primary selection - but everywhere else on the desktop middle
click goes on pasting, which is the thing this program exists to get away from.
KWin has a switch for it on a Wayland session, where the paste is a protocol
the compositor either offers or does not, and that is what gets written. It is
true from the next login on. What the key said before is recorded, so disable
puts it back, and a key that already said no is left alone and never switched
back on. X11 has no such switch and nothing is written there.
Off under Settings for anyone who wants the paste kept.
A build with a prefix of its own put them in $(PREFIX)/lib/systemd/user, which
is right for /usr/local and wrong for the one prefix an install without root
can use: systemd searches $XDG_DATA_HOME/systemd/user and never
~/.local/lib/systemd/user. An install into ~/.local came out with a working
program whose watcher could not be enabled at all.
They go under share now, which both a system prefix and a home one are
searched for. Nothing changes for the packages - the deb and the rpm pass
USERUNITDIR in themselves.
That prefix is what an atomic distribution leaves a user, so the readme says
how to install on Bazzite: layer the rpm and reboot, or put the whole thing in
$HOME, which is where everything it writes ends up anyway.
Inside a Chromium application the flag settles this on its own - with
autoscroll on, Blink stops pasting the primary selection. Everywhere else
on the desktop middle click goes on pasting, which is the thing this whole
program exists to get away from.
KWin has a switch for it, on Wayland, where the paste is a protocol the
compositor either offers or does not: EnablePrimarySelection in kwinrc.
Written with kwriteconfig, the way System Settings would, because kwinrc
has a cascade behind it. What the key said before goes in the ledger, so
disable puts it back - and a key that already said false is left alone and
not recorded, so a paste the user switched off themselves is never
switched back on.
X11 has no such switch and nothing is written there.
Steam's helper script is only patched when the patch keeps the file at the
length Steam wrote down. Where the comments cannot pay for the argument,
nothing is written at all: a file of the wrong length costs the whole client
package downloaded and installed again, and a client that quits at the end of
it instead of coming up.
With no such patch left to prop up, -noverifyfiles is gone from everything that
carried it - Steam's launcher entry, its autostart entry, the shortcut on the
desktop and the ones Steam writes for single games. Steam repairs its own
installation again, and nothing of this program's is on its command line. A
patch an earlier version appended is rebuilt to fit at the next apply, or taken
back if it cannot be.
A script somebody puts in front of the client to add a switch of its own is
recognised as a way of starting Steam, rather than as an application to hand
the flag to.
A desktop entry edited in place that the ledger has lost is written again from
the copy kept beside it. Without that, an entry from an older version kept an
older answer for good - a browser patched that way stayed on the flag that
shows the "unsupported command-line flag" bar while every other browser moved
off it in 1.3.0.
A desktop entry that was edited in place is left alone once it carries the
marker, and the only thing that ever writes it again is the undo a change of
flags goes through - which reads the ledger. So an entry the ledger has lost is
one nothing looks at any more: it keeps whatever an older version put on its
command line, and an update that moves browsers to a different flag moves every
browser but that one.
The copy taken before the edit is named after the path, not recorded in the
ledger, and is still there. A marked entry with no ledger line is now put back
from that copy and written again from scratch, which is the same thing the undo
would have done, and it lands in the ledger on the way out.
Only entries edited in place need this. A generated entry is built from the
source entry every time and is right by construction, and a flag file has its
block rewritten whenever the contents differ.
The patch that keeps the script's length was the good path and appending was
the fallback, with -noverifyfiles on everything that starts Steam to cover for
it. That cover does not exist.
Steam checks its files at the shutdown it runs itself, not only at a start
somebody handed arguments to, and that run carries no -noverifyfiles whatever
the session was started with. One wrong length there costs the whole client
package downloaded, extracted and installed again - and the client quits at the
end of it instead of coming up, which is the "Steam just closed itself" that
this was seen as:
BVerifyInstalledFiles: steamwebhelper.sh is 130 bytes, expected 84
Update wird heruntergeladen ... Paket wird extrahiert ...
Aktualisierung abgeschlossen, Steam wird geladen ... Shutdown
So the flag now either fits in the space the comments give back or it is not
written at all, and the status screen says Steam is not patched. No autoscroll
in the interface is a far smaller thing than a client that reinstalls itself.
With no growing patch left to prop up, -noverifyfiles has nothing to do and is
gone with everything that carried it: Steam's launcher entry, its autostart
entry, the shortcuts on the desktop and the ones it writes for single games.
Steam repairs its own installation again. An installation from an older version
is taken back once through the flag scheme, and a patch that version appended
is rebuilt to fit at the next apply - or taken back, if the comments cannot pay
for it.
A script somebody puts in front of the client to add a switch of its own is
still a way of starting Steam, but nothing recognised it as one: the check is
by name, and the script is not called steam.
Such a script tends to name the flag it exists to add, and that flag is one of
the markers the hint scan reads as "this is Chromium". The entry was therefore
handled as an application and had the flag appended to every Exec line of it,
where Steam ignores it, instead of being handed to the Steam module - so the
interface it was pointing at never got autoscroll, and the launcher entry never
got Steam's own switch either.
The handover a launcher script makes is now followed one step, and a script
that hands over to Steam counts as Steam. One step is all there is: the
client's own launcher is recognised by name already.
A browser no longer shows the "unsupported command-line flag" bar. It is given
--enable-features=MiddleClickAutoscroll, which asks for the same feature
without being on the list of flags Chromium warns about; everything that embeds
an older Chromium keeps the flag that works there, and shows no bar either way.
Helium gets its own name for the feature alongside it, so autoscroll works
there for the first time.
An installation from 1.2.0 or earlier is taken back and written again on the
next apply.
--enable-blink-features is on the list of flags Chromium warns about, so every
browser the flag was applied to put a yellow "unsupported command-line flag"
bar above each page.
Browsers are given --enable-features=MiddleClickAutoscroll instead. It asks for
the same thing - Blink generates a feature of the same name for each of its
runtime flags - and is not on that list. That spelling only works from Chromium
124 onwards, so everything else keeps the flag that works everywhere: an
application embedding an older Chromium, Steam's CEF among them, has no such
bar to show anyway.
Helium knows the feature under a name of its own and ignores the Chromium one,
so browsers are asked for HeliumMiddleClickAutoscroll as well; autoscroll never
worked there before. A name a browser does not know is ignored, which is what
makes one list safe for all of them.
An installation set up by an earlier version is taken back and written again
once, because a file that is already marked as patched would otherwise be left
alone with the old flag in it.
Steam's autoscroll stops depending on -noverifyfiles: the patch is written at
the size and timestamp Steam recorded, so the client's own file check finds
nothing to repair and the flag survives whichever way Steam was started. An
installation patched by 1.1.0 is redone at the original size on the next apply.
Also picks up the launch paths that were never covered - shortcuts on the
desktop, Steam as a Flatpak, steam-native and steam-jupiter.
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