| 29 Oct 2024 |
 hexa | good enough for me, I'd much rather get the tested enduser builds out | 22:57:18 |
| 30 Oct 2024 |
|  stigo joined the room. | 08:22:25 |
| stigo | hi 🦊 | 08:22:44 |
| hexa | the thunderbird android app is out | 20:23:58 |
| hexa | and it can import settings from desktop by qrcode | 20:24:09 |
| hexa | but we probably need tb 132 for that | 20:24:18 |
| hexa | so it is probably about time to package it up | 20:24:27 |
| hexa | nvm | 20:29:20 |
| 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@epvpn) | 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 |
