We need to filter not only `-Wl,-O1`, but also other flags like
`-Wl,-O2`, `-Wl,-Og`, `-Wl,-Os`, etc. Otherwise, SDK build would fail,
for example, as its default `$LDFLAGS` includes `-Wl,-O2`.
We need to manually strip only the optimization element of
comma-separated flags, e.g. from `-Wl,-O1,-s` to `-Wl,-s`.
To support multiple characters that can follow `-O`, e.g. `-Ofast`,
we should use regexp like `[[:alnum:]]*`.
The repo `github.com/flatcar-linux/mantle` has been moved to
`github.com/kinvolk/mantle`. However, Github Actions still fetch cork
binaries from the original URL, by running `curl` without `-L`. So the
request does not get redirected to the new URL. As a result,
`CORK_VERSION` becomes null.
Fix it by replacing `flatcar-linux` with `kinvolk`, as well as adding
`-L` to the curl command, just in case.
Go 1.15.5 fixed a security issue CVE-2020-28366, by rejecting certain
LDFLAGS for CGO. See https://github.com/golang/go/issues/42559.
However, that change breaks builds based on the Flatcar build chain,
because `go_export` sets `$LDFLAGS` to `-Wl,-O1 -Wl,--as-needed`.
As a result, Go build fails like:
```
go build runtime/cgo: invalid flag in go:cgo_ldflag: -Wl,-O1
```
We need to remove the flag `-Wl,-O1` from $LDFLAGS before building the
Go runtime, to fix the failure.
Although `dev-libs/cyrus-sasl` pulls in `net-mail/mailbase`, the
mailbase package is not needed at all.
Simply mark it as provided, to make it build without mailbase.
Also enable python_single_target_python3_6 for tdb, talloc, tevent.
Remove unnecessary arm64 keywords.
Clean up unnecessary USE flags.
At the moment bind-tools does not enable `gssapi`, so its `nsupdate`
tool is also not able to run `realm` command. As a result, configure
script of `sssd` fails when running `echo realm | nsupdate`, like
`syntax error`.
To avoid such issues, we need to disable the nsupdate check for now.
After we could enable `gssapi` for the SDK correctly, we can bring back
the nsupdate check in the future.
Now that the upstream sssd 2.3.1 does not support `--runstatedir` option
from its configure script, we need to remove the option, to unblock the
configure issue like `unrecognized option --runstatedir`.
Instead we need to pass `runstatedir=` to emake commands.
In the past we
[enabled](https://github.com/flatcar-linux/coreos-overlay/commit/172d9311bacd)
the USE flag `gssapi` only for amd64, not for arm64. We did so to
avoid build issues that only happened for arm64.
However, that change caused interesting side effects in the SDK, where
bind-tools ended up being compiled without `gssapi`. It means, tools
like `nsupdate` in the SDK are not able to deal with certain commands
like `realm`. As a result, configure scripts in packages like
`sys-auth/sssd` fail, because they cannot run commands like
"echo realm | nsupdate".
We should bring the `gssapi` USE flag back to the SDK, to avoid such
issues in the future.
The `BDEPEND` is a build-time requirement, so it should not be included
in the whole `DEPEND` list. If it does, an installation of
`sys-auth/sssd` causes other dependencies to be installed not only in
the `/build`, but also under the SDK. That's not what we want, so we
need to exclude `BDEPEND` from the list.
Update sys-auth/sssd, by syncing with upstream Gentoo.
Mainly needed by net-fs/samba 4.11.
Also resolves CVE-2018-16883, CVE-2019-3811, CVE-2018-16838.
- Add a minimal USE flag for only installing libraries
- Change the Perl and Python run-time deps to build-time only
- Drop a bunch of dependencies with broken cross-compilation
- Enable using bundled libraries in their place
- Disable building libraries requiring Python
Original-by: David Michael <dm0@redhat.com>
https://github.com/flatcar-linux/coreos-overlay/commit/8445f8b4386a
The key server currently doesn't work. Since the key is not used
currently but the key we have hosted on our web server, we can remove
this failing step to restore GitHub Actions.
Apply Flatcar-specific changes, like below:
- Carry over our custom tmpfiles and securetty files
- Remove /etc files and install them to /usr, use tmpfiles
- Switch /etc/login.defs edits to /usr/share/shadow/login.defs
- Drop moving passwd out of /usr since we don't have split-usr
- Drop pkg_postinst
Original-by: David Michael <dm0@redhat.com>
6fd490ebfefd ("sys-apps/shadow: Apply CoreOS changes")
Enable Kernel config for PSI (Pressure Stall Information), which might
help system administrators to detect bottleneck in cpu, memory and io
in an easy way.
```
$ zgrep -i _psi /proc/config.gz
CONFIG_PSI=y
$ ls -l /proc/pressure/
-r--r--r--. 1 root root 0 Oct 7 11:56 cpu
-r--r--r--. 1 root root 0 Oct 7 11:56 io
-r--r--r--. 1 root root 0 Oct 7 11:56 memory
$ cat /proc/pressure/cpu
some avg10=0.13 avg60=0.68 avg300=0.28 total=1195993
$ cat /proc/pressure/io
some avg10=0.00 avg60=1.11 avg300=0.68 total=2828208
full avg10=0.00 avg60=0.91 avg300=0.56 total=2334731
$ cat /proc/pressure/memory
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
```
See also https://www.kernel.org/doc/html/latest/accounting/psi.html ,
https://facebookmicrosites.github.io/psi/docs/overview
Fixes https://github.com/flatcar-linux/Flatcar/issues/162
Use host tool when building cross.
Bump revision to -r1.
Adjust the patch on top of dbus-glib 0.110.
Original-by: Geoff Levand <geoff@infradead.org>
6d7756b77b10 ("dev-libs/dbus-glib: Fix cross compile build error")
We have these patches in v245 too. I have missed them when doing the
update to v246, because apparently I have assumed that our flatcar
branches are more or less some upstream branch/tag + our patches on
top. That assumption was wrong and it surfaced when I rebased the
v245-flatcar branch to the v245.8 tag.
Our current cros-workon setup was awkward to use when a new patch
release happened on upstream. In this case we would go to our
`v<VERSION>-flatcar` branch and merge/cherry-pick the commits from
upstream that appeared between the release we have been using so far
and the new release. In such case, our non-upstreamed patches were
hidden somewhere in history. To fix that, I proposed having a branch
for each patch release, so the branch would always be based on an
upstream tag and have our patches on top of that. An alternative
proposition was to just use the Gentoo workflow for patches, and this
is what we are doing here.
This also slightly minimizes the difference between the Gentoo recipe
and ours.
