There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
https://lists.torproject.org/pipermail/tor-announce/2019-January/000171.html
FWIW, in the ChangeLog (in the source, sorry) it mentions:
As a reminder, the Tor 0.3.4 series will be supported until 10 June
2019. Some time between now and then, users should switch to the Tor
0.3.5 series, which will receive long-term support until at least 1
Feb 2022.
So we should consider moving to 0.3.5 "soon" :).
Quoth the release notes:
> It includes several bugfixes, including a bugfix for a crash issue that
had affected relays under memory pressure. It also adds a new directory
authority, Bastet.
This patch restructures the expression and wrapper to minimize Nix store
references captured by the user's state directory.
The previous version would write lots of references to the Nix store into
the user's state directory, resulting in synchronization issues between
the Store and the local state directory. At best, this would cause TBB to
stop working when the version used to instantiate the local state was
garbage collected; at worst, a user would continue to use the old version
even after an upgrade.
To solve the issue, hard-code as much as possible at the Store side and
minimize the amount of stuff being copied into the local state dir.
Currently, only a few files generated at firefox startup and fontconfig
cache files end up capturing store paths; these files are simply removed
upon every startup. Otherwise, no capture should occur and the user
should always be using the TBB associated with the tor-browser wrapper
script.
To check for stale Store paths, do
`grep -Ero '/nix/store/[^/]+' ~/.local/share/tor-browser`
This command should *never* return any other store path than the one
associated with the current tor-browser wrapper script, even after an
update (assuming you've run tor-browser at least once after updating).
Deviations from this general rule are considered bugs from now on.
Note that no attempt has been made to support pluggable transports; they
are still broken with this patch (to be fixed in a follow-up patch).
User visible changes:
- Wrapper retains only environment variables required for TBB to work
- pulseaudioSupport can be toggled independently of mediaSupport (the
latter weakly implies the former).
- Store local state under $TBB_HOME. Defaults to $XDG_DATA_HOME/tor-browser
- Stop obnoxious first-run stuff (NoScript redirect, in particular)
- Set desktop item GenericName to Web Browser
Some minor enhancements:
- Disable Hydra builds
- Specify system -> source mapping to make it easier to
extend supported platforms.
Saves about 5.2 MiB.
To use geoip, add something like
```
GeoIPFile ${tor.geoip}/share/tor/geoip
GeoIPv6File ${tor.geoip}/share/tor/geoip6
```
to torrc
The 0.2.9 series is now a long-term support release, which will
receive backported security fixes until at least 2020.
tor should now build against libressl, as in
```nix
tor.override { openssl = libressl; }
```
Also re-enable the test-suite; works fine on my end.
Fixes https://github.com/NixOS/nixpkgs/issues/20840
Some notes for future reference:
- Firefox only supports legacy gstreamer (0.10)
- gmp and ffmpeg are appearantly used by gst-ffmpeg so must be in the
library search path
- Setting GST_DEBUG="*:3" or so was useful in figuring out what to add
- Remove redundant preConfigure
torsocks installs into $libdir/torsocks, so setting libdir=$out/lib
doesn't really help. To put the shared objects into $out/lib we'd have
to manually move them into $out and patch various files (the script
itself expects $libdir/torsocks).
- Use nativeBuildInputs