The `--jobs` parameter that some scripts defined was not used anywhere
in jenkins or mantle. So the value of the parameter always ended up
being equal to `${NUM_JOBS}` set by `common.sh`. Also, even if the
`--jobs` parameter was used for some script, that script usually
didn't forward the jobs value to other scripts, so the other scripts
ended up using `${NUM_JOBS}` again. Also, the `${FLAGS_jobs}` variable
was used by some functions in the build library, and those functions
were sometimes invoked by scripts that didn't define the
`${FLAGS_jobs}` variable. It is tedious to track which script should
actually define the parameter, and where it should be forwarded.
Just get rid of this half-working pretense. If you want to affect how
many jobs `emerge` uses, export the `NUM_JOBS` environment variable
before calling any script.
For `EMERGE_FLAGS` and `REBUILD_FLAGS` we unconditionally specify the
`--jobs` flag's value to `${NUM_JOBS}` because they are passed to
`emerge`. On the other hand we drop the `--jobs` parameter from the
`UPDATE_ARGS` variable, because this variable passed to `setup_board`
or `update_chroot`, which don't have this flag any more.
Now, in the oem aci creation step we make use of the jobs param.
Without this flag, an empty string is passed to to emerge which results
in failure.
Signed-off-by: Sayan Chowdhury <sayan.chowdhury2012@gmail.com>
They end up using emerge_to_image which needs uses the `$FLAGS_jobs`
parameter. Seems like new portage does not like getting the parameter
like `--jobs=` (with an empty value).
The script is written in python2 and it imports portage code. Since
the portage is going to become a python3-only code, the script needs
porting to python3. It is not the high priority right now, because it
seems to be not used by other scripts or jenkins.
The script needs to be ported, because it is importing portage code
which became python3 only.
The porting I did is likely a lousy job, but at least it stopped
failing with some p(yt)hony errors.
Previously we broke the cycle caused by sys-apps/util-linux only,
while disabling cryptsetup USE flag in systemd to avoid another
cycle. That worked before, because the follow-up merge of the rest of
packages built sys-fs/cryptsetup before sys-apps/systemd. After an
update, the new portage is ordering the builds in different way and
sys-apps/systemd ended up being built before sys-fs/cryptsetup and
that failed during the configure phase because of unmet dependencies.
Better build all the packages taking part in the loop (not counting
the virtual packages), so we become less reliant on the package build
ordering. It is going to take slightly more time as we build a couple
of packages more.
Instead of rebuilding just one package and maybe rebuilding others as
a fallout, force rebuilding all the mentioned packages. This makes the
build process a bit more robust against package build ordering
changes.
May be useful when breaking multiple dep loops that have some common
packages, so we build them all once.
ROOT_OVERLAY variable is defined in terms of TEMPDIR. The TEMPDIR
variable is set to an empty value by catalyst.sh, which the two
scripts import. So ROOT_OVERLAY always ended up being located in
toplevel directory (i.e. `/`). But the TEMPDIR variable gets a
meaningful value after calling the catalyst_init function, so define
the ROOT_OVERLAY after the function is called.
I have no idea how this thing worked before - the repos never were in
/usr/portage nor in /usr/local/portage… But the newer version of
portage seems to be pretty picky about the validity of repos location,
so fix them.
eselect calls "portage get_repo_path /build/amd64-usr coreos" at some
point. Before updating portage, portageq seemed to take all the
information not from /build/amd64-usr (which at the time contained no
repo information at all), but rather from /. The newer version of
portageq seems to respect the passed root now, so it actually tries to
consult the nonexistent repos configuration in /build/amd64-usr and
fails. To avoid the failure, perform the copying of the configuration
files earlier.
When a license file is newly added, portage may not yet have it in the
shared folder and the license inclusion step fails.
Fall back to the source repositories and look for the license file
there, too. Print a warning if not found instead of failing to build.
The build_image script invokes the create_dev_container function, and
passes the `FLAGS_group` as param. Use the param, to generate the
binhost URL instead of using the DEFAULT_GROUP which stays as developer
always.
Fixes: kinvolk/Flatcar#298
Signed-off-by: Sayan Chowdhury <sayan@kinvolk.io>
Kernel source tree started to have a broken link
`tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S`.
Especially in case of Kernel 5.8.18, like:
```
broken link: /usr/src/linux-5.8.18-coreos/tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S
ERROR build_packages: test_image_content: Failed symlink check
```
Ignore the symlink when checking broken symlinks.
Setting the invalid CCACHE_ variables resulted in strange failure
in projects depending on meson, newer version like 0.55.3. For example
systemd build fails like the following errors:
```
* ACCESS DENIED: utimes: /mnt/host/source/ccache
* ACCESS DENIED: utimes: /mnt/host/source/ccache
F: utimes
S: deny
P: /mnt/host/source/ccache
A: /mnt/host/source/ccache
R: /mnt/host/source/ccache
C: ccache cc /build/amd64-usr/var/tmp/portage/sys-apps/systemd-246/work/systemd-246-abi_x86_64.amd64/meson-private/sanitycheckc.c -o /build/amd64-usr/var/tmp/portage/sys-apps/systemd-246/work/systemd-246-abi_x86_64.amd64/meson-private/sanitycheckc.exe -O1 -pipe -pipe -D_FILE_OFFSET_BITS=64
```
We should not set up ccache at all, as it has been already disabled in
coreos-overlay repo.
