Dear Maintainer(s),

timidity has been flagged by Lintian as shipping a sysv-init script
without a corresponding systemd unit file. The default init system in
Debian is systemd, and so far this worked because a transitional
sysv-init-to-unit generator was shipped by systemd. This is in the
process of being deprecated and will be removed by the time Trixie
ships, so the remaining packages that ship init scripts without
systemd units will stop working.

There are various advantages to using native units, for example the
legacy generator cannot tell the different between a oneshot service
and a long running daemon. Also, sanboxing and security features
become available for services. For more information, consult the
systemd documentation:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html

You can find the Lintian warning here:

https://lintian.debian.org/sources/timidity

In case this is a false positive, please add a Lintian override to
silence it and then close this bug.

Thanks!

Dear Maintainer(s) of affected packages, these bugs have been open for
more than 2 years now. Policy was updated to make units mandatory for
system services. The removal of compat with sysv-init scripts from
systemd has been postponed from trixie to forky, but it is now
approaching. In approximately a month's time, this should hit
unstable, if everything goes well.

Therefore in order to ensure the remaining bugs do not fall through
the cracks I am raising severity again, as there is a very high chance
the affected packages will stop working as intended in about a month's
time in the default setup.

As already mentioned in the original bug report, if your package is
not intended to work as a systemd service or under systemd at all,
please feel free to downgrade or close+wontifx or anything else as you
see fit. The severity raising is not intended to make anyone support
scenarios they don't wish to support, but simply to ensure attention
is given to the issue, even if just to close+wontfix. Also the bugs
were opened based on Lintian reports, and it is possible that there
might be false positives.

Thanks for your work and understanding.

I found this bug under Debian Release Critical Bugs relevant for testing.


Modern Linux audio stacks such as PulseAudio and PipeWire are designed
around per-user audio sessions rather than system-wide sound services.
As a result, running TiMidity++ as a system-wide daemon (whether via
SysV init or a system service) is no longer the recommended approach and
may not work correctly when the audio device is managed by the user's
audio session.

If required, users can start a TiMidity++ daemon manually with:

$ timidity -iA

For a more permanent setup, TiMidity++ can be started automatically at
login using a desktop autostart entry or a systemd --user service.

This is also the approach taken by other distributions. The OpenSUSE
README states:

   When using pulseaudio the use of timidity as a system wide daemon is
discouraged,
   because both pulseaudio and timidity need the same device
exclusively. However
   timidity can be started as a daemon for the user to provide the MIDI
ports he/she
   needs [...]

and recommends:

   $ timidity -iAq -Oe -s 44100

Similarly, the Arch Linux wiki notes:

   If you are using PulseAudio, that may also cause the service to fail.
You may want to
   add the following command as an autostart program in your desktop
environment.

   $ timidity -iA

Given the move towards per-user audio services, I don't believe
replacing the existing SysV init script with a system-wide systemd unit
would be an improvement. A systemd --user service would be more
appropriate for users who require a persistent TiMidity++ daemon. Such a
service file is, I believe, not commonly provided by Debian.

I hope this helps!

Kind regards,

     Edmund