Your message dated Mon, 15 Dec 2025 11:42:35 +0100
with message-id <[email protected]>
and subject line Re: Bug#1122194: ITS: mp3splt
has caused the Debian Bug report #1122194,
regarding Should mp3splt be removed from Debian?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1122194: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1122194
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: mp3splt
Version: 2.6.2+20170630-3.4
Severity: important
X-Debbugs-Cc: [email protected], Debian Multimedia Maintainers
<[email protected]>, Ron Lee <[email protected]>, Package
Salvaging Team <[email protected]>
Hi Ron,
I would be interested in helping with mp3splt, following the Package
Salvaging procedure outlined in the Developers Reference[1]. From what I
see, the package seems to meet the criteria for this process, and I'd
like to support keeping it maintained in Debian. As the Salvage process
suggests, here is a list of the criteria that I believe apply:
- NMUs (more than one NMU in a row).
- Bugs filed against the package do not have answers from the
maintainer.
- There are QA issues with the package.
I believe the package would be a great addition to the Multimedia team,
and I took the liberty to create the Salsa repository here[2]. If you
choose not to accept the ITS, I'd be more than happy to help you move it
to another location, such as debian/, or wherever you prefer. My goal is
to make it as easy as possible for you to join the team. I'd also be
delighted to assist in adding you as a team member if you could share
your Salsa login.
This package was highlighted in the Bug of the Day[3] initiative, which
aims to introduce newcomers to manageable tasks and guide them through
the workflow to solve them. The focus of this initiative is on migrating
packages to Salsa, as it's a great way to help newcomers become familiar
with a consistent Git-based workflow.
Kind regards
Andreas.
[1]
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://salsa.debian.org/multimedia-team/mp3splt
[3] https://salsa.debian.org/qa/tiny_qa_tools/-/wikis/Tiny-QA-tasks
-- System Information:
Debian Release: forky/sid
APT prefers testing
APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5,
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.38+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=sh: 0: getcwd() failed:
No such file or directory
UTF-8), LANGUAGE=de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
[Closing the bug asking whether removal makes sense.]
Hi Ron,
first of all, thank you for taking the time to explain your perspective
and for having maintained this package over the years. Your description
of its maintenance model helped me understand the background much better.
Am Sun, Dec 14, 2025 at 08:25:58PM +1030 schrieb Ron:
> mp3splt is one of those tools that has a fairly narrowly defined job, that
> you don't generally need to do every day, but when you do need to do it,
> there really isn't any other tool made to do that job (or at least wasn't
> at the time I needed and revived it, and I'm not off the cuff aware of any
> change to that since).
Fully agreed. I was not aware of mp3splt before encountering it via the
Bug of the Day, and my attempt to work on it was made in good faith and
out of genuine interest in the functionality it provides.
> Since then, we've all got older and busier, and the mp3 container format
> is no longer as commonly used as it was, though there are still plenty of
> them in existence and I don't expect that to change any time soon.
>
> So this package hasn't got the sort of attention that it might if it was
> something that had everyday use, or if I was the sort of person with so
> much spare time on my hands that I was itching for busywork to do which
> would have near to no real world consequence - and I'm very grateful to
> the people who have stepped up from time to time to upload some improvement
> to it that scratches some itch of their own.
My motivation was to contribute to such a package by improving its Debian
packaging and by trying to put it on a footing that allows occasional,
collaborative maintenance when needed. From my experience, having a shared
Git repository on Salsa with more than one involved person often lowers
the barrier for exactly this kind of episodic maintenance.
> And I know we have the deletionists who think that kind of existence is
> intolerable - but I know for sure that if I turn out to be the next person
> who needs this, I'd be very glad to find the seed of what I need already
> available, even if it needs a little sun and water to make it germinate
> again.
Just to be clear from my side: my original intention was never to argue for
removal. On the contrary, I picked up the package because I consider it
useful and worth keeping available to Debian users. The question of
removal only arose later in the context of an RC bug about open CVEs and
their visibility to users, not because I consider the package itself
obsolete.
> So if someone else wants to officially make themselves an uploader of this
> then good contributions to it will be very welcome.
Thank you for clarifying this. I take this as confirmation that my
interest in the package, as expressed by commit 00e8654a[1], is welcome
in principle, even if you disagreed with the way the process started.
I have reverted that commit for now. Given the concerns raised in the
discussion, I preferred to step back from this change until there is a
shared understanding of the desired maintenance model.
> If they don't, and it
> still exists in the repo the next time that I am that person, and I'm still
> one if its listed uploaders, then I'll share my work with everyone else
> by uploading it.
My intention was explicitly to keep you listed as an uploader, unless you
ask to be removed. I see this as a way of respecting and supporting people
who have already invested time and knowledge into the package.
> ...
> Surely knowledge must precede any declaration of intent?
I fully agree. What I intended to contribute was primarily Debian
packaging work: fixing an open bug, addressing some issue in the
upstream code (58f5e844), and updating metadata (including licensing
information that was incomplete). I hope this demonstrates a serious and
practical interest in the package, even if my knowledge of the upstream
code is limited.
> Sorry, but that's not really true. The issues were not 'unnoticed'
> and not being actively developed is not 'bit rotting'.
Thanks for the clarification. When I used the term “unnoticed”, I mainly
meant that there was no bug tracking CVEs in a way visible to users.
Your explanation in #1122255 provides exactly that missing context, and I
consider it sensible and sufficient documentation of the situation.
Based on this clarification, I am closing the bug that requested removal
of the package.
> So in the absence of someone else stepping up to the be the primary
> point of contact for issues regarding this package, I'm happy to
> continue on in that role. And this package does still have a
> relevant (if somewhat niche) job that it performs which we have no
> other equivalent replacement for that I'm aware of.
That sounds good to me. I am happy that the package remains available
and that there is still someone willing to act as a point of contact
when needed.
> I don't think it's right to try and foist it onto another team
> that did not volunteer themselves willingly - but I don't think
> the absence of such a team is a good reason to simply annihilate
> it either.
I agree that maintenance should not be forced onto any team. My attempt to
work within a team context was meant as an offer to collaborate, not to
shift responsibility unwillingly.
To summarise my intent: I would like mp3splt to remain in Debian with a
clearly communicated maintenance model and a Git setup that enables easy
collaboration when needed. I would explicitly encourage cherry-picking
from the Salsa repository I created, as it already contains packaging
cleanups and documentation that may be useful going forward.
It would be great to see an upload by an involved maintainer in the near
future, as a visible sign of continued interest in the package. After a
long series of NMUs that went unconfirmed, such an upload would help make
the current maintenance situation clearer to both users and contributors.
If you prefer a different repository location or workflow, I am of course
very happy to coordinate.
> All The Loves,
Same
Andreas.
[1]
https://salsa.debian.org/multimedia-team/mp3splt/-/commit/00e8654acea28878832a0cb113a0eb2ffc6a292f
--
https://fam-tille.de
--- End Message ---
