package.json's version is what a release will be, not what a build from
the development branch is - so About said 0.1.0, then 1.0.0-rc.1, for
builds that were neither. scripts/version-label.mjs decides once, for the
window (__APP_VERSION__) and the daemon (NOBILIS_CHANNEL, exported by the
daemon build scripts): the version for CI building its v<version> tag, a
checkout on that tag, or the master branch; "development" for anything
else.
A development build is never offered a newer release: "development" is not
a version to compare.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Settings > About lists nobilis's audio decoder (libopus and its
version), from the daemon's version answer.
- The daemon build scripts run cargo from inside nobilis/, so its
.cargo/config.toml - which names the bundled libopus's version - applies.
- libopus_sys's build does not rerun for that setting, so a kept target
directory (here, or CI's cache restored by prefix) would keep a bundled
libopus that calls itself "unknown". After building, each script looks
for that string in the daemon and rebuilds just libopus_sys if it is
there. Seen working on the first run: the Windows daemon was stale and
now reports libopus 1.5.2.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The release workflow and the PKGBUILD already did; the two build scripts
behind npm run daemon, pack and deploy did not, so a Cargo.toml that
disagreed with Cargo.lock was quietly re-resolved and the lockfile
rewritten instead of the build failing.
Co-Authored-By: Claude Opus 5.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]>
SalastilandClaude Opus 5.5