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 29e89248bfe74ca8d9d539c7ae441f
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 0f38d9669ffd74991b65a9c40cdbcf2a98438d1f, 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
0d2f06ae3a1f8347dc09cd0dfe6d12b757368e4d, 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)
We need to set dontUseImakeConfigure in a few places to prevent imake
from overriding the default configure phase. This packages all have a
configure script that needs to get run:
- Xaw3d
- R
- tkgate
- ssvnc
A few changes needed here:
- We don’t want to guess what our platform is. We can patch location
and targetdir to not put things in an unpredictable directory.
- Make premake4 a native build input.
- Set the premakefile variable.
Adds a configure phase for packages using premake.
premakeConfigurePhase runs the correct premake version for the premake
you are using (see premake_cmd).
Although the tests are passing locally, it seems as the excessive
filesystem usage causes several build failures and timeouts in the Hydra
and OfBorg infrastructure:
* https://hydra.nixos.org/build/84374861 (python3 on linux.x86_64)
* https://hydra.nixos.org/build/84368459 (python2 on linux.x86_64)
Some of these tests are failing after several seconds though, but I
couldn't identify a pattern and I'm not overly surprised that a FTP
library has impure tests. However the API seems to be usable in a Python
{2,3} environment, so it should be safe to use even with disabled tests.
```
b Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy.
```
It seems the "less secure if a crash happens" does not need a crash to
happen.
With batch mode:
```
/[...]/.
Start (0) does not point to parent (___)
```
For pretty much everything copied in.
Without batch mode, everything passes `fsck`.
See #51150
```
b Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy.
```
It seems the "less secure if a crash happens" does not need a crash to
happen.
With batch mode:
```
/[...]/.
Start (0) does not point to parent (___)
```
For pretty much everything copied in.
Without batch mode, everything passes `fsck`.
See #51150
