None of these are necessary anymore. They do not apply cleanly to
current versions of ebuilds in Gentoo's repository, causing builds to
fail.
Going forward, I think it will be better to maintain patched ebuilds in
the Aimee OS repository, rather than patching them at build time.
Instead of building host tools along with the target packages, we now
rely on the build container to contain everything we need to build Aimee
OS. The _aimee-os.org/build/build-{target}_ image (tentative name)
includes a cross-compilation toolchain and all of the tools that were
originally listed in `host-tools.packages`.
Aimee OS variants can now supply a `semange.mods` file in their
configuration directories. This file contains SELinux customizations,
in the format produced by `semanage export`. Variants can use this
mechanism to set SELinux booleans, change user/login mappings, and other
SELinux policy customization. At build time, the base `selinux.mods`
file in the source directory is combined with the variant's file, if it
exists, and the resultant customizations are applied in a single
transaction.
The `mksquashfs` command accepts a `-pf` argument, which specifies a
file that defines "pseudo files." Each line in the file defines some
file path and an operation to perform on that path *in the generated
filesystem image*. This allows, e.g. creating files, changing their
permissions, etc. that cannot be done in the source directory for
whatever reason.
Aimee OS now allows a variant to provide a pseudo file definition file
for `mksquashfs` by creating a `squashfs.pseudo` file in its
configuration directory.
Variants no longer need to specify the full contents of the
`squashfs.exclude` file. The "base" file in the source directory gets
combined with the one from the config directory (if it exists).
The `build.packages` and `install.packages` files in the CONFIGDIR now
only need to include *additional* packages to install. The packages
*required* for Aimee OS are always installed, listed in the
corresponding files in the source directory.
In effort to support different builds of Aimee OS using the same
scripts, without necessarily having to fork this repository, the build
system now supports a `CONFIGDIR` setting. When this variable is set,
files defining the target environment, such as the lists of packages to
install, the kernel configuration, the Portage configuration, etc. are
found in the path it specifes.
The reference build, for the Home Assistant Yellow board, is configured
in the `yellow` directory. To build it, run:
```sh
CONFIGDIR=yellow ./vm-build.sh
```
If any file in the `overlay` directory changes, the `build-rootfs.sh`
script needs to be re-run in order to copy the changes into the
destination root and regenerate the SquashFS image.
Instead of copying the Portage configuration files to `/etc/portage` and
`/usr/${target}/etc/portage`, the build scripts now use the
configuration directories from the source directory. This avoids issues
with changes (especially removal of files) getting propagated to the
actual configuration paths.
The Portage packages that need to be built and/or installed are now
specified in the `build.packages` and `install.packages` files,
respectively. Similarly, packages to be installed on the host system
are specified in `host-tools.packages`. Finally, the
`installonly.packages` file contains a list of packages that are
installed in the destination root, but not built in the sysroot
beforehand.
This allows `make` to better track when the package sets change. It
will also make it easier to maintain different sets for different
variants in the future.
When running inside a QEMU microvm with the source directory shared
via 9pfs, the kernel build process fails
> Error: Could not mmap file: vmlinux
Thus, we need to run the build in a path on a local filesystem. To
support this, the Makefile now supports an `O` option, and all the build
scripts have been adjusted to make use of it as needed.
Since building in a local filesystem would ultimately discard the final
artifacts when the VM terminates, we need yet a different location for
the files we want to keep. The `IMAGESDIR` option can be used to
specify this path. This path can be on a shared filesystem, thus
saving the artifacts outside the microvm.
Building the OS is now as simple as running `make` on a Gentoo system.
Interestingly, when `make` is executed as a (grand)child process of
another `make` process, it always prints an `Entering directory ...`
message. This breaks the `make kernelversion` command, by adding
extraneous text to the output.
Dustin