| 19 Oct 2021 |
 Ryan Burns | here is a similar failure: https://hydra.nixos.org/build/156087864/nixlog/2
argo and jx both segfaulted while dumping shell completions to a file
however, I can only reproduce the jx failure locally, argo builds fine for me | 08:56:07 |
 das_j | any chance you can strace that dump call? | 09:16:24 |
| Ryan Burns | @nix { "action": "setPhase", "phase": "installPhase" }
installing
execve("/nix/store/mdrahngimfvh4m6cwgjdb0zs6y2g7fsr-jx-2.1.155/bin/jx", ["/nix/store/mdrahngimfvh4m6cwgjdb"..., "completion", "bash"], 0x7fffffffd360 /* 90 vars */) = 0
brk(NULL) = 0x5edb000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
+++ killed by SIGSEGV (core dumped) +++
/nix/store/ckw39mx7sx2axnhms10z3i2xgrwspcq1-stdenv-linux/setup: line 87: 19683 Segmentation fault (core dumped) strace $out/bin/jx completion $shell > jx.$shell | 21:57:58 |
| 20 Oct 2021 |
| das_j | That kind of doesn't seem related to the coreutils stuff since coreutils aren't used here… but since you bisected to that exact commit it somehow has to be | 06:50:10 |
 Sandro | Please check with coredumpctl what exactly crashed | 07:07:57 |
| 21 Oct 2021 |
 hexa | sorry for not being able to tend for staging-next as I intended, other things are keeping me busy currently. | 11:00:12 |
| 22 Oct 2021 |
| Ryan Burns | In reply to @sandro:supersandro.de
Please check with coredumpctl what exactly crashed Never used coredumpctl before but coredumpctl debug didnt give any useful information | 01:19:26 |
| Ryan Burns | (gdb) run
Starting program: /nix/store/mb7ymizzmrynrcxfayckc6fcvym5k8hx-jx-2.1.155/bin/jx
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fd00a5 in dl_main () from /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/ld-linux-x86-64.so.2
(gdb) bt
#0 0x00007ffff7fd00a5 in dl_main () from /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/ld-linux-x86-64.so.2
#1 0x00007ffff7fe82fe in _dl_sysdep_start () from /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/ld-linux-x86-64.so.2
#2 0x00007ffff7fce073 in _dl_start () from /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/ld-linux-x86-64.so.2
#3 0x00007ffff7fcd058 in _start () from /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/ld-linux-x86-64.so.2
#4 0x0000000000000001 in ?? ()
#5 0x00007fffffffc926 in ?? ()
#6 0x0000000000000000 in ?? ()
| 01:19:30 |
 trofi | I noticed master can't be merged into staging-next for 2 packages:
- both modified: pkgs/development/python-modules/jupyter-client/default.nix
- both modified: pkgs/development/python-modules/jupyterlab-git/default.nix
I have 2 questions:
- How does it usually gets handled? Would normally an update author propose an valid merge as a pull request?
- Does anyone get alerted for these failures?
| 16:19:18 |
 jonringer | I'll fix them | 16:19:51 |
| jonringer | I think I did recent updates to them | 16:19:56 |
 Alyssa Ross | trofi: usually it's fixed by somebody merging master into staging-next and pushing to staging-next. | 16:20:16 |
| Alyssa Ross | there's alerting here: https://github.com/NixOS/nixpkgs/pull/105153 | 16:20:33 |
| jonringer |
How does it usually gets handled? Would normally an update author propose an valid merge as a pull request?>
ad-hoc'ly by committers
Does anyone get alerted for these failures?
individuals, no. Some one needs to inspect the actions
| 16:21:03 |
| trofi | Aha, nice! | 16:22:27 |
| Alyssa Ross | I just check the PR with the action messages whenever I'm bored. Not sure what other people's workflows are. :P | 16:22:51 |
| jonringer | resolved | 16:33:28 |
| jonringer | ironically, those packages are broken until https://github.com/NixOS/nixpkgs/pull/142432 gets merged anyway | 17:15:26 |
| 23 Oct 2021 |
| hexa | I assume we restarted the failing builds on darwin already? | 11:34:00 |
 Vladimír Čunát | Yes, I think almost all were tried at least twice. It should be visible in build steps. | 16:03:15 |
| hexa | so what are we to do, given that ris succeeded in building git on darwin? | 17:37:57 |
| Vladimír Čunát | Disable that problematic test? | 17:48:45 |
| Vladimír Čunát | (perhaps on darwin only) | 17:49:02 |
| Ryan Burns | sounds good to me | 17:57:58 |
| 24 Oct 2021 |
| hexa | https://github.com/NixOS/nixpkgs/pull/142801 | 23:51:17 |
| hexa | maybe this will get things going again | 23:51:30 |
| 25 Oct 2021 |
| das_j | happysalada: I have no idea why I always get different results but alacritty just builds for me on x86_64-darwin on the staging-next branch: /nix/store/dcamgxvm8z1af0zi4csq7v3myz87g8m0-alacritty-0.9.0 | 09:13:33 |
| das_j | This time we can probably hardly blame it on ZFS | 09:15:13 |
| das_j | Googeling anything about that just brings up people "rewriting" coreutils in Rust… is there another way to reproduce the problem? | 09:16:30 |
| Ryan Burns | alacritty succeeds for me on x86_64-darwin 🤷 | 09:19:02 |
