Page MenuHomeSolus

GNOME Podcasts
Closed, LockedPublic


Name - GNOME Podcasts

Homepage -

Why should this be included in the repository? - There is currently two podcast apps in the Solus SC. One is called Vocal, built for Elementary OS, but is distro agnostic. However it has been very buggy since its release and crashes/freezes constantly. There is also gPodder which is a great app, however it only downloads podcasts, it does not have the ability to play podcasts within the app. I propose including GNOME Podcasts into the Solus repos because it allows you to download and play podcasts all in the app, and it works just fine under my testing. GNOME Podcasts is also currently under active development as recently as yesterday.

Is it Open Source - YES

Who and how many users do you anticipate will use this software? - More and more people listen to podcasts, roughly 1/3 of Americans listen to podcasts monthly. Over 100 million people listen to podcasts each year in America alone. Now how many of those people are Solus users? I don't know, but I can say those that are Solus users, at least 25% or more of them would listen to podcasts and that is why I would like GNOME Podcasts added to the repos. If I had to pull a number out of my hat, I'd say 100 to 1,000 people might use this app.

Link to source tarball/zip file -

Related Objects

Duplicates Merged Here
T8133: GNOME Podcasts

Event Timeline

JoshStrobl updated the task description. (Show Details)Aug 31 2018, 3:22 PM
JoshStrobl added a subscriber: JoshStrobl.

at least 25% or more of them would listen to podcasts and that is why I would like GNOME Podcasts added to the repos

Not really sure where you'd get this number.

In terms of it being called "GNOME Podcasts", it's mildly infuriating given the repo is technically "hammond", so I'd like clarification from upstream as to what they intend to call it, and make sure it's consistent.

JoshStrobl renamed this task from PKG REQ - GNOME Podcasts to GNOME Podcasts / Hammond.Aug 31 2018, 3:23 PM
JoshStrobl triaged this task as Needs More Info priority.
JoshStrobl moved this task from Backlog to Awaiting Package Upgrades on the Package Requests board.

Moving to Awaiting Package Upgrades pending clarification from any upstream dev on intended name and shifting things to be consistent.

tristan957 added a comment.EditedOct 29 2018, 2:35 AM

This is going to require Solus to upgrade GTK to 3.24.1 due to dependency on libhandy

DataDrake renamed this task from GNOME Podcasts / Hammond to GNOME Podcasts.Dec 27 2018, 8:35 PM
DataDrake lowered the priority of this task from Needs More Info to Wishlist.
DataDrake updated the task description. (Show Details)
DataDrake added a project: Needs Maintainer.
stigarn claimed this task.Mar 16 2019, 7:50 AM
Jacalz added a subscriber: Jacalz.
JoshStrobl removed stigarn as the assignee of this task.Mar 16 2019, 11:24 AM
JoshStrobl added a subscriber: stigarn.

@stigarn I will package this when we move to the GNOME 3.32 stack.

JoshStrobl closed this task as Wontfix.Apr 19 2019, 11:06 AM

This isn't going to land. It requires libhandy, which is not only a library with a currently unstable API/ABI, but entirely oriented towards mobile UX. I find it entirely unacceptable to start requiring mobile UX libraries for desktop applications, or applications which in our case will only be used in a laptop / desktop environment.

I can maybe understand not including it due to the unstable nature of its development, but I am not sure I understand why a libhandy dependency should block Podcasts and Fractal inclusion entirely. By blocking libhandy, hobby developers can't use it easily and GNOME contributors will be unable to easily develop parts of the applications that use it. Is there any way that this decision can be reconsidered at a 1.0.0 release of libhandy? Adding to this, many of the C-based GNOME projects like GCC have Meson options for disabling libhandy support entirely. You seem to be ragging on Podcasts and Fractal for wanting to reach users on various platforms. I agree that projects should probably try to have some form of option to not include the mobile support UI elements, but this seems like more of a personal preference than one that should be enforced on all users of Solus. You can see that I have tried my hand at packaging this (libhandy, Fractal) in the past, so there are people invested in its inclusion. It is just a little baffling to me that web wrappers are good to go in the repository (Discord, etc.), but a desktop application with mobile support at small sizes is not.

Typically, we prefer stable tagged releases. However, this may be waived if:
The software has significant traction (i.e. prerelease)
A bug fix only exists beyond the latest stable release for a git source

