| 27 Oct 2021 |
 moritz.hedtke | In reply to @vcunat:matrix.org
I can't see anything wrong really. Perhaps just not too ergonomic in my opinion (in Element UI at least). Now it's this small window which I think it's nicer. Maybe it depends on the size of the message or so | 10:25:58 |
| moritz.hedtke | Regarding the first error are you sure it's when the tests are running? I will check later but I though it was still while building but I didn't really pay attention that closely | 10:26:56 |
 Vladimír Čunát | In reply to @moritz.hedtke:matrix.org
Regarding the first error are you sure it's when the tests are running? I will check later but I though it was still while building but I didn't really pay attention that closely I'm not sure. I didn't save the log and it got rewritten by the one with tmpfs usage :-/ (there it's when "Generating browser application bundles") | 10:30:52 |
| moritz.hedtke | Yeah ok, that sounds more likely to be while building. I thought that both errors are more or less at the same place and the thing I said above happens (so timing decides whether already crashed or closed pipe) | 10:32:44 |
| Vladimír Čunát | Now with ext4 I got the same error as with tmpfs. | 10:38:02 |
| Vladimír Čunát | * Now with ext4 I got this same error as with tmpfs. | 10:38:12 |
| Vladimír Čunát | * Now with ext4 I got this same error as with tmpfs, unless it mattered that I didn't restart nix-daemon after unmounting /tmp. | 10:38:53 |
| Vladimír Čunát | * Now with ext4 I got this same error as with tmpfs, unless it mattered that I forgot to restart nix-daemon after unmounting /tmp. | 10:39:10 |
| moritz.hedtke | I would find it plausible that the error is not consistent as I rarely got EPIPE on my laptop too. But don't know whether you need to restart nix-daemon. Also could make sense that one error is more likely in tmpfs and the other on extra because tmpfs is probably a bit faster | 10:41:34 |
| moritz.hedtke | * I would find it plausible that the error is not consistent as I rarely got EPIPE on my laptop too. But don't know whether you need to restart nix-daemon. Also could make sense that one error is more likely in tmpfs and the other on ext4 because tmpfs is probably a bit faster | 10:41:59 |
| Vladimír Čunát | Probably. EPIPE again after restarting the daemon. | 10:52:03 |
 das_j | I got assigned a bug number and added it both into the commit message and the PR message. Once verified that this fixes Darwin it's probably good t go | 12:04:42 |
| Vladimír Čunát | The thing is that Hydra can't cancel whole evals, so it might be good to avoid the rebuild on *-darwin for now and just apply the patch without reverting the other commit. | 12:25:02 |
| Vladimír Čunát | (i.e. move that revert to the staging branch) | 12:25:58 |
| das_j | can do | 12:26:10 |
| moritz.hedtke | Goddammit Vladimír Čunát or somebody else can you try https://gist.githubusercontent.com/mohe2015/23407b8f83ae8cca0948629789d08518/raw/264e85a4a879ae4195c32756f5473373beab844a/goddammit.diff on top of staging-next please? Probably the esbuild version is just broken. | 13:44:52 |
| Vladimír Čunát | In reply to @moritz.hedtke:matrix.org
Goddammit Vladimír Čunát or somebody else can you try https://gist.githubusercontent.com/mohe2015/23407b8f83ae8cca0948629789d08518/raw/264e85a4a879ae4195c32756f5473373beab844a/goddammit.diff on top of staging-next please? Probably the esbuild version is just broken. It builds for me. (I didn't really inspect what it does and the implications.) | 14:33:06 |
| moritz.hedtke | Thanks for testing. It just updates to the latest version of peertube (with the minimal effort). Also we missed a place where we used esbuild instead of esbuild_locked (the yarn.lock pinned version) but I tested and that didn't matter. | 14:34:14 |
| moritz.hedtke | As I read a bugreport about that specific esbuild version (with an unrelated bug) I just assume its either golang that breaks the build or something else. But I'm 95% sure its esbuild even though other tools got updated too. Maybe I will investigate more later but now its way more managable. Also das_j should probably update the coreutils bug report if you agree with my assessment | 14:35:38 |
| Vladimír Čunát | I gather that some "versions" of peertube build are affected by the coreutils bug and some aren't affected? | 14:37:10 |
| Vladimír Čunát | * I gather that some "versions" of peertube build system are affected by the coreutils bug and some aren't affected? | 14:37:19 |
| moritz.hedtke | Maybe its not a coreutils bug but just a different -frandom-seed and we could change the derivation hash of literally any dependent derivation of golang or peertube | 14:37:43 |
| moritz.hedtke | I'm pretty sure I got the root cause: https://github.com/mohe2015/nixpkgs/tree/esbuild-bug look at the last commit - I think its a bug in the golang compiler because for me the previous commit .#esbuild/bin/esbuild segfaults but for the last one it doesn't. Please verify so we can be confident it has nothing to do with coreutils. | 15:23:54 |
| moritz.hedtke | Looking at the diff https://gist.github.com/mohe2015/2a0aeef7d1e7217aec2b25cd8db40775 I'm actually not sure any more and it could possibly be a copy-failure. Do you know where golang gets its random-seed similar data from so I could override it. Or is it dependent on the derivation hash which you can't change. Because I would like to build it on top of master with the same random-seed similar data. | 15:35:59 |
| moritz.hedtke | Checked with xxd and diff and lots of data is overwritten with zeros | 15:42:46 |
| moritz.hedtke | Are that symptoms of coreutils cp bug? | 15:42:57 |
| Vladimír Čunát | That sounds plausible. Holes are long consecutive zeroed ranges. | 15:44:34 |
| Vladimír Čunát | And the identified commit did change something around hole-seeking. | 15:45:09 |
| moritz.hedtke | Ok, so now I don't have to find the non-existent bug in golang any more and we are pretty confident that the coreutils bug is actually this bug. Interesting that changing the derivation fixes it so the bug is probably really extremely rare but if you're building a lot you are bound to experience it. | 15:51:09 |
| das_j | We should move as much of the discussion as possible to https://github.com/NixOS/nixpkgs/issues/143208 since that is more open (and at least one coreutils maintainer is currently following the staging-next PR) and it doesn't clutter the channels that could also be used for other issues | 18:55:24 |
