| 27 Oct 2021 |
 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 |
| 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 |
