main cannot build the flatpak right now. #193 took skia-safe/skia-bindings 0.87.0 → 0.99.0 in crates/pf-console-ui/Cargo.toml, but packaging/flatpak/io.unom.Punktfunk.yml still pinned the 0.87.0 prebuilt Skia archive, so every flatpak leg since that merge dies with:
error[E0599]: no variant, associated function, or constant named `Default`
found for enum `SkPathFillType` (and `SkPathDirection`)
--> cargo/vendor/skia-bindings-0.99.0/src/defaults.rs:57
Why it reads like a crate bug (it isn't)
Nothing in that message points at the manifest. The offline sandbox can't fetch Skia, so the manifest pre-downloads a tarball and sets SKIA_BINARIES_URL: file:///…/skia-binaries.tar.gz. Because the URL is file://, the fetch can never fail — there is no download error to notice. skia-bindings just unpacks the archive verbatim into target/…/build/skia-bindings-*/out/skia/, including the bindings.rs it was generated with.
Those two Defaults are associated consts emitted intobindings.rs, so they travel with the archive, not with the crate — 0.99.0's src/defaults.rs was compiling against 0.87.0-era bindings. Confirmed by extracting the 0.99.0 archive:
Present on both x86_64 and aarch64 — exactly the two the compiler reported missing.
Cargo.lock and cargo-sources.json are derived from the lock and self-corrected to 0.99 on their own. This tarball is the only hand-maintained pin in the offline chain, which is precisely why it was the thing left behind.
⚠ The asset name changed across the bump, not just the version: jpeg entered skia-safe's default feature set at 0.99, so the resolved-feature key went pdf-textlayout-vulkan → jpegd-jpege-pdf-textlayout-vulkan. A future bump cannot be done by string-substituting the version number.
Validated against each archive's own key.txt / tag.txt (tag 0.99.0, key a25a0fdb7d90429aa2d1-<target>-jpegd-jpege-pdf-textlayout-vulkan), with libskparagraph.a and the Vulkan backend symbols present, so the archive still matches the feature set pf-console-ui resolves.
Preventing the repeat
crates/pf-console-ui/Cargo.toml already documented the correct 0.99.0 asset name — the bump author verified the native build path and evidently never knew the flatpak hand-pin existed. Both bump sites (plus packaging/flatpak/README.md) now carry a pointer to the other, and the README explains why the failure surfaces as a compile error rather than a fetch error.
Verification
Manifest parses as YAML with both pins resolving to the intended assets; sha256s computed from the actual downloads.
cargo metadata still parses the edited Cargo.toml (comment-only change).
Both Default consts confirmed present in the extracted bindings.rs for both architectures.
⏳Not run: an end-to-end flatpak build — that needs a Linux flatpak host. The fix is verified at the archive level. The flatpak CI leg on this PR is the first real end-to-end check.
`main` cannot build the flatpak right now. #193 took `skia-safe`/`skia-bindings` 0.87.0 → 0.99.0 in `crates/pf-console-ui/Cargo.toml`, but `packaging/flatpak/io.unom.Punktfunk.yml` still pinned the **0.87.0** prebuilt Skia archive, so every flatpak leg since that merge dies with:
```
error[E0599]: no variant, associated function, or constant named `Default`
found for enum `SkPathFillType` (and `SkPathDirection`)
--> cargo/vendor/skia-bindings-0.99.0/src/defaults.rs:57
```
### Why it reads like a crate bug (it isn't)
Nothing in that message points at the manifest. The offline sandbox can't fetch Skia, so the manifest pre-downloads a tarball and sets `SKIA_BINARIES_URL: file:///…/skia-binaries.tar.gz`. Because the URL is `file://`, **the fetch can never fail** — there is no download error to notice. skia-bindings just unpacks the archive verbatim into `target/…/build/skia-bindings-*/out/skia/`, *including the `bindings.rs` it was generated with*.
Those two `Default`s are associated consts emitted **into** `bindings.rs`, so they travel with the **archive**, not with the crate — 0.99.0's `src/defaults.rs` was compiling against 0.87.0-era bindings. Confirmed by extracting the 0.99.0 archive:
```rust
impl SkPathFillType { pub const Default: SkPathFillType = SkPathFillType::Winding; }
impl SkPathDirection { pub const Default: SkPathDirection = SkPathDirection::CW; }
```
Present on **both** x86_64 and aarch64 — exactly the two the compiler reported missing.
`Cargo.lock` and `cargo-sources.json` are derived from the lock and self-corrected to 0.99 on their own. This tarball is the **only** hand-maintained pin in the offline chain, which is precisely why it was the thing left behind.
### The fix
Repins both arch entries to the 0.99.0 assets:
| arch | sha256 |
|---|---|
| x86_64 | `158407a4b5ce8738431bb76498be3a44fda770e51d61aac18a0e0e97becdc1de` |
| aarch64 | `cf5469d1d963f704cc997f9b3342d11c49b917002361947e5c7bf7dcc3f13534` |
⚠ The asset **name** changed across the bump, not just the version: `jpeg` entered skia-safe's default feature set at 0.99, so the resolved-feature key went `pdf-textlayout-vulkan` → `jpegd-jpege-pdf-textlayout-vulkan`. **A future bump cannot be done by string-substituting the version number.**
Validated against each archive's own `key.txt` / `tag.txt` (tag `0.99.0`, key `a25a0fdb7d90429aa2d1-<target>-jpegd-jpege-pdf-textlayout-vulkan`), with `libskparagraph.a` and the Vulkan backend symbols present, so the archive still matches the feature set `pf-console-ui` resolves.
### Preventing the repeat
`crates/pf-console-ui/Cargo.toml` already documented the correct 0.99.0 asset name — the bump author verified the *native* build path and evidently never knew the flatpak hand-pin existed. Both bump sites (plus `packaging/flatpak/README.md`) now carry a pointer to the other, and the README explains why the failure surfaces as a compile error rather than a fetch error.
### Verification
- Manifest parses as YAML with both pins resolving to the intended assets; sha256s computed from the actual downloads.
- `cargo metadata` still parses the edited `Cargo.toml` (comment-only change).
- Both `Default` consts confirmed present in the extracted `bindings.rs` for both architectures.
- ⏳ **Not run:** an end-to-end flatpak build — that needs a Linux flatpak host. The fix is verified at the archive level. The flatpak CI leg on this PR is the first real end-to-end check.
The dependency currency wave took skia-safe/skia-bindings 0.87.0 -> 0.99.0 in
crates/pf-console-ui/Cargo.toml, but packaging/flatpak/io.unom.Punktfunk.yml still
pinned the 0.87.0 prebuilt archive, so every flatpak leg since the merge dies with
error[E0599]: no variant, associated function, or constant named `Default`
found for enum `SkPathFillType` (and `SkPathDirection`)
--> cargo/vendor/skia-bindings-0.99.0/src/defaults.rs:57
Nothing about that message points at the manifest, so it reads like a crate bug. It
isn't. `SKIA_BINARIES_URL: file://…` makes skia-bindings unpack the pinned tarball
verbatim into target/…/build/skia-bindings-*/out/skia/ — *including the bindings.rs
it was generated with*. Those two `Default`s are associated consts emitted INTO
bindings.rs, so they travel with the archive, not with the crate: 0.99.0's
src/defaults.rs was compiling against 0.87.0-era bindings. Verified directly — the
0.99.0 archive carries `impl SkPathFillType { pub const Default = Winding }` and
`impl SkPathDirection { pub const Default = CW }` on both x86_64 and aarch64.
Because the URL is file://, the fetch can never fail, so there is no download error
to notice — the only symptom is a compile error deep in a vendored crate.
The asset name changed across the bump: `jpeg` entered skia-safe's defaults at 0.99,
so the resolved-feature key went `pdf-textlayout-vulkan` -> `jpegd-jpege-pdf-textlayout-vulkan`.
Confirmed against each archive's own key.txt/tag.txt (tag 0.99.0, key
a25a0fdb7d90429aa2d1-<target>-jpegd-jpege-pdf-textlayout-vulkan), and libskparagraph.a
plus the Vulkan backend symbols are present, so the feature set still matches what
pf-console-ui resolves.
Everything else in the offline chain (Cargo.lock, cargo-sources.json) is regenerated
from the lock and self-corrects; this tarball is the single hand-maintained pin, which
is exactly why it was the thing left behind. Both bump sites now carry a pointer to
the other so the next one can't split-brain the same way.
enricobuehler
scheduled this pull request to auto merge when all checks succeed 2026-08-13 13:53:16 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
maincannot build the flatpak right now. #193 tookskia-safe/skia-bindings0.87.0 → 0.99.0 incrates/pf-console-ui/Cargo.toml, butpackaging/flatpak/io.unom.Punktfunk.ymlstill pinned the 0.87.0 prebuilt Skia archive, so every flatpak leg since that merge dies with:Why it reads like a crate bug (it isn't)
Nothing in that message points at the manifest. The offline sandbox can't fetch Skia, so the manifest pre-downloads a tarball and sets
SKIA_BINARIES_URL: file:///…/skia-binaries.tar.gz. Because the URL isfile://, the fetch can never fail — there is no download error to notice. skia-bindings just unpacks the archive verbatim intotarget/…/build/skia-bindings-*/out/skia/, including thebindings.rsit was generated with.Those two
Defaults are associated consts emitted intobindings.rs, so they travel with the archive, not with the crate — 0.99.0'ssrc/defaults.rswas compiling against 0.87.0-era bindings. Confirmed by extracting the 0.99.0 archive:Present on both x86_64 and aarch64 — exactly the two the compiler reported missing.
Cargo.lockandcargo-sources.jsonare derived from the lock and self-corrected to 0.99 on their own. This tarball is the only hand-maintained pin in the offline chain, which is precisely why it was the thing left behind.The fix
Repins both arch entries to the 0.99.0 assets:
158407a4b5ce8738431bb76498be3a44fda770e51d61aac18a0e0e97becdc1decf5469d1d963f704cc997f9b3342d11c49b917002361947e5c7bf7dcc3f13534⚠ The asset name changed across the bump, not just the version:
jpegentered skia-safe's default feature set at 0.99, so the resolved-feature key wentpdf-textlayout-vulkan→jpegd-jpege-pdf-textlayout-vulkan. A future bump cannot be done by string-substituting the version number.Validated against each archive's own
key.txt/tag.txt(tag0.99.0, keya25a0fdb7d90429aa2d1-<target>-jpegd-jpege-pdf-textlayout-vulkan), withlibskparagraph.aand the Vulkan backend symbols present, so the archive still matches the feature setpf-console-uiresolves.Preventing the repeat
crates/pf-console-ui/Cargo.tomlalready documented the correct 0.99.0 asset name — the bump author verified the native build path and evidently never knew the flatpak hand-pin existed. Both bump sites (pluspackaging/flatpak/README.md) now carry a pointer to the other, and the README explains why the failure surfaces as a compile error rather than a fetch error.Verification
cargo metadatastill parses the editedCargo.toml(comment-only change).Defaultconsts confirmed present in the extractedbindings.rsfor both architectures.The dependency currency wave took skia-safe/skia-bindings 0.87.0 -> 0.99.0 in crates/pf-console-ui/Cargo.toml, but packaging/flatpak/io.unom.Punktfunk.yml still pinned the 0.87.0 prebuilt archive, so every flatpak leg since the merge dies with error[E0599]: no variant, associated function, or constant named `Default` found for enum `SkPathFillType` (and `SkPathDirection`) --> cargo/vendor/skia-bindings-0.99.0/src/defaults.rs:57 Nothing about that message points at the manifest, so it reads like a crate bug. It isn't. `SKIA_BINARIES_URL: file://…` makes skia-bindings unpack the pinned tarball verbatim into target/…/build/skia-bindings-*/out/skia/ — *including the bindings.rs it was generated with*. Those two `Default`s are associated consts emitted INTO bindings.rs, so they travel with the archive, not with the crate: 0.99.0's src/defaults.rs was compiling against 0.87.0-era bindings. Verified directly — the 0.99.0 archive carries `impl SkPathFillType { pub const Default = Winding }` and `impl SkPathDirection { pub const Default = CW }` on both x86_64 and aarch64. Because the URL is file://, the fetch can never fail, so there is no download error to notice — the only symptom is a compile error deep in a vendored crate. The asset name changed across the bump: `jpeg` entered skia-safe's defaults at 0.99, so the resolved-feature key went `pdf-textlayout-vulkan` -> `jpegd-jpege-pdf-textlayout-vulkan`. Confirmed against each archive's own key.txt/tag.txt (tag 0.99.0, key a25a0fdb7d90429aa2d1-<target>-jpegd-jpege-pdf-textlayout-vulkan), and libskparagraph.a plus the Vulkan backend symbols are present, so the feature set still matches what pf-console-ui resolves. Everything else in the offline chain (Cargo.lock, cargo-sources.json) is regenerated from the lock and self-corrects; this tarball is the single hand-maintained pin, which is exactly why it was the thing left behind. Both bump sites now carry a pointer to the other so the next one can't split-brain the same way.