* Use more system libraries
* Enable KDE4 desktop integration
* Split preparation between postUnpack, patchPhase and preConfigure
Viric, feel free to revert (parts of) this commit.
the kernel itself (and busybox's cifs mount code) are no longer able
to do this in some/most cases and will error out saying:
"CIFS VFS: connecting to DFS root not implemented yet""
Nixos' qemu-vm target is hurt by this, as it wants to mount /nix/store
via cifs very early in the boot process.
this commit just marks the problematic kernels.
An associated commit in nixos will use this info to fix the problem.
spice is a next-generation remote desktop protocol, aimed at virtual
machines.
focus is not just on display/input devices, but clipboard, audio,
video, opengl, smartcards, usb devices as well, no matter if the
virtual machine runs locally or on a remote host.
not everything is implemented yet, and I didn't enable all available
features yet.
Currently, spice is able to make qemu-kvm virtual machines very usable
for workstation guests, with good 2d video support, clipboard sharing,
full resolutions, auto-mouse-grab/ungrab, xinerama / multiple guest
monitors. Good drivers for windows 7 guests are available, as well as
linux Xorg drivers / agents.
Basically, kvm was already the best-performing VM solution (using
virtio drivers), but virtualbox, while slower, had better
desktop-integration support (still wins if you want opengl). Spice
fixes this, making the choice very easy.
Passing install_root=$out isn't a good idea because the install script is going
to pre-pend that prefix to all other paths even though these have the $out
prefix already. The resulting installation is a mess. Instead, we use the
"fake" install prefix "out" and then move all files and directories into the
right place afterward.
adding useful function foldAttr which behave like fold on attr values grouped by name
(without assertions now)
Signed-off-by: Marc Weber <marco-oweber@gmx.de>
With this change, java packages will build with openjdk by default. The
primary driver for this is legal: The build farm is not allowed to
distribute the proprietary Oracle jdk6, and so it is not allowed to
distribute any packages that depend on it. In my view, this is a purely
beneficial change: from the perspective of the build farm, packages will
go from undistributable due to licensing to either distributable or
undistributable due to failed build (if the package doesn't build
properly with openjdk), and from the perspective of the end user it is
very easy to override the jdk on a package-by-package basis or for all
of nixpkgs in the nixpkgs configuration.
This updates the stable version from 21.0.1180.79 to 21.0.1180.81 and introduces
version 22/23 for the beta/dev channels respectively. This needed quite a bit of
patching because beginning in version 22, the seccomp sandbox is considered
legacy (though BPF is still unfinished) and in order to successfully build, we
need to update the patches as well.
I'm merging this right into master for two reasons:
- There are no changes to the derivation if you're building the stable version
(which is the default), except for the upgrade to version 21.0.1180.81.
- Chromium currently has no reverse dependencies that may break due to this
update.
This originally was one single commit (just an update of all channels) until I
discovered the seccomp BPF build failure.
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.
Users might want to override the 'src' and 'name' of go from 'hg'.
I make the expression compatible with that.
Aside, I also set GOARM in the wrapper for it to build programs fine on
armv5tel by default.
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.
The previous version seemed rather old and not even the examples from the
official site compile with that fossil. As there are no reverse dependencies,
this update should be trivial and hopefully doesn't hurt someones personal
feelings.
If the environment variable HYDRA_DISALLOW_UNFREE is set to "1", then
evaluation of a package with license "unfree" will throw an error.
Thus such packages or any packages that depend on them will fail to
evaluate.
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.
Fix NSS library not finding root CA certificates.
This now uses more or less hardcoded CA certificates from Mozilla, which
is the case on Debian and Gentoo aswell. And it fixes the root CA
loading issue, as i discovered that firefox builds with the bundled
version of NSS. With this branch this is no longer the case.
My long-term plans are to integrate an automatic chainloader for
OPENSSL_X509_CERT_FILE, but I'm not sure if this is really a good idea
(hence not included in this branch), as the nss-pem module is still
somewhat experimental. Regardless of it's experimental nature i'm still
including it in order to make it possible for users to load custom PEM
encoded certificates into the NSS database.
This fixups also makes it possible to enable FIPS mode, in case someone
might be interested in that.
And finally, we have a Chromium without quirky bugs from the
experimental OpenSSL integration, which was my original motivation to do
this.
See #112 for further comments.
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.
Before, the entire directory was deleted and recreated, which fails if we want
to sign libraries (shlibsign is obviously deleted in that step as well), so we
delete everything but "nss-config" on postFixup.
This adds a patch from Debian, as they're already have security modules from NSS
in it's own library directory rather than /usr/lib{,64}/ and patch in loading of
libsoftokn as well.
The patch and our own fix of the patch (well, they hardcode Debian specific
stuff in there) ensures that SECMOD_AddNewModule() will find the right module
from the derivation's output path, so the built-in CA root certificates are
recognized and verified correctly.
Running NSS in FIPS mode is only possible if the libraries are signed correctly,
so we're doing this in the postFixup hook, to insure nothing gets altered after
that phase.
For more information about FIPS mode, please see:
https://developer.mozilla.org/en-US/docs/NSS/FIPS_Mode_-_an_explanation
First of all, let's remove that redundant BUILD_OPT variable.
This variable already is in makeFlags, so we really don't want it to be lurking
around in the attribute set of the derivation, and it annoys me for being there
for days.
We now state build targets explicitly rather than relying on "nss_build_all".
This makes NSPR_CONFIG_STATUS and the touch of build_nspr stamp obsolete, as
only nss_build_all includes build_nspr.
In addition, we don't need the -lz hack anymore, as this has been fixed in
recent NSS versions, so we can completly remove the postBuild hook.
And while we're at it, we're removing those outdated build instructions as well,
especially because we don't and can't follow official building guidelines
anymore, as those are difficult to apply to Nix.
This is a compatibility module which adds suport for PEM certificates used by
OpenSSL and compatible libraries. The module gets built but isn't used at the
moment, so we're going to work on integration of it later.
Let's use system SQLite library, which makes sense anyway. More importantly
because it conflicts with the sqlite package, as NSS is building this as a
shared library aswell.
So to begin with fixing NSS let's get to the latest upstream release and start
fixing, so we won't carry around historic crap we then will throw away anyway.
Please note that this update changes the directory structure quite a bit. In
particular, the file "/etc/bash_completion" no longer exists, which means that
shell code which relies on that path must be updated. I'll commit appropriate
changes for NixOS in a moment.
virtualbox: Fix build for manual kernel.
This should fix building VirtualBox against kernels made using the new
manual kernel configuration system.
This has been tested with the standard nixpkgs kernel as well.
