Naming builds after their commit gave dist/ more than one AppImage for the
first time, and the install script took whichever `ls` listed first. That was
correct for exactly as long as builds overwrote each other: moho-76c7c45 sorts
before moho-ede11ca, so `npm run deploy` built the new one and then installed
the old one over the top of it, reporting success either way.
Caught because the launcher kept starting a build that did not have the change
in it.
It asks for the current commit's own file now, and falls back to the newest by
time where there is no git or no matching name - so a build that did not
happen fails loudly rather than quietly launching yesterday.
Co-Authored-By: Claude Opus 5 <[email protected]>
npm run deploy stopped building the daemon, with "rustup could not
choose a version of cargo to run" - which reads like rust is missing and
is not.
rustup installs a shim, and the shim finds the real toolchain through
CARGO_HOME and RUSTUP_HOME. On the XDG layout those point under
~/.local/share rather than ~/.cargo, so they are named by environment
variables a login shell sets and an npm script never sees. The shim then
has nowhere to look.
The distribution's own /usr/bin/cargo does run, which makes it look like
the answer, and for a native build it is. It is also the wrong one: it
carries no cross-compilation targets, so a Windows build through it
fails with "can't find crate for `core`" - which in turn reads like a
broken checkout. Each wrong answer points at the other, which is why
this has been worked around by hand all week instead of fixed.
So the XDG locations are filled in when nothing else has, rustup's shim
is preferred because it is the toolchain carrying the targets, and every
candidate is asked `--version` rather than assumed - that question being
the only thing that tells a working toolchain from a shim that cannot
find one. The Linux build goes through the same script as the Windows
one now, since it had the same problem and no reason to solve it
differently.
Both were verified through npm rather than from a shell that already had
the right environment, which is the only way this bug is visible at all.
Co-Authored-By: Claude Opus 5 <[email protected]>
pack:win bundled nobilis/target/release/nobilis.exe, and nothing on a
Linux machine ever writes there - a cross-build goes to
target/x86_64-pc-windows-gnu/release/. So the packager took whichever
.exe happened to be at the first path, which on a machine that has been
cross-building for days was three days old. Building a Windows package
today would have shipped a daemon from before XDCC, whispers and
deeplinks existed, and it would only have shown up as "unknown method"
on somebody else's computer.
npm run daemon built the Linux binary regardless of the target being
packaged, so pack:win never refreshed the exe it was about to ship.
There is a daemon:win now that does, and pack:win runs it.
Its own script rather than a line in package.json because two things
have to be right. rustup's toolchain has to be on PATH, not merely named
- cargo runs whichever rustc it finds, and pointing at rustup's cargo
while a distribution's rustc is first still fails with "can't find crate
for `core`", which reads like a broken checkout. And the copy is
conditional on the executable actually existing, since a build that
fails after having produced one once leaves the old one in place, which
is precisely how the stale copy got there.
Caught by the guard on its first run: the cross-build failed and the
Aug 28 file was left untouched rather than copied forward.
Co-Authored-By: Claude Opus 5 <[email protected]>
Clicking irc://irc.coreirc.net/elitewarez anywhere on the machine now
brings moho up on that channel.
What happens depends on whether it is a network moho is already on. If
it is, there is nothing to set up: the channel is joined on that
connection and opened, which is what clicking a link to a channel meant.
If it is not, the accounts page opens with the host, port and channel
already filled in - the nick is the only thing such a link cannot
supply, which is why there is a form at all rather than an account
simply appearing. Being on the network is not string equality either: a
link to irc.libera.chat is somewhere you already are if you connected
through irc.eu.libera.chat.
The parser is written against what people actually write rather than
against the drafts, which expired twenty years ago without agreeing. A
bare # starts a fragment, so browsers split the channel off and it has
to be put back; it also arrives percent-encoded, or doubled for a
network-wide channel. A comma is usually another channel and sometimes
one of a small fixed set of flags. A key is never kept - a password out
of a link anybody could have posted is not a thing to write to disk.
Getting there needs three separate paths because the desktops disagree:
an argument on a cold start, a second-instance event once one is already
running, and open-url on macOS. A link arriving before there is a window
is held rather than dropped, since a click that launches the app is
exactly when there is not one yet. The scheme is checked again on the
way in: it arrives as a command-line argument, and an argument is not a
promise about its own contents.
The same links in a message body are now clickable and go the same way,
rather than being handed to the desktop and bounced straight back here.
Parser checked against fifteen link shapes, including the reported one.
Two of them found real faults: several channels being cut to one, and a
key being read where the drafts put a flag.
Points at nobilis 6aa2a1e, without which a new account would have joined
nothing.
Co-Authored-By: Claude Opus 5 <[email protected]>
The AppImage went to ~/.local/bin, which is already on PATH here, with
a launcher entry and the icon at every size a panel or window switcher
might ask for - scaling one 512px icon down at display time is blurrier
than shipping the sizes.
Paired with packaging as `npm run deploy` rather than left as a manual
step. Building and installing are different acts, but the gap between
them is where a stale copy lives: a fresh AppImage sitting in dist/
while an older one runs from ~/.local/bin is exactly the confusion that
already cost an evening once.
Co-Authored-By: Claude Opus 5 <[email protected]>
SalastilandClaude Opus 5