chromium: Improve update script and update to latest versions.
Previously, we had a single hash of the whole version response from
omahaproxy.
Unfortunately the dev version is released quite frequently, so the hash
is of no use at all (we could rather directly fetch rather than
executing the script, because it will fetch all channels anyway).
This pull request adds two methods of caching:
* First of all, if a perticular version/channel is already in the
previous version of the sources.nix file, don't download it again.
* And the second method is to check if the current sha256 is already
downloaded and reads the corresponding sha256 from the lookup table.
So, this should really help to avoid flooding the download servers and
to not stress impatient users too much.
Hurray! This is the first time chromium is working with NSS _and_ is able to
verify certificates using the root certificates built in into NSS.
Optimally it would use certs from OPENSSL_X509_CERT_FILE, but at least it's
working, so let's add that at some later point.
Until this commit we had a single hash of the whole version response from
omahaproxy. This worked well for not updating unnecessarily but only until one
single channel has a new version available.
Unfortunately the dev version is released quite frequently, so the hash is of no
use at all (we could rather directly fetch everything everytime we execute the
script).
This led to this commit, which adds two methods of caching:
First of all, if a perticular version/channel is already in the previous version
of the sources.nix file, don't download it again.
And the second method is to check if the current sha256 is already downloaded
and reads the corresponding sha256 from the lookup table.
So, this should really help to avoid flooding the download servers and to not
stress impatient users too much.
This caused HTML5 video to not work because this shared library is loaded at
runtime.
Unfortunately we can't use system ffmpeg yet, because upgrading would break
builds of other packages, and it would result in a copy of ffmpeg laying around
aswell, so we can defer this until we have fixed ffmpeg.
Thanks to @bluescreen303 for the bug report.
As already promised, the old single-channel source.nix is now obsolete as we're
using Omahaproxy now and the build of the stable version finishes successful and
the browser runs fine.
The previos update script just used the last version of chromium that showed up
at the bucket list at:
http://commondatastorage.googleapis.com/chromium-browser-official/
I'm not sure which channel this list actually holds, so I'm going to switch now
using the official release channels grabbed by omahaproxy. This also has the
advantage that we can provide different versions/flavors of chromium.
We now also write our data to sources.nix instead of source.nix, as we have more
than one source.
Always did this manually by putting -j8 into make flags, which i didn't commit,
as it obviously doesn't make sense to hardcode. However, this flag makes more
sense and obviously we need to avoid overriding buildPhase.
Which is enabled by default if neither pulseaudio or chromium.pulseaudio is
explicitly set. The reason is that chromium falls back to ALSA in case no
pulseaudio is available.
In addition it was necessary to patch media.gyp to ignore the array-out-of-
bounds warning.
This makes it easier to remember, as so far the naming wasn't quite consistent,
sometimes "use*", sometimes "enable*". So in using just use the feature name
itself, it should be pretty clear.
These libraries are heavily patched by the chromium project itself, so let's use
the bundled versions as those won't build anyway and also don't break functional
purity.
We also need to patch the compilation process, so it allows deprecated
declarations when building support for the cups backend. In addition, we also
need to add libgcrypt to dependencies as it's needed by the cups implementation.
This also separates gcrypt and gconf from the basic dependencies.
Unfortunately we cannot get rid of dbus_glib altogether, but maybe we want to
work on a patch to get rid of it? On the other hand it seems to be a TODO of the
chromium project itself, so let's wait and see.
Currently building fails with NSS, so we're using OpenSSL by default. And that's
why we want to make this configurable so if we manage to fix that build failure,
we could switch to using NSS by default.
This is mainly because of the patch to use OPENSSL_X509_CERT_FILE as a way to
specify the CA bundle. A browser which isn't able to verify SSL certificates
might be somewhat useless.
This is to make it more consistent with the naming of the package file and also
consistent with the build, as we're not using the Google branded version.
In addition the derivation attribute set now has a packageName value which can
be used to easily switch the binary names and paths, just in case we want to
switch to using "chrome" (or something entirely different) again.
There are still some libraries left, which we either need to patch or provide
more recent versions. Plus we're going to use openssl, as libnss doesn't want to
do proper SSL (let's debug this later).
If useSELinux is not set, enable seccomp mode by default and avoid building the
SUID helper sandbox at all. This involves a small patch which causes the
commandline arguments to be swapped: --disable-seccomp-sandbox to disable it,
while the option is active by default.
It fetches the latest version based on the bucketlist XML from
commondatastorage and generates a "source.nix" which contains an attribute set
about where to fetch the latest version.
The XML is parsed in a somewhat hackish way using sed, but as this is just an
updater, its okay and we don't want to break a fly on the wheel by employing a
full XML parser.
This only gets chromium to build so far, installation is missing by upstream, so
we need to manually copy the corresponding files. And I guess with nix, we also
need to patch a few paths on installation.
Another issue is that at the moment, a lot of dependencies are used from the
source tree, rather than from the system.
Also, it would be nice to build using LLVM, as it really speeds up compilation a
*LOT* and also has the side effect of resulting in smaller binaries.
Working unit tests would be nice, too. Unfortunately they're quite heavyweight
and take hours to run, so I guess "someday" would be the most appropriate time
to integrate.
Further todo's:
- Allow to disable GConf, GIO and CUPS.
- Option to disable the sandbox (for whatever reason the user might have).
- Integrate gold binutils.
- Pulseaudio support.
- Clearly separate Linux specific stuff.
