Dario Gabriel Lipicar 536234e343 fix(windows): bump logos-package-manager-ui so the Windows build completes ...

The x86_64-windows target could not build. It failed 15 files into
package_manager_ui's compile with

    generated_code/include/logos_sdk.h:5:10:
      fatal error: package_manager_api.h: No such file or directory

and basecamp is only the messenger. `package_manager_api.h` is the typed API of
the package_manager MODULE, and this lock carried TWO revisions of it:

    63a6f8ab  publishes  ...and x86_64-windows
    975dcc50  publishes  darwin, linux only

The bad one arrived through this repo's pin of a package_manager_ui that
predated logos-package-manager-ui#68. With no Windows target for that
dependency the header resolved to nothing, no -I reached the compiler, and the
first file including the generated logos_sdk.h failed. Nothing earlier
complained.

`nix flake update logos-package-manager-ui` collapses it to 63a6f8ab alone. It
also brings logos-module-builder 632f601, which includes

    ea3b393 fix(cross): fail loudly when a dep publishes nothing for the
            target system (#199)

so the next dependency in this position fails in seconds naming itself, rather
than as a missing include after an 87-minute build.

VERIFIED on an x86_64-linux builder -- packages.x86_64-windows.default builds
clean, ma16290wbzdnfpglasxn0dy2k0f9j018:

    DLL import closure converged after 5 round(s); staged 9 DLL(s) into bin/
    PE import closure verified: 117 root(s), 7141 import(s) read, 0 unresolved.

Found by the Windows cache-prime job's third stage, which is the first thing to
have cross-built this closure from a store with NO history. package_manager_ui
was verified working on Windows months ago, but hand-built on a machine whose
store already held what a clean runner has to produce -- so the missing pin had
never been exercised.

2026-08-18 18:17:58 -03:00

16 MiB

Raw Blame History

The file is too large to be shown. View Raw