| 28 Oct 2021 |
 Vladimír Čunát | In reply to @janne.hess:helsinki-systems.de
Vladimír Čunát: is it possible that your ext4 failures are related to your nix substituting intermediate results from the cache? I think almost all inputs were substituted on those attempts. | 08:44:11 |
 das_j | In reply to @vcunat:matrix.org
I think almost all inputs were substituted on those attempts. So is it possible that you just substituted the bad inputs from hydra? That would also explain why changing anything would force you to build locally and not show the issue | 08:46:52 |
| Vladimír Čunát | In reply to @janne.hess:helsinki-systems.de
So is it possible that you just substituted the bad inputs from hydra? That would also explain why changing anything would force you to build locally and not show the issue In both succeeding and failing cases I only retried the final build multiple times, not any dependencies. | 08:48:52 |
| das_j | In reply to @vcunat:matrix.org
In both succeeding and failing cases I only retried the final build multiple times, not any dependencies. so it's likely you just got broken tooling that was built on ZFS and there is no issue with ext4? | 08:52:11 |
| Vladimír Čunát | In reply to @janne.hess:helsinki-systems.de
so it's likely you just got broken tooling that was built on ZFS and there is no issue with ext4? It's ceratinly an option, assuming we have ZFS among Hydra workers. | 08:52:44 |
| Vladimír Čunát | In reply to @janne.hess:helsinki-systems.de
so it's likely you just got broken tooling that was built on ZFS and there is no issue with ext4? * It's ceratinly a possibility, assuming we have ZFS among Hydra workers. | 08:52:53 |
 moritz.hedtke | In reply to @moritz.hedtke:matrix.org
The binary cache now has the broken binary but for some reason I now fail to reproduce locally. (With nix develop .#esbuild to get dependencies and then nix build --option substitute false .#esbuild). Weird. Considering this I believe the zfs workers from hydra to be the culprit. If should be reproducible with these steps assuming cp fails in the esbuild derivation and substituting the go compiler should not matter. I will update them that I strongly believe this to be a misattribution if the issue. Also the bug tracker should be updated if you agree. | 10:24:10 |
| moritz.hedtke | * Considering this I also believe the zfs workers from hydra to be the culprit. If should be reproducible with these steps assuming cp fails in the esbuild derivation and substituting the go compiler should not matter. I will update them that I strongly believe this to be a misattribution if the issue. Also the bug tracker should be updated if you agree. | 10:24:23 |
| moritz.hedtke | The issue mostly was that we both probably paid attention that peertube got built but that was not the broken derivation. Identifying the real broken derivation took a while | 10:25:22 |
| moritz.hedtke | Probably not worth the effort but is it possible to check in which builder it got built and check whether it uses zfs? The first step may even be possible on the web interface I believe | 10:38:39 |
| Vladimír Čunát | In reply to @moritz.hedtke:matrix.org
Probably not worth the effort but is it possible to check in which builder it got built and check whether it uses zfs? The first step may even be possible on the web interface I believe Here, I think: https://hydra.nixos.org/build/156099030#tabs-buildsteps | 10:47:50 |
| moritz.hedtke | I think we need the one that's defined in a let called "esbuild_locked" with 0.12.7 or so. | 10:52:16 |
| moritz.hedtke | https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/peertube/default.nix#L46 | 10:54:46 |
| moritz.hedtke | Derivation is also called esbuild but 0.12.17 | 10:55:03 |
| Vladimír Čunát | I confirm that this esbuild_locked was substituted in my case, as it has no log locally. | 11:00:24 |
| Vladimír Čunát | So rebuilding that single step locally indeed does fix the peertube build. | 11:13:54 |
| das_j | So we can solve the entire issue by replacing the filesystem of the builders?: O | 11:14:45 |
| das_j | * So we can solve the entire issue by replacing the filesystem of the builders? :O | 11:14:46 |
 trofi | staging-next fails to merge into staging for trivial news add/add conflict. example trivial merge: https://dpaste.com/8LKYY7QYP.txt
I tried to submit a pill-request with merge, but github claims it wants to render hundreds of new commits. | 15:59:28 |
 Alyssa Ross | well, a merge does add hundreds of new commits! | 16:00:47 |
| Alyssa Ross | but for that reason they're basically impossible to review, so it's probably easier for a committer to just do it than to review a PR for it | 16:01:12 |
| trofi | Sounds good. Asked in https://github.com/NixOS/nixpkgs/pull/141918#issuecomment-953991366 | 16:08:48 |
| Alyssa Ross | I've fixed it. | 16:09:50 |
 Sandro | It would be really grateful if there would be a good way to prevent this things other than keeping track which packages changed on which branch already | 17:30:35 |
 hexa | you mean merge conflicts? | 17:45:52 |
| hexa | both modified: pkgs/development/libraries/kde-frameworks/fetch.sh
deleted by them: pkgs/development/libraries/kde-frameworks/kio/0002-Debug-module-loader.patch
both modified: pkgs/development/libraries/kde-frameworks/srcs.nix
| 17:47:02 |
| hexa | DO NOT EDIT! This file is generated automatically.
| 17:47:16 |
| hexa | lovely. | 17:47:19 |
 sterni | hexa: just regenerate? | 17:47:31 |
| hexa | yeah, something like this | 17:47:40 |
