Hello, seg 07 set 2020 às 16:13:17 (1599505997), ludo@gnu.org enviou: > Hello, > > Woow, thanks for working on this! The end result is functional, right? > Any important missing items? 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. 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]. 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]. 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]. > 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. Cheers, 1. https://docs.rs/crate/https-everywhere-lib-wasm/0.1.2/source/pkg/https_everywhere_lib_wasm_bg.wasm 2. https://github.com/EFForg/https-everywhere/blob/master/make.sh#L113 3. https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat?h=68#n565 4. https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/extensions/https-everywhere@eff.org/wasm/https_everywhere_lib_wasm_bg.wasm?h=68 5. https://github.com/rust-lang/rust/pull/48125 6. https://github.com/emscripten-core/emscripten/issues/9705 7. https://blog.torproject.org/bad-exit-relays-may-june-2020