[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 <nandre@riseup.net> 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.
Great.
>> 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!
Ludo’.
- [bug#42380] [PATCH] gnu: Add torbrowser-unbundle., Ludovic Courtès, 2020/09/07
- [bug#42380] [PATCH] gnu: Add torbrowser-unbundle., André Batista, 2020/09/08
- [bug#42380] [PATCH] gnu: Add torbrowser-unbundle.,
Ludovic Courtès <=
- [bug#42380] [PATCH] gnu: Add torbrowser-unbundle., Efraim Flashner, 2020/09/09
- [bug#42380] [PATCH 0/9] gnu: Add torbrowser-unbundle., André Batista, 2020/09/15
- [bug#42380] [PATCH 1/9] gnu: Add go-torproject-org-ptlib, André Batista, 2020/09/15
- [bug#42380] [PATCH 2/9] gnu: Add go-github-com-agl-ed25519, André Batista, 2020/09/15
- [bug#42380] [PATCH 2v2/9] gnu: Add go-github-com-agl-ed25519, André Batista, 2020/09/15
- [bug#42380] [PATCH 0/9] gnu: Add go-github-com-dchest-siphash., André Batista, 2020/09/15
- [bug#42380] [PATCH 3/9] gnu: Add go-github-com-dchest-siphash, André Batista, 2020/09/15
- [bug#42380] [PATCH 4/9] gnu: Add go-github-com-dchest-uniuri, André Batista, 2020/09/15
- [bug#42380] [PATCH 5/9] gnu: Add go-github-com-dsnet-compress, André Batista, 2020/09/15
- [bug#42380] [PATCH 6/9] gnu: Add go-schwanenlied-me-yawning-bsaes, André Batista, 2020/09/15