Ofborg does not respect `meta.platforms`

Based on the official manual, I was under the impression that ofborg respected the setting of meta.platforms. However, I’m currently seeing a situation in which meta.platforms does not include aarch64-linux, but ofborg is still trying (and failing) to evaluate the package on aarch64-linux.

Why is ofborg not respect the setting of meta.platforms? What does one have to do in order to prevent ofborg from getting hung up on unsupported platforms?

What part of the manual gives this impression? (Correct link? I don’t see any references to ofborg on the linked page.)

Oh sorry, it says hydra builds according to meta.platforms and I just assumed that ofborg would do the same.

How can I tell ofborg to skip evaluation on certain platforms?

Well, nix-env -qa shouldn’t bail on any platform. Typically you avoid reaching any bad parts by some combination of assert/throw/meta.broken/…

EDIT: but it’s still possible that there’s some unnecessary strictness, either in ofBorg or triggered by it (e.g. somewhere in stdenv). I just had a quick glance on what you linked.

I’m not aware of a mechanism, but I don’t manipulate it a lot.

In any case, I imagine eval failures are a bigger problem than build failures (my mental model suspects that meta.platforms / broken will exempt you from actual builds, but not from eval checks).

Maybe ofborg maintainers such as @cole-h @Artturin @andir know if there’s a lever and if this is a situation that merits pulling it.

it feels correct to me that even if some platform isn’t supported then it still should not fail with a “attribute missing” on that platform with NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

  src = if !cudaSupport then (cpuSrcs."${stdenv.hostPlatform.system}" or (throw "jaxlib not supported on ${stdenv.hostPlatform.system}")) else gpuSrc;

What’s the advantage of using throw over simply cpuSrcs."${stdenv.hostPlatform.system}"? Either way evaluation fails with an error, no?

it wont fail with attribute missing

Is there something special about “attribute missing”? Does that affect ofborg’s behavior?

Missing attribute is a hard error, e.g. like abort. Errors like from throw are catchable and e.g. nix-env -qa will just skip such packages (maybe with printing some warning).


Ah, gotcha thanks @vcunat ! Are there docs/a language spec for how error handling works in Nix?

I’m not aware, beyond bits like Built-in Functions - Nix Reference Manual

1 Like

Ok, thanks all! I will update the jaxlib derivation to use throw and check how ofborg treats that.