[bug#67512] [PATCH v4 3/4] gnu: Add wasm packages.

[Ian Eure <ian@retrospec.tv>]

Hello,

Just pinging on this.  v5 of the patch reduces scope, as we 
discussed; it’s now just a nss update + addition of LibreWolf.

Thanks,

  — Ian

Clément Lassieur <clement@lassieur.org> writes:

> On Wed, Feb 21 2024, Ian Eure wrote:
>
>> Clément Lassieur <clement@lassieur.org> writes:
>>
>>> On Wed, Feb 21 2024, Liliana Marie Prikler wrote:
>>>> Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure:
>>>>> Clément Lassieur <clement@lassieur.org> writes:
>>>>>  > > Are you saying you want a process like:
>>>>> > >  > > 1a. Get wasm toolchain stuff merged.
>>>>> > > 1b. Get Librewolf merged without WASM sandboxing.
>>>>> > > 2. Update icecat, torbrowser, mullvad, and librewolf to 
>>>>> > > > > use  > >
>>>>> WASM sandboxing.
>>>>> >  > Excatly.  1b can be done after 1a, or before 1a.
>>>>> > Is there a technical reason why landing WASM sandboxing 
>>>>> > support for all
>>>>> browsers in the same patch is desirable?  I can intuit none, 
>>>>> and as I’m
>>>>> disinclined to either roll back portions of my existing 
>>>>> patchset, or work
>>>>> on other browsers, the proposal is disagreeable.
>>>> I think this ordering is w.r.t. *patch sets*, not patches.  I 
>>>> wouldn't
>>>> suggest dropping four packages into one patch.
>>>
>>> Indeed I've never said it should be done in one patch.  I said 
>>> one-shot
>>> as in ‘symmetrical’: the work required to add Wasm to our 
>>> browsers
>>> should be more or less the same for all browsers, and code 
>>> duplication
>>> should be avoided.
>>>
>>
>> Forgive me for my imprecision, and thank you for the
>> explanation. Unfortunately, the distinction makes little 
>> difference to me, as
>> it still would require me to do work I’m unwilling to do.  My 
>> unwillingness
>> has less to do with the amount of work than its scope: My goal 
>> is to get
>> LibreWolf into Guix, and I simply have no desire or motivation 
>> to work on
>> other browsers.
>
> Firefox based browsers are closely related.  Sounds impossible 
> to me to
> really do good work on one of them without touching the other 
> ones.
>
>> I think the best course of action is to reduce scope by 
>> removing the WASM
>> component of this patch series entirely.  I’d send a new patch 
>> series without
>> the WASM toolchain packages, and with WASM sandboxing disabled 
>> in the
>> LibreWolf package.  The official LibreWolf binaries don’t 
>> appear to have this
>> enabled, so no hardening would be sacrified vs. LibreWolf 
>> installed any other
>> way.  And since I’m not the original author of the WASM 
>> packages, and not
>> well-positioned to address problems with them, omitting them 
>> seems likely to
>> circumvent difficulties in the review process and support of 
>> those.
>>
>> What do you think?
>
> Sounds good.  And we can add WASM later.