Add a pacman action, whereby pacman is the Arch package manager akin to
apt for Debian. This allows us to install packages, after the initial
pacstrap action (or equivalent).
Akin to the pacstrap action - there is a Debian package for pacman. Plus
upstream pacman continuously builds and tests pacman against Arch,
Fedora and Debian.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
v2: [Ed]
- Drop --color never as it is implicit
- Drop --noprogressbar likewise
- Reorder remaining arguments
- Style tweaks
v3: [Emil]
- Run the lot through gofmt -s -w
- Commit message
- Sort the action alphabetically
v4: [Emil]
- Drop quotes around pacman
Signed-off-by: Ed Smith <ed.smith@collabora.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
---
Similar to the pacstrap action, the formatting is a bit weird props to
gofmt. Happy to drop that hunk.
Add a pacstrap action, which is the Arch variant of debootstrap.
In other words, this allows us to bootstrap an Arch image.
Bear in mind that the tool pacstrap is a thin wrapper around the pacman
package manager. Both of those are separate projects and are available
as Debian packages, in case one wants to give them a try.
This is loosely based on the work by Arnaud Rebillout
Note: the action works only within a fakemachine instance, making it
work outside is doable but left for a later day.
v2:
- drop pacman-key capitalisation
v3:
- drop pacstrap capitalisation
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
---
Some of the changes made:
- Commit message
- Remove all pacman.conf and mirrorlist generation
- Use drop-in user files for ^^
- Remove custom flags passed to pacman-key, pacstrap
- Add Verify hook for validation
- Sort the action
- Run through gofmt -s -w
- Add PreNoMachine() stage
NOTE: the funky formatting of the pacstrap_action.do header is due to
gofmt. Can drop those changes if people prefer.
For me as a user it was unclear to me what kind of penalty there
is for not allowing access to /dev/kvm, so I timed how long
building pine-a64-plus/debian.yaml takes for the different
backends.
I did not use the rpi recipes as they spend a lot of time downloading
firmware blobs.
The tested debos version is 82c36d07b3
(current main at the time of writing) and the benchmarks have been
run on an otherwise-idle box with the following specs:
* Debian Bullseye AMD64 (kernel 5.10.92)
* go version go1.15.15 linux/amd64
* 4 x Intel(R) Pentium(R) CPU G4560T @ 2.90GHz
* Fast M.2 SSD
* 24 GiB of RAM
For posterity, the very simple benchmark script is attached below:
#!/bin/bash
set -eux
time sudo debos --disable-fakemachine debian.yaml
time debos -b kvm debian.yaml
time debos -b uml debian.yaml
time debos -b qemu debian.yaml
These days there are more example recipes then just for
the Raspberry Pi 3; explain that.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
The readme has got a bit out-of-sync with the help command; update the
readme for the new options and descriptions.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
The usage of the container as an executable does not seems to be
straightforward.
Add a warning in docker/README.md and add container installation reference
in main README.md.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This action includes the recipe actions at the given path, and can
optionally overrides or adds new template variables.
To allow recipes to operate both stand-alone and when included, template
variable "included_recipe" is added and set to "true" to indicate that
the recipe is part of a longer chain.
This allows a recipe to skip the unpack step if it's not the first to be
executed or to optionally skip a pack action when it's not the last.
For compatibility, both the parent recipe and all included recipes have
to be for the same architecture.
Limitations of combined recipes are equivalent to limitations within a
single recipe (e.g. there can only be one image partition action).
Print-recipe option is saved in DebosContext to allow each "recipe action"
to print its source during Parse.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This adds debos options:
- --print-recipe to print final recipe
- --dry-run to compose final recipe to build but without any real work
started
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This change makes debos read a predefined set of environment variables
from the host and propagates it to fakemachine. The set of environment
variables is defined by environ_vars on cmd/debos/debos.go. Currently
the list of environment variables is configured to the proxy environment
variables as documented here[1]:
http_proxy, https_proxy, ftp_proxy, rsync_proxy, all_proxy, no_proxy
While the elements of environ_vars are in lower case, for each element
both lower and upper case variants are probed on the host, and if found
propagated to fakemachine. So if the host has the environment variables
HTTP_PROXY and no_proxy defined, both will be propagated to fakemachine
respecting the case.
This patch also adds --environ-var and -e command line options that can
be used to specify, overwrite, and unset environment variables for
fakemachine with the syntax:
$ debos -e ENVIRONVAR:VALUE ...
To unset an enviroment variable, or in other words, to prevent an
environment variable to be propagated to fakemachine, use the same
syntax without a value. debos accept multiple -e simultaneously.
[1] - https://wiki.archlinux.org/index.php/proxy_settings
This change depends on:
8b7eea7096cd015771cf9862647b7cd04bb41904 - machine.go: Add support to
environment variables
on fakemachine repository.
Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
`debootstrap` and git are quite obvious, but I think worth mentioning
`systemd-container` - `systemd`-nspawn was missing
`qemu` packages are required by `fakemachine`
Yaib (yet another image builder) was always a temporary name, while I
suck at naming debos seems like a pretty good name that isn't overly
confusing (yaib is also the name of an irc bot).
With the renaming I'm also considering the current yaml format and
actions as stable, which means no backwards incompatible will be done
from this point onwards without changing the major version (1)
