| 27 Oct 2021 |
 Vladimír Čunát | * I tried again with the same error, so the messages appear stable and FS changes when an error happens. (well, on a quick guess) | 08:30:55 |
 das_j | I have created a potential workaround: https://github.com/NixOS/nixpkgs/pull/143097 | 09:08:58 |
|  lourkeur (Nix OwO) joined the room. | 09:30:25 |
| das_j | 
Download image.png | 09:31:26 |
| das_j | Final version | 09:31:33 |
 moritz.hedtke | In reply to @vcunat:matrix.org
I haven't poked into details of the error. It looks like it attempts some tests after build and those all end with
Error: The service is no longer running
I think the error is from esbuild which is a JavaScript module bundler. | 10:21:59 |
| moritz.hedtke | In reply to @vcunat:matrix.org
It still fails, but the error is different; I think it happens a bit earlier than with ext4 (before any tests start)
Generating browser application bundles (phase: building)...node:events:368
throw er; // Unhandled 'error' event
^
Error: write EPIPE
I sometimes got that error locally in my machine and sometimes the other. I could not identify what influences it but I assume it's just the timing whether esbuild is no longer running or it just crashed or so and an EPIPE comes (which means written to closed pipe?) | 10:23:41 |
| moritz.hedtke | What's wrong with the reply feature?!? | 10:24:06 |
| Vladimír Čunát | In reply to @moritz.hedtke:matrix.org
What's wrong with the reply feature?!? I can't see anything wrong really. Perhaps just not too ergonomic in my opinion (in Element UI at least). | 10:25:20 |
| 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 |
