| 12 Feb 2024 |
 trofi | I wrote the maintainers/scripts/bootstrap-files/README.md recently. That might help you. | 00:33:05 |
| trofi | * I wrote the https://github.com/NixOS/nixpkgs/blob/master/maintainers/scripts/bootstrap-files/README.md recently. That might help you. | 00:33:55 |
 Puna | that seems to talk about updating existing bootstrap-files via already present hydra jobs, i'm trying to add new bootstrap-files with no matching hydra job | 06:43:04 |
| Puna | and the file that defines those targets for hydra now has a comment seemingly asking ppl to not add new targets unless there's already a matching bootstrap-files entry for it. but both of those seem to require each other first, so i'm not sure what the intended procedure is supposed to be for this anymore | 06:51:33 |
| trofi | Ah, ok. I would expect hydra cross-job submission to be the first step before creation of boothstap-files. | 07:16:28 |
| trofi | * Ah, ok. I would expect hydra cross-job submission to be the first step before upload request of bootstrap-files. | 07:19:04 |
| Puna | so would i, but that doesn't seem to be compatible with NOTE: Only add platforms for which there are files in './bootstrap-files'. | 08:03:24 |
| Puna | and the powerpc64 entry that already existed there was cleaned up because of that | 08:06:41 |
| trofi | As Artturin added it maybe they can clarify the wording (I can extend bootstrap-files/README.md this evening to explain how to add a new target if there is a consensus on how to do it). I think there is a subtle difference between "do not add things that are not expected to land on 'tarballs.nixos.org'" and "do not add things that are about to be landed 'tarballs.nixos.org'". I would say the second one is fine. I think https://github.com/NixOS/nixpkgs/commit/e2adc3a3a23d8735937e23105741763b05140812 is a counter-example. | 09:31:50 |
| trofi | Let's start from a tiny https://github.com/NixOS/nixpkgs/pull/288250 | 09:41:17 |
| 2 Mar 2024 |
|  Qyriad joined the room. | 19:34:40 |
| 3 Mar 2024 |
 Philip Taron (UTC-8) | stdenv folks, Qyriad concocted a PR which really helps make the stdenv hooks more self-documenting. I've reviewed it, and while more eyes would definitely be better, having built my NixOS system with it, I think it's good to go.
What's needed in order to get it either further reviewed or merged?
| 23:00:03 |
| 4 Mar 2024 |
| Puna | In reply to @trofi:matrix.org
Let's start from a tiny https://github.com/NixOS/nixpkgs/pull/288250 thanks! adding the entry to the file now, so the original PR can go back to referring to Hydra build results and use your script for requesting an upload: https://github.com/NixOS/nixpkgs/pull/293257 | 14:07:46 |
| 9 Mar 2024 |
| Philip Taron (UTC-8) | Qyriad: did you see a-n-n-a-l-e-e 's comment on your merged PR? | 01:47:16 |
| Qyriad | I did just now | 01:49:09 |
| Qyriad | That is correct behavior for how the change was designed — it outputs just as part of the build log, just like phase headers do | 01:50:03 |
| Qyriad | nix-shell -p doing that is kind of an artifact of the cursed way nix-shell is implemented — personally I would argue this is a good thing, and makes it more transparent that nix-shell is a derivation that relies on hooks to make it work | 01:51:32 |
| Qyriad | though I suppose it is a lot of output for a common operation | 01:51:42 |
 @a-n-n-a-l-e-e:matrix.org | Redacted or Malformed Event | 01:54:08 |
| @a-n-n-a-l-e-e:matrix.org | $ nix-shell -I nixpkgs=. -p bash --run "exit"|wc -l
104
104 lines of output from the new logging.
| 01:55:16 |
| @a-n-n-a-l-e-e:matrix.org | (when bash already built) | 01:55:55 |
| @a-n-n-a-l-e-e:matrix.org | i thought i needed to add --print-build-logs but perhaps that is when using the experimental commands. | 02:01:00 |
| @a-n-n-a-l-e-e:matrix.org | #! /usr/bin/env nix-shell
#! nix-shell -I nixpkgs=. -i bash -p bash
when nix-shell used as interpreter has same issue and the output is sent to stdout, which seems bad.
| 02:05:16 |
| Qyriad | Ah right the nix- commands have print-build-logs by default, hm | 02:11:03 |
| Qyriad | Well, I could leverage the Nix log FD that's already in stdenv, and make it log based on the loglevel setting Nix itself is called with — that would make it so getting the logs vs not wouldn't change the derivation | 02:12:00 |
| @a-n-n-a-l-e-e:matrix.org | i think logging to stdout needs a fix or a revert as that will break pipelines that use nix-shell as an interpreter. i verified older nixpkgs log build output to stderr when below commands are run for the first time.
$ cat foo.sh
#!/usr/bin/env nix-shell
#! nix-shell -i bash -p "(hello.overrideAttrs { postBuild = \"#0\"; })"
hello
$ ./foo.sh 2>/dev/null
Hello, world!
but outputs all the hook logging when run with nixpkgs with the hooks change.
| 02:39:02 |
| @a-n-n-a-l-e-e:matrix.org | (i do like the hook logging in general -- seems like a good change) | 02:44:23 |
