As Flatcar relies on systemd-networkd for network configurations,
it is not needed to keep dhcpcd in production images at all.
According to the commit
https://github.com/kinvolk/coreos-overlay/commit/9be90f06e838 ,
it was added back in 2014 just because systemd-networkd was not mature
enough. That was already ~7 years ago, so we can safely assume that
the issue had been already gone, so we can simply use systemd-networkd.
generate_patches takes three parameters - a category, a package name
and a description. Invoking the function like `generate_patches
sys-kernel coreos-{sources,modules,kernel} Linux` makes "sys-kernel"
to be a category, "coreos-sources" to be a package name and
"coreos-modules" to become a description, while "coreos-kernel" and
"Linux" are simply ignored.
It has worked so far only because coreos-sources was first in the list
and that's where the actual changes in Manifest file happened. Had the
order of the packages been different, the workflow would be
broken. Since only coreos-sources was modified and all worked fine,
simplify the call to generate-patches.
This change updates coreos-init to a version which includes
a new SSHD config to limit crypto to "known secure" algorithms only.
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
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).
Initially I moved the eclass to overlay and modified them there to
avoid making customizations in portage-stable, but for some reason
portage cannot locate these eclasses when building packages from
portage-stable.
This change is to avoid masked packages and resulting fromt that build
failures like:
!!! All ebuilds that could satisfy "x11-misc/makedepend" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-misc/makedepend-1.0.5::portage-stable (masked by: invalid: DEPEND: USE flag 'ppc-aix' referenced in conditional 'ppc-aix?' is not in IUSE)
Hopefully these customizations will go away once we update the
eclasses and packages that inherit these eclasses.
