The new bootspec feature, now enabled by default, refers to the
`modDirVersion` field, which was not present in that stub implementation
of the kernel package interface.
This fixes evaluation on a system without a kernel (shared rootfs).
This can be useful when used with `nix repl`. For example, using:
```
:p options.environment.systemPackages.definitionsWithLocations
```
You can figure out where a specific package was added, when simple
grepping is hard in Nixpkgs.
As of right now, it mostly makes things black on white.
Why make enabling the theme a discrete option? That's because it can be
useful for people like me who would like to live with a flicker-free
boot using a black on white fbcon!
I try to convert strings to integers so the configuration is less
awkward. Nix doesn't do `0x______` integers. So since colours are never
written in base ten, let's allow strings.
This ensures that, for implementation details, bits that use stage-0 as
a synonym for stage-1 when it is not supported gets the same exact eval
than the one for stage-1.
Without this change, some `fdt-forward` and changes made under that
`mkIf` would end-up included. `fdt-forward` was found to be in the
stage-1 image even though it was irrelevant.
... this way, the framebuffer content is not evicted by a needless mode
change.
AFAIK none of our targets will be affected by this change. The
framebuffer should already be setup with the correct mode. This was
holdover from early early cargo-culting about the framebuffer.
I have verified on a few devices, it does not worsen their behaviour.
Technically this is an issue from 5.1, but the patch won't apply on 5.1,
so let's target the following stable release.
It serves no purpose to force on 5.1~5.3 which are EOL and should not
have been used as a base by vendors.
By using a square aspect ratio logo as the source material, we can
"fill" the area, which will not go outside of the bounds, which implies
that the image is scaled to the smaller dimension.
This image is then trimmed, meaning that it is cut to remove any
redundant colour at the outside edge.
There is no `override` that will work given the number of `callPackage`
calls between this and the actual derivation.
I guess `overrideAttrs` could be used instead, if we used an attribute
of the derivation instead. I'm not sure if it's better since it would
entail using `apply` to `overrideAttrs` the final `kernel.package`
value.
