Add it to the generator script (generate-expr-from-tarballs.pl) and then
add the updated generated file (pkgs/servers/x11/xorg/default.nix) after
performing the steps outlined in the generator script.
NOTE: People seem to have updated .../default.nix manually (even though
it has a "THIS IS A GENERATED FILE. DO NOT EDIT!" header), so I had to
skip some changes to not downgrade several packages.
The configure script tries to probe whether /var/run exists when
determining the location for the pid file, which is not very nice when
doing chroot builds. Just set it explicitly to avoid the problem.
For reference, the culprit in configure.ac:
````
piddir=/var/run
if test ! -d $piddir ; then
piddir=`eval echo ${sysconfdir}`
case $piddir in
NONE/*) piddir=`echo $piddir | sed "s~NONE~$ac_default_prefix~"` ;;
esac
fi
AC_ARG_WITH([pid-dir],
[ --with-pid-dir=PATH Specify location of ssh.pid file],
...
````
Also, use the `install-nokeys` target in installPhase so we avoid
installing useless host keys into $out/etc/ssh and improve built purity
as well.
This update was generated by hackage2nix v20151217-3-gd4ae18a using the following inputs:
- Nixpkgs: 236677809b
- Hackage: 62b6b580fb
- LTS Haskell: d3e5ae70f9
- Stackage Nightly: ef03f60b53
Two reasons for this change:
- most of 5.0 packages don't build yet
- node packages are memory intensive and block Hydra evaluation
(Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS)
PS: Removing node packages from evaluation goes from 7.5G down to
4.6G for whole nixos release job.
See #3594 and #11865
Relevant changes:
- Python version switched to Python 3
- ssdeep library got replaced with tlsh
- the 'magic' Python package got replaced with a different one
- Minor build system improvements == less work for us
Currently, building RPM with `python = python3` causes this:
checking for a Python interpreter with version >= 2.6... python3
checking for python3... /nix/store/dykqxnrwiz9drlcv2wy8lpvl3xvklx0g-python3-3.4.3/bin/python3
checking for python3 version... 3.4
checking for Python.h... yes
checking for library containing Py_Main... no
configure: error: missing python library
That comes from this snippet in configure.ac:
AC_SEARCH_LIBS([Py_Main],[python${PYTHON_VERSION} python],[
WITH_PYTHON_LIB="$ac_res"
],[AC_MSG_ERROR([missing python library])
])
So it's looking for (e.g) `libpython3.4.so` wheras we have `libpython3.4m.so`.
Patching the configure script to match seems to make that work (although
I don't really understand what the heck is this 'm' business about).
