This does make me wonder about a secondary effect of the metapackages - we have a number of packages that install and enable systemd units, is this something that's worth addressing in our packages or am I overthinking it again?

I note they've not been released in a while and there's year old changes so I plan an upload in the coming week or two!

--
Hibby
MM0RFN

On Sun, 10 Mar 2024, at 6:15 PM, Daniele Forsi wrote:

Mark Lus wrote:

After installing the current package on two intel based PCs, the working audio card would be replaced with "Dummy Output". Resulting in no audio out.

please reinstall hamradio-all then, when you audio stops working (at
the net reboot, I think) run this command as root:
systemctl stop remotetrx

your audio should start to work again immediately (non need to logout
or reboot), but to make this permanent run these commands as root:

systemctl disable remotetrx
systemctl disable svxlink

If you only disable remotetrx, at the next reboot svxlink takes over
the audio device

--
73 de IU5HKX Daniele

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Re: Dave Hibberd

This does make me wonder about a secondary effect of the metapackages - we have a number of packages that install and enable systemd units, is this something that's worth addressing in our packages or am I overthinking it again?

Starting daemons on package install is normal Debian practice...

On Sun, 10 Mar 2024, at 6:15 PM, Daniele Forsi wrote:

Mark Lus wrote:

After installing the current package on two intel based PCs, the working audio card would be replaced with "Dummy Output". Resulting in no audio out.

please reinstall hamradio-all then, when you audio stops working (at
the net reboot, I think) run this command as root:
systemctl stop remotetrx

your audio should start to work again immediately (non need to logout
or reboot), but to make this permanent run these commands as root:

systemctl disable remotetrx
systemctl disable svxlink

If you only disable remotetrx, at the next reboot svxlink takes over
the audio device

... Though installing random packages should not cause breakage like
that. Does anyone know what exactly happens there? Is the purpose of
these packages to make the default audio device something else?
"remotetrx" might sound like that, but I've never used it.

Christoph DF7CB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Mar 2024, at 4:04 PM, Christoph Berg wrote:

Re: Dave Hibberd

This does make me wonder about a secondary effect of the metapackages - we have a number of packages that install and enable systemd units, is this something that's worth addressing in our packages or am I overthinking it again?

Starting daemons on package install is normal Debian practice...

Is it possible to ship the configs as examples under /usr/share/doc/svxlink/examples and add a ConditionPathExists to the systemd unit, a little similar to what has been done on #1022903 ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Re: Dave Hibberd

This does make me wonder about a secondary effect of the metapackages - we have a number of packages that install and enable systemd units, is this something that's worth addressing in our packages or am I overthinking it again?

Starting daemons on package install is normal Debian practice...

Is it possible to ship the configs as examples under /usr/share/doc/svxlink/examples and add a ConditionPathExists to the systemd unit, a little similar to what has been done on #1022903 ?

Sure, if it fixes a problem...

Christoph

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)