Awesome, thanks again for the tips Jeff,
I went ahead and de-installed WSJT-X updated my ports tree and rebuilt
it on my current 12 install, it does build fine and runs ok, even lets
me click on a few station calls to initiate contact then maybe the third
or fourth try I seem to always end up
One of the beautiful things about FreeBSD is building out of the ports
collection. Everything is built from source, so it should not matter if
you are on 11, 12 or 13. I would encourage an update to 13 if you have
a non-production machine, simply because that is where people seem to be
doing
Il 04/01/22 20:17, Paul Bramscher via
wsjt-devel ha scritto:
Thanks
Joe -- we appreciate the update. Downloaded the source tarball
from your Princeton site, compiled without issue on Debian 11.
Previously I was running 2.5.3 with a Kenwood TS-
Thanks Jeff.
I'm running 12.X currently but 2.5.4 seems to build fine for me at least
I could try to re-run the build and watch for any warnings or errors..
is it a matter of needing to jump to the 13.X version train? or should
it still work under 12.X?
Thanks again
Jason
On 1/7/22 09:50
That has been fixed and WSJT-X 2.5.4 builds out of the ports collection
on FreeBSD 13.
portsnap fetch update
make install clean
WSJT-X 2.5.4 builds and installs without error.
Oh, and thanks for the reminder to send Diane the request to add the
binary to the package collection.
On 1/6/2
Only apps using the QT framework appear to have this problem. Unfortunately,
without rewriting wsjt in some other framework, it's hard to solve.
I'd think that adding the resync to the error process (when you pop up the
"audio failure" window, resync the audio numbering) would work, but I'm not
On Thu, Jan 06, 2022 at 09:48:22PM -0800, Paul Kube via wsjt-devel wrote:
> Any change to audio device availability on MS Windows is likely to renumber
> the indexes of other devices, when this happens WSJT-X gets no notification
> that it has happened.
So does this mean that when a new audio dev
