Repository navigation
Stop forcing system-fonts, release 0.1.10 - #15
Merged
Merged
Conversation
added 3 commits
September 6, 2026 23:44
The headless feature set landed in #14 without a version bump, and 0.1.9 was already on crates.io from #13, so the publish workflow skipped it and the change reached nobody. `cargo install qa-inspect-host` still gets a host that compiles the Tauri runtime, which is why the consumer that needs it fails on Linux: The system library `glib-2.0` required by crate `glib-sys` was not found error: failed to compile `qa-inspect-host v0.1.9` Exactly the hole the review of the engine change described, walked into one merge later.
Nothing here needs it any more. The host job ran there because `qa-inspect-host` could not be built anywhere else: it reached the engine through `tauri-runtime-blitz`, which brought the Tauri runtime, which does not compile on Linux at all. The host opens no window and now does not compile one, so the reason is gone and macOS was being spent on a renderer check and a packaging check that Linux does. All four CI jobs and the publish job move to ubicloud. `zsh` becomes `bash`, which is what the ubuntu image has and what these POSIX scripts wanted anyway, and both jobs that build the host gain fontconfig -- a font library, not a window stack; `cargo package` verifies by building, so publishing needs it too.
`system-fonts` is `parley/system`, which pulls fontconfig. A headless host asserting semantic outcomes has no reason to enumerate the machine's font catalogue, and needing a system library to run a QA check is the tell that something is being built that should not be. With it gone the host's graph has no fontconfig, no Tauri, no GTK. Nothing is installed for its CI job now, and a step asserts that stays true. Verified against ps-blitz's fixture suite: six groups, all passing, with the host built this way.
`system-fonts` is a `blitz-dom` default and reaches `yeslogic-fontconfig-sys` on Linux, so a host that opens no window and reads no font catalogue still needed fontconfig development headers to build. `default-features = false`, and the rest of the list is every default this actually uses. Nothing replaces it. An earlier attempt bundled a face on the reasoning that without one parley shapes nothing, every box measures zero, and a check asserting that a heading painted fails for a reason unrelated to the page. That reasoning was never measured, and it is wrong: what a check reads is the semantic tree and box geometry, and a block box has dimensions whether or not its text shaped. Against a host with no font registered, ps-blitz's 14 engine fixtures pass 14, and the UI component sweep passes 74 of 74. The checks are not merely unable to fail, either. Repointing `cancelled-click-paints` at a heading the document does not contain fails it: `no painted node matching "heading:Not In This Document" has a box`. `fontconfig-sys` in the graph gate rather than `fontconfig`. The gate is for crates that link a system library; `fontconfig-parser` is pure Rust that reads fontconfig's XML, it arrives through `fontdb` behind usvg, and the broader pattern failed the job for a dependency that installs nothing. Host graph on the Linux target, normal edges, against tauri-runtime-blitz 0.3.4: 0 matches. Against the published 0.3.3 it is 2, both of them the `system-fonts` this removes from the runtime -- that is the release this waits on.
pathscale
force-pushed
the
release/host-0.1.10
branch
from
September 6, 2026 17:22
9c50f7b to
0b1bf9c
Compare
…s too This branch dropped `system-fonts` by setting `default-features = false` and retyping the six remaining defaults by hand. tauri-runtime-blitz's branch had grown the identical list independently, and two consumers arriving at the same workaround is what showed the problem was upstream rather than here. `system-fonts` should never have been a default of `blitz-dom`. It reaches `parley/system` and, on Linux only, `yeslogic-fontconfig-sys`, so every consumer linked a system library unless it remembered to opt out. Fixed at the source in pathscale/ps-blitz#87, which also removes the same feature from a dev-dependency in `blitz-script` and `blitz-wasm` and adds a `cargo deny` gate so the default cannot come back. So this goes back to plain `^0.4` defaults; a copy of someone else's default list goes stale the next time they add one, silently and in the direction of dragging in more than was asked for. The graph gate stays, and is not made redundant by the one upstream: that guards ps-blitz's crates, this guards the assembled host, which also pulls tauri-runtime-blitz. Two fixes to it: - `--edges normal,dev`, not `normal`. A dev-dependency is exactly how this escaped upstream, and this job runs `cargo test`, so dev edges are part of the graph it is asserting about. - The Linux target is pinned rather than inherited. `yeslogic-fontconfig-sys` is reached only there, so a check that takes the host's target says nothing the day it runs anywhere else. It also prints what it found on failure, instead of only a count. Requires ps-blitz 0.4.4 and tauri-runtime-blitz 0.3.4. Publishes 0.1.10.
`system-fonts` was named explicitly on both `blitz-dom` and `blitz-script`. It reaches `parley/system` and, on Linux only, the `yeslogic-fontconfig-sys` system library, so a host that opens no window and reads no font catalogue still needed fontconfig development headers to build. This first dropped it by setting `default-features = false` and retyping the six remaining defaults by hand. tauri-runtime-blitz had grown the identical list independently, and two consumers arriving at the same workaround is what showed the problem was upstream: it should never have been a default of `blitz-dom`. Fixed there in pathscale/ps-blitz#87, so this is plain `^0.4`. No-op against the engine as published. `blitz-dom` 0.4.3 still has the feature in its defaults, so the resolved graph is unchanged and this repository's host and package jobs run on macOS regardless, where a face comes from Core Text and costs no system library. It lands first anyway, and that is the point of doing it alone. ps-blitz#87 builds `qa-inspect-host` from a checkout of this branch with its own crates patched in over the registry, deliberately, so that an installed host cannot judge the change under test against the last release. But an explicit opt-in here switches the feature back on inside the patched engine, and nothing in ps-blitz can turn it off. This is the dependency that has to be fixed before that one can be. Published, so the bump is required: 0.1.9 on crates.io keeps the opt-in, and `ui` installs the host from the registry. Without a new version the fix reaches nobody once 0.4.4 lands. The CI move to ubicloud and the dependency-graph gate are not here. Both assert against a Linux graph that is genuinely still dirty until 0.4.4 is published, so they would fail for the right reason at the wrong time. They come back once the engine is out.
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.
system-fontswas named explicitly on bothblitz-domandblitz-script. It reachesparley/systemand, on Linux only,yeslogic-fontconfig-sys, so a host that opens no window and reads no font catalogue still needed fontconfig development headers to build.What this PR previously got wrong
It dropped the feature by setting
default-features = falseand retyping the six remaining defaults by hand. tauri-runtime-blitz#52 had grown the identical list independently, and two consumers arriving at the same workaround is what showed the problem was upstream:system-fontsshould never have been a default ofblitz-dom. Fixed there in pathscale/ps-blitz#87, so this is now plain^0.4.This is the dependency that has to be fixed first
No-op against the engine as published:
blitz-dom0.4.3 still has the feature in its defaults, so the resolved graph is unchanged, and this repository'shostandpackagejobs run on macOS regardless, where a face comes from Core Text and costs no system library.It lands first anyway, and alone, because ps-blitz#87 builds
qa-inspect-hostfrom a checkout of this branch with its own crates patched in over the registry. That is deliberate: an installed host would judge the change under test against the last release. But an explicit opt-in here switches the feature back on inside the patched engine, and nothing in ps-blitz can turn it off.Measured,
qa-inspect-host,x86_64-unknown-linux-gnu,--edges normal,dev,yeslogic-fontconfig-sys:The bump is required
0.1.9 on crates.io keeps the opt-in, and ui#286 installs the host from the registry. Without a new version the fix reaches nobody once 0.4.4 lands.
Deliberately not here
The CI move to ubicloud and the dependency-graph gate. Both assert against a Linux graph that is genuinely still dirty until 0.4.4 is published, so they would fail for the right reason at the wrong time. They come back once the engine is out.
Order
trb 0.3.4 is published. This, then ps-blitz#87 (0.4.4), then the CI refresh here.