Running zpaq on an older but not ancient 64-bit Intel server aborts
with an ‘Illegal instruction’ error. Turns out the build expression
was using -march=native to generate distibution binaries...
Change this to more conservative, portable settings which should
cover ‘all’ CPUs. It may run slightly slower — but that at least
implies running.
As a nice side effect, all common compile flags are now back in
`compileFlags` whence they came, and actually used consistently.
http://hydra.nixos.org/eval/1234895
The mass errors on Hydra seem transient; I verified ghc on i686-linux.
Only darwin jobs are queued ATM. There's a libpng security update
included in this merge, so I don't want to wait too long.
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.
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).
Removed path substitutions from setup.py because these should be handled
by the setuptools install prefix.
Except that the install prefix won't quite work until issue #4968 is
resolved.
In the meantime there are preInstall and postInstall scripts so that
this package continues to work with the nix python packaging
improvements.
It's not included in upstream beets but are linked in the documentation
under "Other plugins", see:
http://beets.readthedocs.org/en/v1.3.15/plugins/index.html#other-plugins
I found this one particularly useful for syncing files to varios media
players that refuse to read my FLAC files properly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
After trying with a dozen files, it seems the bs1770gain backend is much
more reliable than the audiotools backend and especially does a better
job (well, compared to audiotools which either does doing nothing at all
or throws an exception) when used on alboms that contain different
sample rates/sizes.
Additionally, we already had a few issues regarding the audiotools
backend, even to the extent that @sampsyco almost wanted to drop it
upstream (see sampsyco/beets#1342).
Also related issues are #10376 and sampsyo/beets#1592.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
When a new version of colordiff is released the old tarball is moved to
the archive directory. This breaks builds until the derivation is
updated to the new version. This commit lets fetchurl know about the
archive URL.
