alright, we got a recent build, so I tried again. Updated to 550e11f and ran:

$ colmena build -v --show-trace --nix-option builders "" --nix-option cores 0
x | these 11 derivations will be built:
x |   /nix/store/f1s6y83hb8gdl0s49vmj0w54i5a75gd7-ollama-0.5.7.drv
x |   /nix/store/fpfv7cn50ns667qrkwx2frn26di1hnc7-ollama.service.drv
[snip]
x | building '/nix/store/f1s6y83hb8gdl0s49vmj0w54i5a75gd7-ollama-0.5.7.drv'...

even though f1s6… is right there. Is there a way to debug that nix-community is even being requested at all, perhaps?

Do we want to enable aarch64-linux for cuda package set on hydra?

I think it makes sense with already available GH200 and Digits available in May

I am currently working on fixing cuda-samples. I wanted to bikeshed a bit more about its dependency on the insecure freeimage package. I still think that in general having eval errors for insecure package dependencies is useful. Afaik, the official hydra builders don't build insecure packages, so I am kind of against setting allowInsecure/allowInsecurePredicate/permittedInsecurePackages in release-cuda.nix.

On the other hand, it's kind of silly to treat cuda-samples as insecure just because it depends on freeimage. Most of the code in cuda-samples is for demonstration/validation purposes only, a lot of it doesn't even have proper error checking and shouldn't be used in production anyway. So it is extremely weird to refuse building cuda-samples just because there are some potential buffer overflow exploits or whatever in the library it uses for image reading.

I still think that we should just change freeimage to

freeimage.overrideAttrs (prev: {
  meta = prev.meta // {
    knownVulnerabilities = [ ];
  };
})

specifically only in the cuda-samples derivation.

However, if not shipping "vulnerable" binaries is so important, then we could keep cuda-samples broken, but introduce a separate cuda-samples.passthru.buildCheckOnly derivation that ignores the freeimage "vulnerabilities", but then replaces its installPhase with something along the lines of touch $out. That way, we keep cuda-samples.buildCheckOnly as a useful smoke test, but don't distribute any "potentially vulnerable" binaries. Though, TBH, this sounds like over-engineering and we should just override freeimage.knownVulnerabilities in cuda-samples specifically.

Any thoughts?