This update was generated by hackage2nix v20151217 using the following inputs:
- Nixpkgs: 1e4c0752db
- Hackage: 42db5021ee
- LTS Haskell: 253d4da342
- Stackage Nightly: 57c8505aea
- The patch fixes building against gst-1.6.
- Having to change three files with almost same contents would drive me mad,
so I unified them into a single expression. /cc @ttuegel
- libxslt seemed unneeded, and it uses libxml2 anyway.
In order to increase portability and flexibility, now the build phase
explicitly sets "compiler=c++" as a make parameter.
Further, there is a link "higan" for backwards compatibility; higan was
split in icarus (the game ROMS database manager) and tomoko (the
emulator itself).
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 serves as a regression test, because right now if you enable
networking.useNetworkd the default loopback interface doesn't get
assigned any IP addresses.
To be sure, I have bisected this and it has been introduced with the
update to systemd 228 in 1da87d4.
Only the "scripted" networking tests have to succeed in order to trigger
a channel update of nixos-unstable, so I'm leaving this test as broken
and we have to figure out next what's the *exact* reason for the
breakage.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
The 0.8.4 version of Tomahawk doesn't yet recognize the new taglib
version that has been introduced in b762a20 and fails during
configurePhase.
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>
