This makes it possible to use chromium headless with WebGL
(e.g. for webdriver tests) without having to rebuild from source.
The upstram default is to enable, thus simply removing our disabling switch.
Also fixes#41918.
I don't really have the hardware resources nor time to do this properly,
but I'll try to keep a watch on Chromium (updates, PRs, and issues)
until we've found a new team [0].
Testing will be performed on a best effort basis (no guarantees :o).
I've also briefly documented the current maintainer
roles/responsibilities and added `meta.longDescription`.
[0]: https://github.com/NixOS/nixpkgs/issues/78450
This change allows widevine to work in chromium (it was previously
broken due to a segfault). Newer versions of chromium do not use the
libwidevinecdmadapter.so. Instead, libwidevinecdm.so should be installed
in the chromium libExec directory.
Upstream provides a much more featureful desktop entry file. If we use
that we take advantage of all of those features and don't have to maintain it
ourselves.
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>
requiredSystemFeatures is not a meta attribute but a derivation
attribute. So "big-parallel" was being ignored on e.g. chromium,
causing it to be built (and timing out) on slow machines.
http://hydra.nixos.org/build/45819778#tabs-buildsteps
Before version 54, the WideVine CDM plugin was built unconditionally and
it seems since version 54 this now is dependent upon a GYP/GN flag on
whether to include the CDM shared library or not.
Also, we now use a patch from Gentoo which should hopefully get the CDM
plugin to work properly, at least according to their bugtracker:
https://bugs.gentoo.org/show_bug.cgi?id=547630
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not the job of Nixpkgs to distribute beta versions of upstream
packages. More importantly, building these delays channel updates by
several hours, which is bad for our security fix turnaround time.
This reverts commit 5979946c41.
I have tested this by building against the stable version of Chromium
and it seems to compile just fine, so it doesn't seem to be needed
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Working on Chromium really drives me nuts due to its build time, also I
really don't have quite a lot of time these days to properly maintain it
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Built and run Beta and Stable locally. Dev is surrently superseded by Stable so
it doesn't matter much.
- Dev: 47.0.2508.0 -> 48.0.2564.22
- Beta: 46.0.2490.64 -> 48.0.2564.23
- Stable: 45.0.2454.101 -> 47.0.2526.73
Changed the SSL dependencies to the supported configuration on Linux (according
to Torne @Freenode/#chromium-support).
- NSS is a dependency since it is used to access the ceritiface store.
- Dropped system OpenSSL support, the bundled BoringSSL is used.
This probably fixes issue #10555. Note that without this adjustment the build
fails even.
Dropped uneeded old patches.
Overview of the updated versions:
stable: 43.0.2357.125 -> 43.0.2357.130
beta: 44.0.2403.52 -> 44.0.2403.61
For the beta channel the following changes were necessary:
* Drop all patches which were added in c290595 because they apply to
44.0.2403.52 only. The shipped version of Blink was older than the
one used for Chromium itself and thus contained just the
cherry-picked patches from upstream Blink.
* The ffmpegsumo library is now statically linked the same way as in
the dev version, so let's not try to put it into the output store
path.
All channels were built successfully on my Hydra at:
https://headcounter.org/hydra/eval/187176
VM tests did also pass and can be found at:
x86: https://headcounter.org/hydra/build/707636
x86_64: https://headcounter.org/hydra/build/707637
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just silencing the error will not prevent Chromium from trying to start
up the SUID sandbox anyway, thus flooding stderr with:
LaunchProcess: failed to execvp:
After digging a bit in the source code I found out that the SUID sandbox
binary is indeed used, but only for setting oom_score_adj within the
user namespace (as "root"). So let's build the sandbox binary and of
course don't set setuid bit.
These annoying error messages were originally introduced by 0aad4b7 and
I'm deeply sorry for annoying you guys out there with them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of the updated versions:
stable: 40.0.2214.91 -> 40.0.2214.115
beta: 41.0.2272.16 -> 41.0.2272.64
dev: 41.0.2272.16 -> 42.0.2305.3
Introduces 42.0.2305.3 as the new dev version, which no longer requires
our user namespaces sandbox patch. Thanks to everyone participating in
https://crbug.com/312380 for finally having this upstream.
In the course of supporting the official namespace sandbox (that's what
the user namespace sandbox is called), a few things needed to be fixed
for version 42:
* Add an updated nix_plugin_paths.patch, because the old
one tries to patch the path for libpdf, which is now natively included
in Chromium.
* Don't copy libpdf.so to libexec path for version 42, it's no longer
needed as it's completely built-in now.
* Disable SUID sandbox directly in the source instead of going the easy
route of passing --disable-setuid-sandbox. The reason is that with
the command line flag a nasty nagbar will appear.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This brings a new stable version 40.0.2214.91 along with a beta update
to version 41.0.2272.16, the dev channel is still stuck at version
41.0.2272.12 and within the next days will jump to version 42.
For this reason, I've done some cheating here and brought the beta
channel in par with the dev channel, because dev is older than beta on
OmahaProxy.
Here's an overview of the channel upgrades:
stable: 39.0.2171.65 -> 40.0.2214.91 [1]
beta: 40.0.2214.10 -> 41.0.2272.16 [1] [2] [3]
dev: 41.0.2224.3 -> 41.0.2272.16 [1] [2] [3]
[1]: We needed to patch in locations of lib{pci,udev}.so, because
Chromium tries to load them at runtime. For version 41 startup will
fail if it is unable to load libudev, but it also has the advantage
that this fixes GPU detection using libpci in the stable version,
which in turn could fix a few bugs on NixOS.
[2]: The upstream Debian package for the binary plugins now uses XZ
compression for the enclosed data tarball.
[3]: Chromium 41 needs {shapshot,natives}_blob.bin in order to start up,
so let's cp it among with the .pak files to avoid adding a
conditional for version 40.
The release annoucement of the stable channel update can be found here:
http://googlechromereleases.blogspot.de/2015/01/stable-update.html
Note that this release contains 62 security fixes(!) and I'm hereby
apologizing for the delay of this update.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The Chromium PDF plugin is now available as open source software and is
already included in the Chromium source tree in current stable, so there
is no need to extract it from the Chrome binary package anymore.
See release announcement at http://blog.foxitsoftware.com/?p=641
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is because of a single file that symlinks to the source output
path:
libexec/chromium/resources/extension/demo/library.js
Target within source output path:
chrome/browser/resources/extension_resource/demo/library.js
So we just need to ensure that the cp command follows symlinks during
installPhase and we should no longer have this unnecessary dependency.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Let's ensure we do all architecture-dependant stuff inside
mkChromiumDerivation and not pass archInfo around, so we can properly
decouple it from the main function.
This partially reverts 8d54dc6d13.
The main reason for doing this is because the architecture information
is no longer required in Chromium 37, so let's uglify and XXX it in
common.nix and remove it once version 37 hits the stable channel.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The packageName attribute defines the output path and binary name of the
product that's going to be created, so we really want to have "chromium"
instead of "chromium-browser" here, especially for the resulting binary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This results in a new function called mkChromiumDerivation, which can be
used to easily build packages that are based on the Chromium source
tree.
We pass through this function as mkDerivation in the chromium wrappre,
so in the end if you want to create such a package, something like:
chromium.mkDerivation (base: {
name = "your-shiny-package-based-on-chromium";
...
})
will suffice.
Of course, this is only the first step towards this functionality,
because right now I'm not even sure the Chromium browser itself will
build.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We don't want ta have the source derivation in the runtime dependencies
of the browser itself. Also, we've broken the Firefox wrapper, because
we've no longer exposed the packageName attribute.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm giving up on this after several attempts to correctly unbundle the
largest part, namely Google's WebKit fork Blink. Right now it's so much
tied into the Chromium source it's going to be fairly hard to do if
you're not working full time on it.
Also, the intermediate steps needed to do this properly would introduce
uneccesary complexity on our side, so we really need to finish this
without leaving it in the "messy" state in order to not make Chromium
even more difficult to maintain than it is already.
However, anyone who wants to proceed on this messy step is free to
revert this commit and continue doing so. In my case I'm going to try
again once https://crbug.com/239107 and https://crbug.com/239181 are
fixed in _stable_ (I don't want to introduce *lots* of conditionals on
the version either).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is because of our symlink mess, as Chromium's build support scripts
are trying to resolve everything based on absolute paths and we split
off the bundled sources from the main derivation.
Yes, I'm refering to this as a mess, because in the end, we're going to
patch up the gyp files and use references someday.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
