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.
