@Andrew many thanks. As do I. See my OP.
A failed build doesn't break XO. It leaves the previous successful build in place.
My post wasn't to ask how to fix my problem, but to point out the issue to others who might care to know (see my last post).
Cheers.
@Andrew For the record, that didn't fix it for me.
To be specific, it >>did<< fix the error regarding bigint in QcowDisk.mts, but a new error popped up later in the build:
yarn run v1.22.22
$ TURBO_TELEMETRY_DISABLED=1 turbo run build --filter xo-server --filter xo-server-'*' --filter xo-web
turbo 2.5.8
• Packages in scope: xo-server, xo-server-audit, xo-server-auth-github, xo-server-auth-google, xo-server-auth-ldap, xo-server-auth-oidc, xo-server-auth-saml, xo-server-backup-reports, xo-server-load-balancer, xo-server-netbox, xo-server-perf-alert, xo-server-sdn-controller, xo-server-test-plugin, xo-server-transport-email, xo-server-transport-icinga2, xo-server-transport-nagios, xo-server-transport-slack, xo-server-transport-xmpp, xo-server-usage-report, xo-server-web-hooks, xo-web
• Running build in 21 packages
• Remote caching disabled
x Internal errors encountered: external process killed a task
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
+ rm -rf /opt/xo/xo-builds/xen-orchestra-202510281354
That was with commit 740fc03, the latest at the time of my build at 2025-10-28 17:54 UTC.
It's unclear to me why the build failed exactly. Except that "Internal errors encountered: external process killed a task". I don't know know what that external process was. Unfortunately the 3rd party build script doesn't seem to preserve failed builds, only a slender log file.
I tried again a little later, with commit 87471d9. That succeeded, but it's unclear to me why. Neither commit explains either the failure, nor the success. The only other difference is that with the success, nodejs was updated (automatically, as part of the 3rd party build script) from 22.20.0-1nodesource1 to 22.21.1-1nodesource1, whereas for the failed build it was still 22.20.0-1nodesource1.
I don't know enough about the build process to untangle what happened... but I don't really need to. I can remain ignorant 
By the way, if my initial post was closer to static noise than useful feedback, please forgive, and please let me know. It was really just an FYI to those who may be both listening and desiring to know. I see things move fast with the repo, with ten or more commits some days, so maybe flooding the forums with 'my build failed!' posts isn't helpful.
Greetings all,
Subject pretty much says it. Build output goes sideways starting with:
@xen-orchestra/qcow2:build: src/disk/QcowDisk.mts(94,52): error TS2365: Operator '&' cannot be applied to types 'bigint' and 'number'.
Looking at github, the errant commit is cb96de6:
As of this post, latest commit is bf705, with two additional commits in between, none of which address this issue.
My build environment is Ubuntu Server 24.04 LTS, with all updates applied, building with ronivay's install script. While I'm aware of the caveat:
This script is not supported or endorsed by Xen Orchestra. Any issue you may have, please report it first to this repository.
... the issue doesn't appear to be related to the script, but the source code. If I'm mistaken, please forgive the intrusion.
Any immediate thoughts on whether this is a proper bug? Or, is it instead an issue with my build environment?
Cheers.
Late to the game, but this might help someone...
I don't recommend this in a production environment, but it would be fine for e.g. a home lab.
I built qemu from source on another host (in my case, on a laptop running Ubuntu Mate):
./configure --static
make
... and then sftp'd the generated qemu-img executable to the XCP-ng host (I didn't care about any other outputs from the build process, some of which failed anyway likely due to the ancient version of Ubuntu Mate running on my laptop).
Building with --static avoided any issues with missing libraries on the XCP-ng host, at least for qemu-img.