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]>
SalastilandClaude Opus 5.5