Package Details: mopidy-podcast 3.0.1-1

Git Clone URL: (read-only, click to copy)
Package Base: mopidy-podcast
Description: Mopidy extension for searching and browsing podcasts.
Upstream URL:
Licenses: Apache
Submitter: bjo
Maintainer: MarcinWieczorek (djmattyg007)
Last Packager: MarcinWieczorek
Votes: 7
Popularity: 0.000000
First Submitted: 2015-05-31 18:03 (UTC)
Last Updated: 2024-01-22 17:50 (UTC)

Latest Comments

1 2 Next › Last »

m040601 commented on 2024-02-06 16:19 (UTC)

MarcinWieczorek commented on 2024-01-22 17:51 (UTC)

I updated the version. Would you be so kind to test the package?

Yes I did test. Everything seems to be working perfectly. Thanks for the care and attention.

The last update on is from 2022 by "Thomas Kemmer".

But the tool is very interesting usefull and seems to do what it is supposed to do well.

I have one question.

You might know the answer, if you are nowadays actually using this tool and mopidy.

I was curious to where do the podcasts actually "are" while I am clicking and playinig one ? Does a "real" mp3 or m4a file actually lands on my computer when I am playing ? A physical file that gets cached somewhere of my PC and that I could copy and use offline later ? I guess not. It must be just some megabytes in memory while playing.

I couldnt find any physical file, so I assume this tool and mopidy just plays the stream, and it is in RAM memory (fifo/unix/socket or something) while playing.

It must be just like playing a video from a youtube URL with mpv. If you want to play it again, you have to be online again. Or if you want to save it offline, you have to do it separately, with a download tool (yt-dlp, wget etc).

Am I correct in my guessing ?

MarcinWieczorek commented on 2024-01-22 17:51 (UTC)

I updated the version. Would you be so kind to test the package?

m040601 commented on 2024-01-22 11:12 (UTC)

This PKGBUILD is out of date. It was last touched in 2019.

There is a v3.0.1 tagged version from April 2022,

MarcinWieczorek commented on 2022-01-23 12:58 (UTC)

There you go mate.

djmattyg007 commented on 2022-01-23 11:36 (UTC)

If you don't feel up to this simple annual maintenance task, I'm perfectly willing to take over this package for you (or at least add me as a co-maintainer).

djmattyg007 commented on 2022-01-23 11:35 (UTC)

Another year of waiting for the pkgrel to be bumped. The python3.10 release was over a month ago. Please, just take a look around at the rest of the python packaging ecosystem and follow suit.

MarcinWieczorek commented on 2021-02-14 10:29 (UTC)

I'm not against but not for. Bumping the pkgrel is "nice", but requiring it is not.

The AUR is unsupported, so any packages you install are your responsibility to update, not pacman's. If packages in the official repositories are updated, you will need to rebuild any AUR packages that depend on those libraries.

djmattyg007 commented on 2021-02-13 23:46 (UTC)

It absolutely is a common practice. You only have to look at the sheer number of python packages on the AUR that have their pkgrel bumped in the first 48 hours after a new python release to see that that is the case.

I've been through this many times with other maintainers. There's basically no downside to changing one character in one file to just ensure that everybody has a working version when they update.

The arguments against doing this do not make sense. The argument of forcing people to re-download a tarball is likely moot, as I suspect most people do not keep their downloaded sources after packaging.

Furthermore, the assumption you're making is that absolutely everybody uses a "traditional" AUR helper designed to manage packages on a single system. I use the aurutils AUR helper, which runs a full pacman package repository. I do this because I run several machines with Arch in my house, and I don't want to have to re-package everything multiple times for no reason. This means that if the package version doesn't change, there is nothing to upgrade.

And yes, I'm aware that aurutils probably has a flag or something to force rebuild a package even when the AUR metadata hasn't changed. That doesn't help - I still have to manually go to each machine and forcibly reinstall the package.

Or, you could just change one character in one file, and everybody's lives suddenly become much easier. Please reconsider your stance on this. New major python releases are coming every 12 months now. If you would prefer, I would be happy to step up as a co-maintainer to perform this task each year.

MarcinWieczorek commented on 2021-01-03 09:49 (UTC)

Bumping the pkgrel in AUR is not a common nor required practice. I guess that's because of python 3.9.1? I haven't updated my system yet, but I'll try to remember to bump it. Thank you for flagging iris too, that package will be just pkgver bumped.

djmattyg007 commented on 2021-01-03 01:33 (UTC)

Please could you bump the pkgrel?