It's being replaced by the generic uefi-x86_64 device.
Basically, replace the QEMU-specific system type by the totally standard
UEFI system type. This way we're dogfooding it way better!
The way we're handling them is to have a global timer that is reset at
any point a task is ran.
This gives a maximum amount of chances to any task to have its
dependencies resolve.
A minimum of 60s is given, but in reality the chances are the conditions
for trying to resolve were already present before the timeout started
counting towards that particular dependency.
Note that a long running task, when successfully ran, does not cause the
timeout to be reached.
E.g. at 10s of timeout a task is started, the loop is not executed until
the task exits. When it exits the branch followed is for a task that
ran, which means that even if the task took 70s total (which gives us 80
seconds) a timeout of 60s wouldn't apply here.
Though, please, don't make your tasks take that much time to run!
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
"default" values in Nixpkgs manual can *somehow* be escaped by the
documentation back to their original string form.
The following ends up escaped into the manual as `"${pkgs.hello}"`.
```
default = "${pkgs.hello}";
```
The methods for this magic have not been found.
Instead, we just change the default strict `handleEvalIssue` so that it
does absolutely nothing and lets them through.
Anyway we won't be building them.
Actual work should be done to figure out why those `default = pkgs.___`
cause issues *only* with our docs generation, and don't fail the NixOS
channels :/
This replaces the embryonic "Porting Guide" link from the top menu, and
the new page links back to it.
This, in turn, allows us to make more resources easily accessible in a
curated page, rather than hoping users will use the Site Map.
