| 31 Oct 2024 |
 @aloisw:kde.org | It's a bit funny that they warn for release and daily, but not beta. | 09:22:02 |
|  emily joined the room. | 22:40:07 |
| 1 Nov 2024 |
| emily | long shot, but if anyone knows anything about the WASI stuff in Firefox… https://github.com/NixOS/nixpkgs/issues/352724 | 01:43:26 |
 hexa | it was painful to set up | 01:44:57 |
| hexa | that's what I remember | 01:45:00 |
| hexa | it was the reason we created a firefox maintainers room in the first place | 01:45:22 |
| emily | I'm pretty sure we could solve it by just applying the Firefox workaround patch they did originally, but that would leave the mystery of why it was reverted as having been fixed upstream, and why the commit that clearly fixes it doesn't | 01:54:27 |
| 8 Nov 2024 |
|  jschvz joined the room. | 02:57:00 |
|  toastal-matrix-sucks changed their display name from toastal to toastal-matrix-sucks. | 08:57:15 |
| 10 Nov 2024 |
|  @sbc64:matrix.org left the room. | 20:02:11 |
| 12 Nov 2024 |
 jopejoe1 | Planing to rebase and merge https://github.com/NixOS/nixpkgs/pull/289404 tomorrow | 07:20:29 |
 nbp | emily: I can forward questions if needed.
The whole concept is kind of fun. Some components are compiled as WebAssembly before being compiled to assembly and embedded in the binary. There is no WebAssembly interpreted/jitted at the end, but all the sand-boxing of the execution remains around the embedded component. This is a security feature to isolate components of Firefox.
| 10:51:40 |
| nbp | unless you are referring to WASI as a target, in which case I am not aware, but I can still forward questions. | 10:53:53 |
| emily | In reply to @nbp:mozilla.org
emily: I can forward questions if needed.
The whole concept is kind of fun. Some components are compiled as WebAssembly before being compiled to assembly and embedded in the binary. There is no WebAssembly interpreted/jitted at the end, but all the sand-boxing of the execution remains around the embedded component. This is a security feature to isolate components of Firefox.
so here's my understanding of the situation:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1905251 was opened for an LLVM 19-related regression in the WASI build
- https://hg.mozilla.org/integration/autoland/rev/23a9f6555c7c was merged as a workaround
- it was backed out in https://hg.mozilla.org/mozilla-central/rev/b8a794387245 because it was fixed upstream
- from my digging, it seems pretty clear that the upstream fix was https://github.com/llvm/llvm-project/pull/97451
- but we seem to get the same error even in the latest LLVM 19 released months after that fix
- re-applying the previous Firefox workaround fixes it
| 13:49:39 |
| emily | which makes me wonder "are we absolutely sure it was tested that the fix actually fixed it?" | 13:49:51 |
