Repository navigation
Conversation
jcelerier
added a commit
that referenced
this pull request
Oct 11, 2026
… defines Same fix as the other tests in #2330: on Windows <windef.h> defines near as an empty macro, so 'bool near(...)' does not compile. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JeL19ofVgPe9u9q7J1V9ex
jcelerier
force-pushed
the
fix/clang64-static-test-build
branch
from
October 11, 2026 13:15
f9304c9 to
4d0ef49
Compare
jcelerier
force-pushed
the
fix/clang64-static-test-build
branch
from
October 11, 2026 16:00
9952563 to
dee34b7
Compare
jcelerier
force-pushed
the
fix/clang64-static-test-build
branch
from
October 12, 2026 00:52
dee34b7 to
23abcfa
Compare
An add-on built against the SDK compiles with -nostdinc, so every include directory is spelled out on the command line; with the SDK's Qt paths that overruns CreateProcess and ninja stops with "CreateProcess: The parameter is incorrect". CMake 4.4 moved compile flags into a response file by default, but the SDK ships 4.3, which does not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
Companion to the three-argument `osc(address, values, typetags)` that libossia gained in ossia/libossia#957: every number a script put in an OSC message went out as a float, so there was no way to send the int source index SpatGRIS's /spat/serv grammar requires -- the shipped Spatial Protocol Mapper emits it as "sffffff" with the index as 1.000000. The fixture sends the /spat/serv shape with "sifffff", one argument per supported tag, a message with no tag string at all, and a tag string shorter than the argument list. The test asserts the exact datagram bytes against hand-written OSC fixtures -- address and type tag strings padded to four bytes, network-order IEEE-754 payloads -- so nothing libossia encodes is its own oracle, and reads the type tag string back out of the packet with its own four-byte-padding arithmetic. The libossia pin moves to that commit on master, and stops there rather than at master's head: the three geometry commits after it belong with the score-side shading work, and one of them changes the default ambient colour, which has no business landing through a test. The earlier version of this test pinned the submodule to the pull request branch instead, which is why it could not be merged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
`ci/appimage.build.sh` runs appimagetool, which is itself an AppImage, so
it needs either FUSE or APPIMAGE_EXTRACT_AND_RUN. FUSE is unavailable
under rootless docker on the self-hosted host, which is why
appimage.yml sets the variable on the job and appimage.deps.sh says in
so many words that libfuse2 is therefore not required.
The tool repositories reach the same script through
ossia/actions/custom-score-build, which did not set it, so every
packaging job that went that way died at the same place:
/usr/bin/fusermount3: mount failed: Operation not permitted
Cannot mount AppImage, please check your FUSE setup.
open dir error: No such file or directory
##[error]Process completed with exit code 127.
That is fixed in the action itself, in ossia/actions#29, which is what
actually unblocks the tools -- they pin the action at @master. The
default here is for anyone running the script by hand on a machine
without FUSE, and `${VAR:-1}` leaves a caller that wants FUSE able to
ask for it.
Reproduced and checked locally by running appimagetool on an AppDir with
no fusermount on $PATH: unset, it exits 127 with the same "open dir
error" line; with the variable, exit 0 and the AppImage is written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
jcelerier
force-pushed
the
fix/clang64-static-test-build
branch
from
October 12, 2026 00:55
23abcfa to
09a5258
Compare
jcelerier
added a commit
that referenced
this pull request
Oct 12, 2026
Member
Author
jcelerier
added a commit
that referenced
this pull request
Oct 13, 2026
… defines Same fix as the other tests in #2330: on Windows <windef.h> defines near as an empty macro, so 'bool near(...)' does not compile. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JeL19ofVgPe9u9q7J1V9ex
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
Verification
Cross-repository context
Scope
Only the 20 session-modified tracked files are included. No unrelated untracked files or dependency edits are included. The machine-local test-PDB suppression policy and generated build artifacts are deliberately excluded; repository debug defaults and enabled tests are unchanged.
Also here: the OSC type tags test, recovered from #2322
#2322 was closed because it pinned
3rdparty/libossiato the pull request branch of ossia/libossia#957 rather thanto a commit on libossia's master, so it could never be merged. The test itself
was fine and was the only thing left of that work, so it rides here rather than
in a PR of its own.
tests/integration/MapperDatagramProtocolsTest.cppgains one case for thethree-argument
osc(address, values, typetags): the /spat/serv shape with"sifffff", one argument per supported tag, a message with no tag string atall, and a tag string shorter than the argument list. It asserts the exact
datagram bytes against hand-written OSC fixtures — address and type tag strings
padded to four bytes, network-order IEEE-754 payloads — so nothing libossia
encodes is its own oracle, and it reads the tag string back out of the packet
with its own padding arithmetic.
The libossia pin moves from
15a6c68801tod94955801, which is that change onlibossia master. It deliberately stops there instead of at master's head: the
three geometry commits after it belong with the score-side shading work in
#2326, and one of them changes the default
ambient colour from 0.03 to 0, which has no business landing through a test PR.
Not built locally — the integration tests are not configured in the build tree
I have here, so this one case is on CI to compile and run.
And: the AppImage build needs no FUSE whichever workflow calls it
This is what sat-mtl/livepose#83 one failing job was
dying of, and the same hazard sits under every tool repo's packaging job.
ci/appimage.build.shruns appimagetool, which is itself an AppImage, so itneeds either FUSE or
APPIMAGE_EXTRACT_AND_RUN. FUSE is unavailable underrootless docker on the self-hosted host — which is exactly why
appimage.ymlsets the variable on the job, and why
appimage.deps.shsays in so many wordsthat libfuse2 is therefore not required. The tool repositories reach the same
script through
ossia/actions/custom-score-build, which does not set it, sothey die at the one place that depends on it:
The real fix is in the action — ossia/actions#29 —
because the tool repos pin
ossia/actions/...@masterand build score fromscore's
master, so a change living only here reaches none of them until thisPR merges. That PR also covers
package-custom-app, which runstools/create-app-linux.shfor the app's own AppImage: livepose never gotthat far, so fixing only score's script would have moved the failure instead of
removing it. The
${VAR:-1}default kept here is for anyone running the scriptby hand on a machine without FUSE.
Reproduced and verified locally — appimagetool on a minimal AppDir with no
fusermounton$PATH:open dir error: No such file or directory, no AppImage — the CI failure, verbatimAPPIMAGE_EXTRACT_AND_RUN=1