WSJT Application Suite Status - ( Warning, Long Post ! )
Hello all,
First, thank you for allowing me to join the team. I look forward to
helping out, where I can, on the various packaging needs.
Warning: Long Post!! :-)
------------------------
I'll try to keep this as short as possible, however, I think it's
important to understand "a litle bit" of history for each app, in order
to appreciate the efforts being taken to bring each to Debian and *Nix
in general.
I'm part of the WSJT upstream team. My primary focus has been
implementing documentation build systems ( *Nix & Win32, using AsciiDoc
) and providing build tools ( in the form of SDK's ) for each
application ( *Nix & Win32 ). All apps are built with GNU tools, native
on *Nix, MinGW / Mingw32_48 tool chains on Win32 and/or CMake +
Makefiles where appropriate. I take care of all SDK's and documentation
build scripts.
The WSJT app suite has 5 primary applications ( WSJT, WSJT-X, WSPR,
WSPR-X and MAP65 ), Documentation, Support Scripts ( kvasd-installer )
and build / development tools ( various SDK's ). WSPR includes several
secondary binaries used in the ARRL FMT test, as well as Rig calibration
/ offsets for digital modes (similar to MSSTV, MMTTY cal etc).
BRIEF HISTORY:
--------------------
WSJT and WSPR are Python3-TK based
WSJT-X, WSPR-X amd MAP65 are Qt5 Based
Note(s):
-Each application builds it's own library, with many of the Fortran
files overlapping between the apps. Efforts are underway to build a set
of libraries for all the apps to use as a package, but this is a way out
yet.
-The primary target platform for all the applications was originally
Windows. Apart from one item, the KVASD decoder, they are all FOSS or
have proper open source copyrights. As such, a great deal of effort has
gone into porting some, but not all, of the applications to *Nix (
FreeBSD, Linux, Mac etc ). There is still a great deal of work that
needs to be done upstream, but it is under-way and making good progress.
Currently, older versions of WSJT and WSJT-X are available in Debian /
*Nix in general. As such, there are a couple of core issues:
1). The apps were designed to run in a single folder, non privileged,
user setup on Windows e.g. C:\<app-name>. Notably, binaries, libraries
and general app support files do not fit well into FHS. Rather, they
must reside in the same directory where the application is ran from.
This has been addressed in the current WSJT-X release candidates. WSJT
and WSPR ahve work-arounds to copy files to the ~/.<app-name>, not ideal
by any means, but functional.
2). The KVASD decoder, used in WSJT, WSJT-X and MAP65 is a non-FOSS
patented ( source code ) binary, licensed free for Amateur Radio
community, to Joe Taylor, K1JT, provided the end user agrees to the
terms issued "to Joe" for it's usage. As such, cannot be included
directly in packaging. This decoder is "far superior" to the native
decoders in the each of the respective applications. WSJT-X no longer
"requires or downloads" the decoder, but, the performance significantly
is degraded without it. WSJT and MAP65 need patches are to prevent
annoying messages about the decoder not being found.
PACKAGES:
kvasd-installer (ITP: #765987 )
--------------------------------
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765987
Launchpad: https://launchpad.net/~ki7mt/+archive/ubuntu/kvasd-installer
License: GPL-3, by <ki7mt>
Sponsor: I've been working with Kamal on this one
1). Is optional and should be in contrib section (Thanks Kamal for Info)
2). Asks for end user EULA agreement
3). Installs, Removes, and Tests the KVASD bianry from SF to /usr/bin
4). Installs the KVASD binary dependencies (mainly libgfortran)
Note(s):
-In the past, there was only a 32bit version. It now comes in 32 & 64
bit, thus removing the multi-lib requirements on amd64 systems. WSJT,
WSJT-X and MAP65 packaging can now leverage the same binary, at the
users discretion and package dependencies should be adjusted
accordingly, if allowances were made for it previously.
wspr (ITP: #557214)
--------------------
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557214
License: GLP-3, by <various>
Launchpad: https://launchpad.net/~ki7mt/+archive/ubuntu/wspr
Sponsor: I've been working with Kamal on this one as well.
1). This is a new package being introduced.
2). I've had to ( upstream ) completely re-wrote all of the autotools
(configure.ac Makefile.in, etc)
3). I wrote all the manpages and several support files
-Lintian is fairly clean, only a watch file message is presented.
Note(s):
-This package requires all files be located in a single directory.
-The run script does a cp -U for all files into the ~/.wspr
-I've asked Joe (K1JT) when he would like to release it, hopefully
we can get it into Jessie, not sure that is possible seeing how it's a
new package.
WSJT-X
--------------------
Link: https://packages.qa.debian.org/w/wsjtx.html
Maintainer: I believe this is Kamal and John (AC6SL) with others
providing patches. I've talked with John about taking over the as he's
no longer interested in JT modes. We tentatively set the WSJT-X v1.4
release as the demarcation.
1). WSJT-X is undergoing major updates, particularly with the Setup
Tabs, and rig control. It's fully functional, but the current Debian
package will need major updates, particularly with the build/rules file.
Problems:
1). At present, WSJT-X is using a static version of libhamlib.a from the
Upstream Git repo ( a snapshot ). This snapshot will eventually become
libhamlib3, but a release date from Nate and his team is undetermined.
2). The primery method of build is using a CMakeLsts.txt file called a
super-build-script. It has only two targets, but they are both CMake
External targets, which download the hamlib sources, and then WSJT-X
sources during the build. I don't think this is allow on infrastructure
servers or at least, it's not allowed on Launchpad.
3). It's also downloading a pre-built version of it's User Guide, again,
Web-URL downloads not allowed I don't think.
4). I need a formal statement on the use of Static Libraries being used
when the original sources are already in Debian, in this case libhamlib2
+ libhamlib-utils.
Solutions:
1). There's several ways around the downloading issues, but a new rules
file will need to be written.
2). Same for the documentation.
3). Fortunately, the install target is setup correctly for installation.
I worked with Bill (G4WJS) to produce a proper .deb file using pbuilder,
and that aspect seems to be working nicely, wilt no Lintian warnings to
speak of.
WSJT ( target Jessie+1 )
------------------------
Link: https://packages.qa.debian.org/w/wsjt.html
Maintainer: I believe this is Kamal and John (AC6SL) with others
providing patches. I've talked with John about taking over packaging on
this one also, as he's no longer interested in JT modes. We tentatively
set the WSJT v10.0 release as the demarcation.
Allot of Work Needed (upstream). I'll be doing most of this:
1). The autotools need updating, the same as WSPR.
2). Manpage need to be included upstream
3). Need to patch the use of kvasd-installer method of decoding.
4). Include the other patches ( as feasible ) from the current Debian
package.
Note(s):
-I don't think a formal update is possible for Jessie.
JTSDK ( target is Jessie+1 )
----------------------------
1). No ITP Yet
2). Still being written my <ki7mt>
MAP65 ( target is Jessie+1 )
----------------------------
1). No ITP Yet
2.) Updates needed upstream for proper *Nix packaging / builds,
particularly with poortaudio and CMake Find Modules.
WSPR-X ( target is Jessie+1, if at all )
----------------------------------------
1). No ITP Yet
2). Updates needed upstream for proper *Nix packaging
3). This is a development platform for testing new WSPR modes. It is
still undetermined if it will ever be a true formal package or not.
Sorry for the long post, but that's the status of things as I know it.
If you have questions or comments, please send them along.
73's
Greg, KI7MT
Reply to: