[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#42380] [PATCH] gnu: Add torbrowser-unbundle.
From: |
Efraim Flashner |
Subject: |
[bug#42380] [PATCH] gnu: Add torbrowser-unbundle. |
Date: |
Wed, 9 Sep 2020 13:59:44 +0300 |
On Wed, Sep 09, 2020 at 09:20:08AM +0200, Ludovic Courtès wrote:
> 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?
>
It's not something that I've come across before. My first guess would be
to check the linking flags against the ones icecat/firefox uses and see
if anything changed. Or if it needs a different version of rust.
> > 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’.
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
- [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 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
- [bug#42380] [PATCH 7/9] gnu: Add go-gitlab-com-yawning-utls, André Batista, 2020/09/15