Forwarding parameters to another bash invocation through a string
interpreted as a bash script is a bit troublesome. It is not enough to
wrap a parameter like 'foo bar' in escaped double quotes (\") to avoid
it being split into two parameters by bash executing the script
string. It mostly works, but there's always a risk of having a path
where this breaks. It's rare
Wrapping into escaped quotes, be them double or single, also won't
work for passing an array of parameters, so it's even easier here to
trigger globbing or bracket expansion or another unwanted splitting of
supposedly one parameter into multiple. Globbing can be temporarily
disabled with 'set -f' or 'set -o noglob', but this still leaves all
the other special bash characters unescaped. So each parameter in the
array should be escaped before they are put into the script string.
The escaping can be done with `printf` and its '%q` formatter, so
let's do so. For single parameters it is as simple as
`foo_escaped=$(printf '%q' "${foo}")`, for arrays a loop needs to be
used.
Build and CI tests should run automatically whenever a pull request is
opened, reopened or updated. On the other hand, it is not necessary to
run build and CI tests on the events ready_for_review and
review_requested.
We used to create a base_image_var.conf tmpfiles config file that
contained information about directories under /var that weren't
covered by any other tmpfiles config file. Recently some package
update started installing a directory under /var that belonged to a
user/group not found directly in passwd/group file in /etc. This
user/group was defined in passwd/group in /usr/share/baselayout, but
at the early boot, these are not yet checked for user/group
information, so systemd-tmpfiles running inside initrd failed when
trying to create such an entry using the base_image_var.conf tmpfiles
config file.
Split the base_image_var.conf into two files - base_image_var.conf and
base_image_var_late.conf. The former will only contain entries owned
by user/group that are supposed to exist very early in the boot, while
the latter will contain the rest of directories - those will be
created later during the boot.
This will generate tmpfiles config only for directories that are owned
by an allowed user and group if such are passed. Not passing any
allowed users or groups, allows any user or group.
The `dev-python/setuptools_scm` was renamed in first quarter of 2023
to `dev-python/setuptools-scm` (the underline was replaced with a
dash). To be safe, check for blockers with the new package name, just
in case.
The `list` command of `equery` will exit with status 3 if a package is
not found and `--quiet` is in effect. This results in some non-fatal
noise during the SDK build:
INFO update_chroot: Maybe removing some hard blocks
ERROR update_chroot: script called: update_chroot '--toolchain_boards=arm64-usr' '--usepkg' '--nousepkgonly' '--getbinpkg'
ERROR update_chroot: Backtrace: (most recent call is last)
ERROR update_chroot: file update_chroot, line 250, called: remove_hard_blocks 'sudo_e_emerge' 'equery' 'dev-python/setuptools_scm:2'
ERROR update_chroot: file update_chroot_util.sh, line 49, called: get_versions_from_equery 'equery' 'dev-python/setuptools_scm'
ERROR update_chroot: file update_chroot_util.sh, line 9, called: die_err_trap '"${equery_cmd}" --quiet --no-color list --format='${version} ${fullversion}' "${pkg}"' '3'
ERROR update_chroot:
ERROR update_chroot: Command failed:
ERROR update_chroot: Command '"${equery_cmd}" --quiet --no-color list --format='${version} ${fullversion}' "${pkg}"' exited with nonzero code: 3
INFO update_chroot: No hard blockers to remove
Shut the noise up. If package is not found, then there is simply
nothing to do.
The two-phase nightly builds create an intermediate tag first, which
didn't match the main nightly tag regexp before. Because of that, the
commit was not pushed to the main branch. The following final SDK
build had a version that matched the regexp, but the last commit (with
the intermediate tag on it) wasn't in main, and thus was also not
pushed.
