Using `.override` inside the builder leads to `.override` outside being
ignored, as the `mruby` used would be whatever was last given to the
passthru `builder`'s own overrides or callPackages.
This breaks current calls to `mruby.builder` when `gems` was given.
Though since it breaks noisily, it won't silently ignore your gems.
This might seem weird at first, but is totally needed. We have 48 bit
integers we need to handle, RGBA colours.
AFAICT full-blown Ruby would automatically handle going through another
class for larger integer. But it looks like mruby doesn't
Let's intead use the 64 bit type!
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
