This release keeps dependencies and maintenance posture current for teams operating this tool.
✓ No known CVEs patched in this version
Topics
+1 more
Summary
AI summaryFixed make failures in empty git repos and corrected ExVer range operations to consider downstream revisions.
Changes in this release
| Type | Severity | Summary | CVE |
|---|---|---|---|
| Bugfix | Medium |
`make` no longer fails in a git repository lacking an index. `make` no longer fails in a git repository lacking an index. Source: llm_adapter@2026-07-17 Confidence: high |
— |
| Bugfix | Medium |
ExVer range operations now correctly consider downstream revision. ExVer range operations now correctly consider downstream revision. Source: llm_adapter@2026-07-17 Confidence: low |
— |
Full changelog
What's Changed
Fixed
makeno longer fails in a git repository that has no index yet.s9pk.mklisted$(GIT_DIR)/indexas an unconditional prerequisite of the s9pk targets, butgit initdoes not create an index until the firstgit add— so make aborted withNo rule to make target '.git/index', needed by '<id>_x86_64.s9pk'before the pack step ever ran. This hit every freshly scaffolded package:s9pk init-packagerunsgit initand stages nothing, and the generatedTODO.mdsends the packager straight tomakeas their first build, while the workflow guide tells them to iterate with a dirty tree and commit once at the end. The existing$(if $(GIT_DIR),…)guard asked only whether a repo exists, not whether these files do.GIT_DEPSnow filters through$(wildcard …), so a missingHEADorindexdrops out of the prerequisite list instead of halting the build. Nothing else needed to change:s9pk packalready handles a commit-less repo, reportingNo git commit found in . — building without a commit hash in the manifestand packing with a nullgitHash. These entries are rebuild triggers, not build requirements
Fixed
-
ExVer range operations no longer ignore the downstream revision.
compareVersionRangePointsandadjacentVersionRangePointscompared the upstream version twice instead of comparing the downstream on the second pass, so two points that shared an upstream but differed in downstream (1.0.0:3vs1.0.0:15) collapsed into a single point. Everything built on the truth tables inherited the error —normalize()silently dropped the lower of the two, andintersects()/satisfiable()could answer on a merged point.=1.0.0:0 || =1.0.0:1normalized to=1.0.0:1.The visible consequence was in packed manifests:
canMigrateFrom/canMigrateToare derived from the version graph and normalized, so any package declaring anotherversion sharingcurrent's upstream advertised a range narrower than the truth (mempoolat3.3.1:15withother: [3.3.1:3]shippedcanMigrateFrom: <=3.3.1:3rather than<=3.3.1:15). No upgrade actually broke — StartOS resolves migrations through the version graph rather than gating on this field, and the registry index does not yet populatesourceVersionfrom it — but the manifests were wrong and would have become load-bearing the moment either changed. The Rust implementation derives its point ordering and was never affected.
Weekly OSS security release digest.
The CVE patches and breaking changes that affected production tools this week. One email, every Sunday.
No spam, unsubscribe anytime.
Share this release
About StartOS
Browser-based, graphical Operating System (OS) that makes running a personal server as easy as running a personal computer.
Related context
Related tools
Earlier breaking changes
- vstart-sdk/v2.0.4 'setupMain' callback now accepts any DaemonBuildable rather than requiring a Daemons.
- vstart-sdk/v2.0.4 `Daemons.dynamic` now takes `effects` and returns a `DaemonReconciler` instead of replacing `main`.
- v0.4.0-beta.9 Previous backups incompatible with v0.4.0; create fresh backup after updating.
Beta — feedback welcome: [email protected]