Arch Linux User Repository

tl;dr This package no longer works on Arch Linux.
Also, the upstream project seems unmaintained.
You may want to start looking for alternatives.

In April 2024, the tensorflow package on Arch Linux was updated to v2.16, which no longer supports the Estimator API.
This means that the spleeter package is no longer working.

Additionally, the upstream project seems to have pivoted to focus their development efforts on Spleeter Pro, leaving Spleeter’s community edition essentially unmaintained.

Given upstream project’s track record of ignoring community contributions including critical bug fixes, I feel that contributing a fix to migrate away from Estimator would be a waste of everyone’s time.

Instead, I recommend everyone to migrate away from Spleeter altogether and to look for alternatives instead.

I’m going to orphan this package after 2024-06-30 so it can be reaped on the AUR’s next Spring cleaning.

@Potajito Not that I know of, but I haven’t done any research yet.

@Auerhuhn is there any alternative/fork for this?

I’m going to orphan this package after 2024-06-30 so it can be reaped on the AUR’s next Spring cleaning.

@Auerhuhn You could also open a deletion request.

tl;dr This package no longer works on Arch Linux.
Also, the upstream project seems unmaintained.
You may want to start looking for alternatives.

In April 2024, the tensorflow package on Arch Linux was updated to v2.16, which no longer supports the Estimator API.
This means that the spleeter package is no longer working.

Additionally, the upstream project seems to have pivoted to focus their development efforts on Spleeter Pro, leaving Spleeter’s community edition essentially unmaintained.

Given upstream project’s track record of ignoring community contributions including critical bug fixes, I feel that contributing a fix to migrate away from Estimator would be a waste of everyone’s time.

Instead, I recommend everyone to migrate away from Spleeter altogether and to look for alternatives instead.

I’m going to orphan this package after 2024-06-30 so it can be reaped on the AUR’s next Spring cleaning.

is there any practical difference?

@xiota It’s just a smaller dependency, no difference other than that.
(The non-core part of poetry is simply not needed for the build.)

Do I need to revise other python packages?

I’d say that’s up to you.
(I did change it in all my packages for consistency’s sake.)

@Auerhuhn python-poetry → python-poetry-core, is there any practical difference? (Do I need to revise other python packages?)

@sekret I also have all passing tests with no mock plugin. While mock and python-mock are not in the PKGBUILD, they are in the poetry.lock file Don't know why/how/whether it changes results.

Not a clean chroot if not cleaned before build. Here's the dependency tree of the AUR packages:

python-ffmpeg-python 0.2.0
python-museval 0.4.0
  python-musdb 0.3.1
    python-stempeg 0.1.8
      python-soundfile 0.12.1
python-norbert 0.2.1

Since the failing tests are for 4stems, if you don't use 4stems, you can build with --nocheck.

@sekret Ok, I tried makechrootpkg -n -r $CHROOT but tests are still passing for me.

I've never used aurutils. It installs the executable /usr/bin/aur, but I don't see the switches -c, -f nor -N.

Apologies for my confusing comment. I was referring to the aur build subcommand. I invoke it from inside the checked-out PKGBUILD directory like so:

aur build -cfN .

and cannot manage to get it running right now. I'll investigate this further another day.

Alright, let me know if and when you get around to it, or if you find another way that allows me to reproduce those failures.

1. I meant those packages spleeter-data-2stems, spleeter-data-4stems and spleeter-data-5stems.
2. No, I haven't done anything besides building and installing the dependencies and then trying to compile it with makechrootpkg -n -r $CHROOT. I haven't used the switch -c (which cleans the chroot before the action) because of the many dependencies, which I then would have to reinstall with the -I switch. It's possible that a makedependency of one of the dependencies causes this.

I've never used aurutils before (afair) and cannot manage to get it running right now. I'll investigate this further another day.

@sekret Cannot reproduce in a clean chroot (using aurutils with -cfN switches).

https://paste.debian.net/1295850/

1. What exactly do you mean by stems data packages?

2. Comparing our logs, I’ve noticed that yours mentions a mock plugin while mine doesn’t. Did you install that plugin manually?