Let tasks specify artifact files that CI systems can archive.

Allow bootstrap-commits.yml to fix the commits of packages that would otherwise build from branches.

Let xbstrap-pipeline take a map of available versions to make this possible.

So patch --merge doesn't work on macOS, and so xbstrap breaks.

Doing, for example, xbstrap pull-pack --deps-of weston-desktop will download the repodata file for every single package. While this is not much data in the grand scheme of things, it would be cleaner if we didnt need to do this every single time.

Allow bootstrap.yml to indicate stability levels from the set: stable, unstable, broken. Do not build broken packages in xbstrap-pipeline. Do not care about the success of unstable packages.

virtual_tools are not passed here when using --build. Ideally, --build should act the exact same as a build stage of the package it references, except with a different command.

It would be convenient to have a tool to bump packages, e.g. when bumping the world on ABI breaks. Implementing this by rewriting the YML would be hard, so I'd suggest making the revision field required and grepping for that.

Currently, there is an asymmetry between tool and package builds. Tools have an additional ìnstallspecification inbootstrap.ymland do not use the collection mechanism. Furthermore, there is an unintuitive difference in names:compile-toolfor tools vs.build` for packages. Fix this.

--recursive currently checks for updates along edges of the dependency graph. It also tries to redo all steps that can reach these updates. However, this strategy is overly broad: for example, it tends to rebuild toolchains that depend on some package that was changed (e.g., a libc).

It would be more useful if --recursive only redid steps that reach the updates by build edges (but the check for updates should still follow all edges).

Add commands to verify that builds (i.e., files within the packages/ and tools/ directories) and packed files can be replicated byte-wise.

Currently theres no __main__ module installed during pip install xbstrap. this prevents xbstrap being run via python -m xbstrap.

Would be useful for --deps-of, for example.

Right now, includes are resolved relative to the current working directory. They should be resolved relative to the location of bootstrap.yml instead.

Currently, patches only work for git-backed sources, as git am is used to apply them.

default should only affect xbstrap builds, not xbstrap-pipeline.

In commit c5caa31, we switched to the the PyYAML BaseLoader. This loader does not deserialize Boolean values correctly.

This causes a failure in https://github.com/managarm/bootstrap-managarm when --all is passed to install/download and similar commands. Reported in managarm/managarm#73 (comment).

Currently, xbstrap-pipeline creates a graph of jobs and their dependencies. For distributed builds, it would be more convenient to know the artifacts that a job depends on.

pkg-config is more reliable than hard-coding LIBRARY_PATH and CPATH.

Add a command that rebuilds packages after repositories or dependencies have been updated. Proposed name: xbstrap remake and xbstrap remake --recursive (to also rebuild if dependencies have changed).

Similarly, add xbstrap remake --reverse to update all reverse dependencies of a package.

see also:
managarm/bootstrap-managarm@0e9f9c3

specifying both is ambiguous, and hence, should fail

Due to the lack of /bin/bash xbstrap doesn't work on Nix OS when recipes shell out. References to /bin/bash should be replaced with /usr/bin/env bash.

When running xbstrap download --all and the packages directory is not created it errors about that, it should probably create it itself

Make plans deterministic by sorting edge lists by subject (i.e., package or tool) first and then by action.

determine_rolling_id() does not consider commits that have been fixed by commit: properties or by bootstrap-commits.yml entries; this can yield false positive Rolling ID of package X does not match true rolling ID errors.

some packages will need to generate their version dynamically, based on information from git repositories, one of these packages is managarm-system, another is mlibc

naturally, this state of things should be considered temporary, and proper versioning should be introduced into mlibc and managarm, in the meanwhile however, arch (for once) has a decent solution: https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver()_function and specifically

pkgver() {
  cd "$pkgname"
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

this is of high priority: tonigts CI run will be largely futile without it