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>
Previously, we installed std by omitting the tools directory. Now, there are
occasions where you actually want to use things like tools.haxelib from within
your project, for example to create something that interfaces with the haxelib
API. So we now just remove all files in there that were created during the main
build in postBuild.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Neko seems to think it is running in 32bit, even though it is compiled for
64bit. The fix is included in 1.8.3, which is not yet released as of now, so we
add a temporary fix until the release.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I plan to later use uscan for simplifying package updates in some
NixPkgs packages. I have no code for that now.
I added Perl packages File::DesktopEntry and File::BaseDir in a slightly
hascky way because one part of the installation system replaced PREFIX=
with --prefix= and the other complained that it doesn't know what to do
with --prefix=. I checked that a script using File::DesktopEntry works,
and I don't know enough Perl to rewrite buildPerlPackage and hope that
my change is an improvement.
I removed trnaslated manpages because it uses po4a which has some more
Debian-specific dependencies of its own.
As well as for neko, we now have way less cruft within the mkDerivation
attribute set. We also now use make to build haxe, which will include haxelib
and haxedoc as well.
The main reason why I was doing this was because the package didn't build and
still was referencing mawercer.de, which does not contain those tarballs
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should simplify the input of the derivation builder significantly and of
course we don't need to rely on mawercer.de to supply the needed files. Also,
the derivation name doesn't include "-cvs" anymore, as we're building from the
release tarball.
In addition, we don't need the patch anymore, as it was so simple that it could
be done easily with sed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The openjdk BOOT_CYCLE bootstrap doesn't use the binaries built in the first stage for the second stage, so we get a bunch of errors like:
/bin/sh: /nix/store/wdgl7xl9b72hn212l0672ad5sn7vh44y-openjdk-bootstrap/bin/native2ascii: No such file or directory
Instead, just build each stage as a separate derivation
It seems the resulting output path has no reference to libxine, so it
does not get used. Probably it needs some hard-coded link-paths as
eaglemode wants to use dlopen for some things.
If anyone wants to use eaglemode's xine support and fix this issue,
please make it optional.
- big cleanup of optional dependency handling
I hope I didn't miss any cases.
- XVID
xvid support seams broken, both built-in as external.
I didn't notice any issues playing xvid video's though, as ffmpeg's
default mpeg4 decoder handles xvid-encoded files just fine.
It seems the only users affected by this are users who still encode
xvid with mencoder (instead of plain ffmpeg). If this really is an
issue to anyone, please let me know, so I can look into it some more,
or retain an older mplayer version next to this one.
