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
This reverts commit 788e760b51. NixOS
doesn't even have an /etc/skel. And if we had, 1) NixOS has the
ability to create regular files rather than symlinks in /etc
(environment.etc.<file>.mode = ...), so files in /etc/skel that should
be copied as regular files can be supported; and 2) we may actually
*want* to copy a symlink.
Also, typos in file names. Bleh.
This reverts commit a2ddd3643e.
@peti pointed out that python2.6 packages are now prefered over
python2.7. In a local test it was the other way round. seems to be
arbitrary or I messed up the test.
Git's Makefile has a NO_INSTALL_HARDLINKS flag to produce symlinks
instead of hard links. However, it still produces hard links between
$out/bin and $out/libexec, hence the patch.
Also, update Git to 1.8.2.1.
for `nix-env -i` the later defined python27Packages seems to win.
Another solution might be to have python26 oder python27 either in the
name or the version. Let's have a look at haskelPackages for that.
The freaky implementation was done that way in order to avoid unnecessary
re-builds of all Haskell packages by changing the wrapper script used
internally in those builds.
See <https://github.com/NixOS/nixpkgs/pull/466> for further details.
It works enough to display bootsplash animations in an xorg session and a VT.
I haven't figured out how to run it successfully from the initrd yet and I'm also not happy with the postInstall mess, but I'd rather merge it now than let it get lost. It seems like it should be possible for a user to activate it by using boot.initrd.extraUtilsCommands and boot.initrd.postMountCommands
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>
The previous implementation used the following tying-the-knot trickery to
override 'doCheck' to false for the given build:
cabalNoTest = {
mkDerivation = x: rec {
final = self.cabal.mkDerivation (self: (x final) // { doCheck = false; });
}.final;
};
That seemed to work, but for some reason it caused trouble with some builds --
not all -- that use jailbreakCabal. The problem was the 'stdenv' attribute
couldn't be evaluated properly anymore:
$ nix-build ~/pkgs/top-level/release-haskell.nix -A optparseApplicative.ghc6104.x86_64-linux --show-trace
error: while evaluating the attribute `drvPath' at `/nix/store/qkj5cxknwspz8ak0ganm97zfr2bhksgn-nix-1.5.2pre3082_2398417/share/nix/corepkgs/derivation.nix:19:9':
while evaluating the builtin function `derivationStrict':
while instantiating the derivation named `haskell-optparse-applicative-ghc6.10.4-0.5.2.1' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:40:13':
while evaluating the derivation attribute `configurePhase' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:107:13':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/strings.nix:55:26':
while evaluating the attribute `outPath' at `/nix/store/qkj5cxknwspz8ak0ganm97zfr2bhksgn-nix-1.5.2pre3082_2398417/share/nix/corepkgs/derivation.nix:18:9':
while evaluating the builtin function `getAttr':
while evaluating the builtin function `derivationStrict':
while instantiating the derivation named `jailbreak-cabal-1.1' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:40:13':
while evaluating the derivation attribute `nativeBuildInputs' at `/home/simons/.nix-defexpr/pkgs/stdenv/generic/default.nix:76:17':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/lists.nix:135:21':
while evaluating the attribute `buildInputs' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:22:17':
while evaluating the builtin function `filter':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:22:60':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:119:17':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/customisation.nix:61:22':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/customisation.nix:56:24':
while evaluating the builtin function `isAttrs':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/development/libraries/haskell/Cabal/1.14.0.nix:1:1':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:113:20':
while evaluating the attribute `final' at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:114:7':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:9:5':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/stdenv/generic/default.nix:51:24':
while evaluating the attribute `meta.license' at `/home/simons/.nix-defexpr/pkgs/development/libraries/haskell/Cabal/1.14.0.nix:17:5':
infinite recursion encountered
I tried to figure out why this happens, but eventually gave up. The new
implementation passes an argument called 'enableCheckPhase' to the Cabal
builder, which determines whether the user-specified doCheck value has any
effect or not. Now, a normal override can be used to disable unit testing.
The new job set has the following structure:
pkg.ghc762.x86_64-linux = pkgs_x86_64_linux.haskellPackages_ghc762.pkg;
pkg.ghc762.i686-linux = pkgs_i686_linux.haskellPackages_ghc762.pkg;
pkg.ghc6123.x86_64-linux = pkgs_x86_64_linux.haskellPackages_ghc6123.pkg;
pkg.ghc6123.i686-linux = pkgs_i686_linux.haskellPackages_ghc6123.pkg;
This gives us (in theory) the ability to generate a Hydra page that displays
the build status of a package across all versions of GHC and all systems. Right
now, Hydra is not up to it, but Eelco says the feature is "on the todo list".
This file doesn't specify the supported build systems explicitly. Instead, that
information is taken from the respective pkg.meta.platforms attribute.
- rename to zc_builout* while keeping alias back to buildout (opening ticket
later to remove it)
- meta: adding zpl licenses
- meta: adding me maintainer
If you upgrade from 3.7 you might get errors like these:
In the Package Explorer:
Could not create the view: org.eclipse.jdt.ui
And some other stuff in the Error Log; "Unable to resolve plug-in [...]"
The solution is to delete your eclipse workspace (or just the hidden
setting files in there, if you have important user data).