This project is gaining traction with GNOME including it in essential applications albeit more geared toward mobile friendly UIs. But here I also concede the unstable API/ABI of the library. It does not seem right to force rebuilds of reverse deps every time this project is updated.

The value added by both Podcasts and Fractal is very high. Podcasts (the media) are extremely popular among people these days. Currently I see 2 desktop podcast clients within the repo: Vocal and GPodder. Never used either of them, but Podcasts get the nod for being endorsed enough by GNOME to be included on their website To do that, I believe the application has to be fairly conformant to GNOME HIG, which is an obvious value add for people who want a consistent look and feel across their desktop. GPodder for instance sticks out like a sore thumb. On to Fractal. Fractal has the most value add of either of the two. The only Matrix client I can find within the repo is Riot. Riot is an electron application. Electron applications are a poor man's attempt at cross-platform support. Because Riot is an Electron application, support for theming is extremely lacking and it sticks out like a sore thumb. Fractal on the other hand is again referenced by GNOME at It also follows GNOME's HIG (assuming my hypothesis is correct). There is no GTK native alternative that I can find in the repo.

Solus team members reserve the right to permanently reject a package request without the need for further discussion once the rejection is issued. The limited time of contributors should be considered and respected, instead of dragging out and ‘necromancing’ old issues in a vain attempt to force inclusion of previously rejected software. In the event of any policy change, existing/expired package requests will NOT be reevaluated under new criteria as this would lead to an exponential growth in work upon every policy change, and is physically impossible to handle for a project of any size.

I think that this point should be clarified. At the current moment, there are 3 members on the core team and 4 global maintainers. Is it possible to bring contested opinions like this to a vote? Surely not everyone shares the same opinion. If this policy continues to stand, it should be specifically mentioned in the Package Inclusion Policy. Additionally, the scope should be expanded to ban any packages that include Kirigami, but don't allow maintainers to disable the dependency. To my surprise I found that Kirigami is already packaged for Solus at, so this entire situation requires clarification because if KDE applications which require Kirigami are allowed (ie Plasma's System Settings), then Podcasts and Fractal should be allowed in as well following API/ABI stability of libhandy. I understand one is required for a desktop environment to run, and the others are non-essential.

In summary, please consider this a petition for any application that will make use of libhandy now or in the future to be moved to "Blocked for Inclusion" until libhandy reaches API/ABI stability. This policy purposefully gimps application adoption purely because the developers want their application used on both Mobile and Desktop platforms. For reference libhandy widgets only change when the content no longer fits on the screen. Here are screenshots of both Fractal and Podcasts which obviously show that they are Desktop-oriented applications with the benefit of being usable on a mobile platform in the future (ie Librem 5). It isn't like these applications thrust the user into a mobile UX. The user has to purposefully decrease the window size to see libhandy at work.

Our personal preferences are precisely what makes Solus what it is. We have chosen not to include GNOME Podcasts and ask that you please respect our wishes. Solus is not a democracy. Our pragmatic approach to package inclusion allows us to keep the repo small and our efforts focused. Thank you.

I am aware of all this. I asked for a democracy amongst the powers that be. Not the users like myself. I am not sure how any of what I wrote could be disrespectful. I am merely questioning something which seems like a weird hill to die on, not including a package merely because it depends on libhandy.

Is there any documentation on running a custom Solus repo?

JoshStrobl changed the task status from Wontfix to Locked.EditedApr 25 2019, 1:07 AM

Is there any documentation on running a custom Solus repo?

We should have comprehensive ferryd documentation once the rewrite is complete. Regardless that is off-topic to this matter.

Democracy between Team members is not relevant here. You'll be hard pressed to find anyone on the team that would disagree with my decision on the matter. There has never been any instance where the Solus Team has needed to have some sort of democratic vote, because we are sensible enough to recognize each other's strengths and knowledge in various fields. Whether that's DataDrake knowledge on various infra and tooling, Peter on performance optimizations and testing, Girt on Plasma and KDE, kyrios on MATE, joe on dmd and various matters around that toolchain, ermo on samba+kodi+other media server matters, or myself when it comes to GNOME and Budgie.

I'm locking this issue. There is not a single application which requires libhandy that is going into the repo, and items like Contacts which now require it are being removed with this stack upgrade. This matter is not up for debate, it isn't an interpretation of our vision for the project, the existence of those applications with libhandy directly conflict with it. If you disagree, you are welcome to package them for yourself, or use them via Flatpak.

This task has been locked.