| 13 Oct 2021 |
 Piper McCorkle (they/them or she/her) | * I've got the bootstrap tools built, now my Hydra "cluster" (it has two machines, but one is a Raspberry Pi so it's not working on this) is churning away at seeing what else I need to tweak to get stdenv building | 04:07:52 |
| Piper McCorkle (they/them or she/her) | * for those of you interested in SPARC & PowerPC (specifically sparc64 and ppc64le for now), I've started working on getting stdenv working on them: https://github.com/NixOS/nixpkgs/pull/141448 | 04:09:17 |
| Piper McCorkle (they/them or she/her) | I'd love to hear y'all's thoughts on this:
https://github.com/NixOS/nixpkgs/pull/141448#issuecomment-941916618
W.r.t. bootstrap tools, see also #115406. These always get held up because it's hard to verify that the bootstrap tools are reproducible - how do you do that for native bootstrap tools on a platform we don't support yet? But on the other hand, cross-compiled bootstrap tools won't build stdenv because of #113977, so I'm not really sure how to proceed here.
Very true... it seems like there are three stages to building bootstrap tools:
- Cross-compile
- Native using cross tools
- Native using native tools
Maybe there should be more automation around building these - like, on a system with qemu-binfmt, you have a derivation that runs through all three stages, though that requires having a way to inject the newly built bootstrap tools into nixpkgs.
The first approach that comes to mind would be adding an argument to nixpkgsFun for the seeds, which probably wouldn't be a bad idea in general. I'd love to hear other people's thoughts on that though.
| 04:47:28 |
 Ryan Burns | I think it would be a good idea to try to produce the tarballs entirely on our hydra builders. That way there would be no "leap of faith" where the people in charge of tarballs.nixos.org have to upload an untrusted blob - they would just persist a trusted artifact direct from hydra. | 04:51:48 |
| Piper McCorkle (they/them or she/her) | Do the Hydra builders have qemu-binfmt? If not, we'll need to have a sparc64 and ppc64le buildbox to run those builds on. | 04:54:06 |
| Piper McCorkle (they/them or she/her) | * Do the Hydra builders have qemu-binfmt? If not, we'll need to have a sparc64 and ppc64le (etc) buildbox to run those builds on. | 04:54:18 |
| Ryan Burns | Unfortunately not. But what about running the build inside a full-fledged VM? We already use VMs for the NixOS tests, and cross-compile entire NixOS systems for embedded hardware. I don't think it would be too much of a leap to cross-compile a testing VM and use it to bootstrap our exotic platforms. | 04:56:12 |
| Piper McCorkle (they/them or she/her) | True, we could do that! Though that means we need to get a NixOS system working before being able to add that platform. | 04:58:02 |
| Piper McCorkle (they/them or she/her) | I wonder what the hurdles would be to getting qemu-binfmt added to the build boxes, that seems like a more elegant solution than a VM and it would mean running it locally would be as easy as nix build (as long as you have qemu-binfmt or a remote builder for the arch) | 05:20:57 |
| Ryan Burns | Maybe a question for https://github.com/NixOS/nixos-org-configurations/? | 05:34:04 |
| Piper McCorkle (they/them or she/her) | Looks like they have a Matrix room (#infrastructure:nixos.org ), asked there | 05:37:59 |
| Piper McCorkle (they/them or she/her) | In other news, with this commit you should be able to build a new bootstrap-tools just by building a derivation: https://github.com/NixOS/nixpkgs/pull/141448/commits/422076f81423e6f163669737bb70d7824653ea5d | 06:05:56 |
 sterni | In reply to @piper:lutris.engineering
True, we could do that! Though that means we need to get a NixOS system working before being able to add that platform. to start out it could be any linux distribution running a nix-daemon | 08:33:52 |
 Alyssa Ross | although then trust is expanded to that distro | 08:35:53 |
| sterni | if there just was binfmt_misc for macOS huh :p | 09:28:50 |
| Alyssa Ross | ain't that what Darling is trying to do? | 09:31:24 |
| sterni | I just wanted to make a joke about darwin being trusted technically :) | 09:33:36 |
| sterni | I wouldn't like trusting macOS for building NixOS/Linux stuff though; it's fine for building darwin ofc | 09:33:58 |
| 14 Oct 2021 |
| Piper McCorkle (they/them or she/her) | I'm getting some really strange test failures on coreutils for ppc64le https://termbin.com/s4vc
Example:
FAIL: tests/du/no-x
===================
--- exp 2021-10-14 16:02:44.259294987 +0000
+++ out 2021-10-14 16:02:44.206294528 +0000
@@ -1 +1 @@
-du: 'd/no-x': Permission denied
+/build/coreutils-8.32/./src/du: cannot access 'd/no-x': Permission denied
FAIL tests/du/no-x.sh (exit status: 1)
Anyone seen anything like this before?
| 17:06:48 |
| Piper McCorkle (they/them or she/her) | This is part of the multi-stage bootstrap tools build, and I'm sadly not sure which stage it's part of - is it possible to show the dependency tree of a derivation? | 17:07:59 |
| Piper McCorkle (they/them or she/her) | Never mind, found nix-tree | 17:10:30 |
| Piper McCorkle (they/them or she/her) | Ha, turns out I screwed up and it wasn't actually doing a multi-stage build (wasn't propagating an attr), guess I'm glad it didn't succeed and leave me with a cross bootstrap tools | 17:30:05 |
| 17 Oct 2021 |
|  Yuka (she/her) joined the room. | 13:28:51 |
|  mars joined the room. | 19:02:47 |
| 21 Oct 2021 |
| Alyssa Ross | Just in case anybody missed it, we can build systemd with musl now thanks to yuka! https://nixpk.gs/pr-tracker.html?pr=141980 | 08:29:22 |
| 23 Oct 2021 |
| sterni | Ryan Burns: ghc disables pie hardening for musl can this be dropped now? | 10:05:04 |
| Ryan Burns | sterni: Not sure - weren't people running into segfaults or smth before it was disabled? | 17:37:16 |
| Ryan Burns | my pie hardening fixes only addressed build-time failures so if anything was funky at runtime it might still need to be disabled | 17:37:49 |
| sterni | I'm not sure, maybe worth to try to blame the file | 18:44:51 |
| Alyssa Ross | i often check out the commit before the hardeningDisable was added and try building — if it failed then but now succeeds without, it's probably safe to remove. If it did build before, it was probably added to fix a runtime issue and should be retained pending further investigation. | 18:51:12 |
