Skip to content

build: bump logos-module-builder from 0.2.5 to master - #91

Open
dlipicar wants to merge 1 commit into
masterfrom
build/bump-module-builder
Open

build: bump logos-module-builder from 0.2.5 to master#91
dlipicar wants to merge 1 commit into
masterfrom
build/bump-module-builder

Conversation

@dlipicar

Copy link
Copy Markdown
Contributor

Bumps logos-module-builder from the 0.2.5 tag (2026-07-26) to master
(e45caf1). Nothing else changes — no source, no metadata.json.

What comes with it

  • 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).

Verification

On aarch64-darwin, against this lock:

$ nix build .#default .#lgx-portable .#unit-tests
 ── Results: 39 passed (4ms) ──────

.lgx produced with a darwin-arm64 variant, as before.

What this does NOT fix, stated so it is not mistaken for done

packages.x86_64-windows now exists as a consequence of the bump — 20
attributes where there were none — but it does not yet resolve to a
derivation:

$ nix eval .#packages.x86_64-windows.default.drvPath
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 exists only on
logos-messaging/logos-delivery#4125.
So the fix is a platform-keyed overlay — precisely what ad1899d above 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.

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>
@github-actions

Copy link
Copy Markdown

📊 delivery-module doc-test report

This commit of the delivery module, packaged as an .lgx and run through a logoscore daemon — rendered alongside the commands actually run and their output (updated each run, commit f160f5f):

Pages can take a minute to update after the run finishes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant