To be able to build `net-fs/samba` 4.11, we need to import
`net-libs/gnutls` from upstream Gentoo. Since gnutls is one of the
hard requirements of upstream Samba, we are not able to disable the
dependency on gnutls.
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")
Now that `dev-lang/tcl` is included in SDK, we can now build
dev-db/sqlite without having to rely on third-party patches
in coreos-overlay.
So simply sync sqlite with Gentoo upstream, and update to the latest
version 3.33.0.
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.
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.
To be able to update `dev-util/gdbus-codegen` to 2.64.5, we need to
specify a single target python3.6 for gdbus-codegen.
Without it, it is not possible to emerge gdbus-codegen, because
it thinks there are multiple python single targets for the package.
Now that dev-libs/glib was updated to 2.64.5, we need to also update
dev-util/gdbus-codegen to 2.64.5.
Otherwise we would see strange slot conflicts like:
```
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(dev-libs/glib-2.64.5:2/2::portage-stable, ebuild scheduled for merge) pulled in by
>=dev-libs/glib-2.58.3:2 required by (dev-util/gdbus-codegen-2.58.3:0/0::portage-stable, binary scheduled for merge)
(dev-util/gdbus-codegen-2.58.3:0/0::portage-stable, binary scheduled for merge) pulled in by
dev-util/gdbus-codegen required by (coreos-base/hard-host-depends-0.0.1-r194:0/0::coreos, binary scheduled for merge)
```
