There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
Adding package mp3cat, a command line mp3 utility which will concatenate
multiple mp3 files, and keep only the audio frames, discarding headers
and so on.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
I've introduced the plugin and have been maintaining it ever since, so
it's time to make myself the official maintainer in order to avoid
confusion about who to address when issues about the alternatives plugin
arise.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @wisp3rwind
This introduces the following upstream changes:
* The package is now on PyPI
* Require at least beets v1.4.7
* Update album art in alternatives when it changes
* Python 3 support (Python 2.7 continues to be supported)
* Support the format aliases defined by the convert plugin ('wma' and
'vorbis' with current beets)
* Bugfix: Explicitly write tags after encoding instead of relying on
the encoder to do so
* Bugfix: If the formats config option is modified, don't move files
if the extension would change, but re-encode
I updated this because I was pinged by @wisp3rwind about moving back to
@geigerzaehler's repository at [1].
This is what @wisp3rwind wrote in the comment[2] (which was originally
directed to @Profpatsch):
(I hope you're the one to bug, or at least can ping someone else), I
just noticed that you switched the NixOS package to my repository.
Would you please switch it back to this repo soon-ish? The code here
is better tested, and [3] is handled less elegantly on my fork since
it requires changes to the configuration. The latter are undocumented,
but whoever has bothered to take a look at the code might end up with
(harmless) unused config entries.
So in essence we're now back to the original upstream repository again,
which I changed to @wisp3rwind's fork in 29e89248bf
because it fixed issues with Python 3.
Stripping the long_description from setup.py also doesn't seem to be
required anymore, but I didn't investigate why (might be because either
our Python tooling now sets a default language or the README simply no
longer has non-ASCII characters).
[1]: https://github.com/geigerzaehler/beets-alternatives
[2]: https://github.com/geigerzaehler/beets-alternatives/issues/23
[3]: https://github.com/geigerzaehler/beets-alternatives/pull/27
Signed-off-by: aszlig <aszlig@nix.build>
Since 0f38d9669f, the default Python
version for Python 3 is now Python 3.7.
It has been a while since beets had a new release, but the fix for
Python 3.7 is already in master (and it's also rather small), so I
decided to cherry-pick the commit as a patch.
I've built the package along with its tests and they failed at first,
but the errors were unrelated. So I disabled the tests for pylint, as
they're failing right now.
In addition I also needed to temporarily revert
0d2f06ae3a, which supposedly should fix
issues with Python 2 but aparently breaks Python 3 support and during
the beets tests we get a ModuleNotFoundError for the "_gi_gst" module.
However I didn't further investigate why this happens, as I'm time
constrained right now. But after disabling the pylint tests and the
revert of the mentioned gst-python commit, the beets tests succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jtojnar, @lopsided98 (for introducing the gst-python change)
Cc: @domenkozar, @pjones (other beets maintainers)
The fact that futhark is a Haskell package is an implementation detail. To
install it users should just have to specify `futhark` instead of
`haskellPackages.futhark`.
Additionally futhark is overridden with `haskell.lib.justStaticExecutables` to
reduce closure size.
Since the switch to using python3Packages in commit
72934aa94e, the plugins no longer build
because they end up with a mix of Python 2 and Python 3 packages.
The reason for this is that the Beets package itself uses callPackage to
reference the plugins, however the overrides are not applied there and
thus the plugins end up getting pythonPackages from the top-level which
is Python 2 and beets with Python 3 dependencies.
Unfortunately this is not the only reason for the builds to fail,
because both plugins did not actually support Python 3.
For the copyartifacts plugin, the fix is rather easy because we only
need to advance to two more recent commits from upstream, which already
contain fixes for Python 3.
The alternatives plugin on the other hand is not maintained anymore, but
there is a fork at https://github.com/wisp3rwind/beets-alternatives
which has a bunch of fixes. In 2e4aded366
I already backported one of these fixes to the version from
https://github.com/geigerzaehler/beets-alternatives, but for Python 3
support it's a bit more complicated than just one little fix.
So instead of adding another series of patches which replicate the code
base of the fork and become a maintenance burden, I opted to directly
switch to the fork and remove the patch on our side.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @domenkozar, @pjones, @Profpatsch
The upstream release notes are a bit bigger, so I'm not including it
here. You can find it at:
https://github.com/beetbox/beets/releases/tag/v1.4.7
Originally I wanted to just fix the build, which is currently broken
because a few tests have failed, but the fix for the tests is already
included in the 1.4.7 upstream release[1], so I opted to update instead.
Other than running the tests included in beets (in addition to
building/running tests of the "alternatives" and "copyartifacts"
external plugins) I have made some small queries on my local music
collection, but haven't tested import or any write operation.
[1]: https://github.com/beetbox/beets/commit/8eb50fee33044dea008408423ee
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @domenkozar, @pjones
* treewide: http -> https sources
This updates the source urls of all top-level packages from http to
https where possible.
* buildtorrent: fix url and tab -> spaces
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/abcMIDI/versions.
These checks were done:
- built on NixOS
- /nix/store/4qkyx6if8zsdv2msnpl5i020vc1k2fg1-abcMIDI-2018.06.23/bin/abc2midi passed the binary check.
- /nix/store/4qkyx6if8zsdv2msnpl5i020vc1k2fg1-abcMIDI-2018.06.23/bin/midi2abc passed the binary check.
- /nix/store/4qkyx6if8zsdv2msnpl5i020vc1k2fg1-abcMIDI-2018.06.23/bin/abc2abc passed the binary check.
- /nix/store/4qkyx6if8zsdv2msnpl5i020vc1k2fg1-abcMIDI-2018.06.23/bin/mftext passed the binary check.
- /nix/store/4qkyx6if8zsdv2msnpl5i020vc1k2fg1-abcMIDI-2018.06.23/bin/yaps passed the binary check.
- Warning: no invocation of /nix/store/4qkyx6if8zsdv2msnpl5i020vc1k2fg1-abcMIDI-2018.06.23/bin/midicopy had a zero exit code or showed the expected version
- /nix/store/4qkyx6if8zsdv2msnpl5i020vc1k2fg1-abcMIDI-2018.06.23/bin/abcmatch passed the binary check.
- 6 of 7 passed binary check by having a zero exit code.
- 0 of 7 passed binary check by having the new version present in output.
- directory tree listing: https://gist.github.com/a4a2746a6da64d05744606861cb9987a
- du listing: https://gist.github.com/a08bedfb270cfa58dc555486ba421a75
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/abcMIDI/versions.
These checks were done:
- built on NixOS
- /nix/store/vdps371mlbhdiyp2dijfxfricjm642kc-abcMIDI-2018.06.13/bin/abc2midi passed the binary check.
- /nix/store/vdps371mlbhdiyp2dijfxfricjm642kc-abcMIDI-2018.06.13/bin/midi2abc passed the binary check.
- /nix/store/vdps371mlbhdiyp2dijfxfricjm642kc-abcMIDI-2018.06.13/bin/abc2abc passed the binary check.
- /nix/store/vdps371mlbhdiyp2dijfxfricjm642kc-abcMIDI-2018.06.13/bin/mftext passed the binary check.
- /nix/store/vdps371mlbhdiyp2dijfxfricjm642kc-abcMIDI-2018.06.13/bin/yaps passed the binary check.
- Warning: no invocation of /nix/store/vdps371mlbhdiyp2dijfxfricjm642kc-abcMIDI-2018.06.13/bin/midicopy had a zero exit code or showed the expected version
- /nix/store/vdps371mlbhdiyp2dijfxfricjm642kc-abcMIDI-2018.06.13/bin/abcmatch passed the binary check.
- 6 of 7 passed binary check by having a zero exit code.
- 0 of 7 passed binary check by having the new version present in output.
- directory tree listing: https://gist.github.com/1bacbc0e094f32d6579ecca45ec92dc1
- du listing: https://gist.github.com/8b31f54a9e4b0cda7274d402fe6eda18
Lots of packages are missing versions in their name. This adds them
where appropriate. These were found with this command:
$ nix-env -qa -f. | grep -v '\-[0-9A-Za-z.-_+]*$' | grep -v '^hook$'
See issue #41007.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/abcMIDI/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/abc2midi -h’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/midi2abc -h’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/midi2abc --help’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/abc2abc -h’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/mftext -h’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/mftext --help’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/mftext help’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/yaps -h’ got 0 exit code
- ran ‘/nix/store/cw3374p08xihakpimdka1afpa8s0kqh9-abcMIDI-2018.05.02/bin/abcmatch -h’ got 0 exit code
- directory tree listing: https://gist.github.com/ab3313bb3097bf194e4ac83d6cc0b9bc
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/abcMIDI/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/abc2midi -h’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/midi2abc -h’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/midi2abc --help’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/abc2abc -h’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/mftext -h’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/mftext --help’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/mftext help’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/yaps -h’ got 0 exit code
- ran ‘/nix/store/s7dh3851ix5avzik864jz5abrswrmf8z-abcMIDI-2018.04.24/bin/abcmatch -h’ got 0 exit code
- directory tree listing: https://gist.github.com/d75d63bae2db4467af91a891a9a1b597
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/playerctl/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/p0qhcjwl78w4rwdqwkh7zzifpc2v60p3-playerctl-0.6.0/bin/playerctl -h’ got 0 exit code
- ran ‘/nix/store/p0qhcjwl78w4rwdqwkh7zzifpc2v60p3-playerctl-0.6.0/bin/playerctl --help’ got 0 exit code
- ran ‘/nix/store/p0qhcjwl78w4rwdqwkh7zzifpc2v60p3-playerctl-0.6.0/bin/playerctl -v’ and found version 0.6.0
- ran ‘/nix/store/p0qhcjwl78w4rwdqwkh7zzifpc2v60p3-playerctl-0.6.0/bin/playerctl --version’ and found version 0.6.0
- found 0.6.0 with grep in /nix/store/p0qhcjwl78w4rwdqwkh7zzifpc2v60p3-playerctl-0.6.0
- directory tree listing: https://gist.github.com/0d015359b346703f7434ab698e4ad496
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/abcMIDI/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/abc2midi -h` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/midi2abc -h` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/midi2abc --help` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/abc2abc -h` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext -h` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext --help` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext help` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext -V` and found version 2018.03.21
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext -v` and found version 2018.03.21
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext --version` and found version 2018.03.21
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext -h` and found version 2018.03.21
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/mftext --help` and found version 2018.03.21
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/yaps -h` got 0 exit code
- ran `/nix/store/21xl9z5m4rag6rhc5jhy3ik15vdzj8dd-abcMIDI-2018.03.21/bin/abcmatch -h` got 0 exit code
- directory tree listing: https://gist.github.com/4a5c8556345e7bb0a99964ec83e3384b
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/abc2abc -h` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/abcmatch -h` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext -h` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext --help` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext help` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext -V` and found version 2018.03.08
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext -v` and found version 2018.03.08
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext --version` and found version 2018.03.08
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext -h` and found version 2018.03.08
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/mftext --help` and found version 2018.03.08
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/yaps -h` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/abc2midi -h` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/midi2abc -h` got 0 exit code
- ran `/nix/store/3r7nwg28yy402gl01m9b14h5j865365g-abcMIDI-2018.03.08/bin/midi2abc --help` got 0 exit code
Semi-automatic update. These checks were performed:
- built on NixOS
- ran `/nix/store/57kxxdmzd8k758sj5fsc430cq54dzr4f-mpdas-0.4.5/bin/mpdas -h` got 0 exit code
- ran `/nix/store/57kxxdmzd8k758sj5fsc430cq54dzr4f-mpdas-0.4.5/bin/mpdas -v` and found version 0.4.5
- ran `/nix/store/57kxxdmzd8k758sj5fsc430cq54dzr4f-mpdas-0.4.5/bin/mpdas -h` and found version 0.4.5
- found 0.4.5 with grep in /nix/store/57kxxdmzd8k758sj5fsc430cq54dzr4f-mpdas-0.4.5
- found 0.4.5 in filename of file in /nix/store/57kxxdmzd8k758sj5fsc430cq54dzr4f-mpdas-0.4.5
cc "@taketwo"
Since the bump of beets to version 1.4.6 in e5fab33efd
the tests no longer run successfully because beets 1.4.6 introduces a
breaking API change for the Item.move() method which now instead of just
passing copy=True the operation is now passed using a different
"operation" keyword argument.
Unfortunately the original repository of beets-alternatives is
unmaintained since 3 years and thus there is no upstream fix available
at the moment.
However, there is a fork maintained by @wisp3rwind, which addresses this
problem (wisp3rwind/beets-alternatives@33c6525ed4)
and a bunch of other fixes.
The reason why I'm not using the patch from @wisp3rwind is that it
simply doesn't apply against beets-alternatives 0.8.2, but my patch here
essentially does the same.
Signed-off-by: aszlig <aszlig@nix.build>
Upstream issue: geigerzaehler/beets-alternatives#13
Cc: @Profpatsch
In order to run the tests for the external plugins of beets, we need to
have beets itself as a dependency. So in order to do that, we now pass
beets without plugins and tests to the nativeBuildInputs of the plugins
so that we can run them.
As soon as the plugins are built they become part of the final beets,
which also has tests enabled, so disabling the tests for beets
derivation that is used for external plugin tests is a non-issue here
because they're going to be executed anyway.
Enabling tests for the alternatives plugin is pretty straightforward,
but in order to run tests for the copyartifacts plugin, we need to bump
the source code to the latest Git master.
The reason for this is that the version that was in use until now
required to have the beets source directory alongside of the
copyartifacts source code, but we already have beets available as a
normal dependency.
Updating copyartifacts to latest master largely consists of unit test
changes and a few Python 3 compatibility changes. However, one change
has the biggest stat, which is
sbarakat/beets-copyartifacts@1a0c281da0.
Fortunately, the last change is just moving the implementation to a
newer API from upstream beets and by the looks of the implementation it
seems to break support for moving files. However, reverting this commit
also reveals that moving files was already broken before, so it wouldn't
matter much whether we have this version bump or not.
Tested with the following command:
nix-build -E '(import ./. {}).beets.override {
enableAlternatives = true;
enableCopyArtifacts = true;
}'
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @domenkozar, @pjones, @Profpatsch, @michalrus
Regression introduced by 94351197cd.
Running the tests results in the following traceback:
...
File ".../unittest/loader.py", line 91, in loadTestsFromName
module = __import__('.'.join(parts_copy))
File ".../test/regrtest.py", line 184, in <module>
for module in sys.modules.itervalues():
RuntimeError: dictionary changed size during iteration
The reason for this is that the test directory itself is called "test"
and the package including regrtest.py is also called "test", so the
loader tries to load tests from its own implementation.
We could fix this by changing PYTHONPATH and/or making the test
directory a proper package, but we'd still have failing tests because
beets itself is required to run the tests.
However for now I'm just removing the unit_tests kwarg in setup.py so
that we have the same behaviour as before the initially mentioned
commit.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
* ultrastardx-beta: init at 1.3.5
* libbass, libbass_fx: init at 24
* ultrastar-creator: init at 2017-04-12
* buildSupport/plugins.nix: add diffPlugins
Helper function to compare expected plugin lists to the found plugins.
* ultrastar-manager: init at 2017-05-24
The plugins are built in their own derivations, speeding up (re-)compilation.
The `diffPlugins` function from `beets` is reused to test for changes in the
plugin list on updates.
* beets: switch to diffPlugins
The function is basically just extracted for better reusability.
The package included outdated intltool makefiles, resulting in installation of
local files to `$out/'@DATADIRNAME'`. Running `intltoolize -f` forces
regeneration of the Makefile and fixes the issue.
So this was suggested as [long ago as October, 2015](https://github.com/NixOS/nixpkgs/issues/10376#issuecomment-147734898).
Despite being fairly ignorant of the nix Python support, I decided
that I really wanted this; this change brings in what I believe are
the necessary components---I have, at least, successfully run `beet
replaygain` and `beet bpd`---but it may not do it in the best way; I'm
happy to consider input on that front.
I can at least state that all three changes are necessary---leave any
one of them out and gstreamer support doesn't work.
This largely reverts commit 599312739e.
The main reason is that it breaks the plugins, because the mentioned
commit didn't change the attributes for the plugins as well.
But instead of just fixing the attributes when we import the plugin
packages, let's just override pythonPackages in all-packages.nix.
Right now, Beets is in transition to Python 3, so we don't need to wait
that long until we can remove the dependency on Python 2:
https://github.com/beetbox/beets/releases/tag/v1.4.1
Once Python 3 support is no longer beta, we can just change this by
changing one line only instead of several.
Tested this by building beets with both external plugins.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @FRidh
Full upstream release announcement:
https://github.com/beetbox/beets/releases/tag/v1.4.1
I had to rebase the keyfinder-default-bin.patch in order to apply with
the new release.
Other than that I didn't test whether beets works on my machine, as I
have a more or less temporary setup at the moment.
However, since the bump of mutagen to version 1.34 in commit
555928c228, the mediafile tests fail and
thus this commit unbreaks beets.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The top-level attribute has been removed in commit
771ed59b48.
This has been partially resolved in commit
18bdd44729.
The latter change however only addressed the main derivations but missed
out on the plugins. This is now done by just passing pythonPackages down
the chain.
Tested by only evaluating the expression, not building.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @domenkozar, @pjones, @profpatsch
See #11567.
Furthermore, it renames pythonPackages.dbus to pythonPackages.dbus-
python as that's the name upstream uses.
There is a small rebuild but I couldn't figure out the actual cause.
The echonest plugin was removed in 3.18 because the API it used is
shutting down. You might want to try the acousticbrainz instead.
Update pluginsWithoutDeps as needed to keep preCheck working.
This patches the ffmpeg command path so that it will work without ffmpeg
being in the user's current path. The commit contains a suggestion from
me to patch command_output() instead of just replacing "ffmpeg" so that
if a user configuration alters the default commands it will still work.
The default convert configuration invokes ffmpeg, so this patches in the
right storepath. Since it patches the shlex split, even user config will
use the correct path. kudos @aszlig.
The reason why the completion tests didn't pass was because we had it
already disabled in 2acc258dff.
Meanwhile, beetbox/beets@a07cb83 has moved the file from
test/test_completion.sh to test/rsrc/test_completion.sh.
So this has silently re-enabled the completion tests, which we need to
investigate on our side why they failed in the first place.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This improves our Bundler integration (i.e. `bundlerEnv`).
Before describing the implementation differences, I'd like to point a
breaking change: buildRubyGem now expects `gemName` and `version` as
arguments, rather than a `name` attribute in the form of
"<gem-name>-<version>".
Now for the differences in implementation.
The previous implementation installed all gems at once in a single
derivation. This was made possible by using a set of monkey-patches to
prevent Bundler from downloading gems impurely, and to help Bundler
find and activate all required gems prior to installation. This had
several downsides:
* The patches were really hard to understand, and required subtle
interaction with the rest of the build environment.
* A single install failure would cause the entire derivation to fail.
The new implementation takes a different approach: we install gems into
separate derivations, and then present Bundler with a symlink forest
thereof. This has a couple benefits over the existing approach:
* Fewer patches are required, with less interplay with the rest of the
build environment.
* Changes to one gem no longer cause a rebuild of the entire dependency
graph.
* Builds take 20% less time (using gitlab as a reference).
It's unfortunate that we still have to muck with Bundler's internals,
though it's unavoidable with the way that Bundler is currently designed.
There are a number improvements that could be made in Bundler that would
simplify our packaging story:
* Bundler requires all installed gems reside within the same prefix
(GEM_HOME), unlike RubyGems which allows for multiple prefixes to
be specified through GEM_PATH. It would be ideal if Bundler allowed
for packages to be installed and sourced from multiple prefixes.
* Bundler installs git sources very differently from how RubyGems
installs gem packages, and, unlike RubyGems, it doesn't provide a
public interface (CLI or programmatic) to guide the installation of a
single gem. We are presented with the options of either
reimplementing a considerable portion Bundler, or patch and use parts
of its internals; I choose the latter. Ideally, there would be a way
to install gems from git sources in a manner similar to how we drive
`gem` to install gem packages.
* When a bundled program is executed (via `bundle exec` or a
binstub that does `require 'bundler/setup'`), the setup process reads
the Gemfile.lock, activates the dependencies, re-serializes the lock
file it read earlier, and then attempts to overwrite the Gemfile.lock
if the contents aren't bit-identical. I think the reasoning is that
by merely running an application with a newer version of Bundler, you'll
automatically keep the Gemfile.lock up-to-date with any changes in the
format. Unfortunately, that doesn't play well with any form of
packaging, because bundler will immediately cause the application to
abort when it attempts to write to the read-only Gemfile.lock in the
store. We work around this by normalizing the Gemfile.lock with the
version of Bundler that we'll use at runtime before we copy it into
the store. This feels fragile, but it's the best we can do without
changes upstream, or resorting to more delicate hacks.
With all of the challenges in using Bundler, one might wonder why we
can't just cut Bundler out of the picture and use RubyGems. After all,
Nix provides most of the isolation that Bundler is used for anyway.
The problem, however, is that almost every Rails application calls
`Bundler::require` at startup (by way of the default project templates).
Because bundler will then, by default, `require` each gem listed in the
Gemfile, Rails applications are almost always written such that none of
the source files explicitly require their dependencies. That leaves us
with two options: support and use Bundler, or maintain massive patches
for every Rails application that we package.
Closes#8612
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>
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
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>
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>
The configure script requires libogg in both the paths of libopus and
libvorbis. Because is isn't true for the libopus and libvorbis
derivations in NixOS and patching the configure script is a bit tedious,
a temporary environment with libogg, libvorbis & libopus is used.
I presume there's something about how github creates the .zip files such
that they can change SHA.
Please note: this is a very outdated version of pasystray---I don't know
if that's intentional, but perhaps a better strategy would be to update
it wholesale.
We're passing glibcLocales to the tests directly, so we don't pollute
the builder's environment anyway, so no reason to override anything
there.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I know, I know, this is me being ultra-nazi about those things, but
beets is about OCDing your music collection, so why not apply this to
the Nix expressions as well?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We can now finally drop the mediafile and test fix patches, because they
were already coming from the upstream repository and are now included in
the release.
Also, this release brings two new plugins:
* permissions: Fix permissions on music files as they are imported.
* plexupdate: Notify a Plex server when the database changes.
The echonest_tempo plugin has finally been removed and so we can drop it
entirely. No plugin as of now tries to do interactive prompts on "beet
config" anymore, so we can test *all* plugins and without providing
dummy options.
The full list of changes can be found here:
https://github.com/sampsyo/beets/releases/tag/v1.3.10
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
See, that's why I hate the gregorian calendar and new years eve: People
tend to celebrate things that are absolutely irrelevant, like this
comment.
The test however assumed that either beets or its test suite would never
survive 2015, so this test should assure it won't survive in >= 2015 :-)
Anyway, the patch is from upstream master, so we can drop it once 1.3.10
is released.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Beets tries to load oll activated plugins on "beet config -e" (however
only on the second run, thus the dummy), so we just pass all activated
plugins into a generated config file and bail out on any errors.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason for doing this is in order to not forget about possible
dependencies in new upstream releases, so if upstream is introducing a
new plugin where we're lacking dependencies, the build will fail on our
side and we can check whether we'll need those.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using commands such as mp3gain and aacgain is only the default for
backwards-compatible reasons. However, on Nix(OS), we would have to
either patch those tools into beets or rely on an impurity, so let's
depend on audiotools and also default to that backend.
Of course, there is also a GStreamer backend, but it comes with a hell
of additional dependencies (which not only cover audio files), which is
why I decided against defaulting to GStreamer and package audiotools
instead (in eecd932).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This also fleshes out/fixes the unit tests, which I've used for
gathering the individual requirements.
Along various Python dependencies we now also have a build-time
dependency on bashInteractive and a runtime dependency on
bashCompletion, which is needed for command line completion to work
correctly.
However, some tests for the shell completion fail at the moment, so I've
disabled them for now.
The patch for fixing mediafile codec info is a modified version of
sampsyo/beets@903e88a, where I just dropped the second hunk modifying
the changelog. It is already merged to master and thus expected to be in
the next upstream version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason for doing this is because the package on PyPI is missing some
files needed for running the test suite (for example:
test/test_completion.sh).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The primary use of beets is not as a Python library and users usually
would expect to install it into the env using "nix-env -i beets" rather
than "nix-env -i pythonX.Y-beets".
Having beets in its own package directory also allows for better
customization, where we're going to implement attributes that can be
used to turn on/off various features and plugins.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is the commandline tool for interacting with the chromaprint
library and it's needed for Picard version 1.2 (as it no longer has
support for AmpliFIND/PUIDs).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
