build: bump logos-module-builder from 0.2.5 to master - #91
Open
dlipicar wants to merge 1 commit into
Open
Conversation
0.2.5 is from 2026-07-26 and this repo has been sitting on it while the builder
moved through two releases and the whole Windows-cross series. `e45caf1`
brings, among others:
* protocol 0.6 -- the caller-identity wave -- and a protocol version that
fails to parse now failing loudly rather than silently vanishing (48cfdbe);
* the cross series: a dep that publishes nothing for the target system now
errors by name instead of silently falling back to the consumer's own
source tree (ea3b393), declared runtime files staged from `<drv>/bin`
(f007edf), and a cross Rust module given winpthreads, headers and archive
(d256a42);
* the SDK chain relocked onto master, including logos-rust-sdk's teardown
exports (bdc9804) and the lossless Qt type mapping (ba1b0aa);
* platform-keyed overlays in metadata.json (ad1899d), and an ABI test that
reads the module-impl exports off the BUILT plugin per backend (26a886b).
Verified on aarch64-darwin against this lock: `nix build .#default
.#lgx-portable .#unit-tests` is green and the unit suite is 39 passed.
`packages.x86_64-windows` now EXISTS as a consequence of the bump -- 20
attributes where there were none -- but does not yet resolve to a derivation,
and this commit deliberately does not chase that:
error: Refusing to evaluate package 'postgresql-17.10' ... because it is
not available on the requested hostPlatform:
hostPlatform.system = "x86_64-windows"
`metadata.json` declares stock `postgresql` under `nix.packages.runtime`, and
nixpkgs refuses it for that host. The Windows-capable libpq lives in
logos-delivery's own `packages.x86_64-windows.libpq`, which only exists on
logos-messaging/logos-delivery#4125 -- so the fix is a platform-keyed overlay
(exactly what ad1899d above adds) once that lands, and it belongs with the rest
of the Windows work in #86 rather than here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
📊 delivery-module doc-test reportThis commit of the delivery module, packaged as an Pages can take a minute to update after the run finishes. |
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.
Bumps
logos-module-builderfrom the0.2.5tag (2026-07-26) to master(
e45caf1). Nothing else changes — no source, nometadata.json.What comes with it
fails to parse now failing loudly rather than silently vanishing (
48cfdbe).errors by name instead of silently falling back to the consumer's own source
tree (
ea3b393), declared runtime files staged from<drv>/bin(f007edf),and a cross Rust module given winpthreads, headers and archive (
d256a42).exports (
bdc9804) and the lossless Qt type mapping (ba1b0aa).metadata.json(ad1899d), and an ABI test thatreads the module-impl exports off the built plugin per backend
(
26a886b).Verification
On
aarch64-darwin, against this lock:.lgxproduced with adarwin-arm64variant, as before.What this does NOT fix, stated so it is not mistaken for done
packages.x86_64-windowsnow exists as a consequence of the bump — 20attributes where there were none — but it does not yet resolve to a
derivation:
metadata.jsondeclares stockpostgresqlundernix.packages.runtime, andnixpkgs refuses it for that host. The Windows-capable libpq lives in
logos-delivery's own
packages.x86_64-windows.libpq, which exists only onlogos-messaging/logos-delivery#4125.
So the fix is a platform-keyed overlay — precisely what
ad1899dabove adds —once that lands, and it belongs with the rest of the Windows work in #86 rather
than here.
Companion bumps onto the same builder rev, all verified the same way:
logos-co/logos-chat-module#65 and logos-co/logos-chat-ui#57.