On 2025-12-09 10:01:22 +0100, Andreas Tille wrote: > Hi Sebastian, > > Am Tue, Dec 09, 2025 at 09:25:00AM +0100 schrieb Sebastian Ramacher: > > > > So, are you becoming the upstream? > > No. > > > If not, uploading it with the team as > > maintainer we give the wrong impression that this package is still > > maintained. > > I intend to maintain the existing codebase within Debian. To give a > concrete example: Bug #1112231 - mp3splt-gtk: Depends on deprecated > dbus-glib - is clearly an issue that ideally should be solved upstream. > As Debian maintainer of the package I see my responsibilities as: > > 1. Tagging the issue upstream (which I just did). > > 2. Ensuring that the package does not block progress inside Debian (for > example, if mp3splt-gtk prevents removal of dbus-glib, I would take > care of removing the GUI component while keeping the CLI tool > functional, if feasible). > > > A prospective maintainer needs to also take up upstream > > maintenance. > > There are many packages in Debian with inactive upstreams that are still > maintained on the Debian side. Could you clarify what you expect in > practice under "take up upstream maintenance"? > > For instance, do you mean creating new releases, rewriting parts of the > codebase, or something else?
mp3splt has three open CVEs from 2017 (!). Going through the issues reported at https://github.com/mp3splt/mp3splt/issues, there are even more reports on crashes (not even counting all the issues where the package produces broken output). Fixing/traiging those would reasonably fall under "taking over upstream maintenance". So if you are not becoming upstream, then I think we and our users are better served by removing this package. A code base with open CVEs that is expected to handle potentially untrusted files and no upstream maintainer falls IMHO below the quality threshold that we can expect from Debian packages. Cheers -- Sebastian Ramacher
