* master: (81 commits)
Add NixOS 17.09 AMIs
gradle: 4.2 -> 4.2.1
maintainers.nix: use my GitHub handle as maintainer name
fcitx-engines.rime: init at 0.3.2
brise: init at 2017-09-16
librime: init at 1.2.9
marisa: init at 0.2.4
opencc: build shared library and programs
josm: 12712 -> 12914
exa: 0.7.0 -> 0.8.0
krb5: add deprecation date for old configuration
rustRegistry: 2017-09-10 -> 2017-10-03
go-ethereum: Fix libusb segmentation faults on Darwin
tor-browser-bundle-bin: 7.0.5 -> 7.0.6
libsodium: 1.0.13 -> 1.0.15
tor-browser-bundle: geoip support
tor-browser-bundle: support transports obfs2,obfs3
tor-browser-bundle: bump https-everywhere to 2017.9.12
tint2: limit platforms to Linux since macOS is not supported and fails the tests
eclipse-plugin-vrapper: init at 0.72.0
...
Storing the build configuration caused Firefox to retain a dependency
on gcc, glibc.dev and icu4c.dev.
This reduces the size of the firefox closure from 587 to 415 MiB.
The original browser bundle expects to run from a bundled directory,
typically under user's home. This version creates a firefox distribution
with preloaded extensions and settings that functions more like an
ordinary firefox installation.
The approach used here could be generalized to allow specification of
custom firefox distributions. Eventually, the code will be factored so
that the tbb is just an instance of that more general construct (firefox
base + extensions + prefs).
Currently, we use the latest upstream versions of extensions and so on.
Eventually we want to track the upstream bundle more closely and ideally
use the exact same inputs (firefox source, extension sources).
To avoid mixing up profile data, all runtime state is stored under
$XDG_DATA_HOME/tor-browser.
Major TODO items
- Pluggable transports
- Upstream TBB version parity
- Avoid fetchgit
- Build NoScript from source (no upstream source repo, however, must rely
on third-parties)
- Improved notation for packaging extensions
- Feature parity with the binary bundle (apulse and runtime purity, in
particular)
Multiprocess tabs always crash, as first reported by the issue mentioned
below. It is now consistently reproducible both on NixOS and non-NixOS
for me, so I've decided to add a toggle to conveniently disable
multiprocess support as a work-around.
Closes https://github.com/NixOS/nixpkgs/issues/27759 but does
not really fix the underlying problem ...
The binary embeds a listing of build-time dependencies derived from
config.cache. Fix by nuking references in the derived header prior to
building.
Reduces size from ~102MB to ~51MB.
This release in a RC for gnupg-2.2. The main difference as far as
nixpkgs is concerned is that the binary `gpg2` is now called `gpg` and
`gpgv2` is called `gpgv`.
This update fixed all explicit use of `gpg2` and `gpgv2` across nixpkgs,
but there might be some packaged software that internally use `gpg2`
not handeled by this commit.
See http://lists.gnu.org/archive/html/info-gnu/2017-08/msg00001.html
for full release information
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
When trying to open or save a file using the file chooser GUI, Vivaldi
would crash with the message
GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser' is
not installed
This commit adds the GTK directory to XDG_DATA_DIRS which fixes the
crash.
The `extraPrefs` parameter is injected verbatim into the mozilla.cfg
file.
Note that the syntax is a superset of the usual prefs.js syntax. The
following procedures are of particular interest:
pref() to set a preference as if it had been toggled in about:config
defaultPref() to set the *default* value of a preference
lockPref() to set a preference & prevent further modification
clearPref() to reset a preference to its default state
Example:
```nix
tor-browser-bundle-bin.override {
extraPrefs = ''
// Increase default security level
pref("extensions.torbutton.security_slider", 2);
'';
}
```
The following errors occur when you start Chromium prior to this commit:
[2534:2534:0625/202928.673160:ERROR:gl_implementation.cc(246)] Failed to
load .../libexec/chromium/swiftshader/libGLESv2.so:
../libexec/chromium/swiftshader/libGLESv2.so: cannot open shared object
file: No such file or directory
[2534:2534:0625/202928.674434:ERROR:gpu_child_thread.cc(174)] Exiting
GPU process due to errors during initialization
While in theory we do not strictly need libGLESv2.so, in practice this
means that the GPU process isn't starting up at all which in turn leads
to crawling rendering performance on some sites.
So let's install all shared libraries in swiftshader.
I've tested this with the chromium.stable NixOS VM test and also locally
on my machine and the errors as well as the performance issues are gone.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Due to licensing costs, Vivaldi bundles a version of ffmpeg compiled
without support for the common H.264 codec. However, it is possible to
supply a custom libffmpeg.so with additional codecs. This derivation
uses the Chromium source to compile a compatible libffmpeg.so.
This approach is recommended by a Vivaldi developer, see
https://gist.github.com/ruario/bec42d156d30affef655
- Update to version 1.10.867.38-1
- Drop i386 arch. Vivaldi has suspended support for Linux 32-bit for
Vivaldi 1.10. Unfortunately, this is due to Chromium suspending support
for it and maintaining it themselves would take too much resources.
See https://forum.vivaldi.net/post/142489.
- Update dependency on gtk2 to gtk3.
- Move dependency patchelf from buildInputs to nativeBuildInputs.
This should allow us to easily add system-wide Chromium extensions via a
NixOS configuration similar to this:
{ pkgs, ... }: {
environment.pathsToLink = [ "/share/chromium/extensions" ];
environment.systemPackages = [ pkgs.my-shiny-extension ];
}
For more details about what Chromium expects within that directory, see:
https://developer.chrome.com/extensions/external_extensions
I've introduced this because of a personal desire to gain more control
about which extensions are installed and what they are able to do. All
of the extensions I use are free software, but despite that it's useful
to either easily patch them and also prevent unwanted automatic updates.
Tested this using the NixOS "chromium.stable" test on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @offlinehacker because of #21050
adisbladis
taku0
Vladimír Čunát
Orivej Desh
Joachim Fasting
Utku Demir
Robin Gloster
Mateusz Kowalczyk
Peter Hoeg
Franz Pletz
Herwig Hochleitner
John Ericson
Eelco Dolstra
Lukas Werling
Maximilian König
Jan Malakhovski
Kirill Boltaev
John Ericson
Joachim F
SLNOS
Jaka Hudoklin
Jörg Thalheim
Jan Tojnar
koenigmaximilian
Frederik Rietdijk
Lancelot SIX
Tim Steinbach
mimadrid
Silvan Mosberger
Tim Steinbach
Nicolas B. Pierron
Graham Christensen
239
Victor Calvert
Linus Heckemann
David McFarland
Nicolas Truessel
aszlig
Rok Garbas
Thomas Tuegel
romildo
Domen Kožar
Charles Strahan
Volth