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>
This should fix the desktop icon location for both desktop entries (the
one from the Chromium derivation itself and the wrapper) and renames the
name of the file so that it gets overridden by the wrappers desktop item
so we don't end up having two of them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We already have a desktop icon from the browser wrapper, so this is only
for people who do not use the wrapper (for example if you don't want to
use Mozilla plugins).
Also, we someday might want to propagate the desktop item to the browser
wrapper as well.
Conflicts:
pkgs/applications/networking/browsers/chromium/default.nix
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>
Next, we're going to refactor update.sh and the first step is to ensure
that we keep everything related to sources into its own subdirectory to
not clutter up the main directory too much.
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>
We obviously don't want the Hydra job of nixpkgs to fail, so we need to
make sure that we have a proper meta attribute on the outermost
derivation.
For builds based on the Chromium source tree (like for example libcef),
we can still move the wrapper elsewhere when we need it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Now, we no longer tie the sandbox directly to the browser derivation but
wrap everything together into one derivation at the entry point at
default.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We now no longer pass enablePepperFlash and enablePepperPDF to the
browser package itself and only use plugins.flagsEnabled from there.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This currently only passes through the arguments and is nothing more
than the foundation of the new structure. In essence, I want to have a
really small default.nix which is then going down into the respective
subparts that are isolated from each other.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is hardcoded for the dev channel at the moment and we're going to
fetch it along with the main Chromium sources.
Also I'm putting this in default.nix at the moment, because we're going
to tear apart the whole Chromium package into several subparts soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We currently can't build the -lite package because beta and dev versions
aren't yet compatible with ICU version 52. But apart from that blocker,
this should get us ready for the switch.
Also, we're now correctly unbundling all dependencies which are used
from <nixpkgs>.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Starting with version 35, version 2 of libgnome_keyring is no longer
supported and it's probably pretty useless to do backports to version 2,
given the assumption that most users on Nix probably don't use it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Okay, now this time we really broke beta and dev, because python_arch no
longer is in build/common.gypi anymore.
This just adds chrome/chrome_tests.gypi to the list of files to be
changed by sed.
Also, this time I did test at least whether gyp is running fine and
interrupted after the first 1000 build targets, so all channels *should*
now build fine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Build failure on Hydra:
https://hydra.nixos.org/build/9823160
This was caused by the update of file in 5885709.
As file seems to be used for only one substition in the gyp files, we
can now drop the build dependency on file and patch out the substition
expression, as it is done before actually testing if the value has been
set by -D (gyp, y u no have lazy eval!?).
PS: Proudly untested against beta and dev channels, redeployed my own
Hydra and building on my workstation here really is ... annoying (lavg
41 on a system with nproc 8, less than 8 GB RAM and you probably will
have as much "fun" as I just had writing this commit mess...a....g
FUCK^H^H^H^H^H^H...e).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since version 34, ICU data files are now created separately and thus
need to be installed as well.
Closes#2016
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit f117341ff2de4b95d223b41b36942e2f60ada2a3)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This closes#1623, and updates _all_ channels to the corresponding
latest upstream versions.
Thanks to @wizeman for opening the pull request noted above and for
another update in between, @aristidb for fixing the patcheShebangs issue
and @shlevy for notifying me about the build failure in stdenv-updates
in the first place.
Sorry to everyone for my inactivity lately.
The following changes were needed in order to build those new releases:
* Patch out /bin/echo to allow building with all options enabled.
* Always use GN from the source tree.
* Remove import of depot_tools for version 34.
* Drop version 32 specific stuff.
With this commit, the following new upstream versions are introduced:
stable: 32.0.1700.77 -> 32.0.1700.102 (builds fine, tested)
beta: 32.0.1700.19 -> 33.0.1750.46 (builds fine, tested)
dev: 33.0.1712.4 -> 34.0.1809.0 (build broken with gnome_keyring)
The dev version requires a more recent version gnome_keyring and thus
won't build if gnomeKeyringSupport is set to true. I haven't tested this
build without gnomeKeyringSupport yet, so it might be broken and will be
fixed later.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This introduces version 31.0.1650.57 as the new version for the stable
channel.
Overview of the updated channels:
stable: 30.0.1599.114 -> 31.0.1650.57
beta: 31.0.1650.34 -> 32.0.1700.19
dev: 32.0.1671.3 -> 33.0.1712.4
This drops the sandbox_userns_30.patch as version 30 is no longer
stable. In addition, we had to patch out some references to /usr/bin/gcc
in the bundled WebKit sources.
Builds are passing and running fine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This removes the conditionals and obsolete cruft for version 29,
especially the old user namespaces sandbox patch.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This splits up the source into one base output (just the build and tools
directory), one for bundled dependencies, one for sandbox sources and
one for the sources of the main browser.
The state of this is heavily work in progress and contains a bunch of
workarounds. For example, we currently copy the entire sources into the
build directory, so a build ultimately requires even more space than
before.
Of course, it's just temporary as neither GYP nor ninja is particularly
friendly if it comes to out-of-tree builds.
Another thing which is heavily WIP is how we handle patches. Ultimately,
those patches shouldn't be applied to the source tree (at least not all)
but rather to the final build's temporary directory.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Now the chromium derivation produces an extra output path for the
sandbox in order to be properly used as a setuid wrapper in <nixos>
without the need to include the full Chromium package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 30.0.1599.22 -> 30.0.1599.37
dev: 31.0.1612.0 -> 31.0.1626.0 (new patch sandbox_userns_31.patch)
I've rebased the user namespace sandbox patch against current trunk for
the dev version, because it didn't apply anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This drops the initial version of the user namespaces sandbox patch and
the fix for NSS 3.15, which is no longer needed because it was fixed
upstream.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Version 29 has now made it into stable, the release announcement blog
post can be found here:
http://googlechromereleases.blogspot.de/2013/08/stable-channel-update.html
Overview of the updated channels:
stable: 28.0.1500.95 -> 29.0.1547.57
beta: 29.0.1547.49 -> 29.0.1547.57
dev: 30.0.1588.0 -> 30.0.1599.10 (userns patch updated)
All channels build fine and are tested (manually at the moment, until we
can run the test suite).
The userns patch for version 30.0.1599.0 from the dev channel didn't
apply anymore and is now rebased against 30.0.1599.10.
In addition, in version 30 the gyp flag for setting the sandbox path
isn't recognized anymore, so we patch it into the source directly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The description now no longer contains the package name itself. Thanks
to nixpkgs-lint for noticing :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The sha256 has changed upstream for 30.0.1566.2 and in addition there is
a new version available, so let's switch to the new version.
Unfortunately the user namespaces sandbox patch doesn't apply anymore
because of http://crbug.com/242290, so this adds a rebased version on
top of the current trunk of Chromium.
In order to build version 30, file is now needed as an additional build
input, because it is used by gyp.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As requested by some users, we finally have support for cloud sync,
spelling, geolocation and a lot more of the services that require API
keys from Google. Details about which services are involved can be found
at: http://www.chromium.org/developers/how-tos/api-keys
Thanks to Paweł Hajdan <phajdan@google.com> for giving us permission to
distribute the API keys with our build of Chromium:
> Note that the public Terms of Service do not allow distribution of the
> API keys in any form. To make this work for you, on behalf of Google
> Chrome Team I am providing you with:
> Official permission to include Google API keys in your packages and to
> distribute these packages. The remainder of the Terms of Service for
> each API applies, but at this time you are not bound by the
> requirement to only access the APIs for personal and development use,
> and Additional quota for each API in an effort to adequately support
> your users.
As noted in the source: Those keys are for use in NixOS/nixpkgs ONLY!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Thanks to @jcumming for notifying me about this in #nixos:
03:47 < jack_c> aszlig: chromium builds with -Werror by default.
03:47 < jack_c> Putting: werror = "";
03:48 < jack_c> into gypFlags fixes that..
...
03:52 < jack_c> aszlig: agree -Werror is a good linting tool, but it should
probably disabled for distribution.
So, I guess it makes sense in our case, especially because different GCC
versions will issue different warnings.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Chromium 28.0.1500.52 finally is stable, so the release channels are now:
stable: 28.0.1500.52 (builds fine, tested)
beta: 28.0.1500.52 (same as stable)
dev: 29.0.1541.2 (patch rebased, builds fine, tested)
The user namespace patch doesn't apply for version 29, so I had to rebase it
against the current trunk (revision 207742).
And as version 27 is outdated, we no longer need to distinguish versions for
patching the hardcoded gcc path in core/core.gypi.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This brings in Chromium 27 as the new stable version.
Specific versions of the updated channels:
stable: 26.0.1410.63 -> 27.0.1453.93 (builds fine, tested)
beta: 27.0.1453.81 -> 28.0.1500.20 (builds fine, tested)
dev: 28.0.1500.11 -> 29.0.1516.3 (builds fine, tested)
We now can finally drop the following patches:
* glibc-2.16-use-siginfo_t.patch
* pulseaudio_array_bounds.patch
These were for version 26 only and thus are no longer needed.
In addition, we no longer have to use the pre/post attributes, as there is just
_one_ place that uses version specific stuff (path to webcore.gyp).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Wanted to do this a long time ago, but never had a reason to do it. But with
Chromium 29 having no make target for chrome_sandbox, we now use ninja as well
as the official build and most other distributions.
The whole build/make flags cruft is now integrated into one buildPhase override
and we just call ninja there by exporting the specific variables.
And this also makes enableParallelBuilding obsolete, as we use NIX_BUILD_CORES
directly now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Actually a "*[0-9]" wildcard isn't enough for some unrelated icons to slip into
the derivation output, so let's explicitely check again within the for loop.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This patch adds support for unprivileged user namespaces found in kernel
versions 3.8.0 and later. In case of Nix, this is especially useful to prevent
having to set up setuid wrappers.
The implementation details about this patch can be found at the top of the file
"sandbox_userns.patch". My first attempt of creating this patch was by modifying
the SUID sandbox. Unfortunately this didn't work out well, because in the event
of a sandbox failure, the host zygote process waits for an answer of the inner
zygote with no timeout. Even if I'd have set a timeout, this would have been
very ugly, giving users which don't have unprivileged user namespaces a delay on
startup.
An alternative approach to the mentioned problem would be to use select() on the
host zygote, watching for changes stdout or stderr and the synchronization
socket. But even that approach isn't feasible because it requires a whole bunch
of even more patching.
Patch was tested with older kernels (3.2.x, 3.7.x) and kernels without user
namespace support enabled, where in case the feature is unavailable it reverts
back to the previous behaviour (no zygote sandbox, only seccomp BPF).
In order to support all Chromium channels, I manually changed the first hunk of
the patch to not include the starting context of the diff, because there is a
whitespace change in more recent versions of the Chromium source tree.
See SVN revision 199882 for the change (revert in this case) in detail:
http://src.chromium.org/viewvc/chrome?view=revision&revision=199882
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is no feature change and only makes the installPhase look nicer and it now
doesn't exceed 80 characters in width anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This updates the following channels to the latest upstream versions:
beta: 27.0.1453.65 -> 27.0.1453.81 (builds fine, tested)
dev: 28.0.1485.0 -> 28.0.1500.5 (builds fine, tested)
For version 28, the reference to /usr/bin/gcc is now located in
third_party/WebKit/Source/core/core.gypi instead of the previous
third_party/WebKit/Source/core/core.gyp/core.gyp.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This updates the channels to the following new versions:
beta: 27.0.1453.47 -> 27.0.1453.65 (builds fine, tested)
dev: 27.0.1453.47 -> 28.0.1485.0 (builds fine, tested)
As we now don't have any version below 26, this update drops all references to
all older versions as well.
In addition to that, the /usr/bin/gcc reference from:
third_party/WebKit/Source/core/core.gyp/core.gyp
Can now - starting at version 28 - be found in:
third_party/WebKit/Source/WebCore/WebCore.gyp/WebCore.gyp
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
stable: 25.0.1364.152 -> 26.0.1410.43 (builds fine, tested)
beta: 26.0.1410.28 -> 26.0.1410.43 (builds fine, tested)
dev: 26.0.1410.28 -> 27.0.1448.0 (build fixed and tested)
For version 27, this introduces a new dependency on libXtst and removes the
patch for siginfo_t and the pulseaudio array bounds error.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This patch was introduced before (7e5109a) the stdenv-updates merge and is no
longer needed, as the current C library doesn't use this flag anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This gets rid of the patch for newer pulseaudio library versions.
In addition, we now have protobuf and pciutils in default dependencies, as those
are required (or better: optional, but recommended and thus activated by the
default gyp options) by versions >= 25.
Also, we now no longer depend on libpng, but I'm not dropping this, as we want
to get back to libpng from nixpkgs again 'real soon'.
The stack-protector flag is now disabled by default accross all versions, and
probably didn't hurt back in version 24, but at least we're now no longer add it
dependant on a particular version.
And those pesky post/onlyXX version booleans are now pre/postXX, to ensure
better clarity.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is needed in order to ensure that the postPatch hook is executed, which is
not when the patches list is empty.
It is fixed by 82f94df719 in stdenv-updates.
So as soon as the branch gets merged, we can get rid of this hack as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit b7cbb4da11.
The main reason behind this - apart from looking ugly - is that it didn't really
solve anything, see:
http://hydra.nixos.org/build/4198299
So, we need a different and less hacky approach...
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Conflicts:
pkgs/applications/networking/browsers/chromium/default.nix
pkgs/top-level/all-packages.nix
Merge conflicts seemed trivial, but a look from viric and aszlig would be nice.
So, this is our sledgehammer, forcing -fno-stack-protector for every gcc/g++ in
the univ... Chromium build. Of course this is a somewhat nasty fix and there
should be a real fix somewhere in Chromium 26. But instead of wandering around
and picking cherries, we now go out for the slaughter until someone brings us
the damn cherries because we are FUURRRIII... no well... time for sleep :-)
May the mighty Hydra be with us!
Thanks to our great fellow @cillianderoiste, for joining the battle with his
almighty battle axe, crushing and burning some CPUs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Tested-by: Cillian de Róiste <cillian.deroiste@gmail.com>
This should at least mitigate our build error to only occur in v8 anymore.
Unfortunately we can't use v8 from nixpkgs right now, so we're going to put out
our sledgehammer in the next commit. Meanwhile, it doesn't hurt to get rid of
the bundled protobuf library, so let's do it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Unfortunately, we have build errors for version 25 in the bundled libvpx:
http://hydra.nixos.org/build/4173075http://hydra.nixos.org/build/4173066
As I can't reproduce this on my local system (I've disabled the option
CONFIG_CC_STACKPROTECTOR here), let's just hope that libvpx is the only part
that fails during build because of this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The upgrade currently doesn't involve the -lite package, as we need to use a few
more dependencies from nixpkgs first before we can finally fully switch over to
the lite package, even though the update script will try to fetch it anyway.
In this update, one particular problem that arises in conjuction with the
seccomp BPF sandbox is caused by this commit:
https://chromiumcodereview.appspot.com/12209029
Which particularily filters flags to the clone() syscall. I've spent (wasted?) a
few hours figuring out the troublesome flag, eventually figuring it out and -
just by curiousity ("Do other distributions have the same problem?") - searched
the web for "chromium CLONE_DETACHED" and BEHOLD...
A post from our OWN mailinglist pops up with the same patch I intended to do:
http://article.gmane.org/gmane.linux.distributions.nixos/10356
So shame on me for not being subscribed to the mailing list, and big thanks to
Ian Farmer for the patch.
As a consequence I'm now subscribed.
So, back to chromium itself, version 26 builds fine and works so far without
much (more to come in later commits) trouble.
We also had to introduce three more dependencies:
* protobuf: This one is because we don't need to use the bundled one anymore,
so we can use the version in nixpkgs.
* speechd: Not sure whether this was bundled or not, but let's use nixpkgs
version as well to keep down build time.
* libXdamage: Needed for screen capturing support.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This update is a bit more problematic, as the bundled version of libpng is
version 1.2.45 and the version in nixpkgs is 1.5.13. Even if trying to run with
libpng12 from nixpkgs, it seems to collide with parts of the bundled version.
So, until this is either fixed upstream or we have a good solution, we're using
bundled libpng for chromium version 25 and higher.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
For this update we needed to fix a bunch of things:
* Limit pulse_audio_fix.patch to version 24 only (fixed upstream in 25).
* Avoid the use of -fstack-protector for version 25.
The -fstack-protector option seems to be passed to libvpx now by default, so
simply use -fno-stack-protector in every occurence of -fstack-protector in
common.gypi. At least for now this will do it, but ultimately and for the future
we may want to have support for that in general.
And if we need that support in chromium directly depends on some of the next
updates to this package, as it seems that we now can switch to quite a lot of
nixpkgs dependencies instead of bundled dependencies.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Might come in handy to actually know when things going to break.
In case you're wondering: Yes, "aszlig" is the name everyone uses in real life
(even my family uses it) and is my pending stage name (not _yet_ officially).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The patch previously was fetched from an Arch Linux contributor but is no longer
available there anymore. So, this is only an intermediate fix until channels get
updated (very soon I hope, even though chromium 25 could get quite messy).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We can still use the config attribute set from within all-packages to pass it to
the package expression, which we do in case of PulseAudio. In order to override
other stuff you can now conveniently use chromium.override without passing a
fake config attribute set.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This allows for more flexible overrides instead of just passing a custom
configuration attrset like:
chromium.override { config.chromium.channel = "beta"; }
So you can now simply do:
chromium.override { channel = "beta"; }
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The patch is no longer needed, as we are now using the BPF seccomp sandbox.
Unfortunately this is not marked "adequately sandboxed" in chrome://sandbox, as
it awaits security review on http://crbug.com/26528.
Unfortunately this gets us into a position where we can't be sure if the sandbox
is working correctly, especially because the non-BPF seccomp sandbox has a bunch
of stability issues and is marked legacy. And we definitely don't want to add
support for the setuid sandbox, do we?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 23.0.1271.60 (build successful)
dev: 24.0.1312.2 (build successful after patching)
The development version needs a patch in order to build properly against
PulseAudio. Issue and origin of the patch can be found here:
http://crbug.com/157876
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 23.0.1271.26 -> 23.0.1271.40
dev: 24.0.1284.2 -> 24.0.1297.0
Both are building successful and the BPF seccomp sandbox fix has been dropped as
it has finally been applied upstream.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
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>
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>
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.
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.
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.
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.
