While debugging an issue with running NixOps tests, I found out that the
output from debClosureGenerator is not deterministic.
The reason behind this is the way how Provides and Replaces fields are
handled. I haven't yet found out what's the exact issue, but so far
packages "Provides" are more or less picked at random.
So, running the NixOps Hetzner tests we get either mawk, original-awk or
gawk altering on every invocation.
While for the test it isn't poisionous whether wi have mawk or gawk,
having original-awk certainly is, because live-build only works with
mawk or gawk.
The best solution would obviously be to make debClosureGenerator
deterministic, but in the case of "Provides: awk", we can safely pick
mawk by default, because the latter has a "Priority: required" in its
package description.
This also has the advantage that we can safely cherry-pick this to
release-15.09 because it's very unlikely that we'll break the
debClosureGenerator by adding a dependency to commonDebPackages.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Someone submitted conflicting (and non-complete) distro bootconfig
support for the Versatile board, so the patch needs changing, yet again.
But at least it's getting smaller.
As mentioned by @aszlig, it's more elegant and sane to use coreutils'
`install`. This commit also changes `platforms` to `unix` since this
should also compile on Darwin for example.
This update was generated by hackage2nix v20150922-23-g9db0d61 using the following inputs:
- Nixpkgs: 1146c867e3
- Hackage: 1791c0e414
- LTS Haskell: 4622b913dc
- Stackage Nightly: f51b9b1513
I have to admit that I did very poor testing in d7307d8 and didn't
notice that the "badfiles" plugin relies on mp3val (thanks to @devhell
for packaging in 6e1ef13) and flac to be actually useful.
We now patch in the store locations of these binaries and make
"badfiles" an optional dependency (though enabled by default).
Now, I have tested "beet bad" on my whole music collection and it worked
fine (well, it has found errors... but that's what it is for).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We have a mirror:// URL for sourceforge stuff so we can still retreive
the source tarball even if downloads.sourceforge.net is down.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This adds mp3val, which in turn is needed for the beets "badfiles"
plugin.
Thanks a lot to @devhell for packaging.
Built and tested locally by myself as well.
Unfortunately I lost the exact failure, but it was something starting
with 'No rule to make target: ...', which suggests missing dependencies
between generated source files.
Introduces a new plugin called "badfiles", which helps to scan for
corruption within the music collection. I've added this to
pluginsWithoutDeps and sorted the list.
Full upstream changelog can be found here:
https://github.com/sampsyo/beets/releases/tag/v1.3.15
This fixes#10376 via sampsyo/beets@225ba28.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
command : 076a2ad -> 91ca5ec
cache : new
exponential-backoff: new
extractor : new
open-golang : new
pretty-words : new
meddler : new
Update drive and bump/add dependencies
Since I think 2.4 h5py introduced a new way to configure mpi. Therefore,
the BuildFlags are removed.
I built h5py and h5py-mpi packages successfully. Not sure though whether
the mpi version does actually work correctly since I don't use it.
Now we always enable large file support, as it should be cheap enough,
and avoids also problems on some filesystems #10181.
The minimal build disables (almost) all options, so it was building
without large file support. However, in musl the `off_t` is *always*
64-bit, which lead to problems, now detected during build time.
