I'm a bit confused as to why ofborg says this needs 5001+ rebuilds. The added extraConfigFlags is clearly guarded by a condition that is false for all of ofborg's evaluations.

Nevermind, I figured it out, have to set extraConfigFlags to null instead of [].

This should no longer cause any rebuilds whatsoever. In light of that, I have changed the base branch to master, since this won't have any effect on any of the builds that Hydra currently performs.

Also, I am confused why we are building glibc when we are trying to use musl!

Will take a look.

Also, I am confused why we are building glibc when we are trying to use musl!

It was somewhere within

nix-build . -A pkgs.pkgsCross.mips64el-linux-gnuabi64.pkgsStatic.nix_2_4

... I'm rebuilding with this patch reverted to find the exact reason. Yeah, I recall being surprised by that too.

Note that you need to be cross-compiling a static binary. Although this sounds esoteric it is incredibly useful for producing the initial nix binary to be used on a brand-new platform. Otherwise you end up with a dynamically-linked nix that expects to find its shared libraries in /nix/store, but if you put them there manually you're doing some pretty shady stuff to what will become the target machine's store. I've done this, and it seems to sorta work, but probably isn't such a great idea.

I also think it would be nice if Hydra built static nix binaries for all the platforms it produces bootstrap-files for. I'll submit a PR for that soon.

On the tip of master the only thing that didn't build for me was boost

 $ nix-build . -A pkgs.pkgsCross.mips64el-linux-gnuabi64.pkgsStatic.nix_2_4 --dry-run
these derivations will be built:
  /nix/store/gjayd0z6742dp30ynpcqs757kkdin7a7-boost-static-mips64el-unknown-linux-muslabi64-1.77.0.drv
  /nix/store/d7c5p1xin7x6b98pn78i0hgzakzqrd9l-nix-static-mips64el-unknown-linux-muslabi64-2.4.drv

I think that means we can close this.

I think that means we can close this.

Yes.

Tracking down exactly what was going on here was harder than I thought, so let me document it.

For the record: this problem was introduced in the early revisions of my PR #161158. @Ericson2314 pointed out here that I was missing cases in the "convert this platform to a statically-linked platform" function. That function had no name at the time, and was copy-pasted into multiple different places; it has since been refactored as makeStaticParsedPlatform and includes the missing cases.

pkgsStatic.nix depends on pkgsStatic.busybox. Without the missing cases mentioned above, pkgsStatic.busybox will depend on glibc-static rather than musl-libc. The end result is a mishmash of some packages linking against musl and some linking against glibc-static. Mayhem ensues.

Anyways, if this happens again, we know why.

the only thing that didn't build for me was boost

@Ericson2314 by the way, that is fixed by #161162, which has had no objections since it was opened almost two months ago (just two minor formatting requests, both implemented)...