| 30 Oct 2024 |
hexa | settings > export for mobile | 20:29:23 |
hexa | it is there on 128.4.0 | 20:29:25 |
hexa | https://github.com/NixOS/nixpkgs/pull/352493 | 23:27:33 |
hexa | apparently this is happening | 23:27:37 |
| 31 Oct 2024 |
vcunat | I wonder if we should do it for 24.11 already. | 06:34:51 |
vcunat | I see no reason not to, though I haven't even tried 129+ yet. | 06:35:23 |
@aloisw:kde.org | Is this not relevant any more? https://github.com/NixOS/nixpkgs/issues/346493#issuecomment-2404566598 | 08:53:01 |
vcunat | Oh, I assumed that would be gone by now, but they're still showing that warning. | 09:01:07 |
@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 (4094@39c3) | 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 |
emily | but β Nixpkgs compilers are weird. it's also possible we're messing it up somehow and it's our fault | 13:50:02 |
nbp | have the changes stick in LLVM, or did they got backed out of LLVM? | 13:56:14 |
hexa | I can see the changes are still applied in 19.1.3 | 14:07:51 |
emily | I didn't see any indication of revert | 14:12:07 |
emily | the Mozilla bug does not directly link the LLVM change, but the circumstances, error message, and workaround are an exact match | 14:12:23 |
emily | and it seems like it should directly fix the build error I saw | 14:12:33 |
emily | so I'm wondering if upstream LLVM fix is broken and Mozilla didn't fully test it (understandable since they haven't yet upgraded their actual builders to LLVM 19 yet AFAIK), or if somehow we are breaking things with our weirdness | 14:12:57 |