We are getting rid of the virtual/pam package. The package provided a
dependency on one of pam or openpam. It looks like Gentoo dropped
openpam, making virtual/pam unnecessary. Also, existence of
virtual/pam causes some circular dependencies to manifest during
emerging.
We are getting rid of the virtual/pam package. The package provided a
dependency on one of pam or openpam. It looks like Gentoo dropped
openpam, making virtual/pam unnecessary. Also, existence of
virtual/pam causes some circular dependencies to manifest during
emerging.
We are getting rid of the virtual/pam package. The package provided a
dependency on one of pam or openpam. It looks like Gentoo dropped
openpam, making virtual/pam unnecessary. Also, existence of
virtual/pam causes some circular dependencies to manifest during
emerging. This package does not depend on virtual/pam outright, but
let's avoid having an out-of-date comment.
The version now matches what is in Gentoo, despite being almost, but
not quite, entirely unlike upstream recipe. The rename is needed,
because some packages may depend on a newer pambase after they are
updated.
This is to avoid importing fcaps eclass which adds a dependency on
sys-libs/libcap, which in turn depends on sys-libs/pam. To get out of
this conundrum, we could specify a "-filecaps" use flag for
sys-libs/pam. Problem with this solution would be no capability
override for the binary making it unable to read /etc/shadow. Thus we
make the binary suid. This is strictly less secure than overriding its
capabilities, but I have no idea how to solve it in a less hacky way.
Qemu has enabled `jpeg` USE flag since the beginning, without any
reason specified. As a result, qemu pulls in unnecessary packages,
`virtual/jpeg` as well as `media-libs/libjpeg-turbo`. However,
Flatcar runs qemu always with `-display none` option. So the `jpeg`
flag is not needed at all.
Simply remove `jpeg` USE flag from qemu.
Before applying Flatcar patches to bsdiff, sync with upstream Gentoo,
so the ebuilds could make use of EAPI=7.
Also drop third-party patches, to be able to start from scratch.
Doing that we can fix [CVE-2014-9862](https://nvd.nist.gov/vuln/detail/CVE-2014-9862),
integer signedness error in bspatch.c. With the vulnerability, remote
attackers to execute arbitrary code or cause a denial of service
(heap-based buffer overflow) via a crafted patch file.
Since Gentoo already has the third-party patch, we can simply make
use of it.
See also https://bugs.gentoo.org/701848 ,
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f4d7646f1d69 .
A symlink `vimdiff` should not be created, if the USE flag `minimal` is
enabled. Otherwise running `vimdiff` results in failure like that:
```
$ vimdiff aaa bbb
This Vim was not compiled with the diff feature.
```
Github Actions for Rust started failing with following errors:
```
Error: Unable to process command '::set-env name=PULL_REQUEST_NUMBER::718' successfully.
Error: The `set-env` command is disabled. Please upgrade to using
Environment Files or opt into unsecure command execution by setting the
`ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For
more information see:
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
```
It happens because we have used peter-evans/create-pull-request@v2,
which did not have a bug fix for the set-env issue.
The bug was fixed in create-pull-request
[v3.4.1](https://github.com/peter-evans/create-pull-request/releases/tag/v3.4.1).
So we just need to update the version to `v3`, which already includes
v3.4.1.
Github Actions for Rust started failing with following errors:
```
Error: Unable to process command '::set-env name=PULL_REQUEST_NUMBER::718' successfully.
Error: The `set-env` command is disabled. Please upgrade to using
Environment Files or opt into unsecure command execution by setting the
`ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For
more information see:
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
```
It happens because we have used peter-evans/create-pull-request@v2,
which did not have a bug fix for the set-env issue.
The bug was fixed in create-pull-request
[v3.4.1](https://github.com/peter-evans/create-pull-request/releases/tag/v3.4.1).
So we just need to update the version to `v3`, which already includes
v3.4.1.
It is already possible to enable kernel config `CONFIG_DEBUG_INFO_BTF`
using dwarves 1.18 included in the current Flatcar SDK, as long as its
arch is amd64.
However, Kernel build fails in case of arm64, when Kernel version is
>= 5.9 and dwarves version is <= 1.18, like the following:
```
+ pahole -J .tmp_vmlinux.btf
PAHOLE: Error: Found symbol of zero size when encoding btf
(sym: '__kvm_nvhe_arm64_ssbd_callback_required', cu: '../source/arch/arm64/kernel/cpu_errata.c').
PAHOLE: Error: Use '-j' or '--force' to ignore such symbols and force emit the btf.
../source/scripts/link-vmlinux.sh: line 141: 1929102 Segmentation fault
```
The bug was fixed via
https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=2e719cca6672,
("btf_encoder: revamp how per-CPU variables are encoded").
The fix was first included in dwarves
[1.19](https://git.kernel.org/pub/scm/devel/pahole/pahole.git/tag/?h=v1.19).
Thus we need to get dwarves 1.19 included in Flatcar SDK, so that the
next Alpha Kernels could have `CONFIG_DEBUG_INFO_BTF` enabled.
# Enables Raspberry Pi 4 PHY
The following 1 line change enables the kernel module to be build enabling the Raspberry Pi 4 PHY enabling the on-board NIC.
# How to use
Build it and boot it :)
# Testing done
Validated the config change against known working 5.8.y kernels on the Pi4.
