The `-o` argument to `xargs` tells it to reopen a TTY to pass to the
spawned process's standard input. If there is no controlling TTY, this
will fail. There's no reason to do this anyway, so let's avoid it.
_sys-apps/util-linux_ first must be built (in the prepare stage) with
`USE=build` and then reinstalled later without that flag. We can save
time in the second step by using binary packages if they are already
available (i.e. from a previous build).
Instead of requiring every Aimee OS project to carry around a full
Portage configuration tree, including patches, saved configurations,
etc., we now support a "layered" configuration system. Aimee OS core
provides a base configuration that includes all settings, patches, etc.
common for all Aimee OS projects. At build time, this base
configuration is combined with the project's configuration, which need
only specify USE flags, etc. for that specific project. This should
make maintenance across multiple projects easier, and make getting a new
project started _significantly_ less cumbersome.
Apparently `FEATURES` and/or `EMERGE_DEFAULT_OPTS` set in `make.conf` do
not seem to apply to packages pulled in as `BDEPEND` dependencies and
installed in `/` instead of `/usr/${target}`. This causes binary
packages to not be built/used for those packages. Passing `--buildpkg`
(`-b`) and `--usepkg` (`-k`) on the command line ensures that binary
packages are built for everything.
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
```
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.
Several packages end up with circular dependencies, depending on which
Portage profile is selected. The default profiles have a circular
dependency between *sys-libs/pam* and *sys-libs/libcap*. Systemd and
SELinux profiles have even more issues.
We can break the circular dependencies by explicitly building *libcap*
with`USE=-pam` first, which happens to be the default configuration
generated by `crossdev`. Then, we need to switch to a more complete
profile in order to build *glibc* and *util-linux*. At this point, the
build root should be complete enough to build anything without circular
dependencies.
Dustin