Arch Linux User Repository

@Kennan Thanks for that! I'm not the maintainer, but found actually the last paragraph in the README (of the repo) says how to contribute: create a PR on github.

So probably you could fork pygospa's package repo on github, replay/apply your changes, and create a PR?

Again, I'm not pygospa, but just reading their instructions. Don't know how quickly they would react. If they don't react in time, I guess maybe you can create another AUR package with a different name (e.g. mopidy4-mpd?) for now; eventually merge that package with this one (or delete that one)?

I added a commit in a local fork that brings it up to version v4.0.0 https://github.com/kennanhunter/mopidy-mpd-aur.

It works locally but if someone can go through and make sure that this is up to AUR standard that would be wonderful, as I've never contributed before.

Thank you!

I created for myself git version PKGBUILD. Since i am no python pro i don't know if it helps but i want to at least give back if i make some changes -> https://paste.rs/vz56C

I haven't used mopidy-mpd since a long time. Maintaining complicated patches here doesn't look feasible to me without actually using the software. I'll disown this package and someone can pick this up then.

Since my latest update, mopidy seized to work on my machine. After some research I figured out that the reason was in mopidy having a changed protocol, while mopidy-mpd still uses the old protocol, passing TlTrack objects instead of integers. In my log I found these statements:

mopidy.exceptions.ValidationError: Expected an integer, not TlTrack(tlid=2, track=Track(album=Album(artists=[Artist(musicbrainz_id=' ...

In the mopidy-mpd repository these are already changed in code, however, the pipeline is in fail mode for the last two months now, and the latest release v3.3.0 is now nearly 3 years old; whereas the main program has had 5 new versions since (the newest from last year December breaking this plugin). So I am not sure if this will still happen, as they are also calling for new maintainers.

In the mean time, this patch fixed my immediate issue; just add it next to the PKGBUILD file:

--- a/mopidy_mpd/protocol/playback.py
+++ b/mopidy_mpd/protocol/playback.py
@@ -221,7 +221,7 @@
     tl_tracks = context.core.tracklist.filter({"tlid": [tlid]}).get()
     if not tl_tracks:
         raise exceptions.MpdNoExistError("No such song")
-    return context.core.playback.play(tl_tracks[0]).get()
+    return context.core.playback.play(tl_tracks[0].tlid).get()


 @protocol.commands.add("previous")

To make it run, it must also be added in the source section of the PKGBUILD

source=("${pkgname}-${pkgver}.tar.gz::https://github.com/mopidy/mopidy-mpd/archive/v${pkgver}.tar.gz" "fix-playid.patch")

and run updpkgsums to add the sha256 for the patch.

I believe the cleanest way would be to check all the method calls; but for me the one line above fixed everyhting I need, and I cannot reproduce the other use cases where the other methods are called. Would be nice, if the patch could be added to this AUR package.

Oh, I was a bit faster than the official packages. Mopidy 3.3.0 has now landed in the repos. Does mopidy-mpd work again now?

FYI The latest revision of this package (3.3.0-1) is not compatible with the mopidy package in the community repository. Mopidy will still boot, but this extension will fail to load with the following warning:

Disabled extension mpd: Mopidy>=3.3.0 required, but found Mopidy 3.2.0 at /usr/lib/python3.10/site-packages

Bumped up the pkgrel to accomodate python 3.10 https://gist.github.com/xadips/bb0a43e8f9b1ee109b96e2e161a00d69

Bumped the version up to the Package update that was released over the last weekend: https://pastebin.com/8rdTkmTU

Could you please bump the pkgrel to force a rebuild for python3.9?