The BIND configure script finds extra dependencies in /usr/include and /usr/lib,
and activates additional features if it does. This may cause the build to fail
on systems that cannot use a chroot environment. Actively disabling those
additional features prevents this issue from occurring.
This modifies how the `riak` and `riak-admin` scripts work such that one has to specify environment variables for where the data, log, and etc directories live.
* Add needed dependencies:
coreutils, python, ruby, java and several Perl modules (Time::HiRes
1.9.724 is no longer available, bump to 1.9725)
* Use sha256 instead of md5 (more secure)
* Wrap munin perl scripts so they find their dependencies at runtime
* Rework meta description attributes.
FIXME/TODO: munin is still not usable; it tries to write log files and
web graphs to its installation path.
See #490 discussion.
This reverts commit 1278859d31, reversing
changes made to 0c020c98f9.
Conflicts:
pkgs/desktops/xfce/core/xfce4-session.nix (take master)
pkgs/lib/misc.nix (auto)
With this patch support for SSL is compiled into lighttpd.
IMO encryption is in most use cases important, therefore SSL support should be build in. This would simplify the setup of a standard web application a lot.
SSL support of lighttpd is documented at
http://redmine.lighttpd.net/projects/1/wiki/Docs_SSL
Before, files were put in /var, requiring the server to be run as a
privileged user even when just testing locally. This can be overridden
by setting the SYS_PREFIX env variable, or on a more coarse-grained
basis in /etc/rabbitmq/rabbitmq-env.conf
Signed-off-by: Shea Levy <shea@shealevy.com>
- update some modules to work with the newer server
- fix many other modules via overrides
- huge cleanup in overrides via better propagation
and pixman include flattening
- URLs of XCB stuff have been moved
The build complains about missing "file" and "which" commands, so add them as
build inputs.
"file" is used by the autotools configure script to tweak what -m flag
(if any) to pass to the linker when it asks it for shared library
support.
Here is an example of -m values for GNU ld:
Supported emulations:
elf_x86_64
elf32_x86_64
elf_i386
i386linux
elf_l1om
elf_k1om
"which" is used in the build phase to look for svnversion and git, to build a
version stamp. Since we build from a release tarball (and don't pass svn or git
as inputs either), this check fails and falls back to the version number in the
tarball.
There is one build warning left, but I think this is normal on NixOS:
/tmp/nix-build-lighttpd-1.4.32.drv-0/lighttpd-1.4.32/libtool: line 1085: ldconfig: command not found
One important denial of service (in 1.4.31) fix: CVE-2012-5533[1].
NOTE: There are some errors about missing commands during the build, but
I'm pretty sure they were there before. And the result seems to be
working anyway...
* /usr/bin/file: No such file or directory
* /bin/sh: line 2: which: command not found
* /tmp/nix-build-lighttpd-1.4.32.drv-0/lighttpd-1.4.32/libtool: line 1085: ldconfig: command not found
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5533
First, pass in `self' again so that overriding works properly (thanks
for pointing that out, @edolstra)
Second, instead of having linuxPackages*.kernel mean something different
inside the set and out, add a new attribute linuxPackages*.kernelDev,
which for the generic kernel is simply linuxPackages*.kernel but for the
manual-config kernel is the `dev' output (which has the build tree,
source tree, etc.)
The second change required trivial modifications in a bunch of
expressions, I verified that all of the linuxPackages* sets defined in
all-packages.nix have the same drv paths before and after the change.
Signed-off-by: Shea Levy <shea@shealevy.com>
The original fix modified a generated file instead of the
manually-maintained overrides file. Checked by inspection.
Signed-off-by: Shea Levy <shea@shealevy.com>
This is the Oracle Database which they give out for free, therefore it's called
Express Edition.
Well, I pretty much packaged this in vain as I finally found out that i don't
need that Oracle Database stuff at all. And my original purpose was to do SQL
query/constraint testing.
So before I'm going to throw this away (forever, oh no!), maybe someone else
might have a use case for this.
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.
Additionally, turn on a lot more features in mpd by
adding dependencies. Can be controlled by xxxSupport flags,
as before. By default, everything is enabled.
It seems that (almost?) all NixOS users start X using the services module,
because startx seems to be broken for quite some while. And it hit me while
getting to NixOS for the first time as well, so I then decided to just use the
service module.
As I'm working with multiple X servers, writing wrappers in ~/nixpkgs/config.nix
became tedious and so I decided to fix it, hopefully without breaking anything.
The fix consists of:
* Provide a default location for the Xorg log (~/.xorg.log - hope that's okay)
* Expose xauth through xinit to ensure purity and "unexpected behaviour", also
known as "simply not working", because xauth isn't in the user's environment.
* Actually provide the X binary so it doesn't have to be passed to startx every
time.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
6.14.6 requires a newer version of libdrm, which in turn requires a newer
version of mesa. I cheated and edited the generated default.nix file instead of
re-generating it, since generate-expr-from-tarballs.pl complained of a collision
between two tarballs providing different versions of xorg-server.
The NixOS service module loads those modules by default. So we need to build
them here as well.
I'm not really sure why these modules are included by default, because (except
from maybe CGI) they obviously are only usable in very rare cases. Am I wrong?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason because the configure script is unnable to find libxml2 is because it
is searching for a header file in `libxml/*.h`. Obviously this cases an error,
because it's actually in `${libxml2}/include/libxml2/libxml/*.h`, so let's add
the parent directory to --with-libxml2 and remove the comment from buildInputs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
