The new version is the one already committed in trunk as revision 160697.
In order to get into beta and stable this could take some while so we're going
need to carry around that patch for some time.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This dependency has recently been added to chromium while we didn't notice it,
so let's avoid to use the bundled version.
It might make sense to remove the unneeded files in third_party/ based on a
whitelist, so that we notice future changes like this earlier.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
While libexif has been bundled with chromium for some months already, they only
recently added the GYP option to switch to using the system library. So, let's
enable it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Version 22 is the current version of the stable channel, so we don't need to
carry around a patch for earlier versions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This removes the patch introduced in 949afcc0f2.
The reason behind this is because even though we patch in the legacy seccomp
sandbox by default, it won't be used anyway as both cannot coexist anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is just a temporary fix and will only thrown away as soon as a proper fix
is included upstream, see http://crbug.com/149834 for more details about this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
dev: 23.0.1271.10 -> 24.0.1284.2 (not tested, probably won't build?)
beta: 22.0.1229.91 -> 23.0.1271.17 (issues, see below)
While testing the beta release, I've been bitten by http://crbug.com/149834, so
as this is a beta release, I'm not sure if we should patch again to disable the
BPF seccomp sandbox.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The BPF renderer sandbox is now the default in 23. But still, it is not regarded
as "adequately sandboxed" from Google so we still need the legacy seccomp
sandbox.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Well, after looking a bit more thoroughly through the zlib patch from the
Chromium team, it seams, that this really fix an issue that hasn't yet been
applied upstream. Unfortunately neither Chromium nor Zlib give more information
about that issue. Maybe they're waiting until its resolved upstream and thus the
temporary patch?
The bad news is, that the fix for the vulnerability is incomplete in Chromium
and covers only the use cases of Chromium itself, so we can't include that
patched version in nixpkgs zlib derivation.
Until the issue is fixed upstream we're hereby safer off turning it off in
Chromium and thus use the bundled and patched version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
dev: 23.0.1271.10
beta: 22.0.1229.91
stable: 22.0.1229.79
The revert for SVN revision 151720 is now obsolete in the current beta release
and is only needed for the stable version. So let's hope that >= 22.0.1229.91
will get stable soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 22.0.1229.56
dev: 23.0.1262.0
Patch for http://crbug.com/143623 still applies and is still not fixed upstream.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
SVN revision 151720 breaks the build with system zlib, see:
http://src.chromium.org/viewvc/chrome?view=rev&revision=151720
The issue here is, that r151720 introduces changes directly in zlib, which
aren't upstream and unfortunately there is no more information stating the exact
reasons for this change, as all references to it are not publicly available:
http://crbug.com/139744https://chromiumcodereview.appspot.com/10837057
So for the moment, we're going to add a patch, which applies to v22 and higher,
which essentially reverts r151720, until either more information on the issue is
available or it is resolved upstream.
As someone has already reported the issue, we just need to track the following
issue:
http://crbug.com/143623
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm personally not using mouse/gpm support for w3m, because I find it somewhat
too awkward when copy/pasting text. But maybe there are users out there who want
to have it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This builds the w3m image helper with fbcon support if the derivation is called
with graphicsSupport set to true. This change shouldn't break anything as
graphicsSupport is disabled by default, so in any case it could only break
things for users explicitly passing the attribute.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This enables legacy seccomp sandbox by default even on chromium 22, because the
BPF sandbox is still work in progress, please see:
http://crbug.com/139872http://crbug.com/130662
Because the BPF seccomp sandbox is used in case the legacy seccomp mode
initialization fails, we might need to patch this again, as soon as the BPF
sandbox is fully implemented to fall back to legacy seccomp and use BPF by
default.
We now have two patches for "default to seccomp" - one for Chromium 21 and one
for 22 or higher.
The patch doesn't apply in version 22 and newer, because mode 1 sandboxes are
connsidered "legacy" (well, apart from the fact that I'd personally prefer BPF
anyway), for reasons I wasn't able to find, yet. But let's proceed on BPF
integration and thus gain more insight on the exact reasons.
If you look at what changed, you'll surely notice that version 22 is now in
beta, so we have to expect things to break. And one thing that will break for
sure is the seccomp patch, because beginning with 22 the new BPF seccomp sandbox
is going to replace the mode 1 seccomp sandbox.
This commit doesn't add any feature and just fixes a small annoyance which
result in messages like this:
Checking if xxx applies...no.
See that there is no whitespace between "..." and "no"? Well, the world cares
for more important things, but for me personally those minor annoyances can turn
into major annoyances.
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.
So, now even Firefox can be built with our shiny new fixed up NSS derivation,
and as this is desired (especially if we want to support certificates from the
CA bundle), let's make it the default.
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.
The reason is because unpacking debian packages requires fewer dependencies (ar,
gzip and tar, nothing more), and in addition we can explicitly reference a
version number from the apt repository.
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.
The configure script picks up libbsd.so from the host machine.
It uses simple find command to locate the file, but the linker
can not use it.
The fix replace the search path to /no-such-path
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.
first time a Flash control is loaded, with the following message on
stderr:
/nix/store/c5ma4l7nlzcwdkjzrflni58aacqrfs1y-xulrunner-13.0/lib/xulrunner-13.0/plugin-container: symbol lookup error: /nix/store/c5ma4l7nlzcwdkjzrflni58aacqrfs1y-xulrunner-13.0/lib/xulrunner-13.0/plugin-container: undefined symbol: malloc_message
Need to investigate where malloc_message is defined.
svn path=/nixpkgs/trunk/; revision=34368
I took mainly the patch from Alexandr Foremny, but I had to solve conflicts.
Moreover it required the old webkit.
svn path=/nixpkgs/trunk/; revision=33596
This merge leads to a big rebuild, but this wouldn't hurt as I'm going to
reintegrate this branch soon.
svn path=/nixpkgs/branches/glib-2.30-take2/; revision=33455
Not merged r32497 (tree conflict, glibc GNU Hurd update). Ludovic, could you
please look at this?
svn path=/nixpkgs/branches/stdenv-updates/; revision=32520
Merge conflicts:
* unzip (almost trivial)
* dvswitch (trivial)
* gmp (copied result of `git merge`)
The last item introduced gmp-5.0.3, thus full rebuild.
+ensureDir->mkdir -p in TeX packages was catched by git but not svn.
svn path=/nixpkgs/branches/stdenv-updates/; revision=32091
--enable-official-branding to get a browser that calls itself
"Firefox". But I'll leave the flag in for the moment.
* Removed Firefox 8.0.
svn path=/nixpkgs/trunk/; revision=31984
was ignored anyway. With the --with-system-libvpx flag, the build
barfs with:
checking for vpx/vpx_decoder.h... yes
configure: error: vpx/vpx_decoder.h found, but is not in /usr/include
svn path=/nixpkgs/trunk/; revision=27089
gradients in tabs and other places in the interface to be missing
(i.e. entirely white). Should investigate why our own Cairo doesn't
work properly.
svn path=/nixpkgs/trunk/; revision=26666
Otherwise, on a cross-built lynx, it cannot gunzip pages that came in gzip-compressed.
(It was calling the host gzip, a lynx dependency, before)
svn path=/nixpkgs/branches/stdenv-updates/; revision=24882
