| 14 Jul 2023 |
|  @rick:matrix.ciphernetics.nl changed their display name from Rick (Mindavi) to Mindavi. | 11:22:17 |
 Alex | In reply to @p14:matrix.org
So it does look like it builds but is missing for some other reason. What bit of the hydra infrastructure would cause it to become a cache hit ordinarily? A successful build. Everything Hydra builds is cached.
So either Hydra lost the need to build it to build its jobs (due to job changes or failed evaluation), or your local build of the package doesn't have the same derivation as that built by Hydra. | 11:24:41 |
 p14 | I’m only building nixpkgs unmodified from upstream, No overlays or anything like that. I’m wondering if hydra stopped needing to build it? How would I tell what pulled it into the hydra build when it was working, and then look for that in today’s state? | 11:26:17 |
| p14 | Unfortunately the standard stdenv also stopped being a cache hit for a while around a similar time. I tried doing a git bisect where I skip commits if the ordinary standard environment does not build. Unfortunately, this points at a large set of commits including merges from staging. | 11:27:43 |
| Alex | In reply to @p14:matrix.org
I’m only building nixpkgs unmodified from upstream, No overlays or anything like that. I’m wondering if hydra stopped needing to build it? How would I tell what pulled it into the hydra build when it was working, and then look for that in today’s state? I'd probably bisect until I find the exact commit where Hydra stopped building it, then look at what changed and how it affects the build closure using nix why-depends --derivation. | 11:27:48 |
| p14 | The commit pointed to by the bisect is the binutils patch (sha mentioned above), which is suspicious. But that requires rebuilding quite a bit of stuff. | 11:30:23 |
| Alex | FWIW stdenv depends on binutils | 11:31:01 |
| p14 | (That is, a bisect without skipping bad ordinary stdenvs) | 11:31:07 |
| p14 | Yeah, the fact that commit is not a hit makes me wonder if something else went wrong? I suppose with the periodic rebuilds it could be anything between that commit and the next commit built by hydra? How would I figure out which commits were built by hydra so I can look at them? | 11:32:18 |
| Alex | Hydra builds practically every commit.
Look in the "inputs" tab for each evaluation.
The evaluations list also shows whenever an input changes version. | 11:33:43 |
| p14 | I am struggling to understand how Hydra built this derivation. I am looking at the release 2305 nixos jobset, and the oldest thing there. I searching for pkgsStatic does show something up, but not pkgsCross. | 11:40:10 |
 @trofi:matrix.org | I would guess that only cross-trunk jobset from https://hydra.nixos.org/project/nixpkgs#tabs-project would build cross-compilers. | 15:06:19 |
| @trofi:matrix.org | It might be that you were lucky to try 23.05 when it was very close to trunk when binaries lied around. But I could completely misinterpret it as well. | 15:07:10 |
| @trofi:matrix.org | And looking at https://hydra.nixos.org/jobset/nixpkgs/cross-trunk there was a severe regression ~today: we lost 812 extra jobs. | 15:09:48 |
| @rick:matrix.ciphernetics.nl | In reply to @trofi:matrix.org
And looking at https://hydra.nixos.org/jobset/nixpkgs/cross-trunk there was a severe regression ~today: we lost 812 extra jobs. Aborted by user it says | 15:41:45 |
| @trofi:matrix.org | Ah, good catch! I clicked on a few real failures, saw libgcc_s.so breakage and though the rest are the same. | 15:44:13 |
 sorear | In reply to @emilytrau:matrix.org
sorear: would you tell us more about what you're trying to do? :) build a package, any package, with llvm 16 ->
try using pkgsLLVM.stdenv ->
useLLVM builds a stdenv with llvm 11. I was able to override that with an overlay, but the llvm runtimes build system changed substantially between 14 and 15 and compiler-rt/libcxxabi/libunwind >=15 don't build for the hostPlatform.useLLVM=true case. After a few days I have patches to nixpkgs that let me build a pkgsLLVM(llvmPackages = llvmPackages_15).stdenv and it works for simple C programs but not C++ programs.
This was a few weeks ago, but I just joined matrix for other reasons and thought I should let people know about the ongoing project | 15:52:25 |
|  @cole-h:matrix.org changed their display name from cole-h to cole-h (back 1 Aug). | 23:51:16 |
| 17 Jul 2023 |
| @trofi:matrix.org left the room. | 06:25:35 |
| 18 Jul 2023 |
 Artturin | -embedded needs ld.lld while non -embedded doesn't https://github.com/NixOS/nixpkgs/issues/235675 | 22:38:29 |
| 19 Jul 2023 |
|  @uuuvn:dendrite.fail joined the room. | 19:39:30 |
| 22 Jul 2023 |
| p14 | Th | 10:06:37 |
| p14 | * This issue is a bit of a bummer: https://github.com/NixOS/nixpkgs/issues/177129 | 10:06:47 |
| p14 | * This issue is a bit of a bummer: https://github.com/NixOS/nixpkgs/issues/177129
Would it be reasonable to put the workaround of having an empty libgcc_eh.a somewhere into nixpkgs? | 10:07:10 |
| @trofi:matrix.org joined the room. | 12:48:14 |
| 24 Jul 2023 |
|  @tamtaram:chat.heizhaus.org changed their display name from Tamara to Tamara (she/they). | 15:07:50 |
 qbit | error: builder for '/nix/store/j2panv0dqfkn9x6h6mrwqr2wkgcbjwf9-zsh-armv6l-unknown-linux-gnueabihf-5.9.drv' failed with exit code 2;
last 10 log lines:
> 766 | # define memcpy memmove
> | ^~~~~~~
> builtin.c:6221:5: note: in expansion of macro 'memcpy'
> 6221 | memcpy(opts, saveopts, sizeof(opts));
> | ^~~~~~
> make[2]: *** [Makemod:230: builtin.o] Error 1
> make[2]: Leaving directory '/build/zsh-5.9/Src'
> make[1]: *** [Makefile:449: modobjs] Error 2
> make[1]: Leaving directory '/build/zsh-5.9/Src'
> make: *** [Makefile:188: all] Error 1
For full logs, run 'nix log /nix/store/j2panv0dqfkn9x6h6mrwqr2wkgcbjwf9-zsh-armv6l-unknown-linux-gnueabihf-5.9.drv'.
| 17:11:44 |
| qbit | aww | 17:11:45 |
| qbit | anyone running on armv6l? :D | 17:16:57 |
| @trofi:matrix.org | Looks intriguing (the paste seems to lack an actual error reported by gcc, and contains only the clarifying note after the error) | 21:00:23 |
