Working CI with non-gui phases

[hmelder]

This is currently a draft PR aiming to get a fully automated toolchain up and running.

Features:

• Sandboxed building using Debian's pbuilder, and pdebuild along with debhelper utilities
  • pbuilder hooks for dependency management via local repository (See pbuilder/)
  • Transparent pbuilder management
• Fast building using Github Actions
  • Phases clearly separated for easy debugging
  • Packages uploaded as artefacts
  • Option to skip sandboxing for workers*
• Build utility should be aware of dependencies and build phases
• Automatic packaging of origin tarballs required by quilt
• Architecture, and release independent
• Storing debian/ package descriptions with metadata separate from the source (more on that below)
  • Transparently fetching sources from git

Traditionally, debian/ configuration is shipped along side the code. A maintainer would grab the latest release and upload it to the corresponding git repository of the debian package.

Modern distributions like NixOS, VoidLinux, or ArchLinux aggregate all package descriptions inside a single mono-repo to avoid complex ownership hierarchies or teams. This lowers the entry barrier of updating a package significantly:

• Complex dependencies can be managed from one synchronised state, instead of hundreds of independent repositories which need manual coordination (-> time intensive)
• Patching package descriptions is easier
• Simpler CI/CD
• Automatic tools to notify the current maintainer of a new release

I chose to do the same for this repository. The resulting structure:

• Debian package file in `source/debian´
• Additional metadata (name, upstream, installation order (non-sandbox)) in source/description as JSON
• cmd The build utility. Invoked via ./cmd/main.sh.
• pbuilder: Configuration, and hooks for pbuilder

Definitions:

• debootstrap: A tool for bootstrapping a debian root filesystem
• pbuilder: A tool that uses debootstrap to build a minimal rootfs, and manages the building of debian packages within this rootfs.
• debuild: The standard way of building packages directly on the HOST system
• debhelper: An aggregation of ancient and painful to use build scripts (The debian/rules file is a Makefile with multiple pre-configured "pipelines")

• To speed-up the building of packages with GitHub Actions, I chose to implement an additional option that uses a completely different way of building the packages natively. This should not be used on a normal machine!

[hmelder]

Ready to review!

[hmelder]

The workflow uploads all the packages as compressed tarballs containing the debian packages.

See: https://github.com/gnustep/tools-packaging/actions/runs/6762034966

[hmelder]

Turns out we need QEMU for ARM64 building. I have looked at https://github.com/uraimo/run-on-arch-action, but they do not support bookworm.

I would suggest postponing the cross CI for now

[hmelder]

Merged as discussed in email. Further work with cross-building is following