[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#42380] [PATCH] gnu: Add torbrowser-unbundle.

From: Ludovic Courtès
Subject: [bug#42380] [PATCH] gnu: Add torbrowser-unbundle.
Date: Wed, 09 Sep 2020 09:20:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi André,

André Batista <> skribis:

> Just a small token of my appreciation for your years of work on
> guix. I'm glad to be able to give something back to this community.

Thank you.

> I've been using this package for the last month or so and did not
> hit any bugs so, though I'm not a heavy web user, I think it's fair
> to say the result is functional.
> On the down side, the https-everywhere extension is broken as is
> since it's missing lib-wasm. I've built but did not send here a
> version which just copies lib-wasm to its proper place before
> building the extension and this version works without further
> issues.
> The reason I did not send it to this list is that lib-wasm source
> provides a precompiled prepackaged file[1] which is then used on
> https-everywhere build script and it's source code is not actualy
> compiled[2]. As I understand it, the Tor Project just relies on
> this precompiled binary on its build procedure and the same seems
> to be true for IceCat[3][4].

Oh, glad that you were able to identify that issue, which presumably had
been overlooked so far.

> In order to have everything compiled from source, I've had to
> define a lot of rust libs which were required for building
> wasm-pack and then to have a rustc with wasm32-unknown-unknown
> target enabled and compatible with wasm-pack (apparently newer
> versions changed compiler strings and wasm-pack errors out when
> trying to parse). For over two weeks I've been trying without
> success and always thinking that the next build would succeed.
> Long story short, maybe there's just one more issue pending when
> compiling lib-wasm. When wasm-pack is invoked, everything
> compiles but I'm getting the following error:
> note: lld: error: 
> /gnu/store/kwdsf42z7ib6fr5vggqi9nc4jpi1znxy-rust-1.38.0/lib/rustlib/wasm32-unknown-unknown/lib/libstd-373ca16e620a2f9a.rlib:
>  archive has no index; run ranlib to add one
> for a few rust libs. Without lld, it complains about a missing
> rust-lld binary. Also, this appears to be the rust standard
> nowadays[5].

Ah.  I’m Cc’ing Efraim, who’s been very much into Rust packaging for
some time; does that ring a bell, Efraim?

> If I'm not terribly wrong, this issue[6] seems to suggest an
> approach for emscripten which could solve this issue without
> removing the 'strip' phase which was the work around suggested
> by some on the same thread.
> Another issue that is pending is that libwasm depends on rust
> multi-default-trait-impl crate. This crate defines lgpl2.1+ on
> its Cargo.toml file, but the sources does not contain neither a
> copy of the license. So I'm unsure if this is enough to make it
> free software. So I'm planning on sending some mails to both the
> maintainer and FSF to see if this needs improvement.


>> For the final submission, we’d need one patch per new package, as is
>> customary.  That will have the advantage of allowing review to proceed
>> one bit at a time.  :-)
> For sure. I'll give it a few more tries and cleanup the mess
> here before sending this patch series. If I don't succeed, I'm
> planning on sending it anyway so at least the libs can be
> added and maybe someone can spot what I'm missing. But maybe
> it's wise to hold Tor Browser itself since there has been an
> announcement of some large percentage of exit relays messing
> with Tor traffic[7].

I don’t think Guix users will radically increase traffic over Tor, so I
think we can keep going.  :-)

>> Regarding Tor Browser itself, can you think of ways to factorize code
>> with IceCat?
> Other than sharing the https-everywhere definition, I was
> thinking maybe we could take a diff of Tor Browser and Firefox
> and avoid downloading firefox source twice when building both
> browsers. But I need to take a more careful look. I'll give
> this question some thought.

OK.  I was expecting at least things like some of the build phases and
most/all of the inputs to be the same, but I haven’t checked.

Thanks again for all the work!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]