Using string interpolation for concatenating paths caused the whole
nixpkgs source to be included as an "inputSrc" for the kernel derivation.
linux.drv:
"inputSrcs": [
...
"/nix/store/4crmmrpb9axxymrrh77lf35n015scnpj-mobile-nixos",
...
],
With concatenation, only the resulting file is included as an
"inputSrc", which avoids unnecessary kernel rebuilds when nixpkgs
changes.
linux.drv:
"inputSrcs": [
...
"/nix/store/hdr6v584ig3dpjlcs9afxxky3lvzm2nw-randstruct-provide-seed.patch",
...
],
It seems that under specific conditions:
- 2a5 hardware
- -j22
the call to `make install zinstall` (simplified here) may break, with
the installation of `System.map` happening in a manner where it fails
the build. It was not trivial to reproduce elsewhere than on a 2a5
machine, for unknown reasons.
It was also only observed on google-walleye, but there is no reason is
shouldn't be failing on other devices too.
Odd.
The applet is specifically written to show what we call the "recovery
menu". Yes, it's also the boot selection, but it will get confusing with
the upcoming boot tracking splash UI that's upcoming.
It looks like this is not a regression from the latest changes to the
kernel builder. Testing on top of ffdba8fecb
exhibits the same issue.
This change works around the issue by doing it with one invocation of
`make`, rather than doing it twice.
It has not been figured out at which exact version of the kernel this
stops being an issue, and if it is an issue from mainline Linux
outright, or something that came from Android-specific modifications.
Though it has been verified that for 3.18, both Qualcomm and Mediatek
source trees exhibit the same issue.
Fixes#216
This is a temporary measure. The last changes have proven that we can't
just overrideAttrs things willy-nilly like that, and that the whole
builder is in need of a revamp.
Let's wait for the revamp, and do the minimum work required to fix the
normalization for existing builds.
This uses the actual output expected by the build, rather than hoping
menuconfig gives the same result.
For kernels prior to 5.8 it wasn't an issue.
Starting with 5.8 the build environment will influence the actual
configuration used.
We're stripping some information when comparing.
The exact TEXT_VERSION string will change according to whether it's a
native or cross compilation.
Finally, minor version bumps are not relevant here.
