The wrapper for bundlerApp, starting with
e8993319724901f132dd4ed997f5383c4a482940 in Nixpkgs ends up using the
runtimeShell for the target platform. Yes, with buildPackages.
This forces an mruby that is more appropriate, rather than rely on
buildPackages.
It may look like it works for aarch64 without this patch, but this is
only because for pkgsStatic+aarch64 cross-compiles fine.
This package provides a unique binary per architecture, which can load
an additional script from the flashable zip.
This way, one "expensive" (not really) build of mruby+script is shared
for the whole architecture.
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.
