Re: [wsjt-devel] Please read: Windows users installing the latest v2.1.0 GA 64-bit version

[Greg Beam]

It's on the Same page:

https://slproweb.com/products/Win32OpenSSL.html

Link: https://slproweb.com/download/Win64OpenSSL_Light-1_1_0k.exe

73's
Greg, KI7MT

On 7/18/19 1:52 AM, Tom Ramberg via wsjt-devel wrote:

That's the WIN32 version.

73 de Tom OH6VDA
Sendt fra min iPad Air 2

18. jul. 2019 kl. 10:15 skrev Maurizio Brameri 
mailto:maurizio.bram...@fastwebnet.it>>:



I have found this link: https://slproweb.com/products/Win32OpenSSL.html

Bye,

Maurizio


Il 18/07/2019 08:38, Tom Ramberg via wsjt-devel ha scritto:
Could you please provide a link to the installation file of 
WIN64_OpenSSL_1.1.0k_Light?


73 de OH6VDA Tom
Sendt fra min iPad Air 2

18. jul. 2019 kl. 01:39 skrev Bill Somerville >:



Hi,

you may get an SSL/TLS network error when fetching a fresh LoTW 
users database ("Settings->Colors->Logbook of the World User 
Validation"). The WSJT-X User Guide current states that the OpenSSL 
v1.0.2 libraries are required for this to work, this is incorrect 
for the 64-bit version of WSJT-X, that requires the latest v1.1.0 
version of the OpenSSL libraries. The instructions are the same 
except use the Win64_OpenSSL_v1.1.0k_Light package for the 64-bit 
version of WSJT-X.


Apologies for the release notice not containing this information, I 
have only just discovered this new dependency.


73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net 


https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 64 bit raspbian

[Greg Beam]

Hi Bill, Sandro,

Ubuntu has an ARMv8 (arm64) distro. I can't say off-hand that I know 
anyone using it in ham radio, mostly server based applications.


My PPA has been building the ARMv8 (arm64) package for a while now. 
Again, I don't know if anyone is installing it, but the *.deb package is 
there nonetheless.


Link to Packages, Bionic is the latest:
https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx/+packages

73's
Greg, KI7MT

On 7/16/19 8:41 AM, Bill Somerville wrote:

On 16/07/2019 15:27, Alessandro Gorobey via wsjt-devel wrote:


referring to
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/doc/user_guide/en/install-linux.adoc 



* 64-bit: {raspbian} <--
- To install:
+
[example]
sudo dpkg -i wsjtx_{VERSION}_armhf.deb
--

I think that is a 32 bit version for raspbian, not for the 64 bits.

I am correct ?

Thanks
--
73
Sandro
IW3RAB


Hi Sandro,

you are quite correct. The ARM version of WSJT-X is 32-bit. My mistake 
as at the time it was rolled out I was working on a large commercial 
project porting software to ARM 64-bit and I had the AArch64 
architecture high on my brain stack ;)


If someone wished to run 64-bit WSJT-X on an ARM processor, including 
the Raspberry Pi models 2 and 3, they could install a 64-bit o/s that 
provides ARM support such  as OpenSUSE Linux (maybe CentOS as well) then 
build WSJT-X from sources. I would be surprised if it was not 
straightforward. Our package maintainers may already be doing so.


73
Bill
G4WJS.




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] New library required for building: qt5-linguist

[Greg Beam]

Hi Dave,

If there is a shorter way (smaller footprint), I've not found it. Not to 
say there isn't one. I think it's the dblatex portion that gets really 
piggy.


73's
Greg, KI7MT

On 7/15/19 3:01 PM, Dave Slotter, W3DJS wrote:

Bill,

Thanks, I added qttools5-dev-tools and CMake seems to be satisfied.

While you're making changes, there are a lot of year references to 2018 
which should probably say 2019.  :-)


And lastly, where do I get "a2x" for building the man pages? Is it in 
ASCIIDoc? Installing that requires 800MB on my machine. Is there a 
smaller installation method to get "a2x"? Not that I can't spare that 
room, but that's a lot for one single binary...


73,

--
Dave Slotter, W3DJS 


On Mon, Jul 15, 2019 at 4:53 PM Bill Somerville > wrote:


On 15/07/2019 21:39, Dave Slotter, W3DJS wrote:
 > There appears to be a new requirement to build under Ubuntu 16.xx.
 > CMake seems to now require Qt5LinguistTools in order to build,
whereas
 > that was not required in earlier release candidate builds of 2.1.0.
 >
 > Where do I get this library to satisfy CMake? (Thanks in advance.)
 >
Hi Dave,

I believe the required package is qttools5-dev-tools .

Apologies for the INSTALL file not being updated to reflect that new
requirement, it will be corrected for the next release.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0: GA release

[Greg Beam]

Hi Joe,

I downloaded and installed the Ubuntu Bionic(18.04) x86-64 package from 
your site. No issues with the install; it's up and monitoring 30m FT8.


I built the source package with pbuilder for Bionic(18.04). No issues, 
so I am pushing the source tgz to Launchpad for Bionic:


One issue with Disco (19.04), readline7, so I won't be publishing that 
distribution today. Likewise, Xenial (16.04) is having issues with the 
qttools5-dev package. Not sure what's going on there as it's available 
in the distribution. Will need to investigate further.


Assuming no build failures on Bionic, the package(s) should be published 
in an hour or so when the slower servers finish.


Launchpad ...: https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx
Current Version..: WSJT-X v2.1.0 GA Release
Ubuntu Distros...: Bionic
Supported Arch...: i386, amd64, armv7, armv8, ppc64el

I am not certain, but, I thought I read that Debian was including these 
newer versions of WSJT-X at the distribution level. If so, that would be 
really good news and negate the need for PPA's.



73's
Greg, KI7MT


On 7/15/19 8:05 AM, Joe Taylor wrote:
The WSJT Development Group is pleased to announce the general 
availability (GA) release of WSJT-X Version 2.1.0.


WSJT-X 2.1 is a major upgrade that introduces FT4, a new protocol for HF 
contesting.  Improvements have also been made in the following areas:


   - FT8 waveform generation using GMSK, fully backward compatible
   - user options for low-sidelobe waterfall and spectrum display
   - UDP messaging for inter-program communication
   - accessibility

... as well as many minor enhancements and bug fixes.

We now provide a separate installation package for 64-bit Windows, 
offering significant improvements in decoding speed.



A more detailed list of program changes since WSJT-X 2.0.1 can be found 
in the cumulative Release Notes:

http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt

Upgrading from earlier versions of WSJT-X should be seamless.  There is 
no need to uninstall a previous version or move any files.


Please do not continue to use any release candidate -- that is, any beta 
release with "-rc#" in the version name.


Links to installation packages for Windows, Linux, and Macintosh are 
available here:

http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General 
Public License (GPL).  Development of this software is a cooperative 
project to which many amateur radio operators have contributed.  If you 
use our code, please have the courtesy to let us know about it.  If you 
find bugs or make improvements to the code, please report them to us in 
a timely fashion.


We hope you will enjoy using WSJT-X Version 2.1.0.

  -- 73, Joe, K1JT, for the WSJT Development Group



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ALL.TXT (again)

[Greg Beam]

Hi Claude,

Personally, I don't have a need for it either. If all I am after is QSO 
validation: grep + awk or a good quality text editor is all that's 
needed :-)


However, if one wants to do any sort of data analysis, the flat file 
format is less than ideal. Normalizing the data would go a long way 
toward shrinking the footprint, however, it also adds a level of 
complexity some may not find very pleasant.


I am aware, and have done a bit of parsing in the past regarding the 
varying data structures of the file. It's changed a a good bit over the 
last few versions.


In any case, it's a doable thing if one wants to store their history / 
data (for whatever reason). IoT devices often use these 
variable-structure data sets with great success. The variance in the 
ALL.TXT file is minimal compared to some I've seen.


73's
Greg, KI7MT


On 7/9/19 4:11 AM, Claude Frantz wrote:

On 7/9/19 10:58 AM, Greg Beam wrote:

Hi Greg,

I think parsing the lines into fields is the best long-term solution 
for storage (allows for much better indexing).


This make only sense if you can assign a clear definition to every 
field. In the case of ALL.TXT, not all lines have the same structure. 
Especially, the date and the time can be in different lines, depending 
on the used WSJTX release.


However, we'd need to do a fair bit of checking on each line to 
determine its structure first; 


This is essential.

To be honest, I cannot see the advantage of having the data, stored in 
ALL.TXT, in a database. Myself, I'm using ALL.TXT only to verify strange 
situations or to verify a situation where I get a QSO confirmation for a 
QSO not in the log. A database is very useful when we often need access 
to the data and when we need rather complex queries. These requirements 
do not apply to ALL.TXT. Remember, the database management software 
needs disk space and processing time.


Best wishes,
Claude (DJ0OT)



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ALL.TXT (again)

[Greg Beam]

Hi Mike,

I finally had some time to tinker with this some. On my Win laptop using 
WSL, MSYS2, or MonaXterm (Cygwin port), import performance is not 
impressive by any means. I suspect files system interoperability is the 
root cause. Searches, once imported, are fine. On my Linux workstation 
imports are extremely fast; note: I'm running MongoDB on an XFS 
partition with an abundance of Ram (MongoDB is Ram piggy).


I tinkered around with (3) scripts:

Import Script (atimport.sh)
Link: http://paste.ubuntu.com/p/bh5vGB5GPW/

Call Sign Lookup (atcheck.sh)
Link: http://paste.ubuntu.com/p/NHv9tztx2Z/

Parse line into fields (retest.py)
Link: https://paste.ubuntu.com/p/8HdPcTVXpN/

I think parsing the lines into fields is the best long-term solution for 
storage (allows for much better indexing). However, we'd need to do a 
fair bit of checking on each line to determine its structure first; 
check == "slower imports". Once the main (first) bulk import is done, 
incremental updates would be snappy.


I'm sure there are far better solutions; like a UDP service that just 
pushes the decodes straight into a database (of any kind) :-)


73's
Greg, KI7MT


On 7/1/19 3:05 PM, Black Michael via wsjt-devel wrote:

Please do post the code.

Thanks Greg.

de Mike W9MDB




On Monday, July 1, 2019, 03:53:15 PM CDT, Greg Beam  
wrote:



Hello All,

Here's an example from today's log:

Results: https://paste.ubuntu.com/p/382VVMth4S/

The query takes about (2) seconds or so using a $regex search on
7,390,224 logged events matching two callsigns; this is without being
indexed nor field splitting. It is one string per line imported to a one
field document in MongDB

I can post the script I used as a gist, if anyone is interested:

- Copies the ALL.TXT to $temp_file
- Converts it to CSV
- Generates two helper JS scripts
- Generates one example JS query
- Drops, then re-imports the alltext collection
- Runs the a sample Query.

Note: for incremental (daily) updates, there is no need to drop the
collection (alltext) before inserting new events. I just do that for
performance testing.

It's a simple one-line query command that would work on Win/Linux/Mac:

mongo < example.js

You can, if desired, write any number of commands to perform stats,
lookup(s), whatever, and use the same easy method to query the DB.
However, as this is a single sting entry, much of the analytical value
would be missing, as the fields / categories are not captured.

73's
Greg, KI7MT



On 7/1/19 1:27 AM, Claude Frantz wrote:
 > On 7/1/19 7:59 AM, Claude Frantz wrote:
 >
 > Just as an example of code extract in perl:
 >
 > if ($line =~ m/^(\d{4})-([A-Z][a-z]{2})-(\d{2})\b/ ) {
 >      $day = $3 ;
 >      $month_alpha = $2 ;
 >      $year = $1 ;
 > }
 > elsif ($line =~ m/^(\d\d)(\d\d)(\d\d)_\d{6}\b/ ) {
 >      $day = $3 ;
 >      $month_num = $2 ;
 >      $year = 2000 + $1 ;
 > }
 > elsif ($line =~ m/^(\d{4})-(\d\d)-(\d\d)\b/ ) {
 >      $day = $3 ;
 >      $month_num = $2 ;
 >      $year = $1 ;
 >      }
 >
 > I have not tested it, I hope there is no error. This allow to decode the
 > 3 formats of ALL.TXT about which ones I remember about. Please note that
 > the month can be numeric or alpha. If alpha, you have to convert to
 > numeric, if you want to compare to a numeric value. Please note also,
 > that the mode switching was an extra line in previous formats.
 >
 > Best wishes,
 > Claude (DJ0OT)



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ALL.TXT (again)

[Greg Beam]

Hi Dan,

The example's I spoke of aren't running through a JS engine, they are 
being ran through Mongo itself to perform the queries. If you want to 
run native JS server side, you'd be better off install NodeJs or 
similar. There are a ton of PGP/MongoDB tutorials out there. The main 
difference being, you'd be using MongoClient through an ODM most likely.


There's nothing to say one could not have multiple collections; one with 
a full string such as the example I did, and another that has each field
broken out by field types. Breaking out the fields has a number of 
advantages, particularly for analytics.


I'll tidy up the Bash script I use, and post it as a Gist. You could run 
it through MSYS2, Cygwin, or WSL even, as all should have access to 
Windows Local Servers. It would take a few changes for Path variables, 
but nothing major. I have Apache running on my server as it hosts some 
of testing environment. I'll may play around with a PHP form or two and 
see how that goes.


73's
Greg, KI7MT


On 7/1/19 3:45 PM, Dan Malcolm wrote:

Because I want to search via my webserver, I have a separate PHP script that 
does the search.  Probably not as fast as MongoDB.  I do get good cohesive 
reports though.  I get a report for example that will show me just one of my 
QSO's, and will store results in a text file.  That makes it useful to refer to 
later, or to include in an email to my QSO partner.

All that said I would like to explore MongoDB.  The idea that query via js 
script may mean that I can still have private web access.  I use IIS on Win10 
and just the local machine can access it.

__
Dan – K4SHQ


-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com]
Sent: Monday, July 1, 2019 3:47 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] ALL.TXT (again)

Hello All,

Here's an example from today's log:

Results: https://paste.ubuntu.com/p/382VVMth4S/

The query takes about (2) seconds or so using a $regex search on
7,390,224 logged events matching two callsigns; this is without being indexed 
nor field splitting. It is one string per line imported to a one field document 
in MongDB

I can post the script I used as a gist, if anyone is interested:

- Copies the ALL.TXT to $temp_file
- Converts it to CSV
- Generates two helper JS scripts
- Generates one example JS query
- Drops, then re-imports the alltext collection
- Runs the a sample Query.

Note: for incremental (daily) updates, there is no need to drop the collection 
(alltext) before inserting new events. I just do that for performance testing.

It's a simple one-line query command that would work on Win/Linux/Mac:

mongo < example.js

You can, if desired, write any number of commands to perform stats, lookup(s), 
whatever, and use the same easy method to query the DB.
However, as this is a single sting entry, much of the analytical value would be 
missing, as the fields / categories are not captured.

73's
Greg, KI7MT





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ALL.TXT (again)

[Greg Beam]

Hello All,

Here's an example from today's log:

Results: https://paste.ubuntu.com/p/382VVMth4S/

The query takes about (2) seconds or so using a $regex search on 
7,390,224 logged events matching two callsigns; this is without being 
indexed nor field splitting. It is one string per line imported to a one 
field document in MongDB


I can post the script I used as a gist, if anyone is interested:

- Copies the ALL.TXT to $temp_file
- Converts it to CSV
- Generates two helper JS scripts
- Generates one example JS query
- Drops, then re-imports the alltext collection
- Runs the a sample Query.

Note: for incremental (daily) updates, there is no need to drop the 
collection (alltext) before inserting new events. I just do that for 
performance testing.


It's a simple one-line query command that would work on Win/Linux/Mac:

mongo < example.js

You can, if desired, write any number of commands to perform stats, 
lookup(s), whatever, and use the same easy method to query the DB. 
However, as this is a single sting entry, much of the analytical value 
would be missing, as the fields / categories are not captured.


73's
Greg, KI7MT



On 7/1/19 1:27 AM, Claude Frantz wrote:

On 7/1/19 7:59 AM, Claude Frantz wrote:

Just as an example of code extract in perl:

if ($line =~ m/^(\d{4})-([A-Z][a-z]{2})-(\d{2})\b/ ) {
     $day = $3 ;
     $month_alpha = $2 ;
     $year = $1 ;
}
elsif ($line =~ m/^(\d\d)(\d\d)(\d\d)_\d{6}\b/ ) {
     $day = $3 ;
     $month_num = $2 ;
     $year = 2000 + $1 ;
}
elsif ($line =~ m/^(\d{4})-(\d\d)-(\d\d)\b/ ) {
     $day = $3 ;
     $month_num = $2 ;
     $year = $1 ;
     }

I have not tested it, I hope there is no error. This allow to decode the 
3 formats of ALL.TXT about which ones I remember about. Please note that 
the month can be numeric or alpha. If alpha, you have to convert to 
numeric, if you want to compare to a numeric value. Please note also, 
that the mode switching was an extra line in previous formats.


Best wishes,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ALL.TXT (again)

[Greg Beam]

Hello All,

This is similar to how I parse the file also; read / split the line and 
check line[0], then do what's needed based on checking the first string.


At present, my ALL.TXT is over 400MB. What I've been doing to prevent 
read lock issues is creating a daily diff file between a copy and the 
active ALL.TXT file; sticking each diff-file in folder to process at 
whatever time I wish without affecting WSJT-X operations:


alltxt-diff-20190629-0300.txt
alltxt-diff-20190630-0300.txt
etc, etc, etc

After each diff run, I update the copy so it's ready for the next day. 
There are hundreds of ways to accomplish the same thing, but, I found 
this to be easy and fairly painless (disk space is cheap these days :-) )


What to do with the data after has been my focus of late. I've been 
playing around with MongoDB (a schema-less JSON/BSON Document storage 
database) to sick the decoded lines in. You can either split the lines, 
or just stick the entire line in as a new document for long term 
storage/later-date access.


The $regex processing capability of MongoDB is extensive, and very fast! 
One can easily parse a multitude of string combinations, even with the 
entire line in one field, for example:


use wsjtx;
db.alltxt.find( { $and: [
{event:{$regex:'MY-CALL'}},
{event:{$regex:'HIS-CALL'}}
]
});


That would print the lines (documents) that contains both 'my-call' and 
'his-call'.


You could add ..'DATE_STRING' or any combination you wish to further 
refine the search without having to split the lines at all.


In case folks are worried about the number of documents in each 
collection, I've added the entire WSPR Decode Archive (from WSPRnet) to 
a MongoDB Database/collection set (one collection for each year, 2008 
thru 2019, at just over 95GB on disk size). Later collections have 
"millions" of decodes in them. Single collection Query Times are =< 1 to 
2 seconds. With added indexing, times are in the Millisecond range :-) 
Aggregate queries, those spanning multiple collections/years, vary in 
time depending on the data being sought but are well within an 
acceptable time limit for most use cases I've had.


73's
Greg, KI7MT

On 7/1/19 1:27 AM, Claude Frantz wrote:

On 7/1/19 7:59 AM, Claude Frantz wrote:

Just as an example of code extract in perl:

if ($line =~ m/^(\d{4})-([A-Z][a-z]{2})-(\d{2})\b/ ) {
     $day = $3 ;
     $month_alpha = $2 ;
     $year = $1 ;
}
elsif ($line =~ m/^(\d\d)(\d\d)(\d\d)_\d{6}\b/ ) {
     $day = $3 ;
     $month_num = $2 ;
     $year = 2000 + $1 ;
}
elsif ($line =~ m/^(\d{4})-(\d\d)-(\d\d)\b/ ) {
     $day = $3 ;
     $month_num = $2 ;
     $year = $1 ;
     }

I have not tested it, I hope there is no error. This allow to decode the 
3 formats of ALL.TXT about which ones I remember about. Please note that 
the month can be numeric or alpha. If alpha, you have to convert to 
numeric, if you want to compare to a numeric value. Please note also, 
that the mode switching was an extra line in previous formats.


Best wishes,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X v2.0.1 Available via Launchpad PPA

[Greg Beam]

Hello All,

First, apologies for the lengthy delay on getting the latest version
(v2.0.1) published. I had no end of problems with Mint 19 on my new
workstation rebuild (nothing to do with WSJT-X itself). In the end, it's
back to Ubuntu for the Base-OS.

Build Data:
- Distributions: Xenial (16.04), Bionic (18.04), Cosmic (18.10)
- Architectures: amd64, arm64, armhf, i386, ppc64el

Note: Trusty (14.04) builds were failing, for several reasons, using
bootstrap locally and on Launchpad. As Trusty goes End-Of-Life (EOL) in
April, I decided to pull the v2.0.1 package for "Trusty Only" and move
forward with the latest supported distributions.

Installation and Upgrade:
See: https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx

73's
Greg, KI7MT



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X Dev Tools Installation for (Debian, Ubuntu, Mint, others)

[Greg Beam]

Hello All,

 

Of late, there have been several folks experiencing problems when setting up
their Linux Development Tooling across various Debian | Ubuntu based
distributions. To try and alleviate some of those anomalies and provide a
consistent setup process, I've created a meta-package that installs the
dependencies for you with minimal effort. I've scratched out a couple
documents providing an overview [1] and specific how-too for various
platforms [2]. If you have specific installation notes, problems or
requests, please use the issue-tracker [3]. This is the first release of
this package; however, the same dependency list has successfully built the
WSJT-X | Hamlib combination over 200 runs using Launchpad-Servers without
issue; starting back before Ubuntu 14.04.

 

NOTE :  There are no build scripts, of any kind, provided in the meta
package. All this package does is install a list of build-dependencies
targeting WSJT-X and Hamlib.

 

[1] Overview

https://github.com/KI7MT/launchpad-packaging

 

[2] How-Too | Installation

https://github.com/KI7MT/launchpad-packaging/tree/master/src/wsjtx-metadev

 

[3] Bugs | Requests | Other

https://github.com/KI7MT/launchpad-packaging/issues

 

73's

Greg, KI7MT

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X v2.0.0 Build Failure: Ubuntu 14.04 via Bootstrap

[Greg Beam]

Hi Jim,

I have stayed clear of Kubuntu flavors on my Ham Radio box because of the
potential headaches; I do like the environment and the tools it provides
though.

Regarding Launchpad Builds: The Dev-Team provides *.deb files already and
they get posted on Joe's site. The LP builds are more of a sanity check than
anything as they are built by the Ubuntu Build Servers (the same servers
that build their distributions) in a clean environment. Bottom line is, if a
package builds properly on the Ubuntu Build Servers, then it should build on
a users' workstation given the dependencies are met.

The Trusty issue is probably known, and it's an accepted break in the builds
for the sake of future development. Either way, its overcome by events and
won't be an issue going forward.

73's
Greg, KI7MT

-Original Message-
From: Jim Shorney  
Sent: Tuesday, December 18, 2018 11:11 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X v2.0.0 Build Failure: Ubuntu 14.04 via
Bootstrap


FWIW, I was on (Kubuntu) Trusty prior to the recent round of updates and
RCs, but it was getting to the point where keeping all the dependencies up
to current standards was a real chore as Trusty nears end of life. That
prompted a move to Bionic and software joy has returned.

I do appreciate your package builds Greg, and have used them often enough in
the past. Lately I have been building from source just because I'm
impatient. :) Thanks for all that you guys do. 

And if this old phart can learn to read instructions and build from source
than there is no excuse for anyone to go off in a snit because the pieces
don't snap into place automagically. :D

73

-Jim
NU0C

On Tue, 18 Dec 2018 21:52:55 -0700
"Greg Beam"  wrote:

> Hi Bill,
> 
> Source: https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0.tgz
> 
> I finally got around to building WSJT-X v2.0.0 with Launchpad && local 
> pbuilder (Debian Bootstrap), but, I have run into an error that may 
> have been discussed already. UB 14.04 (Trusty) is using Qt 5.2.1, 
> while UB 16.04
> (Xenial) and UB 18.04 (Bionic) are using 5.5.1 and 5.9.5 respectively.
> Xenial and Bionic are building as expected but Trusty is failing on an 
> 'Q_ENUM' error (see attached image | log excerpt).
> 
> Personally, I am not overly concerned about it as Trusty goes EOL in 
> April
> 2019 and folks should be--if not already--migrating to a later LTS 
> release, but thought I'd let you know.
> 
> On a separate, but related note, I had to add two more package 
> dependencies to the Debian control file `Build-Dependencies` but I'm 
> sure your already
> aware:
> 
> - Git
> - libqt5sql5-sqlite
> 
> Other than the Trusty Q_ENUM issue, all else seems to be fine.
> 
> 73's
> Greg, KI7MT
> 



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] installing v. 2.0.0 on Debian stretch

[Greg Beam]

Hello All,

The process (as written below in your email), and as of release WSJT-X v2.0.0, 
will no longer be valid as Trusty is problematic on multiple fronts. If you 
want to use my PPA in this manner on Debian, use the following (note the 
change(s): 
wsjtx-next => wsjtx
trusty => xenial

For Buster:
deb http://ppa.launchpad.net/ki7mt/wsjtx/ubuntu bionic main

For Stretch:
deb http://ppa.launchpad.net/ki7mt/wsjtx/ubuntu xenial main

Then follow the rest of the process.

Ubuntu 16.04 thru 17.10 were based from Stretch/sid. Ubuntu 18.04 was based 
from Buster/sid. To find the version of Debian a given Ubuntu distribution was 
based on, type the following in a terminal:

cat /etc/debian_version

Obviously, this applies to Ubuntu flavors and would be of little help to a 
native Debian installation, but, the reciprocal is what's important here. The 
results align with the PPA you should use for the version of Debian you are 
running.


73's
Greg, KI7MT

-Original Message-
From: n...@comcast.net  
Sent: Tuesday, December 18, 2018 1:00 PM
To: pfb...@comcast.net; wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] installing v. 2.0.0 on Debian stretch

Helping someone who uses Ki7mt's..
https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx

But he hasn't included 2.0 yet.
Any sugestions?

This was the proc:

sudo apt-get install dirmngr
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 862549F9

sudo nano /etc/apt/sources.list
Tack this on:
# -
deb http://ppa.launchpad.net/ki7mt/wsjtx-next/ubuntu trusty main # 

sudo apt-get update
sudo apt-get install


BCNU DE N2LO

Sent from Xfinity Connect Application

-Original Message-

From: pfb...@comcast.net
To: wsjt-devel@lists.sourceforge.net
Sent: 2018-12-18 12:45:27 PM
Subject: Re: [wsjt-devel] installing v. 2.0.0 on Debian stretch

Hi Rich,

I've compiled all WSJT-X 2.0.0 RC's and the general release without a hitch -- 
and confirmed the process on a couple fresh Debian stretch machines also.  
Works great.

What kind of issues are you running into?

73, KD0KZE / Paul


> On December 18, 2018 at 10:21 AM Rich Griffiths  wrote:
> 
> 
> I'd like to chat with someone who has a working install of version 
> 2.0.0 on Debian stretch.  If you're interested, please contact me 
> off-list at rich-at-w2rg-dot-net.
> 
> 73
> 
> ... Rich   W2RG
> 
> --
> 
> Rich ... W2RG
> 
> Sent by Debian Linux - Microsoft free since 2003
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X v2.0.0 Available via Launchpad PPA ( Ubuntu 16.04 | 18.04 )

[Greg Beam]

Hello All,

 

Following Joe's release of WSJT-X v2.0.0, package-manager versions are
available via Launchpad PPA.

 

Distribution(s): Xenial (16.04), Bionic (18.04)

Arch: i386, amd64, armhf, arm64, ppc64el

 

Install:

See => https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx

 

Upgrade:

sudo apt-get update

sudo apt-get --only-upgrade install wsjtx

 

 

73's

Greg, KI7MT

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X v2.0.0 Build Failure: Ubuntu 14.04 via Bootstrap

[Greg Beam]

Hi Bill,

Source: https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0.tgz

I finally got around to building WSJT-X v2.0.0 with Launchpad && local
pbuilder (Debian Bootstrap), but, I have run into an error that may have
been discussed already. UB 14.04 (Trusty) is using Qt 5.2.1, while UB 16.04
(Xenial) and UB 18.04 (Bionic) are using 5.5.1 and 5.9.5 respectively.
Xenial and Bionic are building as expected but Trusty is failing on an
'Q_ENUM' error (see attached image | log excerpt).

Personally, I am not overly concerned about it as Trusty goes EOL in April
2019 and folks should be--if not already--migrating to a later LTS release,
but thought I'd let you know. 

On a separate, but related note, I had to add two more package dependencies
to the Debian control file `Build-Dependencies` but I'm sure your already
aware:

- Git
- libqt5sql5-sqlite

Other than the Trusty Q_ENUM issue, all else seems to be fine.

73's
Greg, KI7MT

Scanning dependencies of target wsjt_qt
make[6]: Leaving directory 
`/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx-build'
make[6]: Entering directory 
`/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx-build'
[ 80%] Building CXX object CMakeFiles/wsjt_qt.dir/qt_helpers.cpp.o
[ 80%] Building CXX object CMakeFiles/wsjt_qt.dir/widgets/MessageBox.cpp.o
[ 80%] Building CXX object CMakeFiles/wsjt_qt.dir/MetaDataRegistry.cpp.o
In file included from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/models/FrequencyList.hpp:10:0,
 from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/MetaDataRegistry.cpp:8:
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/models/IARURegions.hpp:46:17:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (Region)
 ^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/models/IARURegions.hpp:46:17:
 error: expected ';' at end of member declaration
In file included from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/models/FrequencyList.hpp:11:0,
 from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/MetaDataRegistry.cpp:8:
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/models/Modes.hpp:54:15:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (Mode)
   ^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/models/Modes.hpp:54:15:
 error: expected ';' at end of member declaration
In file included from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Configuration.hpp:10:0,
 from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/MetaDataRegistry.cpp:10:
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Transceiver.hpp:66:15:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (MODE)
   ^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Transceiver.hpp:66:15:
 error: expected ';' at end of member declaration
In file included from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/MetaDataRegistry.cpp:10:0:
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Configuration.hpp:71:19:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (DataMode)
   ^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Configuration.hpp:71:19:
 error: expected ';' at end of member declaration
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Configuration.hpp:73:22:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (Type2MsgGen)
  ^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Configuration.hpp:73:22:
 error: expected ';' at end of member declaration
In file included from 
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/MetaDataRegistry.cpp:13:0:
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/TransceiverFactory.hpp:67:19:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (DataBits)
   ^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/TransceiverFactory.hpp:67:19:
 error: expected ';' at end of member declaration
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/TransceiverFactory.hpp:69:19:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (StopBits)
   ^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/TransceiverFactory.hpp:69:19:
 error: expected ';' at end of member declaration
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/TransceiverFactory.hpp:71:20:
 error: ISO C++ forbids declaration of 'Q_ENUM' with no type [-fpermissive]
   Q_ENUM (Handshake)
^
/build/wsjtx-2.0.0/obj-x86_64-linux-gnu/wsjtx-prefix/src/wsjtx/Transceiv

[wsjt-devel] Feedback: Contest Log and Colors

[Greg Beam]

Hello All,

 

First, well done to Joe and all the WSJT-X developers!! I've not made any
QSO's for several months (summer 2018) and was able to get up and running in
no time (v2 RC5 Win32) by reading the docs. Made some rookie mistakes with
QSO's, but, was able to make a few Q's to test things out. Overall, I had
very little trouble getting things working properly once I made a couple
Q's.

 

Couple Suggestions / Comments:


These may be covered elsewhere, but, I've not had a chance to review the
archive. As for my setup, I was only using WSJT-X an JT-Alerts. I've no Idea
if / how N1MM ties into things, if at all.

 

-Contest Log Order: Currently, the log is sorted by first in and the user
must use the scroll bar to get to the bottom of the log to see (last-in). I
was wondering if we could get a sorting option that would allow First-In /
Last-In for the log. It's not critical, but for me, I prefer to see the last
Q logged at the top. 

 

-Use Contest Log for WSJT-X/JT-Alerts: I noticed, during the contest, both
WSJT-X and JT-Alerts were using their normal log objects. In the case of
JT-Alerts it was my DXLab DB, and WSJT-X was using its local default log. In
contest mode, I'm not really concerned about contacts I've made, or not, in
my main logging application(s), rather, only what multipliers that I need
for the given contest. It seems to me that all the alerts, colors, and
highlighting should be the result of what is in the Contest Log, not my
normal logging applications. In JT Alerts I had/saw manty B4 calls appearing
even though I had not worked them in the contest. I updated to the latest
JT-Alerts today before running a few Q's; there may be options I'm not up to
speed on at this point.

 

-Colors During Contests: I'm sure colors has been beaten seven ways to
Sunday, however, during a contest I am only concerned with Q's during the
contest; is the station(s) a new band / multi or not? A CQ-ing station in
Green is a distraction if I've already worked them for a given band/mode
combination. It would be helpful, at least for me, if we could have the
color scheme's (in the Band Activity / Rx Frequency Windows) match that of
contest loggers (N1MM, WriteLog, etc). Maybe this is already possible, and I
am behind the 8-ball here, but, it's certainly helpful in the wee-hours of
the morning when the ops are not always in top-mental condition.

 

-Contest/Non-Contest QSO's: I had a few callers using the standard FT8
exchange(s). I need to read the Docs a bit more, but, is there a way to
quickly switch the from contest:   R 599 MT to normal 
 RST just for that one exchange?

 

Anyway, it was good fun for the time I was able to put in. I look forward to
seeing how things progress with the contest modes.

 

73's

Greg, KI7MT

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X & JTSDK future?

[Greg Beam]

Hi Stephen,

 

re: (post #435): After JTSDK 3.0.2 is released, I’ll be separating the non-WSJT 
frameworks into their own projects to make installation/updates a bit easier 
for everyone. At that point, a User Guide will be added which will explain each 
of the scripts/applications (possibly its own project). A jtsdk-dotnet-core 
repository “rename” will also be made to better align with its purpose. 
Currently, the Windows Build Script (JTBuild-cm.cmd) is for testing only and 
will be converted to a CSharp application so it works cross-platform. The whole 
point of moving to CSharp/Java/Python was to allow any one app/script to work 
on multiple platforms without much hassle.

 

Regarding which version of Qt to use, that is entirely up to the WSJT Dev team. 
Qt 5.9 was an LTS release (3yr support I believe) which is why I added it to 
JTSDK v3. If 5.9.x doesn’t work for Mac OS they may need to bump it to 5.10 or 
whatever is deemed appropriate. Either way, it’s a simple change to JTSDK v3 to 
accommodate the need.

73’s

Greg, KI7MT

 

 

From: Stephen Ireland  
Sent: Saturday, November 17, 2018 11:41 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

 

Hi Bill and Greg,

 

I am just a little surprised, after some ongoing comms, that the JTSDK 3.0.1 is 
not the prime, standard Windows Development platform  So that everyone is 
on the same page.

 

Greg, the JTSDK 3.0.1 works a treat... as long as you follow the instructions 
in your main post (#435) at https://groups.io/g/JTSDK/topic/23847651 .

 

[ It even works with “forks” that use subversion s long as the 32-bit SlikSVN 
client found at  https://sliksvn.com/download/ overwrites the deployed version 
].

 

Greg, can you please perhaps put these instructions found in #435 somewhere 
clearly and cleanly and in a prominent place for all for guidance? From you it 
gains validity. 


Bill, I am of the opinion, with considerable evidential backing, that Qt 5.5 is 
lacking for our needs (as some comms has conveyed); migration and 
standardisation to more contemporary Qt versions are mandated. Note – not 
“bleeding edge” versions, but contemporary versions. We then need to stick 
SOLELY with this version for a while.

 

Greg, I think that the AR community significantly missed your attention to us. 
Yet it is always a reminder to us all that personal interests must ALWAYS come 
first and that we in the AR community must be patient. Patience is a virtue – 
but not a virtue shared by many in the AR community ☹ 

If you need a hand, there are many of us here that can and are willing to help 
and contribute. Some of us (including me) may be “pains in the posterior” on 
occasion, but most in our community have their hearts in the right place.

 

Advancement.

 

73

 

Steve I

VK3VM / Vk3SIR

 

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>  for Windows 10

 

From: Greg Beam <mailto:ki7m...@gmail.com> 
Sent: Sunday, 18 November 2018 4:40 PM
To: 'WSJT software development' <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

 

Hi Bill,

 

Understand all re: points in 1 and 2 below.

 

As for item 3, JTSDK-Tools (JTSDK v3) uses the Qt Installer for updates / 
adding GCC tool-chains and prebuilt-components. At present, version JTSDK-Tools 
v3.0.1 supports both Qt 5.5 and Qt 5.9. As most would agree, using the Qt 
Maintenance Tool is the preferred method of installing/updating Qt Components. 
Adding Qt 5.10 would require a minimal change to the environment script(s) and 
I may add that to version 3.0.2 to cover future needs. It appears that Qt 5.5 
thru 5.10 all use the 5.3.x GCC tool-chain which simplifies things a good bit.

Most of the JTSDK-Tools installation is manually performed by the user, as this 
allows greater flexibility with installation and updates. The addition of MSYS2 
is a major improvement over the original MSYS as it provides a powerful package 
manager (pacman, from Arch Linux) to keep utilities up to date.

 

JTSDK-Tools is, for the most part, geared more toward developers rather than 
casual users. The basics are there for anyone wanting to work on whatever 
project they wish. However, it is not a turn-key solution as it was in the past.

 

73’s

Greg, KI7MT

 

From: Bill Somerville mailto:g4...@classdesign.com> > 
Sent: Saturday, November 17, 2018 2:21 PM
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

 

On 17/11/2018 05:24, Greg Beam wrote:

At this point, I’ve no idea how things are working with WSJT-X builds (Win32 or 
Linux) other than what’s being formally published by the WSJT Dev team. 

Hi Greg,

welcome back!

The relevant changes can be summarized as:

1) we are now using git DVCS. I think you are up to speed on this already and 
are aware of the new git repos on the WSJT SourceForge pr

Re: [wsjt-devel] WSJT-X & JTSDK future?

[Greg Beam]

Hi Bill,

 

Understand all re: points in 1 and 2 below.

 

As for item 3, JTSDK-Tools (JTSDK v3) uses the Qt Installer for updates /
adding GCC tool-chains and prebuilt-components. At present, version
JTSDK-Tools v3.0.1 supports both Qt 5.5 and Qt 5.9. As most would agree,
using the Qt Maintenance Tool is the preferred method of installing/updating
Qt Components. Adding Qt 5.10 would require a minimal change to the
environment script(s) and I may add that to version 3.0.2 to cover future
needs. It appears that Qt 5.5 thru 5.10 all use the 5.3.x GCC tool-chain
which simplifies things a good bit.

Most of the JTSDK-Tools installation is manually performed by the user, as
this allows greater flexibility with installation and updates. The addition
of MSYS2 is a major improvement over the original MSYS as it provides a
powerful package manager (pacman, from Arch Linux) to keep utilities up to
date.

 

JTSDK-Tools is, for the most part, geared more toward developers rather than
casual users. The basics are there for anyone wanting to work on whatever
project they wish. However, it is not a turn-key solution as it was in the
past.

 

73's

Greg, KI7MT

 

From: Bill Somerville  
Sent: Saturday, November 17, 2018 2:21 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

 

On 17/11/2018 05:24, Greg Beam wrote:

At this point, I've no idea how things are working with WSJT-X builds (Win32
or Linux) other than what's being formally published by the WSJT Dev team. 

Hi Greg,

welcome back!

The relevant changes can be summarized as:

1) we are now using git DVCS. I think you are up to speed on this already
and are aware of the new git repos on the WSJT SourceForge project page. The
old svn repo is still there but for reference only, no changes have been
posted to it for some time and it is effectively read-only and frozen.

2) The WSJT-X git repo is only being pushed once for each release shortly
after the release is announced, we have been forced to do that by some
unfortunate misuses of unfinished development code. Note that this still
goes much further that the minimum requirement for Open Source applications,
to make their source code publicly available matching any public releases,
since we still make the full change history visible as well to anyone who
cares. We realize that this somewhat reduces the benefit to those who like
to track the latest developments by building from pre-release sources, but
as it has proved impossible to control arbitrary and unauthorized
redistribution of incomplete development works; we have taken that
capability away.

3) The minimum Qt version required to build WSJT-X from WSJT-X v2.0.0 RC4
onwards in v5.5, this has been moved on so we can take advantage of many Qt
enhancements. We may well move on again with the minimum Qt version, perhaps
to v5.9 or even v5.10, this may even be forced upon us to support the latest
macOS version at some point soon. If and when this happens we will be forced
to drop support for MS Windows XP and Vista. Continuing to support old
versions of Qt and old operating system versions will eventually greatly
disadvantage those running on more contemporary operating system versions
and we will only do that for a limited time.

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X & JTSDK future?

[Greg Beam]

Hello All,

 

I've been away from radio, and any/all code work, for the last couple months
due to family situation in FL. I've just gotten things back up/running here
in MT and I'm going through a mountain of emails. At this point, I've no
idea how things are working with WSJT-X builds (Win32 or Linux) other than
what's being formally published by the WSJT Dev team. 

In late summer I was working on a new project (JTSDK v3 => JTSDK-Tools)
which was a tool-chain only version of JTSDK(v2) based on CSharp/.Net Core.
At present, it's supporting Windows but should cross over to *Nix easy
enough as it's all dotnet, Java and Python. For the most part, most of the
scripts/apps are in support of the tool-chain itself rather than building
WSJT-X.


--https://github.com/KI7MT/jtsdk-dotnet-core

--https://github.com/KI7MT/jtsdk-dotnet-core/wiki

There are no formal build-scripts like there were in JTSDK(v2) (Windows or
Linux), though I am (will be) working on a few for personal use. The new
tool-chain adds support for C# (dotnet core), Python, Java, Maven, Gradle,
and Postgresql which I use for other purposes. Note: none of those
frameworks/apps are needed/required for compiling WSJT-X. I also replaced
MSYS with MSYS2 which is used for compiling Hamlib and upgraded several
support tools/libs (svn, libusb-1.0, FFTW, etc). I have a large update in
the dev branch listed above that has not hit master yet but will in the next
couple weeks.

Over the Thanksgiving break I plan to spend a good bit of time catching up
on things and will be posting status-updates on jt...@groups.io
 .

 

73's

Greg, KI7MT

 

From: Marco Calistri via wsjt-devel  
Sent: Friday, October 26, 2018 10:00 AM
To: wsjt-devel@lists.sourceforge.net
Cc: Marco Calistri 
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

 

Adam,

When I say "top posting" I mean that I'm replying over your latest message
(on top of the msg).
I asked this because in other ML the rule wants that user shall to respond
using "bottom posting" or better under the message sent by the OP to whom we
are responding to.

I will send my latest unsuccessful attempt building log directly to your
email.

The issue has nothing to do with other than hamlib libraries which are not
found by cmake.

Best regards and see you later.

-- 
73 de Marco, PY1ZRJ 

Il 26/10/18 12:14, Adam Schaible ha scritto:

Hi Marco,

 

Not sure what you mean by "top posting" replies but hopefully this is
readable for you. 

 

I don't think there is that much of a connection between asciidoc and
hamlib, I searched in Google "does hamlib use asciidoc" and all the results
that appeared were people having build issues with older versions of WSJT-X,
and nothing from all the many other amateur radio programs that also use
hamlib (such as the very popular FLdigi, which I use for PSK31). So I think
we have two separate issues. I did see one older post recommending (during
build of WSJT-X 1.7.0) to compile using cmake flag "-D
WSJT_SKIP_MANPAGES=ON" so you could try adding that? If you still get the
hamlib error during the build after adding this flag, please try to save
more of the logs and post them here, or just send directly to me if they are
too long for the mailing list.

 

Ciao,

 

-- 

  Adam Schaible

  kb3...@schibes.com  

 

 

 

On Thu, Oct 25, 2018, at 1:21 PM, Marco Calistri via wsjt-devel wrote:

Hi Adam,

I go by "top posting" as it is easier to read the reply for everybody.

Do you think is existing any relationship between "asciidoc/texlive" missing
packages on my system and the specific "hamlib not found" error faced during
the building?

I'm not a software developer, but honestly I don't see any relation, so my
first obstacle is to resolve the hamlib issue which I think is being
produced by this parse:

-- Checking for module 'hamlib'

--   Found hamlib, version 4.0~git

-- Found hamlib 

CMake Error at
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find hamlib (missing: hamlib_LIBRARY_DIRS) (Required is at least
  version "3")
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378
(_FPHSA_FAILURE_MESSAGE)
  CMake/Modules/Findhamlib.cmake:81 (find_package_handle_standard_args)
  CMakeLists.txt:852 (find_package)

Are there any verifications I should do on cmake in order to get rid of this
error?

Cheers,

Marco, PY1ZRJ

 

Il 25/10/2018 12:40, Adam Schaible ha scritto:

Hi Marco,

 

Yes I saw the 2,000+ texlive packages on my computer too, I let zypper go
ahead and install them, each one by itself is quite small. I didn't see this
action in other Linux distros (Debian and Solus) that I made build scripts
for earlier, maybe they already pre-installed texlive, or possibly they put
all the very small pieces of texlive code for each language into one very
large package. 

 

If you can get WSJT-X 2.0.0 RC3 to build on Tumbleweed without texlive
please share you

Re: [wsjt-devel] Building WSJT-X Developmental Software

[Greg Beam]

Hi Claude,

Using the WSJT-X Install Doc: 
-- https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL

Here's How I am testing things now (On Windows, Linux is still WIP):
-- Update JTSDK v2: https://github.com/KI7MT/jtsdk-build-scripts-git
-- Build Testing:
https://github.com/KI7MT/jtsdk-build-scripts-git/blob/master/docs/wsjtx-git-
build.md

Note: I've not had much time to test things after pushing the code to
Github. I can say (FWIW), my last build from the Git Repo on SF was
successful.

73's
Greg, KI7MT

-Original Message-
From: Claude Frantz [mailto:claude.fra...@bayern-mail.de] 
Sent: Tuesday, July 10, 2018 12:35 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Building WSJT-X Developmental Software

Hi Bill & All,

Please give us your recommendation about how to switch from svn to git, in
the current context.

Best wishes,
Claude (DJ0OT)


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Building WSJT-X Developmental Software

[Greg Beam]

Hi Mike,

 

I think it’s more than obvious, the tools developers need are not always in 
line with what end-users expect to see. I’m not sure what you mean by 
“collisions”. What I do know is, there are many projects that have hundreds—in 
some cases thousands--of developers working from / on the same code base; the 
Linux Kernel being one of them, and they are using Git as their VCS ( thanks to 
Mr. Torvalds for another gift 😊 ).

 

The bottom line is, the WSJT project has grown to the point where SVN was no 
longer a viable solution for the developers. There will no doubt be a learning 
curve—and a bit of pain along the way--for those not in the core development 
team. We’ve seen these same pains when moving from WSJT to WSJT-X; the original 
WSPR to WSJT-X WSPR, and so on.

 

Generating an arbitrary number (which already exists with git rev-list by the 
way) is meaningless other than the integer changing (maybe not totally 
meaningless, but hey-ho). Git History, as Bill pointed out earlier, and Git 
Log, are powerful tools once folks come to terms with some basic syntax. Entire 
projects devote endless hours to making pretty command line and UI based Git 
revision history tools. At the end of the day, the only “numbers” that really 
matter are those the development team tag for general availability usage. 
Everything else is merely the next step toward an eventual release.

 

We should cute the dev-team some slack. Restructuring the entire svn repository 
from a folder based archive, to that of a distributed control system is no 
small feat. From where I’m sitting, the shift seems to be working well, and as 
expected.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Monday, July 9, 2018 9:49 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Black Michael 
Subject: Re: [wsjt-devel] Building WSJT-X Developmental Software

 

I was speaking from a human/user perspective as I'm aware what a hash 
is...although collisions in git can occur (unlikely) which never occur in a 
one-up counting system (barring rollover).

 

If one were to say "XX" is the most current version of WSJT-X the vast 
majority of users would not know how to figure out if they are current or not.  
Bad to assume people building wsjtx know git.  Ergo my comment which again, was 
made from a human perspective that it's not a very good system...for users of 
WSJT-X.  Works fine for developers and configuration control.  And when one 
says a problem was fixed in "XX" nobody (and I mean nobody) can know if 
their WSJT-X contains that change without grepping the git log to know if it's 
in there.

 

We will be seeing more of this same question in the future I'm sure so some 
consideration should be given to making it a one-up counter again perhaps 
appending it to the 6-digit git number.

 

de Mike W9MDB

 

 

 

On Monday, July 9, 2018, 6:35:11 PM CDT, Bill Somerville mailto:g4...@classdesign.com> > wrote: 

 

 

Hi Mike,

some comments in line below.

On 09/07/2018 17:51, Black Michael via wsjt-devel wrote:
> No...that number does not increment...it's basically random with git 
> (it's a hash value).  It's just the first 6 digits of the "commit" 
> line which is a hexadecimal number
The git SHA-1 hash codes are not random, anything but in fact. They are 
a unique representation of a commit and all it's history that is 
reproducible with absolute certainty even if the commit is moved to a 
different repository. This is key to how git can maintain integrity 
across distributed and unconnected repositories.
>
> There is a means to making an increment version # but it's not 
> frequently used -- basically one way is to count the # of log entries.
It is basically futile and pointless on anything but the most trivial 
centralized work flow model with no branching, ever.
>
> As long as your version matches the most recent log entry 6-digit 
> number you're current.  And yes...it's not a very good system as one 
> can't say "ensure you are at least version X".
That was never true even with Subversion since svn revision numbers are 
common to all branches. An svn revision number is no more than a label 
for a change set on some branch. All it's magnitude tells you is when 
the commit was made with respect to another, but since consecutive 
commits could be to different branches, that tells you little or nothing 
about the logical lineage of a revision.

Your definition of "not a very good system" is based on a very poor 
system as a reference point, so not a very good argument ;)
>
> de Mike W9MDB
>
73
Bill
G4WJS.




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net  
https://lists.sour

[wsjt-devel] Launchpad Redundant WSJTX-Next PPA Removal #Install-Linux

[Greg Beam]

Hello All,

 

This has nothing do with the repo restructuring. Rather, simply cutting down
on redundancy. As with JTSDK-Nix, my wsjtx-next PPA is no longer needed. It
was only used from time-to-time anyway. It won't be a big loss. As GA
Releases are made available, and if the build passes on Launchpad, the
General Availability PPA should be OK.

 

Both the General Availability and Development PPA's are sitting at the same
level currently. It matters not which is being used (if at all). I've
externally marked the PPA as (obsolete), but will leave it enabled and
published for a time to allow folks to migrate off it properly.

 

There are many ways to remove a PPA. The recommended method is through the
Software Center, as that solves any issues with dependencies, and source
lists without much user interaction. It's up to the user.

 

If you are command-line bound, I use a package called ppa-purge. It's easy,
it works, and is nearly hassle free. Package information is located at on
the Ubuntu Package Search Site [1].

 

Refs:

[1] https://packages.ubuntu.com/search?keywords=ppa-purge

 

73's

Greg, KI7MT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK-Nix Final Release v2.0.26 #Install-Linux

[Greg Beam]

Hello All,

 

I finished updating JTSDK-Nix for the restructured repository, or at least,
to extent it can be updated without a significant undertaking. Before 105's
start flying, a couple of things need to be understood. First, JTSDK-Nix
never had the same build capabilities as JTSDK-Win32. It does not build all
branches, tags, and trunk locations. Never has, and probably never will
unless somebody picks it up. Second, IMHO, it would be more efficient to
start from scratch rather than trying to piece together methods to
accommodate all primary build locations in the repository. Finally, like
JTSDK-Win32, unless there are build-breaking items in this release, I do not
plan to continue working the project for the reasons explained in previous
posts.

 

UPGRADING:

"Before" you run JTSDK-Nix (after the upgrade), it is highly advisable to
rename the following folders:

*   Copy or Move /home/$USER/jtsdk/src to /home/$USER/jtsdk/src.bak (or
whatever you like)
*   Copy or Move /home/$USER/jtsdk/wsjtx to /home/$USER/jtsdk/wsjtx.bak
(or whatever you like)

 

If there are any build path or checkout bugs, moving / backing up your
original code ensures it will be as it was before the upgrade.

 

CURRENT CAPABILITIES:

I only tested a few builds. I did not test all available options.  For
WSJT-X, the 1.9.0 tag was tested. The same was true for the WSJT-X
Superbuild.

 

WSJT:

Only builds ^/wsjt/trunk. This is nothing new and has always been. The
source code is just in a different location.

 

WSPR:

Same as WSJT, it only builds the trunk ^/wspr/trunk. And again, this has not
changed. Only the location of the trunk changed.

 

WSJTX-Superbuild:

I don't have a use-case for this script, and rarely use it; others may so I
updated it. The jtsdk-wsjtx-superbuild script only builds from branches
^/wsjtx/branches and tags ^/wsjtx/tags. I tested the build for Tags 1.9.0,
and that was all. Manually using the superbuild script, I believe you can
build what you like. However, I've not looked at it closely in some time,
things may have changed.

WSJT-X:

Originally, WSJT-X built from its trunk which was under ^/branches/wsjtx,
that is no longer the case. The WSJT-X build script is like wsjtx-sb,
insofar as, it only builds ^/wsjtx/branches and tags ^/wsjtx/tags. 

 

Hamlib:

Until something changes in that source repository, it should be ok. For how
long, I do not know.  What I do know is, the JTSDK-Nix Hamlib build script
is not very flexible. Any change will likely break the app builds that
depend on Hamlib being custom built (if using JTSDK Build Scripts that is).
Or at the very least, fail to checkout and build. If all else fails, there's
always the command-line. Instructions are in the SF repository for WSJT-X I
believe.

 

PACKAGING and SOURCE CODE:

 

Launchpad PPA:

https://launchpad.net/~ki7mt/+archive/ubuntu/jtsdk

 

Source Code:

https://github.com/KI7MT/jtsdk-nix/releases/tag/jtsdk-nix-2.0.26

 

 

73's

Greg, KI7MT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

[Greg Beam]

Hi Sandro,

Joe created the branch for something, but, I don't recall what it was. With
the new structure in place, this can probably just be removed from the build
script script.

I've made a few additional changes, nothing of great importance. When I've
amassed enough to warrant another update, this will be taken care of too.

Thanks for the catch.

73's
Greg, KI7MT

-Original Message-
From: Alessandro Gorobey via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Monday, May 28, 2018 1:57 PM
To: WSJT software development 
Cc: Alessandro Gorobey 
Subject: Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

Hi Greg,

on line 135 of qtenv-build-list.cmd there is a ECHO wsjtx_exp >> %devlist%

seems that is not correctly treated, as "svn co" go to c:\

The code in this branch was very active 3 years ago, but I am in doubt if it
is actually usefully.

May be temporary "rem" or skip instructions refer this branch is more
productive than correct the code.

Il 28/05/2018 20:32, Greg Beam ha scritto:
> Hi Sandro,
> 
> Mike (W9MDB) reported another bug this morning which was rather important.
> It has been fixed. The latest version is now 722.
> 
> If you find anything else, let me know and I'll try to get it resolved 
> today.
> 
> 73's
> Greg, KI7MT
> 
> -Original Message-
> From: Alessandro Gorobey via wsjt-devel 
> [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: Monday, May 28, 2018 12:12 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Alessandro Gorobey 
> Subject: Re: [wsjt-devel] Incorrect build location 1.10.0-rc1
> 
> Hi Greg,
> 
> Thanks for fast corrections.
> 
> 
> 
> Il 28/05/2018 09:30, Greg Beam ha scritto:
>> Hi Charlie,
>>
>> Glad you have everything sorted out.
>>
>> There were a couple bugs that Sandro identified, and two more I 
>> forgot to commit in the 720 fix. So, you may want to update again to 721.
>> It's nothing major, just typos on screens and such.
>>
>> I believe the version issue is resolved now. Least wise, I've built 
>> the trunk and it's displaying 1.10.0 properly. However, it's set in 
>> Versions.cmake as a Release Candidate. Not sure if that's an 
>> oversight or what. I guess we'll see soon enough.
>>
>> JTSDK-Nix is still down hard for WSJT-X builds. With my workload (at 
>> real
>> work) is intense right now. I don't know how soon I can get to fixing 
>> JTSDK-Nix.
>>
>> 73's
>> Greg, KI7MT
>>
>>
>>
>> -Original Message-
>> From: char...@sucklingfamily.free-online.co.uk
>> [mailto:char...@sucklingfamily.free-online.co.uk]
>> Sent: Monday, May 28, 2018 1:11 AM
>> To: WSJT software development 
>> Subject: Re: [wsjt-devel] Incorrect build location 1.10.0-rc1
>>
>> Hi Greg
>>
>> After upgrading to JTSDK release 720, the build now appears in a 
>> correctly named folder.
>>
>> Regarding yesterday's issue, I copied my locally edited files (which 
>> were merged yesterday after using Bill's svn switch command) into the 
>> new
> 'trunk'
>> folder.  Build then went with no problems.
>>
>> 73
>>
>> Charlie
>>
>>> Hi Sandro,
>>>
>>> Thanks for the feedback. While version issue is definably a bug, I 
>>> don't think it falls into the category of critical. The version 
>>> information has no effect on WSJT-X final code whatsoever; mainly 
>>> screen displays and folder separation if enabled. From the feedback 
>>> I received, most don't use separate anyway. The line 71 issue is a 
>>> bit more important as it could limit listings, which in turn could 
>>> cause the build to fail erroneously. If I make another update, I'll 
>>> fix that one for sure.
>>>
>>> As for the http/https situation. There were many users complaining 
>>> about https causing them any number of problems. I've had trouble 
>>> with it in the past, but none recently. Obviously, http is working, 
>>> else, we would be having a totally different conversation. However, 
>>> if credentials are being passed, https or ssh would obviously be a 
>>> better
>> choice.
>>>
>>> If the http/https situation is a major concern, edit the script and 
>>> change the urls to https.
>>>
>>> 73's
>>> Greg, KI7MT
>>>
>>>
>>> -Original Message-
>>> From: Alessandro Gorobey via wsjt-devel 
>>> [mailto:wsjt-devel@lists.sourceforge.net]
>>> Sent: S

Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

[Greg Beam]

Hi Sandro,

Mike (W9MDB) reported another bug this morning which was rather important.
It has been fixed. The latest version is now 722.

If you find anything else, let me know and I'll try to get it resolved
today.

73's
Greg, KI7MT

-Original Message-
From: Alessandro Gorobey via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Monday, May 28, 2018 12:12 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Alessandro Gorobey 
Subject: Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

Hi Greg,

Thanks for fast corrections.



Il 28/05/2018 09:30, Greg Beam ha scritto:
> Hi Charlie,
> 
> Glad you have everything sorted out.
> 
> There were a couple bugs that Sandro identified, and two more I forgot 
> to commit in the 720 fix. So, you may want to update again to 721. 
> It's nothing major, just typos on screens and such.
> 
> I believe the version issue is resolved now. Least wise, I've built 
> the trunk and it's displaying 1.10.0 properly. However, it's set in 
> Versions.cmake as a Release Candidate. Not sure if that's an oversight 
> or what. I guess we'll see soon enough.
> 
> JTSDK-Nix is still down hard for WSJT-X builds. With my workload (at 
> real
> work) is intense right now. I don't know how soon I can get to fixing 
> JTSDK-Nix.
> 
> 73's
> Greg, KI7MT
> 
> 
> 
> -Original Message-
> From: char...@sucklingfamily.free-online.co.uk
> [mailto:char...@sucklingfamily.free-online.co.uk]
> Sent: Monday, May 28, 2018 1:11 AM
> To: WSJT software development 
> Subject: Re: [wsjt-devel] Incorrect build location 1.10.0-rc1
> 
> Hi Greg
> 
> After upgrading to JTSDK release 720, the build now appears in a 
> correctly named folder.
> 
> Regarding yesterday's issue, I copied my locally edited files (which 
> were merged yesterday after using Bill's svn switch command) into the new
'trunk'
> folder.  Build then went with no problems.
> 
> 73
> 
> Charlie
> 
>> Hi Sandro,
>>
>> Thanks for the feedback. While version issue is definably a bug, I 
>> don't think it falls into the category of critical. The version 
>> information has no effect on WSJT-X final code whatsoever; mainly 
>> screen displays and folder separation if enabled. From the feedback I 
>> received, most don't use separate anyway. The line 71 issue is a bit 
>> more important as it could limit listings, which in turn could cause 
>> the build to fail erroneously. If I make another update, I'll fix 
>> that one for sure.
>>
>> As for the http/https situation. There were many users complaining 
>> about https causing them any number of problems. I've had trouble 
>> with it in the past, but none recently. Obviously, http is working, 
>> else, we would be having a totally different conversation. However, 
>> if credentials are being passed, https or ssh would obviously be a 
>> better
> choice.
>>
>> If the http/https situation is a major concern, edit the script and 
>> change the urls to https.
>>
>> 73's
>> Greg, KI7MT
>>
>>
>> -Original Message-
>> From: Alessandro Gorobey via wsjt-devel 
>> [mailto:wsjt-devel@lists.sourceforge.net]
>> Sent: Sunday, May 27, 2018 5:23 PM
>> To: WSJT software development 
>> Cc: Alessandro Gorobey 
>> Subject: [wsjt-devel] Incorrect build location 1.10.0-rc1
>>
>> Hi All,
>>
>> I found some code that conflict with 2 digit in minor version
>>
>> JTSDK-QT v2.0.6-0 Release 719
>> windows 10 home 10.0.16299.431
>>
>> C:\JTSDK\scripts\qtenv-build-list.cmd
>> line 134 & 138 (the check of _MINOR is only on one digit, so a 1.10 
>> cannot be listed) svn list %devurl% |grep ^wsjtx-[1-9]\.[8-9] |%sed%
> "s:/*$::"
>> |sort |uniq  >> %devlist% svn list %garurl% |grep ^wsjtx-[1-9]\.[8-9] 
>> |%sed%
>> "s:/*$::" |sort |uniq  > %garlist%
>>
>> in addition, but only a typo on Line 71 (missed 't' in wsjtx) ECHO GA 
>> and RC List ^( ^^/wsjtx/tags^/ ^)^:
>>
>>
>>
>> C:\JTSDK\scripts\qtenv-build-wsjtx.cmd
>> C:\JTSDK\wsjtx\trunk\qt55\1.1.0\Release\{build, install, package} not 
>> C:\JTSDK\wsjtx\trunk\qt55\1.10.0\Release\{build, install, package} as 
>> expected (1.1 vs. 1.10) line 348 (the build location of 1.10 is 1.1) 
>> cat %vfile% |grep "_MINOR" |awk "{print $3}" |cut "-c1" >mi.v & SET 
>> /p miv=> cat Versions.cmake |grep "_MINOR" |awk "{p

Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

[Greg Beam]

Hi Charlie,

Glad you have everything sorted out.

There were a couple bugs that Sandro identified, and two more I forgot to
commit in the 720 fix. So, you may want to update again to 721. It's nothing
major, just typos on screens and such.

I believe the version issue is resolved now. Least wise, I've built the
trunk and it's displaying 1.10.0 properly. However, it's set in
Versions.cmake as a Release Candidate. Not sure if that's an oversight or
what. I guess we'll see soon enough.

JTSDK-Nix is still down hard for WSJT-X builds. With my workload (at real
work) is intense right now. I don't know how soon I can get to fixing
JTSDK-Nix.

73's
Greg, KI7MT



-Original Message-
From: char...@sucklingfamily.free-online.co.uk
[mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: Monday, May 28, 2018 1:11 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

Hi Greg

After upgrading to JTSDK release 720, the build now appears in a correctly
named folder.

Regarding yesterday's issue, I copied my locally edited files (which were
merged yesterday after using Bill's svn switch command) into the new 'trunk'
folder.  Build then went with no problems.

73

Charlie

> Hi Sandro,
>
> Thanks for the feedback. While version issue is definably a bug, I 
> don't think it falls into the category of critical. The version 
> information has no effect on WSJT-X final code whatsoever; mainly 
> screen displays and folder separation if enabled. From the feedback I 
> received, most don't use separate anyway. The line 71 issue is a bit 
> more important as it could limit listings, which in turn could cause 
> the build to fail erroneously. If I make another update, I'll fix that 
> one for sure.
>
> As for the http/https situation. There were many users complaining 
> about https causing them any number of problems. I've had trouble with 
> it in the past, but none recently. Obviously, http is working, else, 
> we would be having a totally different conversation. However, if 
> credentials are being passed, https or ssh would obviously be a better
choice.
>
> If the http/https situation is a major concern, edit the script and 
> change the urls to https.
>
> 73's
> Greg, KI7MT
>
>
> -Original Message-
> From: Alessandro Gorobey via wsjt-devel 
> [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: Sunday, May 27, 2018 5:23 PM
> To: WSJT software development 
> Cc: Alessandro Gorobey 
> Subject: [wsjt-devel] Incorrect build location 1.10.0-rc1
>
> Hi All,
>
> I found some code that conflict with 2 digit in minor version
>
> JTSDK-QT v2.0.6-0 Release 719
> windows 10 home 10.0.16299.431
>
> C:\JTSDK\scripts\qtenv-build-list.cmd
> line 134 & 138 (the check of _MINOR is only on one digit, so a 1.10 
> cannot be listed) svn list %devurl% |grep ^wsjtx-[1-9]\.[8-9] |%sed%
"s:/*$::"
> |sort |uniq  >> %devlist% svn list %garurl% |grep ^wsjtx-[1-9]\.[8-9] 
> |%sed%
> "s:/*$::" |sort |uniq  > %garlist%
>
> in addition, but only a typo on Line 71 (missed 't' in wsjtx) ECHO GA 
> and RC List ^( ^^/wsjtx/tags^/ ^)^:
>
>
>
> C:\JTSDK\scripts\qtenv-build-wsjtx.cmd
> C:\JTSDK\wsjtx\trunk\qt55\1.1.0\Release\{build, install, package} not 
> C:\JTSDK\wsjtx\trunk\qt55\1.10.0\Release\{build, install, package} as 
> expected (1.1 vs. 1.10) line 348 (the build location of 1.10 is 1.1) 
> cat %vfile% |grep "_MINOR" |awk "{print $3}" |cut "-c1" >mi.v & SET /p 
> miv= cat Versions.cmake |grep "_MINOR" |awk "{print $3}" | 
> C:\JTSDK\msys\bin\sed.exe "s:)*$::" >mi.v & SET /p miv=
> Sometimes I have problem with sourceforge svn svn switch --relocate 
> https:// svn:// or svn switch --relocate http:// svn:// seem solve the 
> problem.
>
> --
> 73
> Sandro
> IW3RAB
>
> --
> --
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
>  Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community 

[wsjt-devel] JTSDK-Win32 Bug Fix 2.0.6 Release 720 #Install-Windows

[Greg Beam]

Hello All,

 

Sandro (IW3RAB) identified a couple of issues in JTSDK-Win32 v2.0.6 Release
719. Originally, I didn't think they were critical, least wise, not enough
to warrant an immediate update. As it turns out, the version number bug will
cause you longer term problems if not resolved now.

 

Changes Made:

*   Change checkout urls to HTTPS in the WSJT-X build script
*   Fix a bug that truncated version numbers to 1 digit, for example:
1.1.0  v.s  1.10.0.
*   Fix a typo in wsjtx-list screen display only

 

In the past, many have reported trouble with HTTPS checkouts. I too have had
them, but not recently. The second item will change where the build, install
and package output folders are located:

 

Release 719 - C:\JTSDK\wsjtx\trunk\qt55\1.1.0\8732\{Release . .

Release 720 - C:\JTSDK\wsjtx\trunk\qt55\1.10.0\8732\Release . .

 

Note: 1.10.0 v.s. 1.1.0 in the paths.

 

UPGRADE:

*   Open JTSDK-Maint
*   Type: update
*   Type: upgrade
*   Close and Open JTSDK-QT as normal.

 

You may have trouble with changing URL's from HTTP to HTTPS. Bill and Sandro
discussed a short How-To [1] on the dev-list. I simply removed the checkout
and pulled new. This may not be optimal for developers or those actively
editing sources. It's up to you as to which method is more appropriate.

 

Ref:

[1] https://sourceforge.net/p/wsjt/mailman/message/36327512/

 

73's

Greg, KI7MT

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

[Greg Beam]

Hi Sandro,

I need to make a correction here. I misunderstood your Line-71 comment. I
thought you were saying it was missing a tag. I see now it just a typo, so
it's not of major concern.

I've fixed the line-71, 134 and 138 issues. However, if the file format
changes, it's just going to break again. So, it's not a good long-term
solution for pulling the version before a build.

73's
Greg, KI7MT

-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Sunday, May 27, 2018 9:21 PM
To: 'WSJT software development' 
Cc: 'Alessandro Gorobey' 
Subject: RE: [wsjt-devel] Incorrect build location 1.10.0-rc1

Hi Sandro,

Thanks for the feedback. While version issue is definably a bug, I don't
think it falls into the category of critical. The version information has no
effect on WSJT-X final code whatsoever; mainly screen displays and folder
separation if enabled. From the feedback I received, most don't use separate
anyway. The line 71 issue is a bit more important as it could limit
listings, which in turn could cause the build to fail erroneously. If I make
another update, I'll fix that one for sure.

As for the http/https situation. There were many users complaining about
https causing them any number of problems. I've had trouble with it in the
past, but none recently. Obviously, http is working, else, we would be
having a totally different conversation. However, if credentials are being
passed, https or ssh would obviously be a better choice.

If the http/https situation is a major concern, edit the script and change
the urls to https.

73's
Greg, KI7MT


-Original Message-
From: Alessandro Gorobey via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net]
Sent: Sunday, May 27, 2018 5:23 PM
To: WSJT software development 
Cc: Alessandro Gorobey 
Subject: [wsjt-devel] Incorrect build location 1.10.0-rc1

Hi All,

I found some code that conflict with 2 digit in minor version

JTSDK-QT v2.0.6-0 Release 719
windows 10 home 10.0.16299.431

C:\JTSDK\scripts\qtenv-build-list.cmd
line 134 & 138 (the check of _MINOR is only on one digit, so a 1.10 cannot
be listed) svn list %devurl% |grep ^wsjtx-[1-9]\.[8-9] |%sed% "s:/*$::"
|sort |uniq  >> %devlist% svn list %garurl% |grep ^wsjtx-[1-9]\.[8-9] 
||%sed%
"s:/*$::" |sort |uniq  > %garlist%

in addition, but only a typo on Line 71 (missed 't' in wsjtx) ECHO GA and RC
List ^( ^^/wsjtx/tags^/ ^)^:



C:\JTSDK\scripts\qtenv-build-wsjtx.cmd
C:\JTSDK\wsjtx\trunk\qt55\1.1.0\Release\{build, install, package} not
C:\JTSDK\wsjtx\trunk\qt55\1.10.0\Release\{build, install, package} as
expected (1.1 vs. 1.10) line 348 (the build location of 1.10 is 1.1) cat
%vfile% |grep "_MINOR" |awk "{print $3}" |cut "-c1" >mi.v & SET /p miv=mi.v & SET /p miv=http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Incorrect build location 1.10.0-rc1

[Greg Beam]

Hi Sandro,

Thanks for the feedback. While version issue is definably a bug, I don't
think it falls into the category of critical. The version information has no
effect on WSJT-X final code whatsoever; mainly screen displays and folder
separation if enabled. From the feedback I received, most don't use separate
anyway. The line 71 issue is a bit more important as it could limit
listings, which in turn could cause the build to fail erroneously. If I make
another update, I'll fix that one for sure.

As for the http/https situation. There were many users complaining about
https causing them any number of problems. I've had trouble with it in the
past, but none recently. Obviously, http is working, else, we would be
having a totally different conversation. However, if credentials are being
passed, https or ssh would obviously be a better choice.

If the http/https situation is a major concern, edit the script and change
the urls to https.

73's
Greg, KI7MT


-Original Message-
From: Alessandro Gorobey via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, May 27, 2018 5:23 PM
To: WSJT software development 
Cc: Alessandro Gorobey 
Subject: [wsjt-devel] Incorrect build location 1.10.0-rc1

Hi All,

I found some code that conflict with 2 digit in minor version

JTSDK-QT v2.0.6-0 Release 719
windows 10 home 10.0.16299.431

C:\JTSDK\scripts\qtenv-build-list.cmd
line 134 & 138 (the check of _MINOR is only on one digit, so a 1.10 cannot
be listed) svn list %devurl% |grep ^wsjtx-[1-9]\.[8-9] |%sed% "s:/*$::"
|sort |uniq  >> %devlist% svn list %garurl% |grep ^wsjtx-[1-9]\.[8-9] |%sed%
"s:/*$::" |sort |uniq  > %garlist%

in addition, but only a typo on Line 71 (missed 't' in wsjtx) ECHO GA and RC
List ^( ^^/wsjtx/tags^/ ^)^:



C:\JTSDK\scripts\qtenv-build-wsjtx.cmd
C:\JTSDK\wsjtx\trunk\qt55\1.1.0\Release\{build, install, package} not
C:\JTSDK\wsjtx\trunk\qt55\1.10.0\Release\{build, install, package} as
expected (1.1 vs. 1.10) line 348 (the build location of 1.10 is 1.1) cat
%vfile% |grep "_MINOR" |awk "{print $3}" |cut "-c1" >mi.v & SET /p miv=mi.v & SET /p miv=http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK v2 End of Life Notification #Announcements #Install-Windows #Install-Linux

[Greg Beam]

Hello All,

 

As most on the jt...@groups.io   are aware, I've
been slowly working toward a JTSDK v3 tool chain that supports building not
only WSJT applications, but includes support for .Net Core, Java and
PostgreSQL application development. With the recent WSJT repository changes,
coupled with those yet to be implemented, JTSDK v2 has outlived its useful
purpose. At present, I have some 20+ private repositories I need to migrate
into my jtsdk-dotnet-core project. To me, it makes little sense to keep
putting effort into a project (JTSDK v2 Tool-Chain) that is not well suited
to vertical/horizontal scalability. Not to mention, the scripts were not
designed for a high degree of flexibility at the repository level; evident
by the recent migration results some have experienced.

 

There are several outstanding issues that still need to be addressed,
particularly on Linux. At present, JTSDK-Nix cannot build the WSJT-X
repositories properly (post restructuring). I will try to get JTSDK-Nix
cleaned up in the next day or so, after which, my primary focus will shift
to the JTSDK v3 tool chain, and a long-term package management strategy that
is scalable. As far as JTSDK-Win32 is concerned, I believe it is fully
functional against the new Subversion structure. However, it would not be
well suited for other CVS systems. If critical issues arise, I will address
them promptly.

 

For those unaware, it is my intention to use .Net Core as a cross platform
framework to replace Windows Batch/*Nix Bash scripts for building WSJT
applications with JTSDK v3. At present, script generation is a secondary
concern to the tool chain. Tool chain installation, and long-term management
are first-priority. A list of current activities can be found on Github [1]
for those that may be interested.

 

Such as the case, if anyone is interested in sustaining work for JTSDK v2,
send me an email offline and we can discuss what I know will need to be
addressed sooner rather than later.

 

Refs:

[1]
https://github.com/KI7MT/jtsdk-dotnet-core/blob/master/TODO-3.0.0-7-beta.md

 

73's

Greg, KI7MT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] SourceForge repository changes

[Greg Beam]

Hi Bill,

 

I don’t really don’t have anything further to add to this conversation. I know 
what I was experienced, and fully understand the mechanics of svn switch.

 

If something in the scripts I’ve written is breaking the builds, I will 
certainly address the issue promptly. Baring that, I don’t see this as 
productive.

 

73’s

Greg, KI7MT

 

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, May 27, 2018 2:52 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] SourceForge repository changes

 

On 27/05/2018 21:32, Greg Beam wrote:

While the svn switch works for the source side (sort of), it breaks the build 
tree.

Hi Greg,

absolutely not, the switch is benign as it switches the repo location related 
to the sources to exactly the same sources i.e. their new repo location. It 
should have no impact whatsoever on the build tree. Conversely orphaning any 
work in progress has the worst possible impact on the build tree as it ignores 
exactly that work in progress.

The repo layout is consistent now, the use of the trunk as the "trunk" and 
sibling branches and tags directories for multiple branches and tags is the 
recommended layout for multiple projects in  single repo. For more details see 
here:

http://svnbook.red-bean.com/en/1.7/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

I suspect you are misunderstanding the power of the "svn switch" command, it is 
able to recognize when the old and new repository paths have a common ancestor, 
as any branch and tag withng a project will have with each other and with the 
trunk of the same project, and do exacly what is needed to move smoothly and 
accurately between them. I do this all the time and have none of the issues you 
are stating.

Regardsless of the above, the required switch was from the old repository path 
of some source files to the new location of the same source files.

If the defect is not going to be corrected then those with work in progress 
have two options, either manually move all their modiied files additions and 
deletions to the new local disk location or not use the JTSDK scripts to 
orchestrate svn upadtes and builds. I suspect the former is going to be ok for 
the majority, let's hope no one was working on a major submission with many 
changes.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] SourceForge repository changes

[Greg Beam]

Hi Bill,

 

There are many things that aren’t / weren’t helpful, but it’s not really 
productive to rehash the past is it.  While the svn switch works for the source 
side (sort of), it breaks the build tree. It too can be cleaned, manipulated, 
or simply deleted and rebuilt. I made a choice, one that was logical given the 
severity of disruption to the original structure.

 

As far as I am aware, there is no requirement to use the build script for “real 
development”. The tool chain is there to use, or not, as one see’s fit. I made 
it plainly clear what the outputs would be, and went as far as providing 
exacting examples. I don’t know how much clearer I could have made things. 

 

The layout—even now--differs from one branch to the next which transends the 
new Trunk, Branches, and Tags layout. The names of the folders differ from 
branches to tags. The trunk doesn’t have subfolders, it’s basically flat until 
a branch is created. To say it’s a simple svn switch from one structure to 
another is just not accurate. Sure, in some circumstances, it may very well be, 
but not if they were using these scripts to begin with. The least disruptive 
path forward was the one I chose.

 

73’s

Greg, KI7MT

 

 

 

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, May 27, 2018 1:34 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] SourceForge repository changes

 

Hi Greg,

that may be what was intended but it isn't very helpful for the few JTSDK users 
that do real development. The consequence of the change in workspace location 
is that their incomplete work has been orphaned with the latest JTSDK checking 
out a whole new fresh workspace and building from hat rather than their 
existing workspace with work in progresss.

I had assumed that the changes to accomodate the new repository layout would 
adjust any checkout commands to checkout/update exactly the same workspace 
contents. The `svn switch` command I gave was all that was necessary to do that 
so long as any checkout command placed the workspace at the same local disk 
path.

73
Bill
G4WJS.

On 27/05/2018 18:23, Greg Beam wrote:

Hi Bill, Charlie,
 
JTSDK is doing exactly what It is intended to do; it is checking out to:
 
C:\JTSDK\src\wsjtx\{trunk, branches, tags}
 
I posted both screenshots of, and wrote out the new paths in the upgrade email 
I posted. I don’t understand how it is not working as expected.
 
73's
Greg, KI7MT
 
-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, May 27, 2018 8:08 AM
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Subject: Re: [wsjt-devel] SourceForge repository changes
 
Hi Charlie,
 
I will guess that the JTSDK is not quite right and is checking out the WSJT-X 
sources in C:\JTSDK\src\wsjtx\trunk instead of C:\JTSDKsrc\wsjtx as used 
previously. You need to delete the new trunk directory and all its contents. 
I'm not sure what JTSDK changes are needed to fix it so that it uses the 
correct workspace directory and builds from it.
 

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] SourceForge repository changes

[Greg Beam]

Hi Bill, Charlie,

JTSDK is doing exactly what It is intended to do; it is checking out to:

C:\JTSDK\src\wsjtx\{trunk, branches, tags}

I posted both screenshots of, and wrote out the new paths in the upgrade email 
I posted. I don’t understand how it is not working as expected.

73's
Greg, KI7MT

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, May 27, 2018 8:08 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] SourceForge repository changes

Hi Charlie,

I will guess that the JTSDK is not quite right and is checking out the WSJT-X 
sources in C:\JTSDK\src\wsjtx\trunk instead of C:\JTSDKsrc\wsjtx as used 
previously. You need to delete the new trunk directory and all its contents. 
I'm not sure what JTSDK changes are needed to fix it so that it uses the 
correct workspace directory and builds from it.

Yes you can copy from command shells, the MS Windows ones are not helpful and 
the select is dumb, not  understanding line breaks but it cam be done, try a 
right-click and select "Edit->Mark" then 
left-click+drag the cursor over what you want to copy then right-click
and select "Edit->Copy".

73
Bill
G4WJS.

On 27/05/2018 14:43, char...@sucklingfamily.free-online.co.uk wrote:
> Done - screenshots here:
>
> https://drive.google.com/drive/folders/1-ZYqPCEN2Nnc497P2t3_pRmkjm-HxyZD?usp=sharing
>
> Is there any way of copying the contents of a command window to save
> taking screenshots?
>
> 73
>
> Charlie
>
>
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK-Win32 Upgrade Available #Install-Windows

[Greg Beam]

Hello All,

 

Following Bill's (G4WJS) WSJT-X Repository Restructuring Announcement [1],
I've updated the JTSDK-Win32 WSJT-X build script to reflect those changes. I
did not use svn switch as the source (checkout), and final build locations
have changed to match the new SF layout.

 

UPGRADE:

*   Open JTSDK-Maint
*   Type: update
*   Type: upgrade
*   Close, then reopen JTSDK-Maint. Verify you are on v2.0.6 Release 719
or greater, then close it.

 

BUILD LOCATIONS:

The source (checkout), final build, install and package locations have all
changed:

*   Source: C:\JTSDK\src\wsjtx\{trunk, branches, tags}
*   Artifact Locations: C:\JTSDK\wsjtx\{trunk, branches,
tags}\{qt_ver}\app_ver\svn_ver\{Release, Debug}{build, install, package}

 

BUILD TESTING:

I've tested the builds listed below. They all completed without error. You
should also test them to ensure all is working properly in your environment.
WSJT-X v1.8 was not run, as I did not want any issues with my WSJTX.ini file
(it's up to you). Not to say there would be; I just did not want to
introduce another variable during build testing.

 

Update WSJT-X Build Lists:

*   Open JTSDK-QT
*   Type: wsjtx-list -u
*   The command should update the WSJT-X build lists for
^/wsjtx/branches and ^/wsjtx/tags

 

Set the following Options:

*   enable-separate
*   enable-autosvn
*   enable-clean
*   enable-rcfg
*   enable-qt55
*   enable-autorun
*   disable-quiet
*   disable-skipsvn

 

Build the Trunk (^/wxjtx/trunk):

*   Open JTSDK-QT
*   Type: build-wsjtx rinstall
*   At the time I built the trunk, the revision was r8729. It built, and
ran without error.
*   New Source Location: C:\JTSDK\src\wsjtx\trunk
*   New Artifact Location:
C:\JTSDK\wsjtx\trunk\qt55\1.9.0\8729\Release\{build,install,package}
*   See Attached Image: wsjtx-1.9-trunk.png

 

Build a Branch (^/wsjtx/branches):

*   Open JTSDK-QT
*   Type: disable-autorun
*   Type: wsjtx-list -d
*   disable-autorun
*   Pick one to build. I chose wsjtx-1.8 because wsjtx-1.9.x is not
available in ^/wsjtx/branches
*   Type: build-wsjtx -b dev -n wsjtx-1.8 -c release -t install
*   I did not run this build. However, it finished without errors.
*   New Source Location: C:\JTSDK\src\wsjtx\branches\wsjtx-1.8
*   New Artifact Location:
C:\JTSDK\wsjtx\trunk\qt55\1.8.1\8675\Release\{build,install,package}
*   Attached Image: wsjtx-1.8-branch.png

 

Build a Tag (^/wsjtx/tags):

*   Open JTSDK-QT
*   Type: enable-autorun
*   Type: wsjtx-list -g
*   Pick one to build. I chose wsjtx-1.9.0
*   Type: build-wsjtx -b gar -n wsjtx-1.9.0 -c release -t install
*   At the time I built the tag, the revision was a r8731. It built, and
ran without errors.
*   New Source Location: C:\JTSDK\src\wsjtx\tags\wsjtx-1.9.0
*   New Artifact Location:
C:\JTSDK\wsjtx\tags\qt55\1.9.0\8731\Release\{build,install,package}
*   See Attached Image: wsjtx-1.9-tags.png

 

Error Reporting:

If any of the builds fail, please report them to jt...@groups.io

 

73's

Greg, KI7MT

 

Refs:

[1] https://sourceforge.net/p/wsjt/mailman/message/36326890/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Launchpad Usage with Debian Proper Installations #Install-Linux

[Greg Beam]

Hello All,

 

There seems to be a lot of confusion about the different package schemas
relating to Ubuntu and Debian. Put simply, Ubuntu would not exist without
Debian. With that in mind, I put together a quick Gist for those using
Debian Proper. If this, or something similar, would be helpful to Debian
Users I can add it as a permanent fixture to JTSDK-Nix documentation.

 

Link: Debian Launchpad PPA How-To
 

 

73's

Greg, KI7MT

 

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

[Greg Beam]

Hi Paul,

 

I forgot about this as I don’t use it much, but, I think it’s what you’re after 
for a simple release representation. On the Project Main Page there is a 
Releases Link <https://github.com/KI7MT/jtsdk-nix/releases>  at the top that 
takes you here:

 

https://github.com/KI7MT/jtsdk-nix/releases

 

73’s

Greg, KI7MT

 

 

From: Paul Bramscher [mailto:pfb...@comcast.net] 
Sent: Friday, May 25, 2018 7:50 AM
To: Greg Beam ; WSJT software development 

Subject: Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

 

Hi Greg--

Thanks for the update, it compiled fine on my Debian 9.4 PC -- and it built 
WSJT-X rc4 8702 without trouble.

On SourceForge it was a simple matter to visually inspect which tar/gz was the 
most current version and to download it. What's the best way to visually 
inspect the most recently tagged/version on github?

e.g. click 'Clone or Download' and then 'Download Zip'? I see in your docs that 
you have a link here: https://github.com/KI7MT/jtsdk-nix/tree/jtsdk-nix-2.0.25

Just wondering if there's a handy visual cue somewhere that I might check every 
so often to see whether you've made a new release. Since I'm not an active 
contributor on it, I don't benefit much from a command-line git checkout -- 
downloading a single zip/tar is fine for my purposes.

Thanks again,
73, KD0KZE / Paul

> On May 25, 2018 at 3:59 AM Greg Beam  <mailto:ki7m...@gmail.com> > wrote:
> 
> 
> Hello All,
> 
> Just a quick follow up.
> 
> I pushed JTSDK-Nix v2.0.25 to Gitbub. Tested builds on WSL (18.04), VM
> (16.04 | 18.04), Native (14.04) for wsjtx-1.9.0-rc4. All passed.
> 
> Attached is a couple of screen-shots from the Windows Subsystem Linux (WSL -
> Ubuntu 18.04) build. Using Xming, one could probably run WSJT-X from the WSL
> instance for testing. I'm not sure about the interoperability layer for
> com-devices, but, the UI should at least fire up.
> 
> 73's
> Greg, KI7MT
> 
> -Original Message-
> From: Greg Beam [mailto:ki7m...@gmail.com] 
> Sent: Thursday, May 24, 2018 11:02 PM
> To: 'WSJT software development'  <mailto:wsjt-devel@lists.sourceforge.net> >
> Subject: RE: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available
> 
> Hi Paul, Bill,
> 
> I didn't re-work any of the WSJT-X build scripts, so obviously the URL's
> would be wrong. As I understand it:
> 
> ^wsjt/wsjt/branches/wsjtx => is still the current dev branch "I think "
> ^/wsjtx/branches/x.y.z => are historical dev branches =< 1.8 and Joe's test
> branches ^/wsjtx/tags => contain all the previous tagged branches
> 
> So rc5, or whatever the future tag will be called, is living in
> ^/branches/wsjtx at present.
> 
> I'm not sure I want to restructure several scripts to accommodate a
> temporary location for the current WSJT-X development branch. Fixing
> ^/wsjtx/branches and ^/wsjtx/tags is just a matter of changing two URL's in
> one script; that's already done, I just need to tag it and push it to the
> Github repo. As a result, 2/3 (for an easy description) of the WSJT-X code
> has been migrated to the new structure (^/wsjtx/branches and ^/wsjtx/tags),
> and the remaining 1/3 (for lack of a better designation) is left as was in
> ^/branches/wsjtx.
> 
> I've updated the docs on SF and for Github. When the push to Github happens
> (2.0.25), that should help clear up the previous version confusion. I built
> wsjtx-1.9.0-rc4 without any trouble on my local machine. I think that is
> working as expected after the URL change for ^/wsjtx/tags.
> 
> 73's
> Greg, KI7MT
> 
> On 24/05/2018 13:32, Paul Bramscher wrote:
> > Thanks for the links -- I've got 2.0.24 installed using that source 
> > zip, but it reports this if I try to build rc candidate
> > wsjtx-1.9.0-rc4 (and a few others that I tried):
> >
> > The following build will be run:
> >
> > * Branch ..: ^/tags
> > * Name : wsjtx-1.9.0-rc4
> > * Type : Release
> > * Target ..: install
> >
> >
> > -
> > SVN UPDATE
> > -
> >
> > Checking Out New Version of wsjtx-1.9.0-rc4
> > svn: E17: URL
> > 'https://svn.code.sf.net/p/wsjt/wsjt/tags/wsjtx-1.9.0-rc4' doesn't 
> > exist
> >
> > Thanks,
> > 73, KD0KZE / Paul
> 
> Hi Paul,
> 
> that URL is wrong, it should be
> 'https://svn.code.sf.net/p/wsjt/wsjt/wsjtx/tags/wsjtx-1.9.0-rc4'.
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> --
> 

Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

[Greg Beam]

HI Paul,

 

Originally, I had an integration setup with SF form Github. Whenever a tag hits 
Gitub, it would push it to SF. It wasn’t working to well at the time. Maybe 
it’s improved somewhat since then, and I’ll have another look at it.

 

The Clone / Download button on Github always pulls the master branch. It should 
(in theory) always be runnable. I’ve not been using branching as I am the only 
one working on it, but I should do really. 

 

The branch:master pull down can list any existing branch, and has a tab for 
tags. It wouldn’t’ me much trouble to add Version Info table at the top of the 
README somewhere. I’ll look at that on the next update.

 

73’s

Greg, KI7MT

 

 

From: Paul Bramscher [mailto:pfb...@comcast.net] 
Sent: Friday, May 25, 2018 7:50 AM
To: Greg Beam ; WSJT software development 

Subject: Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

 

Hi Greg--

Thanks for the update, it compiled fine on my Debian 9.4 PC -- and it built 
WSJT-X rc4 8702 without trouble.

On SourceForge it was a simple matter to visually inspect which tar/gz was the 
most current version and to download it. What's the best way to visually 
inspect the most recently tagged/version on github?

e.g. click 'Clone or Download' and then 'Download Zip'? I see in your docs that 
you have a link here: https://github.com/KI7MT/jtsdk-nix/tree/jtsdk-nix-2.0.25

Just wondering if there's a handy visual cue somewhere that I might check every 
so often to see whether you've made a new release. Since I'm not an active 
contributor on it, I don't benefit much from a command-line git checkout -- 
downloading a single zip/tar is fine for my purposes.

Thanks again,
73, KD0KZE / Paul

> On May 25, 2018 at 3:59 AM Greg Beam  <mailto:ki7m...@gmail.com> > wrote:
> 
> 
> Hello All,
> 
> Just a quick follow up.
> 
> I pushed JTSDK-Nix v2.0.25 to Gitbub. Tested builds on WSL (18.04), VM
> (16.04 | 18.04), Native (14.04) for wsjtx-1.9.0-rc4. All passed.
> 
> Attached is a couple of screen-shots from the Windows Subsystem Linux (WSL -
> Ubuntu 18.04) build. Using Xming, one could probably run WSJT-X from the WSL
> instance for testing. I'm not sure about the interoperability layer for
> com-devices, but, the UI should at least fire up.
> 
> 73's
> Greg, KI7MT
> 
> -Original Message-
> From: Greg Beam [mailto:ki7m...@gmail.com] 
> Sent: Thursday, May 24, 2018 11:02 PM
> To: 'WSJT software development'  <mailto:wsjt-devel@lists.sourceforge.net> >
> Subject: RE: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available
> 
> Hi Paul, Bill,
> 
> I didn't re-work any of the WSJT-X build scripts, so obviously the URL's
> would be wrong. As I understand it:
> 
> ^wsjt/wsjt/branches/wsjtx => is still the current dev branch "I think "
> ^/wsjtx/branches/x.y.z => are historical dev branches =< 1.8 and Joe's test
> branches ^/wsjtx/tags => contain all the previous tagged branches
> 
> So rc5, or whatever the future tag will be called, is living in
> ^/branches/wsjtx at present.
> 
> I'm not sure I want to restructure several scripts to accommodate a
> temporary location for the current WSJT-X development branch. Fixing
> ^/wsjtx/branches and ^/wsjtx/tags is just a matter of changing two URL's in
> one script; that's already done, I just need to tag it and push it to the
> Github repo. As a result, 2/3 (for an easy description) of the WSJT-X code
> has been migrated to the new structure (^/wsjtx/branches and ^/wsjtx/tags),
> and the remaining 1/3 (for lack of a better designation) is left as was in
> ^/branches/wsjtx.
> 
> I've updated the docs on SF and for Github. When the push to Github happens
> (2.0.25), that should help clear up the previous version confusion. I built
> wsjtx-1.9.0-rc4 without any trouble on my local machine. I think that is
> working as expected after the URL change for ^/wsjtx/tags.
> 
> 73's
> Greg, KI7MT
> 
> On 24/05/2018 13:32, Paul Bramscher wrote:
> > Thanks for the links -- I've got 2.0.24 installed using that source 
> > zip, but it reports this if I try to build rc candidate
> > wsjtx-1.9.0-rc4 (and a few others that I tried):
> >
> > The following build will be run:
> >
> > * Branch ..: ^/tags
> > * Name : wsjtx-1.9.0-rc4
> > * Type : Release
> > * Target ..: install
> >
> >
> > -
> > SVN UPDATE
> > -
> >
> > Checking Out New Version of wsjtx-1.9.0-rc4
> > svn: E17: URL
> > 'https://svn.code.sf.net/p/wsjt/wsjt/tags/wsj

Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

[Greg Beam]

Hello All,

Just a quick follow up.

I pushed JTSDK-Nix v2.0.25 to Gitbub. Tested builds on WSL (18.04), VM
(16.04 | 18.04), Native (14.04) for wsjtx-1.9.0-rc4. All passed.

Attached is a couple of screen-shots from the Windows Subsystem Linux (WSL -
Ubuntu 18.04) build. Using Xming, one could probably run WSJT-X from the WSL
instance for testing. I'm not sure about the interoperability layer for
com-devices, but, the UI should at least fire up.

73's
Greg, KI7MT

-Original Message-----
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Thursday, May 24, 2018 11:02 PM
To: 'WSJT software development' 
Subject: RE: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

Hi Paul, Bill,

I didn't re-work any of the WSJT-X build scripts, so obviously the URL's
would be wrong. As I understand it:

^wsjt/wsjt/branches/wsjtx => is still the current dev branch "I think "
^/wsjtx/branches/x.y.z => are historical dev branches =< 1.8 and Joe's test
branches ^/wsjtx/tags => contain all the previous tagged branches

So rc5, or whatever the future tag will be called, is living in
^/branches/wsjtx at present.

I'm not sure I want to restructure several scripts to accommodate a
temporary location for the current WSJT-X development branch. Fixing
^/wsjtx/branches and ^/wsjtx/tags is just a matter of changing two URL's in
one script; that's already done, I just need to tag it and push it to the
Github repo. As a result, 2/3 (for an easy description) of the WSJT-X code
has been migrated to the new structure (^/wsjtx/branches and ^/wsjtx/tags),
and the remaining 1/3 (for lack of a better designation) is left as was in
^/branches/wsjtx.

I've updated the docs on SF and for Github. When the push to Github happens
(2.0.25), that should help clear up the previous version confusion. I built
wsjtx-1.9.0-rc4 without any trouble on my local machine. I think that is
working as expected after the URL change for ^/wsjtx/tags.

73's
Greg, KI7MT

On 24/05/2018 13:32, Paul Bramscher wrote:
> Thanks for the links -- I've got 2.0.24 installed using that source 
> zip, but it reports this if I try to build rc candidate
> wsjtx-1.9.0-rc4 (and a few others that I tried):
>
> The following build will be run:
>
> * Branch ..: ^/tags
> * Name : wsjtx-1.9.0-rc4
> * Type : Release
> * Target ..: install
>
>
> -
> SVN UPDATE
> -
>
> Checking Out New Version of wsjtx-1.9.0-rc4
> svn: E17: URL
> 'https://svn.code.sf.net/p/wsjt/wsjt/tags/wsjtx-1.9.0-rc4' doesn't 
> exist
>
> Thanks,
> 73, KD0KZE / Paul

Hi Paul,

that URL is wrong, it should be
'https://svn.code.sf.net/p/wsjt/wsjt/wsjtx/tags/wsjtx-1.9.0-rc4'.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

[Greg Beam]

Hi Paul, Bill,

I didn't re-work any of the WSJT-X build scripts, so obviously the URL's
would be wrong. As I understand it:

^wsjt/wsjt/branches/wsjtx => is still the current dev branch "I think "
^/wsjtx/branches/x.y.z => are historical dev branches =< 1.8 and Joe's test
branches
^/wsjtx/tags => contain all the previous tagged branches

So rc5, or whatever the future tag will be called, is living in
^/branches/wsjtx at present.

I'm not sure I want to restructure several scripts to accommodate a
temporary location for the current WSJT-X development branch. Fixing
^/wsjtx/branches and ^/wsjtx/tags is just a matter of changing two URL's in
one script; that's already done, I just need to tag it and push it to the
Github repo. As a result, 2/3 (for an easy description) of the WSJT-X code
has been migrated to the new structure (^/wsjtx/branches and ^/wsjtx/tags),
and the remaining 1/3 (for lack of a better designation) is left as was in
^/branches/wsjtx.

I've updated the docs on SF and for Github. When the push to Github happens
(2.0.25), that should help clear up the previous version confusion. I built
wsjtx-1.9.0-rc4 without any trouble on my local machine. I think that is
working as expected after the URL change for ^/wsjtx/tags.

73's
Greg, KI7MT

On 24/05/2018 13:32, Paul Bramscher wrote:
> Thanks for the links -- I've got 2.0.24 installed using that source 
> zip, but it reports this if I try to build rc candidate
> wsjtx-1.9.0-rc4 (and a few others that I tried):
>
> The following build will be run:
>
> * Branch ..: ^/tags
> * Name : wsjtx-1.9.0-rc4
> * Type : Release
> * Target ..: install
>
>
> -
> SVN UPDATE
> -
>
> Checking Out New Version of wsjtx-1.9.0-rc4
> svn: E17: URL
> 'https://svn.code.sf.net/p/wsjt/wsjt/tags/wsjtx-1.9.0-rc4' doesn't 
> exist
>
> Thanks,
> 73, KD0KZE / Paul

Hi Paul,

that URL is wrong, it should be
'https://svn.code.sf.net/p/wsjt/wsjt/wsjtx/tags/wsjtx-1.9.0-rc4'.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

[Greg Beam]

Hi Paul,

 

Source Code - Github : 
https://github.com/KI7MT/jtsdk-nix/archive/jtsdk-nix-2.0.24.zip

 

Prebuilt Packages - Launchpad: 
https://launchpad.net/~ki7mt/+archive/ubuntu/jtsdk

 

I don’t follow Debian much anymore, so I’ve no idea which versions of Ubuntu 
correlate with Debian. And yes, the docs need some attention for sure.

 

73’s

Greg, KI7MT

 

From: Paul Bramscher [mailto:pfb...@comcast.net] 
Sent: Wednesday, May 23, 2018 8:30 PM
To: Greg Beam ki7m...@gmail.com <mailto:ki7m...@gmail.com> 

; wsjtgr...@yahoogroups.com; WSJT software development 

Subject: Re: [wsjt-devel] JTSDK Win32 and Nix Upgrade Available

 

Greetings--

 

I'm running Debian 9.x and the most recent version of JTSDK on SourceForge 
(2.0.22) that I see.  I get this error when launching it now:

 

svn: warning: W160013: URL 'http://svn.code.sf.net/p/wsjt/wsjt/tags' 
<http://svn.code.sf.net/p/wsjt/wsjt/tags%27>  non-existent in revision 8722
svn: E29: Could not list all targets because some targets don't exist

 

The docs on the github site suggest this first:

"Download jtsdk-nix-2.0.21.tar.gz" (Then extract, build, etc.).  This has been 
the method I've used all along, I prefer not to add a PPA.  Is there a 2.0.23 
or somesuch available yet on the SourceForge site that contains these changes?

 

73, KD0KZE / Paul

On May 23, 2018 at 8:35 PM Greg Beam mailto:ki7m...@gmail.com> > wrote:

Hello All,

 

The WSJT application layout was restructured today, and now lives in 
^/wsjt/{trunk, branches, tags}. I have updated both JTSDK-Win32 and JTSDK-Nix 
to accommodate the new layout. When the WSJT-X is relocated (no target date for 
that move yet), that will trigger another round of updates.

 

JTSDK-Win32 Upgrade (to => v2.0.6 Release 718):

*   Open JTSDK-Maint
*   Update
*   Upgrade
*   That should be all that is needed.
*   Check out and build commands have not changed

 

JTSDK-Nix Upgrade (to => 2.0.24-1):

*   I’ve pushed the updates to my JTSDK PPA on Launchpad
*   sudo apt-get update && sudo apt-get upgrade 
*   That should bring you up to date.
*   Source Code Available @ git://github.com/KI7MT/jtsdk-nix.git

 

If you run into problems with either platform, please report them to 
jt...@groups.io <mailto:jt...@groups.io> 

 

73’s

Greg, KI7MT


 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK Win32 and Nix Upgrade Available

[Greg Beam]

Hello All,

 

The WSJT application layout was restructured today, and now lives in
^/wsjt/{trunk, branches, tags}. I have updated both JTSDK-Win32 and
JTSDK-Nix to accommodate the new layout. When the WSJT-X is relocated (no
target date for that move yet), that will trigger another round of updates.

 

JTSDK-Win32 Upgrade (to => v2.0.6 Release 718):

*   Open JTSDK-Maint
*   Update
*   Upgrade
*   That should be all that is needed.
*   Check out and build commands have not changed

 

JTSDK-Nix Upgrade (to => 2.0.24-1):

*   I've pushed the updates to my JTSDK PPA on Launchpad
*   sudo apt-get update && sudo apt-get upgrade 
*   That should bring you up to date.
*   Source Code Available @ git://github.com/KI7MT/jtsdk-nix.git

 

If you run into problems with either platform, please report them to
jt...@groups.io

 

73's

Greg, KI7MT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK Win32 and Nix Upgrade Available

[Greg Beam]

Hello All,

 

Following the SF Repository restructuring message from Bill (G4WJS), I have
updated both JTSDK-Win32 and JTSDK-Nix to accommodate the new layout. When
the WSJT trunk is fully relocated, that will trigger another round of
updates.

JTSDK-Win32 Upgrade (to => v2.0.6 Release 717):

*   Open JTSDK-Maint
*   update
*   upgrade
*   That should be all that is needed.
*   Check out and build commands have not changed

 

JTSDK-Nix Upgrade (to => 2.0.23-1):

*   I've pushed the updates to my JTSDK PPA on Launchpad
*   sudo apt-get update && sudo apt-get upgrade 
*   That should bring you up to date.
*   Source Code Available @ git://github.com/KI7MT/jtsdk-nix.git

 

If you run into problems with either platform, please report them to
jt...@groups.io  

 

73's

Greg, KI7MT

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fwd: WSJT-X Suggestion

[Greg Beam]

Hi Jeff,

 

Joe will have to address the question as to whether they would implement the 
feature.

 

In the meantime, JT-Alerts is a “very useful” tool that will do what you are 
asking, and much more!!

 

https://hamapps.com/

 

73’s

Greg, KI7MT

 

 

From: k7xq [mailto:k...@elite.net] 
Sent: Tuesday, May 15, 2018 11:44 PM
To: WSJT software development 
Subject: [wsjt-devel] Fwd: WSJT-X Suggestion

 



 Original message 
From: k7xq mailto:k...@elite.net> > 
Date: 5/7/18 2:32 AM (GMT-08:00) 
To: wsjtgr...@yahoogroups.com   
Subject: WSJT-X Suggestion 

 

Hello,

I am a current user of WSJT-X.  When using the program, stations not yet worked 
will show up in a purple background and then once worked, will turn green per 
default.  The problem is if I worked the station on 40M but haven't worked the 
station on 80M, the callsign will remain green on 80M .Is it possible on future 
revisions of the program to have the option of using the color coding per band 
rather than universally on all bands?

 

Sincerely,

Jeff K7XQ

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Build environment macOS 10.13.4

[Greg Beam]

Hi Megan,

 

I’m not sure I understand your meaning of switch to the appropriate branch. But 
in any case, WSJT (the original application) is Python based and resides in the 
Sourceforge trunk. WSJT-X resides in a branch of the trunk and is Qt5 based.

 

If you are after a runnable-version for OSX, installers can be found in the 
files section on Sourceforge. Bill (G4WJS) compiles a version of OSX users as 
well (*.dmg file). I believe (though I’ve been out of the loop for a bit) 
1.9.3.rc3 is the last prebuilt version posted for GA testing.

 

https://sourceforge.net/projects/wsjt/files/wsjtx-1.9.0-rc3/

 

Outside of that, I can’t really help much with setting up the build environment 
for OSX. There are instructions and Bill can no doubt get you sorted out with 
things if need be.

 

More info for Compiling:

https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/INSTALL

 

73’s

Greg, KI7MT 

 

 

From: Megan Woods [mailto:megan.wo...@woods-gebler.com] 
Sent: Tuesday, May 15, 2018 11:00 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Build environment macOS 10.13.4

 

Ahh ok..

 

I didn’t realise that it will switch to the appropriate branch and start over.,

 

Megan 

 

 

 

 

On Wed, 16 May 2018 at 2:53 pm, Greg Beam mailto:ki7m...@gmail.com> > wrote:

Hello All,

 

First, there’s been little to know development effort on WSJT in a good while 
(2yrs or more maybe?). Another guess, but, I was probably the last one to 
update the autotools for WSJT, and can guarantee there was no testing done with 
GCC 8 😊

 

WSJT-X is where the current development effort is.  Many are successfully 
building WSJT-X on OSX. Help should be plentiful in that regard. Not to 
mention, decoder performance and all the other improvements (far too many to 
list) have been made exclusively to the WSJT-X branch.

 

73’s

Greg, KI7MT

 

From: Georg Isenbürger [mailto:g...@av8r.de <mailto:g...@av8r.de> ] 
Sent: Tuesday, May 15, 2018 10:23 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] Build environment macOS 10.13.4

 

Hi Megan, 

 

I have tried multiple times to setup the OSX environment. I ran into similar 
issues and finally gave up. Hopefully in the not to far future there will be an 
installer package that builds the environment like under Windows…

 

regards

 

Georg

 

 

Am 16.05.2018 um 03:44 schrieb Megan Woods mailto:megan.wo...@woods-gebler.com> >:

 

Hi,

 

I have been trying to build:

Relative URL: ^/trunk

Repository Root: https://svn.code.sf.net/p/wsjt/wsjt

Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79

Revision: 8658

 

on 

 

  System Version: macOS 10.13.4 (17E202)

  Kernel Version: Darwin 17.5.0

 

I have had a succession of issues satisfying build tool chain especially 
concerning Fortran.

 

Presently it is using:

 

FC   = gfortran

FCV= gnu95

 

I have an issue with unresolved symbols for x86_64 which will definitely be an 
issue with my build environment.

 

I was wondering someone who builds on OSX could give me some pointers as to how 
they set their environment up please.

 

Megan

 

 

Here is the failing output:

 

RUN F2PY Audio.so

-

/usr/local/Cellar/numpy/1.14.3_1/bin/f2py3.6 -c --quiet --fcompiler=gnu95 
--f77exec=gfortran --f90exec=gfortran \

--opt="-cpp -fbounds-check -O2"  -L/usr/local/lib 
-L/usr/local/Cellar/portaudio/19.6.0/lib 
-L/usr/local/Cellar/portaudio/19.6.0/lib -L/usr/local/lib  -L -lfftw3f 
-lportaudio -lpthread -lsamplerate  libjt.a -m Audio ftn_init.f90 ftn_quit.f90 
audio_init.f90 spec.f90 getfile.f90 azdist0.f90 astro0.f90 chkt0.f90

rmbadname1: Replacing "len" with "len_bn".

{}

{}

{}

{}

{}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(in)']}

{'attrspec': ['intent(in)']}

{'attrspec': ['intent(in)']}

{'attrspec': ['intent(in)']}

{'attrspec': ['intent(in)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

{'attrspec': ['intent(out)']}

In file included from 
/var/folders/dk/dhmpt9ts4ylfqywy01_83whwgn/T/tmp0nf1vt18/src.macosx-10.13-x86_64-3.6/Audiomodule.c:16:

Re: [wsjt-devel] Subprocess Error (full details captured)

[Greg Beam]

Hi Steve, 

 

Not sure if the is on point or not, but, the path to the file is a bit wonky:

 

'C:\Users\Steve\AppData\Local\Temp\WSJT-X/houndcallers.txt'

 

Note the forward slash before houdcallers.txt.

 

Could be something, or nothing. Just an observation.

 

73’s

Greg, KI7MT

 

From: Steve Sacco NN4X [mailto:n...@embarqmail.com] 
Sent: Tuesday, May 15, 2018 1:30 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Subprocess Error (full details captured)

 

Greetings, all.

This fired again.  Once again, I was away from the rig, and let WSJT-X continue 
running, so I do not know what it was seeing when this occurred:

Details:

-

Running: C:\WSJT\wsjtx\bin\jt9 -s WSJT-X -w 1 -m 3 -e C:\WSJT\wsjtx\bin -a 
C:\Users\Steve\AppData\Local\WSJT-X -t C:\Users\Steve\AppData\Local\Temp\WSJT-X

At line 70 of file C:\Users\bill\src\wsjt-svn\lib\decoder.f90 (unit = 19)

Fortran runtime error: Cannot open file 
'C:\Users\Steve\AppData\Local\Temp\WSJT-X/houndcallers.txt': No such file or 
directory

 

--

 



 

 

Please let me know what I can do to assist.

 

73,

 

-- 
Steve Sacco
NN4X
Narcoossee, FL 
EL98jh
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] fyi ubuntu 18.04LTS

[Greg Beam]

Hello All,

In isolation, this approach may produce the desired results. However, it
violates concern separation and could break other applications that have
specific library dependencies. This is especially true at the system level.
User-Space library linking would be another topic entirely.

For Debian/Ubuntu based systems, a much better approach would be to use the
Debian Control File (DCF)--which is designed specifically for this type of
problem--to stipulate both the build and runtime dependencies for the
application in question.

Additionally, building the application locally will fail at some point. It
is not a matter of "if", rather, it is "when". Debootstrap is but one tool
users can employ to overt problems of this nature. Using Debootstrap, the
builder completely removes any locally installed libraries and deploys only
those stipulated in the DCF.

Nearly all distributed Ubuntu packages are built using a clean build
environment targeted against distribution revision coupled to an
architecture; e.g. (bionic-xyx-amd64.iso), where"xyz" can take the form of
Server, Desktop, and so on.

As with most all things Linux, there are many ways to skin the fish. While
some methods work, I would be hard-pressed to state manually linking is a
preferred option, or one I use most often.

73's
Greg, KI7MT

-Original Message-
From: Alan VK2ZIW [mailto:bea...@unixservice.com.au] 
Sent: Thursday, May 10, 2018 11:04 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] fyi ubuntu 18.04LTS

Hi Mike and all,

I've often added a symbolic link in the /lib or the /usr/lib directories
from a later library to, the one needed.
In Ubuntu 18.04 LTS, we have libreadline5 and libreadline7 but not
libreadline6.
eg.
cd /lib; ln -s libreadline.so.7.1 libreadline.so.6

Then refresh the library cache if needed. ldconfig

This often fixes a running program's issues but on installation, the Package
Manager may require an entry in the package database. Unpack the .deb file
with "ar x .deb" then unpack the main archive and install the files
manually.

Have fun.

Alan VK2ZIW


On Thu, 10 May 2018 18:58:28 -0400, W2NAP wrote
> deb package fails install without it.
> 
> On Thu, 10 May 2018 22:47:53 + (UTC) Black Michael via wsjt-devel 
>  wrote:
> 
> > And why do we need libreadline6?
> > de Mike W9MDB
> > 
> >  
> > 
> > On Thursday, May 10, 2018, 12:47:53 PM CDT, W2NAP 
> >  wrote:
> >  Not sure if anyone noticed. Libreadline6 is NOT in the 18.04 repos 
> > at all. unknown if it will ever be. work around seems to be 
> > installing the libreadline6 package from artful repo
> > https://packages.ubuntu.com/artful/libreadline6
> > 
> > just wanted to say something in case this was overlooked.
> > 
> > de w2nap
> > 
> > 
> > --

> > Check out the vibrant tech community on one of the world's most 
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
> 
> --
> --
--
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Alan

Evil flourishes when good men do nothing.
Consider the Christmas child.
---
Alan Beard   Unix Support Technician from 1984 to today
70 Wedmore Rd.   Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS
Emu Heights N.S.W. 2750  Routers, terminal servers, printers, terminals
etc..
+61 2 47353013 (h)   Support Programming, shell scripting, "C",
assembler
0414 353013 (mobile) After uni, electronics tech



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Memory Leak in jt9 Process

[Greg Beam]

Hi Doug,

 

We should probably take all this off line, but, the cdimage-daily-live image is 
definitely showing 7.3, where the package system is showing 7.2 … why, I do not 
know. How apt show is rendering 7.2 and gcc -v shoeing 7.3 is another good 
question. 

 

>From the 18.04 daily-live manifest:

gcc-7-base:amd64  7.3.0-12ubuntu1

gcc-8-base:amd64  8-20180319-1ubuntu2

 

And for readline, it seems to skip libreadline6:

libreadline5:amd645.2+dfsg-3build1

libreadline7:amd647.0-3

 

That part makes since as they shifted some time ago. Artful (17.10) also has 
the same packaging for readline. It would seem to me that, If you can compile 
WSJT-X on 17.10, and the only pinch point was readline, you should be able get 
through a build on 18.04 daily-live.

 

73’s

Greg, KI7MT

 

 

From: Doug Collinge [mailto:doug.colli...@gmail.com] 
Sent: Wednesday, March 21, 2018 12:28 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Memory Leak in jt9 Process

 

That's odd. I have a fairly freshly installed and updated Bionic right here and 
gcc -v gives:
gcc version 7.3.0 (Ubuntu 7.3.0-12ubuntu1)

On the other hand, apt show gcc gives:
Package: gcc
Version: 4:7.2.0-1ubuntu1

I did not manually upgrade anything, just apt upgrade.

 

On Tue, Mar 20, 2018 at 10:03 PM Greg Beam mailto:ki7m...@gmail.com> > wrote:

Correction: 

 

My schedule for the Feature Freeze / Release Candidate was wrong. The final 
feature Freeze in April 19th, not March. If there is a bug, it may be picked up 
and GCC bumped to 7.3. As it stands now, the repository is still sitting at 7.2 
for Bionic (18.04).

 

Apologies for the confusion.

 

G.

 

From: Greg Beam [mailto:ki7m...@gmail.com <mailto:ki7m...@gmail.com> ] 
Sent: Tuesday, March 20, 2018 10:43 PM
To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net> >
Subject: RE: [wsjt-devel] Memory Leak in jt9 Process

 

Hi Doug,

 

If the problem is in fact the GCC 7.2 tool chain, that may very well be a 
problem for 18.04 also. For Readline, the version was bumped to libreadline7 
between Xenial (now obsolete) and Artful (obsolete in July). One should be able 
to specify libreadline-dev in the Debian control file, and libreadline7 should 
be picked up. Unless of course, there is a source code need for a feature 
within WSJTX that requires libreadline6 specifically.

 

The Final Ubuntu 18.04 package freeze happened yesterday. So, unless this issue 
is confirmed, and placed at high-priority with respect to release, I doubt GCC 
will shift-off of 7.2 between now and April 26th.

 

I have all the builds for {Trusty, Xenial, Artful,{x86-64,x86}} available here:

 

https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx-next/+packages

 

You can check the Debian source package control files. However, I do not 
specify the use of libreadline-dev specifically, as it’s being pulled in by one 
or more other meta packages; I don’t recall which off-hand.

 

73’s

Greg, KI7MT

 

From: Doug Collinge [mailto:doug.colli...@gmail.com] 
Sent: Tuesday, March 20, 2018 5:20 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] Memory Leak in jt9 Process

 

Mike W9MDB and I have done a bunch of testing to try to figure out this memory 
leak in jt9. I'm finally ready to make a report.

I have installed the distributed deb binaries and built from source for 
1.9.0-rc2 and rc3 on three different versions of Ubuntu, 16.04 LTS (latest LTS 
version), 17.10 (latest non-LTS version), and 18.04 (up-coming LTS 
pre-release). Here are the results:

Ubuntu 16.04 LTS:

- The distributed binary for 1.9.0-rc2 works, 1.9.0-rc3 not tested.

- Compiled binary for 1.9.0-rc2 works. 1.9.0-rc3 not tested.

Ubuntu 17.10:

- The distributed binaries for 1.9.0-rc2 and rc3 work, no leak.

- The compiled binaries for 1.9.0-rc2 and rc3 have the memory leak problem, 
when compiled with the stock gcc, g++, and gfortran at 7.2.0.

- The repositories for 17.10 also include gcc, g++, and gfortran at 6.4.0, 
which produces a functional wsjtx and a jt9 that does not leak.

Ubuntu 18.04 LTS pre-release:

- The distributed binaries for 1.9.0-rc2 and 1.9.0-rc3 both fail to install, 
wanting dependency "libreadline6 (>= 6.0)" but readline6 is not in the 18.04 
repository for some reason, though versions 5 and 7 are.

- The compiled binaries for rc2 and rc3 both work with no leaks. gcc and 
friends are also at 7.3.0 so it must have been fixed.

The bad news:

- there IS a problem if someone running Ubuntu 17.10 tries to compile the 
source. (Like me!)

- the currently-distributed binaries will not install on Ubuntu 18.04 LTS when 
it comes out, unless they add readline6 to the repository.

The good news:

- the problem is not compiled into the distributed deb binaries.

- the problem is evidently not in the wsjtx code, it's in gcc or its libraries, 
and it has already been fixed.

- th

Re: [wsjt-devel] Memory Leak in jt9 Process

[Greg Beam]

Hi Doug, 

 

I’m tied up the next couple days, but after, I’ll pull a new ISO and see if I 
can decipher what going on there. You may want to try:

 

apt-cache policy gcc 

 

Maybe there are multiple versions installed and they are using alternatives or 
something along those lines. The repo default looks to be 7.2 at present, but 
clearly something odd is afoot.

 

73’s

Greg, KI7MT

 

 

From: Doug Collinge [mailto:doug.colli...@gmail.com] 
Sent: Wednesday, March 21, 2018 12:28 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Memory Leak in jt9 Process

 

That's odd. I have a fairly freshly installed and updated Bionic right here and 
gcc -v gives:
gcc version 7.3.0 (Ubuntu 7.3.0-12ubuntu1)

On the other hand, apt show gcc gives:
Package: gcc
Version: 4:7.2.0-1ubuntu1

I did not manually upgrade anything, just apt upgrade.

 

On Tue, Mar 20, 2018 at 10:03 PM Greg Beam mailto:ki7m...@gmail.com> > wrote:

Correction: 

 

My schedule for the Feature Freeze / Release Candidate was wrong. The final 
feature Freeze in April 19th, not March. If there is a bug, it may be picked up 
and GCC bumped to 7.3. As it stands now, the repository is still sitting at 7.2 
for Bionic (18.04).

 

Apologies for the confusion.

 

G.

 

From: Greg Beam [mailto:ki7m...@gmail.com <mailto:ki7m...@gmail.com> ] 
Sent: Tuesday, March 20, 2018 10:43 PM
To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net> >
Subject: RE: [wsjt-devel] Memory Leak in jt9 Process

 

Hi Doug,

 

If the problem is in fact the GCC 7.2 tool chain, that may very well be a 
problem for 18.04 also. For Readline, the version was bumped to libreadline7 
between Xenial (now obsolete) and Artful (obsolete in July). One should be able 
to specify libreadline-dev in the Debian control file, and libreadline7 should 
be picked up. Unless of course, there is a source code need for a feature 
within WSJTX that requires libreadline6 specifically.

 

The Final Ubuntu 18.04 package freeze happened yesterday. So, unless this issue 
is confirmed, and placed at high-priority with respect to release, I doubt GCC 
will shift-off of 7.2 between now and April 26th.

 

I have all the builds for {Trusty, Xenial, Artful,{x86-64,x86}} available here:

 

https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx-next/+packages

 

You can check the Debian source package control files. However, I do not 
specify the use of libreadline-dev specifically, as it’s being pulled in by one 
or more other meta packages; I don’t recall which off-hand.

 

73’s

Greg, KI7MT

 

From: Doug Collinge [mailto:doug.colli...@gmail.com] 
Sent: Tuesday, March 20, 2018 5:20 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] Memory Leak in jt9 Process

 

Mike W9MDB and I have done a bunch of testing to try to figure out this memory 
leak in jt9. I'm finally ready to make a report.

I have installed the distributed deb binaries and built from source for 
1.9.0-rc2 and rc3 on three different versions of Ubuntu, 16.04 LTS (latest LTS 
version), 17.10 (latest non-LTS version), and 18.04 (up-coming LTS 
pre-release). Here are the results:

Ubuntu 16.04 LTS:

- The distributed binary for 1.9.0-rc2 works, 1.9.0-rc3 not tested.

- Compiled binary for 1.9.0-rc2 works. 1.9.0-rc3 not tested.

Ubuntu 17.10:

- The distributed binaries for 1.9.0-rc2 and rc3 work, no leak.

- The compiled binaries for 1.9.0-rc2 and rc3 have the memory leak problem, 
when compiled with the stock gcc, g++, and gfortran at 7.2.0.

- The repositories for 17.10 also include gcc, g++, and gfortran at 6.4.0, 
which produces a functional wsjtx and a jt9 that does not leak.

Ubuntu 18.04 LTS pre-release:

- The distributed binaries for 1.9.0-rc2 and 1.9.0-rc3 both fail to install, 
wanting dependency "libreadline6 (>= 6.0)" but readline6 is not in the 18.04 
repository for some reason, though versions 5 and 7 are.

- The compiled binaries for rc2 and rc3 both work with no leaks. gcc and 
friends are also at 7.3.0 so it must have been fixed.

The bad news:

- there IS a problem if someone running Ubuntu 17.10 tries to compile the 
source. (Like me!)

- the currently-distributed binaries will not install on Ubuntu 18.04 LTS when 
it comes out, unless they add readline6 to the repository.

The good news:

- the problem is not compiled into the distributed deb binaries.

- the problem is evidently not in the wsjtx code, it's in gcc or its libraries, 
and it has already been fixed.

- there is an easy fix if someone wants to compile it on Ubuntu 17.10 - 
downgrade gcc to gcc-6

Recommendation:

- the install notes should warn at least that the code may have a memory leak 
in jt9 if compiled on gcc 7.2.0, and suggest downgrading to gcc 6.4.0. Maybe 
cmake can exclude just that version automatically? 

- maybe the dependency in the distributed deb binary could be relaxed to allow 
readline7, just in cas

Re: [wsjt-devel] Memory Leak in jt9 Process

[Greg Beam]

Correction: 

 

My schedule for the Feature Freeze / Release Candidate was wrong. The final 
feature Freeze in April 19th, not March. If there is a bug, it may be picked up 
and GCC bumped to 7.3. As it stands now, the repository is still sitting at 7.2 
for Bionic (18.04).

 

Apologies for the confusion.

 

G.

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, March 20, 2018 10:43 PM
To: 'WSJT software development' 
Subject: RE: [wsjt-devel] Memory Leak in jt9 Process

 

Hi Doug,

 

If the problem is in fact the GCC 7.2 tool chain, that may very well be a 
problem for 18.04 also. For Readline, the version was bumped to libreadline7 
between Xenial (now obsolete) and Artful (obsolete in July). One should be able 
to specify libreadline-dev in the Debian control file, and libreadline7 should 
be picked up. Unless of course, there is a source code need for a feature 
within WSJTX that requires libreadline6 specifically.

 

The Final Ubuntu 18.04 package freeze happened yesterday. So, unless this issue 
is confirmed, and placed at high-priority with respect to release, I doubt GCC 
will shift-off of 7.2 between now and April 26th.

 

I have all the builds for {Trusty, Xenial, Artful,{x86-64,x86}} available here:

 

https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx-next/+packages

 

You can check the Debian source package control files. However, I do not 
specify the use of libreadline-dev specifically, as it’s being pulled in by one 
or more other meta packages; I don’t recall which off-hand.

 

73’s

Greg, KI7MT

 

From: Doug Collinge [mailto:doug.colli...@gmail.com] 
Sent: Tuesday, March 20, 2018 5:20 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] Memory Leak in jt9 Process

 

Mike W9MDB and I have done a bunch of testing to try to figure out this memory 
leak in jt9. I'm finally ready to make a report.

I have installed the distributed deb binaries and built from source for 
1.9.0-rc2 and rc3 on three different versions of Ubuntu, 16.04 LTS (latest LTS 
version), 17.10 (latest non-LTS version), and 18.04 (up-coming LTS 
pre-release). Here are the results:

Ubuntu 16.04 LTS:

- The distributed binary for 1.9.0-rc2 works, 1.9.0-rc3 not tested.

- Compiled binary for 1.9.0-rc2 works. 1.9.0-rc3 not tested.

Ubuntu 17.10:

- The distributed binaries for 1.9.0-rc2 and rc3 work, no leak.

- The compiled binaries for 1.9.0-rc2 and rc3 have the memory leak problem, 
when compiled with the stock gcc, g++, and gfortran at 7.2.0.

- The repositories for 17.10 also include gcc, g++, and gfortran at 6.4.0, 
which produces a functional wsjtx and a jt9 that does not leak.

Ubuntu 18.04 LTS pre-release:

- The distributed binaries for 1.9.0-rc2 and 1.9.0-rc3 both fail to install, 
wanting dependency "libreadline6 (>= 6.0)" but readline6 is not in the 18.04 
repository for some reason, though versions 5 and 7 are.

- The compiled binaries for rc2 and rc3 both work with no leaks. gcc and 
friends are also at 7.3.0 so it must have been fixed.

The bad news:

- there IS a problem if someone running Ubuntu 17.10 tries to compile the 
source. (Like me!)

- the currently-distributed binaries will not install on Ubuntu 18.04 LTS when 
it comes out, unless they add readline6 to the repository.

The good news:

- the problem is not compiled into the distributed deb binaries.

- the problem is evidently not in the wsjtx code, it's in gcc or its libraries, 
and it has already been fixed.

- there is an easy fix if someone wants to compile it on Ubuntu 17.10 - 
downgrade gcc to gcc-6

Recommendation:

- the install notes should warn at least that the code may have a memory leak 
in jt9 if compiled on gcc 7.2.0, and suggest downgrading to gcc 6.4.0. Maybe 
cmake can exclude just that version automatically? 

- maybe the dependency in the distributed deb binary could be relaxed to allow 
readline7, just in case Ubuntu doesn't get around to including readline6 
(presuming it works, of course)

Doug VE7GNU

 

On Tue, Feb 20, 2018 at 11:59 AM Doug Collinge mailto:doug.colli...@gmail.com> > wrote:

There seems to be a memory leak in the jt9 process started by wsjtx. I have 
included a chart showing the memory use growing from about 20MiB to over 300MiB 
in the course of 11 hours. I set wsjtx to monitor 40m overnight and recorded 
the memory stats produced by /proc/*/statm at one minute intervals. The change 
in slope of the curves indicates the band opening and more signals being 
decoded.

 

The configuration here is Ubuntu 17.10 with an RTL-SDR. gqrx demodulates USB, 
filters and feeds the audio to wsjt-x 1.9.0-rc1 using pulseaudio.

 

Doug VE7GNU

 


​

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
w

Re: [wsjt-devel] Memory Leak in jt9 Process

[Greg Beam]

Hi Doug,

 

If the problem is in fact the GCC 7.2 tool chain, that may very well be a 
problem for 18.04 also. For Readline, the version was bumped to libreadline7 
between Xenial (now obsolete) and Artful (obsolete in July). One should be able 
to specify libreadline-dev in the Debian control file, and libreadline7 should 
be picked up. Unless of course, there is a source code need for a feature 
within WSJTX that requires libreadline6 specifically.

 

The Final Ubuntu 18.04 package freeze happened yesterday. So, unless this issue 
is confirmed, and placed at high-priority with respect to release, I doubt GCC 
will shift-off of 7.2 between now and April 26th.

 

I have all the builds for {Trusty, Xenial, Artful,{x86-64,x86}} available here:

 

https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx-next/+packages

 

You can check the Debian source package control files. However, I do not 
specify the use of libreadline-dev specifically, as it’s being pulled in by one 
or more other meta packages; I don’t recall which off-hand.

 

73’s

Greg, KI7MT

 

From: Doug Collinge [mailto:doug.colli...@gmail.com] 
Sent: Tuesday, March 20, 2018 5:20 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Memory Leak in jt9 Process

 

Mike W9MDB and I have done a bunch of testing to try to figure out this memory 
leak in jt9. I'm finally ready to make a report.

I have installed the distributed deb binaries and built from source for 
1.9.0-rc2 and rc3 on three different versions of Ubuntu, 16.04 LTS (latest LTS 
version), 17.10 (latest non-LTS version), and 18.04 (up-coming LTS 
pre-release). Here are the results:

Ubuntu 16.04 LTS:

- The distributed binary for 1.9.0-rc2 works, 1.9.0-rc3 not tested.

- Compiled binary for 1.9.0-rc2 works. 1.9.0-rc3 not tested.

Ubuntu 17.10:

- The distributed binaries for 1.9.0-rc2 and rc3 work, no leak.

- The compiled binaries for 1.9.0-rc2 and rc3 have the memory leak problem, 
when compiled with the stock gcc, g++, and gfortran at 7.2.0.

- The repositories for 17.10 also include gcc, g++, and gfortran at 6.4.0, 
which produces a functional wsjtx and a jt9 that does not leak.

Ubuntu 18.04 LTS pre-release:

- The distributed binaries for 1.9.0-rc2 and 1.9.0-rc3 both fail to install, 
wanting dependency "libreadline6 (>= 6.0)" but readline6 is not in the 18.04 
repository for some reason, though versions 5 and 7 are.

- The compiled binaries for rc2 and rc3 both work with no leaks. gcc and 
friends are also at 7.3.0 so it must have been fixed.

The bad news:

- there IS a problem if someone running Ubuntu 17.10 tries to compile the 
source. (Like me!)

- the currently-distributed binaries will not install on Ubuntu 18.04 LTS when 
it comes out, unless they add readline6 to the repository.

The good news:

- the problem is not compiled into the distributed deb binaries.

- the problem is evidently not in the wsjtx code, it's in gcc or its libraries, 
and it has already been fixed.

- there is an easy fix if someone wants to compile it on Ubuntu 17.10 - 
downgrade gcc to gcc-6

Recommendation:

- the install notes should warn at least that the code may have a memory leak 
in jt9 if compiled on gcc 7.2.0, and suggest downgrading to gcc 6.4.0. Maybe 
cmake can exclude just that version automatically? 

- maybe the dependency in the distributed deb binary could be relaxed to allow 
readline7, just in case Ubuntu doesn't get around to including readline6 
(presuming it works, of course)

Doug VE7GNU

 

On Tue, Feb 20, 2018 at 11:59 AM Doug Collinge mailto:doug.colli...@gmail.com> > wrote:

There seems to be a memory leak in the jt9 process started by wsjtx. I have 
included a chart showing the memory use growing from about 20MiB to over 300MiB 
in the course of 11 hours. I set wsjtx to monitor 40m overnight and recorded 
the memory stats produced by /proc/*/statm at one minute intervals. The change 
in slope of the curves indicates the band opening and more signals being 
decoded.

 

The configuration here is Ubuntu 17.10 with an RTL-SDR. gqrx demodulates USB, 
filters and feeds the audio to wsjt-x 1.9.0-rc1 using pulseaudio.

 

Doug VE7GNU

 


​

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Monitoring stops suddenly in 1.80 and 1.90 RC2

[Greg Beam]

Hi Frank,

In this case, processor utilization is probably less of a concern than
memory in terms of overall performance. The RIP2 is short to begin with for
"normal" desktop activities. I believe the Pi2 B/(x) models came with ~1GB;
even less on older versions.  While you are watching HTOP, keep an eye on
mem-usage, and when/how-much. You can set the sort order by memory or any
number of filters using HTOP.

73's
Greg, KI7MT

-Original Message-
From: FRANK DB5FP [mailto:db...@gmx.de] 
Sent: Tuesday, March 20, 2018 2:25 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Monitoring stops suddenly in 1.80 and 1.90 RC2

Hi Joe,


sorry first e-Mail did not pass my filter, so it went to spam...and I send a
new one.

At first, green Monitor light does NOT go out. 
Everything looks fine. But waterfall stops and no more messages are decoded.
Sometimes it is possible to recover the program by pressing the Monitor
buton twice.

I tried 1.80 and 1.90 rc2only one instance. Both version have the same
issue.
I'm running FT8 on different bands and report the messages to pskreporter.

I tried to get some more information by  inspecting the processes with
"htop" . It looks like the JT9 process is running but it's more or less
idling 2.4% of CPU usage. During decode it's about 100% (1 core).
During normal idle it's about 11%.


If I shut down the JT9 process by kill-command  and afterwards killing rest
of the application, I can restart the application. By ending the program
with ALT-F4 oder File-Exit I can not restart because of zombie processes on
the message accrues that there would be a lock file.

dmesg and /var/log/mesages don't show any problems.

The problem is independent of any other program running beside wsjtx.
But normally I use gpredict in the same time.

Is there any error-loging possibility in wsjtx ?

73

Frank
DB5FP
 



 
> Hi Frank,
> 
> On 3/17/2018 6:36 AM, FRANK DB5FP wrote:
> > on my Raspberry Pi2 Monitoring Mode stopps suddenly.
> > OS Version : Debian
> > Kernel Linux version 4.14.18-v7+
> > 
> > Suddenly the Waterfall display stops and no messages are decoded BUT 
> > progressbar is still running.
> > Rig controll ist still working.
> > 
> > Any hints?  
> 
> You have reported this problem twice now.  It might help to know what 
> WSJT-X (or possibly some other program running in your RasPi2 ??) is 
> doing when the green Monitor light goes out.  What mode are you 
> running? What other processes are taking CPU time?
> 
> Your system is, of course, in the "bare minimum" category for running 
> WSJT-X.  Have you communicated with others who run WSJT-X on a 
> Raspberry Pi2 ?
> 
>   -- 73, Joe, K1JT
> 
> --
>  Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JSDK Oops on Reinstall

[Greg Beam]

Hi Ricky,

 

Just for clarity, what fails to install?

 

Update-3 adds Ruby and Asciidoctor. If they are not being installed, that is a 
problem. However, I’ve not heard this being an issue for others.

 

Greg, KI7MT

 

From: Ricky Scott [mailto:w7...@w7psk.net] 
Sent: Sunday, December 17, 2017 9:18 AM
To: Black Michael ; WSJT software development 

Subject: Re: [wsjt-devel] JSDK Oops on Reinstall

 

Yes those worked, but one would think the win installer would complete the 
task.   I wonder

if they know it fails install?

 

On December 17, 2017 at 5:33 AM Black Michael mailto:mdblac...@yahoo.com> > wrote:

Scroll down the page and look at the "DOWNLOADS" and "INSTALLATION" sections.

There are several downloads.

 

Click the following links to download.

*   MS-VCredist (2010) 

 
*   MS-VCredist (2013) 

 
*   OmniRig 

 
*   JTSDK Main Installer 

 
*   JTSDK Update-1 

 
*   JTSDK Update-2 

 
*   JTSDK Update-3 

 
*   JTSDK Update-4 

 

 

 

de Mike W9MDB

 

 

On Saturday, December 16, 2017, 11:10:22 PM CST, Ricky Scott mailto:w7...@w7psk.net> > wrote:

 

 

I downloaded the Win installer, but I dont see any other files?

On December 16, 2017 at 7:10 PM Black Michael mailto:mdblac...@yahoo.com> > wrote:

You haven't installed everything.

Read all the directions on this page.

https://sourceforge.net/projects/jtsdk/files/?source=navbar

 

de Mike W9MDB

 

 

On Saturday, December 16, 2017, 7:26:32 PM CST, Ricky Scott W7PSK 
mailto:w7...@w7psk.net> > wrote:

 

 


BUILD APPLICATIONS: ( WSJT-X WSPR-X MAP65 )
-

USAGE:  build-(app_name) (type)

 App Names : wsjtx wsprx map65
 Release Types : rconfig rinstall package
 Debug Types ..: dconfig dinstall

HELP SCREENS
-
 JTSDK-QT Help, Type ..: help-qtenv
 Checkout Help, Type ..: help-checkout
 Build Help, Type .: help-(app_name)
 List Options, Type ...: list-options

COMPILER INFO ( Mingw 48_32 )
-
 C++ : 4.8.0
 GFortran ...: 4.8.0
 GNU Make ...: 3.82.90

CRITICAL APP INFO
-
'asciidoctor' is not recognized as an internal or external command,
operable program or batch file.

 

 

-- Original Message --

From: "Black Michael" mailto:mdblac...@yahoo.com> >

To: "WSJT software development" mailto:wsjt-devel@lists.sourceforge.net> >; "Ricky Scott W7PSK" 
mailto:w7...@w7psk.net> >

Sent: 12/16/2017 12:28:11 PM

Subject: Re: [wsjt-devel] JSDK Oops on Reinstall

 

Open up a command window and do this:

 

\JTSDK\qtenv.cmd

 

Then you should be able to see the error message.

 

de Mike W9MDB

 

 

On Saturday, December 16, 2017, 1:30:37 PM CST, Ricky Scott W7PSK 
mailto:w7...@w7psk.net> > wrote:

 

 

Reinstalling JTSDK I have an issue I cannot resolve.

JTSDK-QT wont open.  I get the start open then the versions pop up momentarily 
and the window

shuts down

 

PY, Maintenance, MYSYS all work ok.  Just QT

 

Scotty W7PSK

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net  
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r8270 compile error

[Greg Beam]

Hi Mike,

 

Try cleaning your build tree / cache. ft8_params.f90 was in fsk4hf, but, I 
believe Steve moved some things around not long ago. It’s now in lib/ft8 and 
builds OK here @8207, not @8270.

 

73’s

Greg, KI7MT

 

 

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Wednesday, November 1, 2017 10:24 PM
To: WSJT Software Development 
Cc: Black Michael 
Subject: [wsjt-devel] r8270 compile error

 

Did someone forget to add a file?

 

[ 14%] [ 14%] Built target qcp
Building Fortran object CMakeFiles/wsjt_fort.dir/lib/ft8_decode.f90.obj
Built target wsprsim
[ 14%] [ 15%] C:\JTSDK\src\wsjtx\lib\ft8_decode.f90:40: Error: Can't open 
included file 'fsk4hf/ft8_params.f90'

 

de Mike W9MDB

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X will not run with debian 9.2

[Greg Beam]

Hi John, All, 

Just a quick note regarding the developer section:

---
2) For the wsjtx developers: It's tough to release binary packages that
cover the wide range of linux releases.  But you can greatly increase the
chance of things working by linking statically against smaller libraries
like libreadline. Of course, you could link statically against everything,
and it might be worth experimenting with that to see how big wsjtx gets. The
disadvantage of linking statically is that if there are bugs in the
libraries you use they won't be fixed by people updating to a new version of
the library (i.e. they would be dependent on you releasing a new version of
wsjtx), which can be especially bad if the problem is a security issue.
However,  wsjtx by its nature isn't likely to be used as an exploit path for
hackers.
---

There are a number of reasons why Static-Linking is not really a good
approach, and should be avoided if it can be. Security vulnerabilities, code
bloat, redundancies, overall image foot-prints etc. I would not disagree
that a time and place exists for static linking. However, as a matter of
general production, I would lean more toward shared where possible.

The issue at hand is a Debian Distribution decision issue. They chose
migration to libreadline7 at Debian Stretch. Ubuntu on the other hand, chose
to remain on libreadline6. The complexity come in where the two cross-over.
Each Ubuntu release has what is called a Debian import freeze. At which
point, they (Ubuntu) pull packaging in from Debian and do what's needed to
align it with their model. This is easily solved by using each distributions
packaging system as intended. Launchpad is not designed for Debian
distributions, even though Ubuntu's origin is directly from Debian. Because
Debian is much more cautious in terms of distribution cycles, packages tend
to behind Ubuntu; that is not the case for libreadlin6 and 7, as Ubuntu is
on 6.3 across the board. The result is, while it is possible to use Ubuntu
repositories for select packages (PPA's or otherwise), a risk exists of
breaking package dependencies, such as the case we have here. The proper way
to resolve that issue is back-porting the needed package. However, that too,
can present circular dependencies making the back-port virtually
unattainable.

The ultimate solution is to build packages against each Distribution +
Version + Arch. That is not really the responsibility of the upstream
development team, unless they chose it to be. However, teams try to
accommodate as many users as possible. Here is in-lies the dilemma. It's
well known, Windows users far exceed all other platforms combined. So, where
is their efforts best served? I would say (even though I am an avid Linux
user), Windows should be the focus. Having said that, Bill has done an
Unbelievable Job in making sure WSJT-X builds on as many platforms as
possible. Accommodating each variant is an unrealistic expectation. That
effort, IMHO, is best served working with the upstream development team via
package maintainers.

The problem is solvable, in many ways, but will require intervention and
management by package maintainers.

73's
Greg, KI7MT 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X 1.8.0 GA Release via Launchpad PPA

[Greg Beam]

Hello All,

 

Following Joe's WSJT-X 1.8.0 GA Release message, I've updated my Lauchpad
PPA's

(WSJTX and WSJTX-NEXT) as released by the WSJT Development Team. Both

packages are sitting at the tagged revision number r8193.

 

Supported Distributions: 

* Trusty, Xenial, Zesty

* Supported Arch: amd64, i386, arm64, armhf, ppc64el

 

GA Release

Installation / Upgrade Information:

https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx

 

Development

Installation / Upgrade Information:

https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx-next

 

73's

Greg, KI7MT

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJTX RC3 for Ubuntu via Launchpad PPA

[Greg Beam]

Hello All,

Following Joe's WSJT-X RC3 message yesterday, I've updated my Lauchpad PPA
(WSJTX-NEXT) to RC3 as released by the WSJT Development Team.

Supported Distributions: 
* Trusty, Xenial, Zesty
* Supported Arch: amd64, i386, arm64, armhf, ppc64el

Installation / Upgrade Information:
https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx-next

73's
Greg, KI7MT







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 1.7.1 builds now fail to start

[Greg Beam]

Hi Rich,

 

Typically, you do not run the build from the “build” folder. Rather, you run it 
from the release/install folder, as that is where all the required QT / GCC 
dll’s are copied to. The auto-run setting for JTSDK (assuming that is what you 
are building with) changes directory to the revision / release / install 
directory, then runs the wsjtx.exe. This would be the same action as if you 
were to run WSJT-X after using the package installer. The plugins directory 
typically resided one level above the /bin directory. However, when running 
from the build directory, that structure does not exist.

 

I can’t really speak to your older build situation.

 

73’s

Greg, KI7MT

 

 

 

From: Rich - K1HTV [mailto:k1...@comcast.net] 
Sent: Tuesday, September 19, 2017 11:14 PM
To: WSJT 
Subject: [wsjt-devel] WSJT-X 1.7.1 builds now fail to start

 

   I had been successfully  building and running WSJT-X development releases 
for many months up to r8072. When RC2 came out I started using it to check it 
for bugs and hadn't built any new 1.7.1 releases until today. I built r8098 and 
it auto started and ran OK. I went into the 8098/release/build folder and made 
a shortcut for wsjtx.exe but when I ran it I received an error message. Running 
the wsjtx.exe directly gives the same error. The message says that the app 
failed to start because it could not find or load the QT platform plugin 
"windows". I tried rebuilding with the same results.





I also tried running wsjtx-exe from a number of older (8060 & 8071) builds 
which previously were working but get the same error.





Can you shed some light as to what might be happening?  Thanks.





73,

Rich - K1HTV





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJTX RC2 for Ubuntu via Launchpad PPA

[Greg Beam]

Hello All,

Apologies for the delay. However, I've updated my Lauchpad PPA (WSJTX-NEXT)
to RC2 as released by the WSJT Development Team.

Supported Distributions: Trusty, Xenial, Zesty (Yakkety is Obsolete, and no
longer supported)
Supported Arch: amd64, arm64, armhf, i386, ppc64el

Installation / Upgrade Information:
https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx-next

73's
Greg, KI7MT






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Build error with hamlib3

[Greg Beam]

Hi Rick,

 

The short answer is, JTSDK-PY is not the right environment for building 
Hamlib3. Either JTSDK-QT, or MSYS, but not JTSDK-PY.

 

To keep the WSJT-X Development list clear JTSDK related issue, please use 
jt...@groups.io   for reporting problems.

 

73’s

Greg, KI7MT

 

From: Ricky Scott W7PSK [mailto:w7...@w7psk.net] 
Sent: Thursday, August 3, 2017 4:57 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Build error with hamlib3

 

Uplgraded JTSDK to 710 by update upgrade in JTSDK Maintenance

 

tried building hamlib 3 with JTSDK-PY with build-hamlib3

 

received some errors

 

rigctl.exe - system error

The code execution cannot proceed because libwinpthread-1.dll was not found.  
Reinstalling the program may fix this problem

 

Recieved it twice 

 

 * Checking Files
rigctl.exe .: OK
rigctld.exe : OK
riglist.h ..: OK
hamlib.pc ..: OK
libhamlib.a : OK

 * Testing Dummy Rig Control
Set Freq .: 14500
Return Freq . :


 RIG CONTROL TEST ERROR


 There was a problem testing Rig Control.
 Check the build for errors manually and
 report the problem to the devel-lsit if
 you cannot resolve the problem.


(JTSDK-PY 3.3 ) C:\JTSDK)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK-Win32 Upgrade Available - Important Update for Compiling Hamlib

[Greg Beam]

Hi Chuck,

 

C:\JTSDK\tools is where the GNU tools are kept (awk, sed, grep, ls, and many 
others). JTSDK Maintenance ( C:\JTSDK\maint.cmd) is just a shell script that 
sets up a specific environment (add paths and such).

 

The Icon: JTSDK Update, runs the update.cmd script from within the root 
directory. It’s the same as opening JTSDK Maintenance, typing update, then 
upgrade.

 

It’s a good point that, using the JTSDK Update icon is probably a better route 
for most rather than using JTSDK Maintenance.

 

73’s

Greg, KI7MT

 

From: Chuck Yahrling [mailto:ab1vl...@gmail.com] 
Sent: Wednesday, August 2, 2017 2:29 PM
To: Bill Turner ; WSJT software development 

Subject: Re: [wsjt-devel] JTSDK-Win32 Upgrade Available - Important Update for 
Compiling Hamlib

 

That's interesting.  I have a folder named Tools under the main c:\JTSDK 
folder.  Inside is  JTSDK Maintenance.

 

I also have an icon at the same level as c:\jtsdk that says JTSDK Update.  I 
used it a few days ago to get me up to 2.0.5-1.  

 

 

 

 

 

On Wed, Aug 2, 2017 at 4:15 PM, Bill Turner via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

Thanks Greg, the maintenance worked fine.  For the benefit of those of us still 
learning JTSDK you might point out that Maintenance is a file called "maint" in 
the JTSDK folder.

 

Thanks for all the work you folks are doing to make WSJT spectacular.

 

Bill, W4WNT

 


  _  


From: Greg Beam mailto:ki7m...@gmail.com> >
To: wsjtgr...@yahoogroups.com <mailto:wsjtgr...@yahoogroups.com> ; 'WSJT 
software development' mailto:wsjt-devel@lists.sourceforge.net> >; ws...@groups.io 
<mailto:ws...@groups.io> ; jt...@groups.io <mailto:jt...@groups.io>  
Sent: Wednesday, August 2, 2017 2:06 PM
Subject: [wsjt-devel] JTSDK-Win32 Upgrade Available - Important Update for 
Compiling Hamlib

 

Hello All,

 

The Hamlib development team recently made a slight change to their build

invocation. As result, a minor change to the JTSDK-Win Hamlib3 build script

was required. 

 

TO UPGRADE:

* Open JTSDK Maintenance

* Type: update

* Type: upgrade

* Close, then reopen JTSDK Maintenance

* Type: version

 

You should now be on v2.0.6-0 Release 710 [1]

 

If you have problems with the update, post them on jt...@groups.io 
<mailto:jt...@groups.io> 

 

[1] jtsdk-win-2.0.6.png

 

73's

Greg, KI7MT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel





 

-- 

73, chuck

 

ab1vl.com <http://ab1vl.com> 

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK-Win32 Upgrade Available - Important Update for Compiling Hamlib

[Greg Beam]

Hello All,

The Hamlib development team recently made a slight change to their build
invocation. As result, a minor change to the JTSDK-Win Hamlib3 build script
was required. 

TO UPGRADE:
* Open JTSDK Maintenance
* Type: update
* Type: upgrade
* Close, then reopen JTSDK Maintenance
* Type: version

You should now be on v2.0.6-0 Release 710 [1]

If you have problems with the update, post them on jt...@groups.io

[1] jtsdk-win-2.0.6.png

73's
Greg, KI7MT
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X: review of message reply and sequencing logic

[Greg Beam]

Hello All,

All I can say is, the fast mode "is fast". 

Joe, Steve, Bill, etc are working on decoder refinement, but for me,
decoding 18+ stations each iteration is more than enough to contemplate. On
the fast mode, I just decoded a station at -21db. I think that's a record
for me on FT8.  -20db decodes are, just eyeballing it, plentiful. On
average, I'm seeing many -15 to -19 stations. For a fact QSO mode, I can't
see where one could ask for more.

73's
Greg, KI7MT

-Original Message-
From: Richard Lamont [mailto:rich...@lamont.me.uk] 
Sent: Tuesday, July 25, 2017 3:44 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X: review of message reply and sequencing
logic

On 25/07/17 22:09, Steven Franke wrote:
> Hi Richard,
> 
>> As Bill mentioned in his OP, the FT8 decoder is still a work in 
>> progress but I have noticed that the r7939/r7944 decoder is currently 
>> too slow to be usable on my machine, which uses a Core 2 Duo E6700 
>> CPU (2 x 2.66 GHz cores), even with nothing much else running. 
>> (Admittedly this machine is getting a bit long in the tooth, but this 
>> is the first time it's been a
>> problem.) The attached .wav takes about 2.5 seconds to decode. This 
>> is not an unusual example.
> 
> 
> There are three decoder depth settings. Have you tried the Fast and Normal
settings? The Fast setting should be quite a bit faster than the RC 1
decoder, and I believe that the Normal setting is comparable to RC 1. The
reason that we provide the Fast and Normal settings is to accommodate folks
who use slower machines. 

Thanks Steve and Bill for your prompt replies. This setting is one of the
features of WSJT-X that I tweaked when I first used it and had long since
forgotten about.

Is there a way to measure decode times accurately?

Just doing it by 'eye', I get these approximate figures )on the same .wav as
before):

1.8.0-rc1  fast/normal/deep   0.2s/0.5s/0.7s
1.8.0-rc2-r7924fast/normal/deep   0.2s/0.5s/0.7s
1.7.1-devel-r7944  fast/normal/deep   0.4s/0.8s/2.5s


73,
Richard G4DYA




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK-CS Beta Testers Needed / jt...@groups.io

[Greg Beam]

Hello All,

As most of the email lists I frequent have, or are in the process of, moving
to Groups.io--which I find most useful--, I've decided to create
jt...@groups.io to try and keep non-relevant traffic off other lists. When
the FT8 mode was announced, I was shocked to see the number of downloads in
July-2017 was >= 1500. That is quite surprising since I've not made any
significant changes in quite some time. I seriously doubt that the
jt...@groups.io list will be high volume. However, if you have issues
installing, using, building WSJT applications (using JTSDK Win32 / Nix,
future OSX), bugs, or feature-requests, please post them to jt...@groups.io.

On a separate, yet related topic, I've started--don't get excited, it's
early days--work on the next major revision of JTSDK (Win32 / Nix / OSX).
More information will be added to jt...@groups.io #Announcements section, as
it becomes available.  In a nutshell, all current code (Win32 / Nix / OSX)
will be rewritten in the .NET Framework; C# WinForms for UI's (Windows to
start, Nix & OSX with Mono if feasible), and .NET Core for most console
applications. If you'd be interested in testing various packages / phases
within the solution (when available), have ideas, or feature requests, post
it to jt...@groups.io under the hashtag #JTSDK-Dev. Keep in mind, I've just
started mapping out the framework, so there is a long way to go before
package testing is ready to roll. Even if you do not want to test code, you
should keep an eye on jt...@groups.io list, as that is where the latest
information and documentation will be kept.

The basic structure will closely follow:
* Project Packages and Documentation source code will be managed on GitHub
* Binary storage (installers / contributed tools) will be on Sourceforge
* All Wiki's will be migrated from Sourceforge (and elsewhere) to
jt...@groups.io 
* jt...@groups.io for all project communications, support, general
discussion, etc.

73's
Greg, KI7MT


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] TQSL's config.xml

[Greg Beam]

Hi Dan,

 

Yes, I understand. I stopped doing that sometime in the past, but couldn’t 
remember exactly “why”. Dave helped me understand it.

 

I don’t make nearly as many QSO’s as I did when contesting “a lot”. Now, 
resubmitting a few QSO’s to LoTW isn’t that big of a deal. Back when I was 
making 1000’s of QSO’s per week/weekend, I wouldn’t not entertain the thought 
of going back and fishing out resubmissions.

 

For now, I’m just waiting on LoTW to do their thing, then I’ll submit all the 
FT8 QSO’s. I did send a bunch to eQSL after somebody confirmed they were 
accepting them.

 

73’s

Greg, KI7MT

 

 

From: Dan Malcolm [mailto:dan.malcol...@gmail.com] 
Sent: Tuesday, July 18, 2017 4:28 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

Greg,

My question was more for information than for a real intent.  I have already 
done the FT8 mapping, and it is working quit well

Dan-K4SHQ

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 12:00 PM
To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Black Michael mailto:mdblac...@yahoo.com> >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm mailto:dan.malcol...@gmail.com> >
To: wsjtx-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] TQSL's config.xml

[Greg Beam]

Hi Dave,

 

OK, thanks for clearing that up. I knew something wasn’t straight forward, but 
could not recall what it was. The resubmission part is what was missing.

 

Thanks

 

Greg

 

From: Dave AA6YQ [mailto:aa...@ambersoft.com] 
Sent: Tuesday, July 18, 2017 2:01 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

>>>AA6YQ comments below

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 2:02 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] TQSL's config.xml

 

Hi Dave,

 

Thanks. I recall--vaguely--there being some issue with using this method before 
LoTW implements the mode. I don’t recall what it was offhand. Something to the 
affect that, once you’ve created the map, you (or LoTW) cannot go back and 
change it in the event the mapping we select locally differs from the 
server-side implementation. 

 

>>>That’s not correct. When LoTW accepts FT8 QSOs directly, you can remove the 
>>>automatic mapping to DATA from TQSL. At that point in time, it would be 
>>>polite to resubmit your FT8 QSOs to LoTW so that QSO partners pursuing an 
>>>FT8 WAS endorsement (if one is introduced) will get the “exact mode matches” 
>>>they need.

 

73,

 

Dave, AA6YQ 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] TQSL's config.xml

[Greg Beam]

Hi Dave,

 

Thanks. I recall--vaguely--there being some issue with using this method before 
LoTW implements the mode. I don’t recall what it was offhand. Something to the 
affect that, once you’ve created the map, you (or LoTW) cannot go back and 
change it in the event the mapping we select locally differs from the 
server-side implementation. Thus, for whatever reason at the time, I chose to 
just wait for LoTW to implement the mode.

 

I think when JT9 came out, there was discussion about the use of mapping to 
data. However, I can’t recall exactly what the situation was. It may be a moot 
point now. It may also I am confusing the RTTY to DATA debate, no sure.

 

73’s

Greg, KI7MT

 

 

From: Dave AA6YQ [mailto:aa...@ambersoft.com] 
Sent: Tuesday, July 18, 2017 11:21 AM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You can configure TQSL to automatically “map” FT8 QSOs to DATA now, which will 
enable LoTW to accept them. See

 

https://lotw.arrl.org/lotw-help/pref-adi/

 

 73,

 

   Dave, AA6YQ

 

 

 

From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Tuesday, July 18, 2017 1:00 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] TQSL's config.xml

 

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Black Michael mailto:mdblac...@yahoo.com> >
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm mailto:dan.malcol...@gmail.com> >
To: wsjtx-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] TQSL's config.xml

[Greg Beam]

You could ask Rick M., Dave, or one of the other Trusted QSL developers, but, I 
would think that adjustments to the client-side will have little to no 
affect—other than mapping the mode to data—until the server-side model has been 
updated to accommodate the new mode. 

 

Even if the ADIF spec is released today, the backend work would still need to 
be done before correct mapping of FT8 QSO’s could be realized. I don’t know 
what the LoTW eng/test/production release process is, but I would suspect work 
has already begun adding changes to the server model based on the proposed ADIF 
changes. 

 

I don’t really understand the urgency here. All one must do is hold back their 
FT8 QSO’s until the LoTW server is ready to accept them (as FT8 QSO’s that is). 
This situation “is not new”, it happens with every new mode / sub-mode 
introduction.

 

73’s

Greg, KI7MT

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, July 18, 2017 10:15 AM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] TQSL's config.xml

 

3.0.6 has not had finally approval yet.

eQSL is just implementing it early.

I doubt ARRL will ever touch a draft ADIF spec.

 

de Mike W9MDB

 

 

  _  

From: Dan Malcolm mailto:dan.malcol...@gmail.com> >
To: wsjtx-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Tuesday, July 18, 2017 11:05 AM
Subject: [wsjt-devel] TQSL's config.xml

 

A question for smarter people than me.

 

TQSL’s config.xml contains all the modes acceptable to TQSL.  Instead of 
mapping FT8->DATA in TQSL, could I accomplish something similar but more 
accurate by inserting a new XML coded line in config.xml?

Insert a line like: “FT8”

 

This might even be moot, since the new ADIF spec is out and includes FT8.  

* LoTW’s website shows config.xml’s latest iteration is v11.0.  No 
mention of which ADIF spec.

* ADIF.ORG’s website still shows v3.0.5 as the latest. 

* eQSL says it’s using ADIF spec 3.0.6.

 

It’s entirely possible that ARRL will update config.xml soon on its own.

 

Dan – K4SHQ

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net  
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] increasing false decodes in Version R7895

[Greg Beam]

Hello All,

 

The method Richard stated below is the preferred build method, for several 
reasons. Those testing the release candidate branch—which is what needs testing 
at this point—should build the ^/wsjtx-1.8-rcX branch, not the ^/wsjtx branch. 
The ^wsjtx branch can have all sorts of unstable, partially complete, and/or 
non-functional code at any given time. The only people that should be building 
from the development branch ^/wsjtx are the application developers, which 99.9% 
of users are not part of.

 

While it is not a problem to use the svn switch command, facilities exist to 
allow you to build the RC dev branch while maintaining your default build 
options. All the while, leaving the ^/wsjtx to the developers. If this is far 
too confusing, you should probably wait for the official RC build from the 
development team.

 

To display wsjtx build options help menu:

help-wsjtx

 

To display the list option help screen:

wsjtx-list -h

 

To see the available branches:

wsjtx-list -a

 

To update available branch list:

wsjtx-list -u

 

Then, as Richard stated, to build the release candidate “dev” branch:

 

build-wsjtx -b dev -n wsjtx-1.8 -c release -t install

 

Note: the above is a dev branch “dev”, not the released GA/RC candidate branch. 
If new fixes/features are added “ontop of” the RC1 branch, and the development 
team askes for testing on this branch, that’s what you should be 
building/testing.

 

When a new RC(x) is released to GA—after updating your lists—it will appear as 
wsjtx-1.8.0-rc2

 

build-wsjtx -b gar -n wsjtx-1.8.0-rc2 -c release -t install

 

Note the “gar”, and full name of the release candidate “wsjtx-1.8.0-rc2” in the 
command above.

 

73’s

Greg, KI7MT

 

 

From: Richard Stanley via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, July 16, 2017 11:49 AM
To: WSJT software development 
Cc: Richard Stanley 
Subject: Re: [wsjt-devel] increasing false decodes in Version R7895

 

Hi Ron

 

not sure if there is a more elegant way but I 

 

wsjtx-list –u 

build-wsjtx -b dev -n wsjtx-1.8 -c release -t install

This works for me.

Richard G7OED 

 

 

 

From: Ron Gibson 

Sent: Sunday, July 16, 2017 4:45 PM

To: wsjt-devel@lists.sourceforge.net 

Subject: Re: [wsjt-devel] increasing false decodes in Version R7895

 

Does anyone know the JTSDK commands to switch to the v1.8 branch?
Ron
VE3CGR

On 7/16/2017 9:24 AM, Bill Somerville wrote:

On 16/07/2017 14:16, Steve Huston wrote:

On Sun, Jul 16, 2017 at 6:38 AM, Bill Somerville mailto:g4...@classdesign.com 
wrote:

The v1.8 branch ^/branches/wsjtx-1.8 which currently identifies as
v1.8.0-rc2 is where your focus should be as this is where fixes for issues
in the RC1 release candidate will be placed ready for the next release
candidate and eventually the general availability release (GA).

Thanks for that, Bill; I knew the wsjtx branch was no longer suitable
for use on air, but I've been away from using svn for long enough that
I forgot about how branching is done and where I should go look for
the right place to grab updates before official packages are released.
Guess I'm too used to Mercurial now (don't ask about git :D )

Hi Steve,

If you are using raw subversion commands then:

$ svn switch ^/branches/wsjtx-1.8

will swap your workspace to the v1.8 branch and:

$ svn sw ^/branches/wsjtx

to get back to the development trunk (branch).

For JTSDK users I believe this is automated and you can switch branches with a 
canned command.

73
Bill
G4WJS.






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

 

  _  

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot 

  _  

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

 


 

 

Virus-free.  

 www.avast.com 

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] libgomp1 >=4.9

[Greg Beam]

Hi Pino,

I am not sure you can, as I "think" Mint 17.3 is based on Trusty (14.04), I
could be wrong, but. Trusty, even with the updates is showing gcc-4.8

https://packages.ubuntu.com/trusty/libx32gomp1
https://packages.ubuntu.com/trusty/i386/libx32gomp1/filelist

You could either upgrade, or enable additional repositories, but that gets
messy. I would say, you are better off upgrading to a newer version of Mint,
but that's up to you. 

Xenial (16.04) is using GCC 5.4.0.

73's
Greg, KI7M

-Original Message-
From: Pino Zollo [mailto:pinozo...@gmail.com] 
Sent: Tuesday, July 11, 2017 6:58 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] libgomp1 >=4.9

Please,

where to find libgomp1 >=4.9


for Mint 17.3 alias  Ubuntu 14.04   32bit ?


Here is not available: https://packages.ubuntu.com/search?keywords=libgomp1

neither here: https://pkgs.org/download/libgomp1



TU 73

Pino ZP4KFX


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX RC1

[Greg Beam]

Erik, All,

At this point in the release cycle, its beneficial to the development team
to test the installation, as well as new features, on as many instances as
possible. Bill created installers for most, if not all, the supported
distributions. We should be testing that release, and providing feedback of
our observations. The revision numbers mean very little to end users at at
present. As for laymen terms, it gets complicated "real quick", so there's
not much point in hashing through that.

Continuing to build from the development branch will only slow things down.
I can't say for certain, however, based on previous release cycles there
will be one or more additional RC's before the final release.

Unless something dramatic happens, there won't be any major changes made
that warrants dev-branch builds for the masses. What is most needed now is
hammering out the proposed release code. If something major crops up, they
can always post another RC.

The more testing we do on the RC revision will only help to ensure a
trouble free product later down the line. Unless your one of the core
developers, or a distribution package maintainers, building from source
code is not the best approach.

I am running the revision Bill posted for Windows. Installation went
without issue, and seems to be running as expected. That
revision-(1.8.0-RC1)-is what we need to be testing.

73's
Greg, KI7MT



On Mon, Jul 10, 2017 at 11:57 PM, Erik -  wrote:

> I guess I’m having a ‘duh’ moment: r7848 is wsjtx-1.8.0-rc1 (I presume)
> ……….. if I update svn and compile I get r7848 but it is 1.7.1-devel and
> this is what I do not understand due to my total lack of knowledge. If
> someone could tell me in layman’s terms why that is I would be grateful.
>
>
>
> Erik EI4KF.
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Sourceforge Update Error

[Greg Beam]

Now ya don't it John, it's busted :-)

You should be able to, from JTSDK-QT: 

cd C:\JTSDK\src\wsjtx
svn cleanup
svn up

or

remove C:\JTSDK\src\wsjtx  then rebuild.

Assuming of course, SF is not actually down.

73's
Greg, KI7MT


-Original Message-
From: John Zantek [mailto:j...@zantek.net] 
Sent: Monday, July 10, 2017 12:36 PM
To: 'WSJT software development' 
Subject: [wsjt-devel] Sourceforge Update Error

I was building a new package and, unfortunately, had to interrupt the batch
file.  When I now respond 'y' when asked to Update from SVN Before Building,
I get:

Sourceforge Update Error
Build-wsjtx was unable to update [ wsjtx ] Sourceforge.  The service may be
down or Undergoing maintenance.  Check the following Link for current site
status reports:
http://sourceforge.net/blog/category/sitestatus

There's actually nothing wrong at Sourceforge and I'm assuming I munged
something locally when I interrupted the batch file update from SVN.  Short
of reinstalling the entire JTSDK, is there a QT command or build-wsjtx
argument to overcome this?

TIA, John KE7B



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Compiling issues...

[Greg Beam]

Hi Ryan,

 

I think the package your looking for is:

 

https://packages.ubuntu.com/xenial/libusb-1.0-0-dev

 

https://packages.ubuntu.com/xenial/i386/libusb-1.0-0-dev/filelist

 

 

.. so that would be: sudo apt-get install libusb-1.0-0-dev

 

That is the package for 16.04 (Xenial).

 

I don’t know how your compiling WSJT-X, so I can’t advise any further than that.

 

73’s

Greg, KI7MT

 

 

From: Ryan Tourge [mailto:ryan.tou...@gmail.com] 
Sent: Friday, July 7, 2017 9:05 PM
To: ll...@gcis.biz; WSJT software development 
Subject: Re: [wsjt-devel] Compiling issues...

 

Well I've tried everything I can think of. And what you fellas could think of, 
and what Facebook could think of. I'm missing something. I'll wait for the RC.

 

On Fri, Jul 7, 2017 at 9:19 PM, Lloyd Kirk mailto:ll...@gcis.biz> > wrote:

You need libusb-1.0.0  and the -devel package I suspect.

Had a similar issue with this on my old centos 6 box and had to compile that 
from source..

Lloyd Kirk
WB5HUP

On 2017-07-07 19:31, G8DQX (WSJT developers on SF) wrote:

Ryan,

one suspects that, for Ubuntu, the command should be:

SUDO APT INSTALL LIBUSB-1.0-0-DEV

HTH,

Robin, G8DQX

 On 08/07/17 00:50, Bill Somerville wrote:

Hi Ryan,

sorry you are having trouble building WSJT-X. Try this:

$ sudo apt install libusb-devel

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net  
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net  
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Feature Request

[Greg Beam]

Just bumped into another one; may apply to other modes as well, not sure.
When Log QSO on 73's is enabled, the box pops as expected. After Clicking OK
to save the QSO, can we get an option to set Tab-2 Gen Message back to CQ ?
I suppose that would apply to Tab-1 Tx6 also ?

G.

-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Monday, July 3, 2017 5:59 PM
To: 'WSJT software development' 
Subject: FT8 Feature Request

Hi Joe, All,

After a brief stint in calling CQ, I soon realized my reflexes with the ole
mouse buttons are not what they used to be. I guess I've not been
participating in enough RTTY contests :-) In any case:

When in RUN mode (calling CQ):
- Would it be possible to assign a single hot-key to grab the First-In
Response to a CQ ?
- Additionally, what about a combination of First-In-First-Out /
Last-In-First-Out check boxes that grabs a response off the stack?
- Maybe an ESM (Enter Sends Message / Right Click ) sends the message from
the Band / Rx Frequency grids
- Lastly, maybe a way to quickly enable / disable ( just in the Band
Activity / Rx Activity) only the responses that contain MY_CALL

As this is a fast mode with HF contest potential, the items above are well
received in the RTTY community in several major programs. 

I'm finding it difficult to focus on the RX box for responses, click on the
responder, and not grab the wrong call, a;; within a second or so. I could
only imagine how that would be after 24hrs of contesting. I've miss-fired on
this several times already. It could be just me, and I've not been operating
fast modes for a while. 

Anyways, just a few thoughts to ponder.

73's
Greg, KI7MT



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] FT8 Feature Request

[Greg Beam]

Hi Joe, All,

After a brief stint in calling CQ, I soon realized my reflexes with the ole
mouse buttons are not what they used to be. I guess I've not been
participating in enough RTTY contests :-) In any case:

When in RUN mode (calling CQ):
- Would it be possible to assign a single hot-key to grab the First-In
Response to a CQ ?
- Additionally, what about a combination of First-In-First-Out /
Last-In-First-Out check boxes that grabs a response off the stack?
- Maybe an ESM (Enter Sends Message / Right Click ) sends the message from
the Band / Rx Frequency grids
- Lastly, maybe a way to quickly enable / disable ( just in the Band
Activity / Rx Activity) only the responses that contain MY_CALL

As this is a fast mode with HF contest potential, the items above are well
received in the RTTY community in several major programs. 

I'm finding it difficult to focus on the RX box for responses, click on the
responder, and not grab the wrong call, a;; within a second or so. I could
only imagine how that would be after 24hrs of contesting. I've miss-fired on
this several times already. It could be just me, and I've not been operating
fast modes for a while. 

Anyways, just a few thoughts to ponder.

73's
Greg, KI7MT


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK Usage and Policy Guidelines

[Greg Beam]

Hello All,

Appropriate Use
==

JTSDK exists to help users build and "test" Joe's software, not distribute
it.  We all want these fantastic applications, but, we "users" must respect
the developers requests.

I've received several reports of WSJTX packages built with JTSDK being
distributed by end-users. If this continues, I'll have no choice but to
remove the package build feature from JTSDK. Joe has, on many occasions,
requested that package installers not be re-distributed by anyone other than
the development team. Please respect their wishes!


For "Non-Developers" / "Testers" - (Setup && Usage)
===
For those of you "testing" Joe's software, a few things to note:

* DO NOT distribute the packages you build for yourself! < nuff said >
* Make sure, "before posting bugs", you are running the latest SVN revision
* Setup JTSDK-QT as follows:

- Open JTSDK-QT [1]
- Set the following options; can be on one line separated by a " ; "
semicolon, 
or you can set them individually. If individually, you do not need the " ; "
:

enable-separate ; disable-quiet ; disable-skipsvn ; enable-autosvn ;
enable-clean ; enable-rcfg ; enable-qt55

You can, if desired, enable-autorun, which will launch the newly built
version for you.

* Check your options are set properly with [2]:   list-options
* Close, then reopen JTSDK-QT
* Build Hamlib3:  build-hamlib3
* Build the Release Install target (unless otherwise directed by a developer
for troubleshooting): 

build-wsjtx rinstall

You can build WSJT-X as often as you like, and should do; especially when
new features have been added, or the development team is requesting broader
use testing.

* Build an installable package ( DO NO DISTRIBUTE THESE < nuff said again >
):
* For most users, this is "not needed, nor desired for testing"

build-wsjtx package


Problems with JTSDK
=

If you have problems with JTSDK (not WSJT-X), email me off line, and we'll
get it sorted out.

@ ki...@yahoo.com
@ ki7m...@gmail.com

Or, post a bug on GitHub: 

Linux: https://github.com/KI7MT/jtsdk-nix/issues
Windows: https://github.com/KI7MT/jtsdk-win/issues


Documentation
=

For Windows, documentation is available online at:
http://jtsdk-win.readthedocs.io/en/latest/

For Linux:   /usr/share/doc/jtsdk/

If you find bugs in the Docs, report them to the appropriate GitHub location
above.


73's
Greg, KI7MT

[1] main-menu.png
[2] options.png

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Linux JTSDK build problem.

[Greg Beam]

Hello All,

Just to completeness; I've not used Ubuntu 14.04 in some time. I fired it
up; did a quick package update; rebuilt Hamlib3, then WSJT-X r7755. No
errors or warnings of consequence to end-users. Currently monitoring 20m
FT8.

I am working with Llyod offline to get his issue resolved.

73's
Greg, KI7MT

-Original Message-
From: Richard Bown [mailto:rich...@g8jvm.com] 
Sent: Friday, June 30, 2017 4:20 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Linux JTSDK build problem.

Hi
Builds OK on linux Mint 18.1 64 bit ,which uses the same libs as ubuntu
16.04


On Fri, 30 Jun 2017 16:10:06 -0600
"Greg Beam"  wrote:

> Hi Llyod,
> 
> You can contact me off-line to keep the traffic on the mailing-dist 
> down a bit.
> 
> Couple question to answer in the offline email:
> * What Linux distro are you using?
> * How did you install JTSDK-Nix?
> 
> 73's
> Greg, KI7MT
> 
> -Original Message-
> From: Lloyd Kirk [mailto:ll...@gcis.biz]
> Sent: Friday, June 30, 2017 3:08 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: [wsjt-devel] Linux JTSDK build problem.
> 
> Hello,
> Can someone contact me perhaps directly if needed to answer a couple 
> of questions? I had JTSDK 2.0.21 installed on ubuntu 14.04  and it was 
> working but would not update the devel wsjtx to current, so I removed 
> it and re-installed. I have built hamlib, when I try to build the 
> latest devel of wsjtx it complains it cant find hamlib. I am sure I 
> must have missed something in the re-install. It has no problems 
> building the other programs i.e wspr, just not wsjtx.
> 
> Lloyd Kirk
> WB5HUP
> 
> --
> --
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> --
>  Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
--
Best wishes /73
Richard Bown

Email : rich...@g8jvm.com
HTTP  :  http://www.g8jvm.com
nil carborundum a illegitemis

##
Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W &
3cms 5W Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W QRV VHF
6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
OS: Linux Mint 18.1  x86_64 on a Dell Inspiron N5030 laptop

## 



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Linux JTSDK build problem.

[Greg Beam]

Hi Llyod,

You can contact me off-line to keep the traffic on the mailing-dist down a
bit.

Couple question to answer in the offline email:
* What Linux distro are you using?
* How did you install JTSDK-Nix?

73's
Greg, KI7MT

-Original Message-
From: Lloyd Kirk [mailto:ll...@gcis.biz] 
Sent: Friday, June 30, 2017 3:08 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Linux JTSDK build problem.

Hello,
Can someone contact me perhaps directly if needed to answer a couple of
questions? I had JTSDK 2.0.21 installed on ubuntu 14.04  and it was working
but would not update the devel wsjtx to current, so I removed it and
re-installed. I have built hamlib, when I try to build the latest devel of
wsjtx it complains it cant find hamlib. I am sure I must have missed
something in the re-install. It has no problems building the other programs
i.e wspr, just not wsjtx.

Lloyd Kirk
WB5HUP


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

[Greg Beam]

Hi Bill,

I tried to connect with you a couple times, but I wasn't making it in on
your side. I think the best I had you was ~ -16gb or so, maybe a little
better.

Looks like us HF sloth's are gonna have to learn how to operate VHF high
speed mode :-)

G.

On Thu, Jun 29, 2017 at 5:17 PM, Bill Somerville 
wrote:

> On 30/06/2017 00:15, Greg Beam wrote:
>
>> I just decoded Joe working Bill. All be it, I did not decode Bill.
>>
>
> Hi Greg,
>
> I am only running 3W. If you want a QSO I can QRO a bit.
>
> 73
> Bill
> G4WJS.
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

[Greg Beam]

Here's an issue "I think".

If you set (check) auto-seq, then, during the QSO, set a different response
than what it expects, say 73's instead of the RRR message, WSJT-X
automatically sends the report message message if the other station sent a
report instead of RRR. I got caught in a do-loop with I3VJW. I wanted to
send RR or 73's, but the sequencer kept sending me back to the call +
report.

G.



On Thu, Jun 29, 2017 at 5:28 PM, Laurie, VK3AMA <_vk3a...@vkdxer.net> wrote:

>
>
> On 30/06/2017 9:10 AM, Joe Taylor wrote:
>
>> Is anyone using "T10"? When I've checked recently, usage seemed to be
>> close to zero.
>>
>> In any eveny, we had no idea that "~" was being used to flag a T10
>> decode.  (Or, for that metter, that you were using those flags in JTAlert.)
>>
>> Maybe you can tell it's FT8 because I (mistakenly) left two spaces
>> between "~" and the start of message, rather than one. :-)
>>
>> -- Joe, K1JT
>>
>
> Joe,
>
> The 2 spaces hack is not really suitable, since JTAlert uses the mode
> field passed in the UDP decode packet. I'd rather not code a fix based on a
> source code error that will likely be corrected in the future.
>
> A JTAlert fix is rather trivial, as I already know if the UDP packet is
> coming from WSJT-X or JTDX, so its a simple application test to determine
> the true mode.
>
> I'll be posting a new JTAlert later today with the fix.
>
> Regarding T10 usage, there is only a small number of users, primarily EU
> based. I have not seen any significant uptake of the mode, there appears to
> be only a small number of regular spotters of the mode.
>
> de Laurie VK3AMA
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Greg Beam]

Hi Dan,

You should be able to install Msys, with autotools, to the default 
C:\MinGW or whatever it is these days. After which you'd need to copy a 
couple of files from the original /msys/etc folder (for mount points and 
such) and edit one file to update a path for the new installation of 
MSYS. Its not difficult. If you want to attempt this email me offline 
and I'll give you the step by step instructions.

73's
Greg, KI7MT


On 3/6/2017 8:57 AM, Dan Malcolm wrote:
> Bill,
> I actually do understand, and thank God for the Bill's and Greg's of this
> world.  My development efforts these days revolves around PHP and the PhpED
> editor.  A much more dragon free environment.  Of course it is programming
> and as such will never be completely dragon free.  Remember the old joke
> about devil and 10 lines of perfect code?
>
> Can we do this?  You tell me what JTSDK architecture you think I need, and
> given what I have in place, I will try to manipulate files/directories to
> match that.  The first problem to solve is getting the needed tools in
> place.  Perhaps then the procedures you provided will work.  That should
> relieve some of my demands on your time, as long as I can still ask the odd
> question.  At least now I have a sense of what needs to happen.  If it all
> fails,  I can just use the release version of WSJTX.
>
> Thanks Bill, and thanks to you to Greg.
>
> _
> Dan Malcolm CFI/II
> K4SHQ
>
>
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Monday, March 06, 2017 9:29 AM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Hamlib3 compile error
>
> On 06/03/2017 14:51, Dan Malcolm wrote:
>> What to do?  Since I have the MinGW Installation Manager I guess I
>> could install everything it offers, but it may be installed in the
>> wrong place to do any good.  Thinking of our email exchanges it seems
>> you expect a lot of utilities to be available and available in a
>> particular place.  Is it possible that something went missing during my
> initial package installation?
>
> Hi Dan,
>
> I need to clarify a few things.
>
> Firstly MinGW is Windows port of the GNU compilers. These are essential as
> we use them to build WSJT-X. You get a version of them as part of the Qt
> install and they match the compilers used to make the Qt libraries and
> tools. This in turn is essential so that projects like WSJT-X can use them
> and be compatible with the Qt libraries.
>
> We also use the Hamlib project for rig control. Unlike Qt which just needs
> MinGW compilers, Hamlib uses the fairly standard autotools as well that
> thousands of Open Source projects use. For autotools to work a Unix like
> shell environment is required and there is one available that goes with
> MinGW, it is called msys. Msys provides a command shell and many utilities
> that would be found on a Unix like system.
>
> The problem with DLL load addresses is a Microsoft issue in that they use a
> binary format that is not position independent. I have no idea why DLLs
> suddenly stop working with fork() emulations, it just happens sometimes. The
> cure is to rebase the relevant DLLs, rebasing in this context is looking at
> the size of each DLL and allocating a unique load address hint to each one
> so that none ever need to be loaded at a different address due to
> overlapping, at least until whatever causes this happens again. It is this
> loading into a process virtual address space at a different address that
> causes the fork() emulations to fail.
>
> It appears that the JTSDK does not provide enough of the msys environment to
> run this rarely required utility, that I tried to help you with but I am
> largely working blind as I do not use the JTSDK and do not wish to install
> it due constraints of other projects. Believe me that rebaseall is what you
> need, it is designed to resolve exactly this issue with one simple command
> invocation.
>
> It is quite possible to install each of the required tools and libraries
> that are needed to build WSJT-X individually. Greg has taken the time to
> build a relatively simple to use package that obviates the user from
> understanding and doing all this work. He provides the minimum needed to do
> the most basic build tasks which works well for almost everyone. In your
> case you have hit an issue that needs a deeper understanding and more
> components to resolve. I am afraid that using standard tools for software
> development is complex and usually messy, you are living in a charmed world
> where someone like Greg has smoothed down all the sharp edges for you but
> nearby there be dragons and one of them has walked out of the forest in your
> direction.
>
> 73
> Bill
> G4WJS.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, SlashDot.org! http://sdm.link/slashdot
> ___

Re: [wsjt-devel] Hamlib3 compile error

[Greg Beam]

Hi Dan,

I can't speak to the rebase situation, however, one has to keep in mind 
the purpose of the MSYS environment as part of JTSDK. It is not a full 
MSYS image/environment instalaltion, it's the chain image, meaning, it's 
there to support for the use of GCC, C++, gfortran, and autotools, not 
an interactive user environment. The MSYS work-space is not even 
installed (though there are a few msys dll's to support the tool chain 
binary requirements), as it is not needed (normally) for the tool chain 
to perform it's intended function. mingw-get is not part of the tool 
chain side, it's part of the MSYS environment / installer side.

This is evident by the fact, grep and find are in the C:/JTSDK/msys/bin 
directory. However, the default or "assumed" profile for mingw-get is 
looking for those binaries in a non-existent MSYS /bin directory (which 
it cannot find), not the tool-chain /bin directory.

I'm not certain, but I believe mingwe-get needs a profile file to tell 
it where MSYS is located along with the tool chain folder ../mingw or 
../mingw32 / wherever the tool chain is located.


73's
Greg, KI7MT

On 3/5/2017 8:50 PM, Dan Malcolm wrote:
> Bill,
> Got that and installed it.  MIngw-get still failed but a search found the
> program under C:\JTSDK\mingw32\bin so I used the full path from the JTSDK
> MYS prompt.  That ran and seemed to install a few pages.  Closed all JTSDK
> windows and then found dash.exe right where you said it would be.  It opened
> a window and /bin/rebaseall gave me this error:
> $ /bin/rebaseall
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found
> _
> Dan Malcolm CFI/II
> K4SHQ
>
>
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Sunday, March 05, 2017 8:53 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Hamlib3 compile error
>
> On 06/03/2017 02:43, Dan Malcolm wrote:
>> The very first step failed with 'bash.exe: mingw-get: command not found'.
>
> HI Dan,
>
> Ah, that's not helpful.
>
> Try this:
>
> https://sourceforge.net/projects/mingw/files/
>
> you want the mingw-get-setup.exe installer offered at the top of the page.
>
> 73
> Bill
> G4WJS.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib compile problem

[Greg Beam]

Hi Colin,

I've hit the the resource unavailable problem in the past but not the 
heap issue.

Try building Hamlib3 from MSYS directly and see if you get the same error.

73's
Greg, KI7MT

On 3/5/2017 12:31 PM, Colin99 Campbell wrote:
> Hi all,
>
> I'm just going through the installation of  JTSDK following the
> instructions
> at https://sourceforge.net/projects/jtsdk/files/win32/2.0.0/ but I can't
> get Hamlib to build. I tried with the default QT version 5.2 but when
> that failed I changed to version 5.5. The result was the same.  At the
> start of  the program I get this message about not being able
> to allocate the heap. I ran the program as administrator but it made no
> odds.
>
>
> Running 'autoreconf -i' to process configure.ac
> and generate the configure script.
> C:\JTSDK\msys\bin\sh.exe: *** 1. unable to allocate heap 0xA01,
> heap_chunk_size 268435456, pid 16244, Win32 error 0
>   0 [main] sh 12836 sync_with_child: child 16244(0x1C0) died before
> initialization with status code 0x1
> 815 [main] sh 12836 sync_with_child: *** child state waiting for longjmp
> /bin/libtoolize: fork: Resource temporarily unavailable
> C:\JTSDK\msys\bin\sh.exe: *** 1. unable to allocate heap 0xA01,
> heap_chunk_size 268435456, pid 15140, Win32 error 0
>   0 [main] sh 16244 sync_with_child: child 15140(0x1B8) died before
> initialization with status code 0x1
>  76 [main] sh 16244 sync_with_child: *** child state waiting for longjmp
> /bin/libtoolize: fork: Resource temporarily unavailable
>
> Any help welcome.
>
> Colin mm5agm
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Greg Beam]

Hi Dan,

The shell script for building Hamlib can be found at:

C:\JTSDK\sctipts\msys-build-hamlib3.sh

On or about line 254 is the make command, just add the V=1 after it:

make V=1

if that is what Bill needs.

Because it's a script doing the work, just tee the output to a file from 
within MSYS (there is an alias to call the script):

build-hamlib3 |tee -a hamlib3-build.log

That should scroll the build on the screen and create a build log for you.

73's
Greg, KI7MT


On 3/4/2017 12:57 PM, Bill Somerville wrote:
> On 04/03/2017 19:21, Dan Malcolm wrote:
>> v5.8.8 built for msys-64int
>
> Hi Dan,
>
> ok, that also is fine. I need to see the full and verbose Hamlib build
> output. Problem is I'm not sure how to do that with the JTSDK, maybe
> Greg is lurking and can help out. What is needed is to add V=1 to the
> Hamlib make command and also to redirect all the output (stderr and
> stdout) to a log file. Then zip and send me that file please?
>
> 73
> Bill
> G4WJS.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Greg Beam]

Hi Dan,

I was mistaken on the msys-64int. I checked my version of Perl via 
different method that only yields the version number. Using --version on 
my installation also returns 64int in the name. I also checked the dll 
headers with dumpbin and it's definitely a 32 bit dll, so you can take 
that rabbit trail off the table, sorry about that.

I've tried several methods to reproduce the error your seeing, but, have 
had no luck thus far. At present, I am at a loss as to what is causing 
your error.

73's
Greg, KI7MT



> On 03/04/2017 06:35 PM, Dan Malcolm wrote:
>> Ok Bill,
>> That's no problem if someone can tell me how exactly.  I found the Autoconf
>> file but the text says not to directly edit it, so I didn't.  I also didn't
>> find any place to edit the make command line.
>>
>> _
>> Dan Malcolm CFI/II
>> K4SHQ
>>
>>
>> -Original Message-
>> From: Bill Somerville [mailto:g4...@classdesign.com]
>> Sent: Saturday, March 04, 2017 1:57 PM
>> To: wsjt-devel@lists.sourceforge.net
>> Subject: Re: [wsjt-devel] Hamlib3 compile error
>>
>> On 04/03/2017 19:21, Dan Malcolm wrote:
>>> v5.8.8 built for msys-64int
>>
>> Hi Dan,
>>
>> ok, that also is fine. I need to see the full and verbose Hamlib build
>> output. Problem is I'm not sure how to do that with the JTSDK, maybe Greg is
>> lurking and can help out. What is needed is to add V=1 to the Hamlib make
>> command and also to redirect all the output (stderr and
>> stdout) to a log file. Then zip and send me that file please?
>>
>> 73
>> Bill
>> G4WJS.
>>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Greg Beam]

Hi Dan, All,

I'm not sure what's going on here either. My version of Perl, via MSYS, 
is 5.8.8. I was able to build Hamlib3 from MSYS directly, and JTSDK-QT 
via QT 5.2 and 5.5 without error.

As Bill suggested, log the build and post it. To eliminate JTSDK-QT ENV, 
use the JTSDK-MSYS terminal, then:

 From JTSDK-MSYS Terminal, type the command:

build-hamlib3 |tee -a hamlib3-build.log

or

build-hamlib3 >> hamlib3-build.log

The first command allows you to watch the build progress. Then post that 
file to the dev list.

As best I can tell, there are no versions of Perl associated with QT, so 
that should not be a conflict of any sort. The update process within 
JTSDK does not alter the MSYS installation. So, if the build worked at 
some point in the past, something has changed in one of the environments 
on your system. What, and where would be a question only you could answer.

73's
Greg, KI7MT

On 3/3/2017 10:58 AM, Dan Malcolm wrote:
> Bill,
>
> Reboot didn’t help and the Windows Event Log messages just reported what
> was already known.  I uninstalled JTSDK and then deleted the folder.  I
> downloaded fresh files from SourceForge, and did a complete reinstall.
> The problem is not fixed.  See the attached capture image.  WSJT-X
> compilation also failed under JTSDK-QT.  There were so many error lines
> that I could not scroll back far enough to see the first one.
> Experience has taught me to fix the first reported failure first.  Are
> these problems related?
>
>
>
> _
>
> Dan Malcolm CFI/II
>
> K4SHQ
>
>
>
> *From:*Bill Somerville [mailto:g4...@classdesign.com]
> *Sent:* Thursday, March 02, 2017 10:21 AM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Hamlib3 compile error
>
>
>
> On 02/03/2017 16:06, Dan Malcolm wrote:
>
> Seems the offending module is: Faulting module path:
> C:\JTSDK\msys\bin\msys-perl5_8.dll.
>
> The problem seems to be inability to find a file
>
> It appears I am using Perl5_8.  If memory serves, there was a
> discussion about which Perl version should be used.  Could 5.8 be
> the problem?
>
> HI Dan,
>
> the message is telling us that the version of perl being used is the one
> in the JTSDK. That should be fine. The errors were memory access and
> copy errors. It could possibly be a corrupted file in the JTSDK. If
> rebooting does not sort this out and there is nothing in the Windows
> Event Log then it may be worth trying to re-install the JTSDK.
>
> 73
> Bill
> G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] compile error

[Greg Beam]

Hi Bill,

I'm not certain as to how other developers manage their commits, but, I 
typically run a separate checkout using svn:// when using SVN that 
adds the developer username to the url. Before running separate 
checkouts, I just committed from the src directory using my SF credentials.

Joe may be able to shed a bit more light on this than I can, as outside 
of a very few commits, I've not made many commits to the WSJT-X branch.

73's
Greg, KI7MT


On 3/2/2017 11:35 AM, Bill Somerville wrote:
> On 02/03/2017 18:04, Greg Beam wrote:
>> If users want to test svn:// v.s.http://, they can edit the top of:
>
> Hi Greg,
>
> thanks for filling the details for the JTSDK Subversion URLs. Since
> SourceForge no longer advertise Subversion access via HTTP I would
> suggest we either use an HTTPS or SVN scheme. Subversion on Windows
> ships with its own SSL libraries so there should be no issue with SSL
> being installed when using HTTPS.
>
> I use SSH+SVN all the time on SourceForge and have no issues with it but
> that is for read+write access hence the SSH wrapper.
>
> Interesting that no one has commented on how they get read+write access,
> does anyone do that with the JTSDK?
>
> 73
> Bill
> G4WJS.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] compile error

[Greg Beam]

Hi Bill,

I can't recall exactly what the reason was, but, in the past there were 
various checkout issues from SF when using the svn:// prefix, which is 
why I opted for using the http:// prefix.

For what it's worth, since SF came back up after their last major down 
period, I've not had any trouble with checkouts or updates, including 
the boost addition. However, I've been using Linux almost exclusively 
the last couple months.

If users want to test svn:// v.s. http://, they can edit the top of:

C:\JTSDK\scripts\qtenv-build-wsjtx.cmd

For HTTP (default)
SET devurl=http://svn.code.sf.net/p/wsjt/wsjt/branches
SET garurl=http://svn.code.sf.net/p/wsjt/wsjt/tags
SET baseurl=http://svn.code.sf.net/p/wsjt/wsjt

For SVN (optional)
SET devurl=svn://svn.code.sf.net/p/wsjt/wsjt/branches
SET garurl=svn://svn.code.sf.net/p/wsjt/wsjt/tags
SET baseurl=svn://svn.code.sf.net/p/wsjt/wsjt

Obviously, if they change the url, then a relocate or new checkout would 
be needed.

73's
Greg, KI7MT


On 3/2/2017 7:00 AM, Bill Somerville wrote:
> On 02/03/2017 13:11, Wolfgang wrote:
>> (JTSDK-QT 5.5 ) C:\JTSDK\src\wsjtx)svn info
>> Path: .
>> Working Copy Root Path: C:\JTSDK\src\wsjtx
>> URL:http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
>> Relative URL: ^/branches/wsjtx
>> Repository Root:http://svn.code.sf.net/p/wsjt/wsjt
>> Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
>> Revision: 7593
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: bsomervi
>> Last Changed Rev: 7593
>> Last Changed Date: 2017-03-02 03:45:29 +0100 (Do, 02 Mrz 2017)
>
> Hi Wolfgang,
>
> that's interesting. I wonder if the use of the HTTP scheme is the root
> of the problem. SourceForge offer the SVN and HTTPS schemes for
> read-only Subversion repository access. Clearly HTTP does work as well
> and I have just tested doing fresh checkouts using it without issue. I
> think we should change to using the SVN scheme in case HTTP does stop
> working and SVN is probably a little more efficient.
>
> Can someone who uses the JTSDK for write access to the WSJT repository
> explain how they set up their Subversion workspace for read+write access
> please?
>
> Greg can easily change the initial checkout URL in the JTSDK to use the
> SVN scheme but that will not change anything for those that, sensibly,
> only ever do updates on an existing workspace.
>
> If anyone is suffering this time out problem right now, you can
> experiment with switching the scheme of your Subversion client area by
> typing the following:
>
> cd C:\JTSDK\src\wsjtx
> svn relocate svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
>
> then try the update again, probably preceded by:
>
> svn cleanup
>
> if the last update attempt failed.
>
> The above `svn relocate ...` command will be overridden if you ask the
> JTSDK to do a clean checkout as it will revert to HTTP scheme.
>
> 73
> Bill
> G4WJS.
>
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX 1.7.0 doesn't install on Debian.

[Greg Beam]

Hi Andreas,

The .deb files posted on Joe's website were more than likely built on a 
Ubuntu distribution, most probably 16.04 considering Ubuntu 14.04 gcc is 
sitting at 4.8.3.

To answer you questions, I don't think anyone is building packages for 
Debian specifically. I build PPA packages for Ubuntu against a number of 
versions & architectures.

I've been told, on occasion, that using Launchpad for Debian proper 
distributions is not advised, but, many of the WSPR users are on 
Raspbian which is a direct pull from Jessie I believe.

You have a number of options:

[1] Use the Ubuntu Trusty .deb (for your arch) off my Launchpad account. 
Ubuntu Trusty was sourced from Jessie, and should work for you.
Link: https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx/+packages

[2] Try to use my Launchpad PPA method of installation:
Link: https://launchpad.net/~ki7mt/+archive/ubuntu/wsjtx

[3] Use the instructions contained within the WSJT-X repository for 
compiling WSJT-X:
Link: https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/INSTALL

There are other methods, but those are known to work with high success 
rates.

73's
Greg, KI7MT


On 1/22/2017 3:11 AM, Andreas Krüger wrote:
> Hello, all,
>
> trying to install wsjtx_1.7.0_amd64.deb from
> https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> on my Debian Jessie computer, I run into these problems:
>
>
> WSJTX 1.7.0 wants version 5.5.0 or newer of libqt5core5a, but Jessie has
> 5.3.2+dfsg-4+deb8u2.
>
> WSJTX 1.7.0 wants version 5.2 or newer of libstdc++6, but Jessie has 4.9.2-10.
>
> (See below for details.)
>
>
> My questions:
>
> Are these dependencies serious?
>
> Or can I hope to get a working Jessie WSJTX 1.7.0 by compiling myself against
> the library versions that Jessie has?
>
> Maybe someone has already done a compile for Debian and I can simply use that?
>
>
> FWIW:
>
> Jessie is the presently released Debian stable.
>
> So the claim on https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> that WSJTX 1.7.0 as provided there (which is what I try to use)
>
> is fit for Debian must, I'm afraid, be taken with a lump of salt presently... 
> ;-)
>
>
> Regards, Andreas, DJ3EI
>
>
> # LANG=C dpkg -i wsjtx_1.7.0_amd64.deb
> (Reading database ... 351518 files and directories currently installed.)
> Preparing to unpack wsjtx_1.7.0_amd64.deb ...
> Unpacking wsjtx (1.7.0) over (1.7.0) ...
> dpkg: dependency problems prevent configuration of wsjtx:
>  wsjtx depends on libqt5core5a (>= 5.5.0); however:
>   Version of libqt5core5a:amd64 on system is 5.3.2+dfsg-4+deb8u2.
>  wsjtx depends on libstdc++6 (>= 5.2); however:
>   Version of libstdc++6:amd64 on system is 4.9.2-10.
>
> dpkg: error processing package wsjtx (--install):
>  dependency problems - leaving unconfigured
> Processing triggers for desktop-file-utils (0.22-1) ...
> Processing triggers for gnome-menus (3.13.3-6) ...
> Processing triggers for mime-support (3.58) ...
> Processing triggers for man-db (2.7.0.2-5) ...
> Errors were encountered while processing:
>  wsjtx

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK

[Greg Beam]

Hi Gary,

In the tar.gz you extracted is a file called README.pkg-list. That would 
be a good place to start.

73's
Greg, KI7MT

On 1/21/2017 11:18 AM, C. Gary Rogers wrote:
> So i downloaded the Linux version of JTSDK to learn how to compile WSJT-X
>
> INSTALLATION
> 
> * Download jtsdk-nix-2.0.21.tar.gz
> * Extract: tar -xf jtsdk-nix-2.0.21.tar.gz
> * cd ./jtsdk-nix-2.0.21
> * ./autogen.sh --prefix=/usr/local
>
> When i try the last command i get this:
>
> PACKAGE DEPENDENCY ERROR
>
> You must have the package Subversion installed to
> checkout and compile JTSDK. Please install the
> appropriate package for your distribution.
>
> Where can i find this package?
>
> Thanks Gary KO3F
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] First Alpha Release of MAP65 v2.7

[Greg Beam]

Hi Joe,

v2.7 r7545 installs and launches properly the first time.

I looked at the MAP65 build script, and it could use a fair bit of 
updating. I'll try to get to that this weekend.

73's
Greg, KI7MT


On 1/20/2017 9:43 AM, Joe Taylor wrote:
> Hi Bill and all,
>
>> that moves things on a bit. I can now install and run map65 but I get a
>> message box with:
>>
>> ---
>>
>> ---
>> Cannot open c:/JTSDK/map65/install/Release/bin/azel.dat
>> ---
>> OK
>> --
>
> It looks as though the package must include my file map65.ini.  Delete
> it and youshould be OK.
>
>> which keeps coming back instantly so I can only exit by killing the
>> map65 process. The map65.exe executable appears not to be a windows
>> application i.e. no winmain which is handy as the console window that
>> opens can be killed to kill the process, probably not desirable on later
>> releases.
>
> Yes, the package was built to include a console window.  I will change that.
>
>> I still don't see a qt.conf file in the package, I think this is
>> essential for any user that does not have the Qt development package
>> installed. You may have a qt.conf in the built in resources, I can't
>> check that, but if not then the default path to load plugins is
>> /plugins and the platform plugin must be in a
>> sub-directory of that called platform/ .
>
> RR, I have put a qt.conf in "resources" for r7545.
>
> Please try
> http://physics.princeton.edu/pulsar/k1jt/map65_2.7r7545-win32.exe
>
>   -- Joe
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] First Alpha Release of MAP65 v2.7

[Greg Beam]

Hi Joe, All,

I don't know what the root cause is at this point, but, check to see of 
the correct qwindows.dll is being copied into the platforms directory 
when building v2.7.

The v2.5 DLL is dated 2/1/2014 2:54 PM
The v2.7 DLL is dated 6/29/2015 4:57 AM

I installed, then ran v2.7, it failed. Renamed the 2.7 version to 
qwindows.dll.orig, copied qwindows.dll from v2.5, and v2.7 fired right up.

I don't know how your building MAP65, but, if your using JTSDK, there 
may be something amiss there. However, I've yet to identify it.

I'll keep looking as time allows.

73's
Greg, KI7MT



On 1/19/2017 8:42 PM, Joe Taylor wrote:
> Hi Bill and all,
>
> Two people have reported a problem starting the alpha release of MAP65:
>
> For example:
>
> After installing the program I get the following error when launching
> "Program has stopped working "looking for a Qt platform plugin "windows".
>
> On the installations I've tested, sub-directory "platforms" appears in
> ../bin and contains a single file, "qwindows.dll".  All seems as it should.
>
> It seems to me we faced this problem once before.  Maybe it depends on
> the Windows version?  Does anyone remember?
>
>   -- Joe


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK build-wsjtx errors

[Greg Beam]

Hi Josh,

Are you able to update the src/wsjtx directory manually from the command 
line?

cd C:\JTSDK\src\wsjtx
svn up

or similar commands.

73's
Greg, KI7MT


On 1/15/2017 7:56 AM, Josh Rovero wrote:
> Recently (last week or so) I have been getting the following error when
> attempting
> to "build-wsjtx package" on Windows 10.
>
>  SVN Check
> 
>
> Update from SVN Before Building? ( y/n )
>
> Type Response: y
>
> 
>  Sourceforge Update Error
> 
>
>  build-wsjtx was unable to update [ wsjtx ]
>  Sourceforge. The service may be down or
>  undergoing maintenance. Check the following
>  link for current site status reports:
>
>  http://sourceforge.net/blog/category/sitestatus/
>
>  If your sure the entry is correct and you suspect
>  a problem with the build script, contact the
>  wsjt-devel list for assistance.
>
> I have tried the basic "upgrade" and *update" JTSDK maintenance options,
> as well as reinstalling the JTSDK from sourceforge.  Response stays the
> same.  The sourceforge site status is not showing any problems.
>
> Any hints for resolving this?
>
> --
> P.J. "Josh" Rovero http://www.roveroresearch.org
> Ham Radio: KK1D http://www.roveroresearch.
> net
> http://www.roveroresearch.info

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FreqCal Mode

[Greg Beam]

Hi Joe,

This is great news. I tried to convert the FMT Fortran files to C++, but 
failed in an epic way, e. This will be a very welcome addition to 
WSJT-X.

Thanks!

Greg.



On 1/9/2017 2:45 PM, Joe Taylor wrote:
> Hi all,
>
> A brief follow-up to my message about FreqCal mode in WSJT-X.  The
> attached screen shot shows what my screen looked like after the program
> has cycled through the 11 test frequencies in my list.
>
> Counting up from the bottom in the waterfall, the frequencies are 660,
> 880, 1210, 2500, 3300, 5000, 7850, 1, 14670, 15000, and 2 kHz.
> The signals at 2500, 3330, and 7850 were too weak to use atthe time of
> this test.  The sequence starts over again after the 20 MHz signal from
> WWV.
>
> -- Joe, K1JT
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] error on building WSJT-x with JTSDK

[Greg Beam]

Hi Bill,

Everything is back to normal, thanks.

73's

Greg, KI7MT



On 12/12/2016 11:27 AM, Bill Somerville wrote:
> On 12/12/2016 12:50, Jay Hainline wrote:
>> Attached is an error message I received this morning when trying to
>> build to the latest version of WSJT-x 1.7.0-rc3.
> Hi Jay,
>
> sorry about that, a small issue compatibility with older versions of Qt.
> Should be ok as of r7380.
>
> 73
> Bill
> G4WJS.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] error on building WSJT-x with JTSDK

[Greg Beam]

Hi Jay,

I hit the same error on Linux last night. I am not sure what the root 
cause is. Maybe Bill can shed some light on is what happening.


73's

Greg, KI7MT


On 12/12/2016 5:50 AM, Jay Hainline wrote:


Attached is an error message I received this morning when trying to 
build to the latest version of WSJT-x 1.7.0-rc3. Currently using 
revision r7376 on a Windows 10 64 bit computer.


Jay Hainline KA9CFD

Colchester, IL  EN40om



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] problem compiling 1.7.0 rc 3 on ARM

[Greg Beam]

Hi Richard,

I agree with Bill on this. The problem appears to the same as you had 
before. I have the Lanchpad version of RC3 ready to posted, but that is 
not solving the problem at hand.

Are you sure you followed the steps / process posted in:

https://sourceforge.net/p/wsjt/mailman/message/35014724/

I have added all the required build dependencies to all the JTSDK Meta 
Pakcages and the WSJTX-NEXT package on Launchpad. If the package builds 
properly on Launchpad, that clearly indicates a problem on the local 
build platform, e.g. your installation. As a side note, I've also built 
WSJT-X using Pbuilder (Debian / Ubuntu bootstrap image) on my Linux 
workstation without error.

To my knowledge, there has been no changes from RC2 to RC3 that would be 
casing this problem. I do not believe this to be a problem WSJT-X, nor 
with the JTSDK build scripts. You have to remember, the JTSDK bash 
scripts are nothing more than a "very thin layer" between the user and 
required Cmake commands to build WSJTX. If your package dependencies are 
correct, you could easily perform the same or similar build commands 
manually on the command line. JTSDK is not required, in any capacity, to 
build WSJT-X on any platform.

73's

Greg, KI7MT



On 12/6/2016 5:48 PM, Richard Bown wrote:
> more info
>
> I'm getting many errors like this on building:-
> /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglfunctions.h:2138:5: error: 
> ‘::glVertexAttribPointer’ has not been declared
>   ::glVertexAttribPointer(indx, size, type, normalized, stride, ptr);
>
> I've loaded all qt5 libs, all fitting vertex* all *libgl* all *gles* , about 
> 800 MB , its not
> playing !!
> before each build jtsdk/wsjtx is deleted so its a clean build.
> Guess I'll have to wait until Greg builds an ARMhf rc3
> This is not going to build on the odroid xu4 without some magic applied
>
>
>
> On Tue, 6 Dec 2016 23:26:36 +
> Richard Bown  wrote:
>
>> this is not responding to deleting all previous builds and gar/
>>
>> tried that several times :(
>>
>>
>> On Tue, 6 Dec 2016 21:49:32 +
>> Bill Somerville  wrote:
>>
>>> On 06/12/2016 21:29, Richard Bown wrote:
 I suspect the problem may be with opengl
 comparing between the two machine, on the ARM I get many jopengl errors
>>> Hi Richard,
>>>
>>> this seems to be a re-run of this thread:
>>>
>>> https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/20160414184913.209df085.richard%40g8jvm.com/#msg35014162
>>>
>>> that seemed to be cleared up by some clean up and re-building.
>>>
>>> 73
>>> Bill
>>> G4WJS.
>>>
>>>
>>> --
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today.http://sdm.link/xeonphi
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] My problems while trying to get the audio samples

[Greg Beam]

Hi Bill,

I don't think, least wise, not by design, JTSDK is installing OpenSSL 
libraries. There are ssleay dll's that accompany applications such as 
Subversion which are renamed under their own naming convention. I would 
have to verify MSYS, Cygwin and the like, however Cygwin is a user 
initiated installation which then in turn installs several packages and 
their dependencies, one of which is likely to be open-ssh. I can't speak 
to QT and it's packaging at the moment, as I do not have access to my 
Windows machine at present. I will look into it though.


As for Windows directory installation, the only thing that gets 
installed in those areas are the Microsoft re-dist packages. But again, 
that is a user initiated action, not something the JTSDK installer 
performs unattended.


73's
Greg, KI7MT


On 12/4/2016 2:49 PM, Bill Somerville wrote:

On 04/12/2016 21:21, Black Michael wrote:
Was trying to figure out how the dlls are copied to the JTSDK install 
directories without any luck.
What gets copied the the release install directory is an old version 
of libeay32.dll from 2008


Hi Mike,

the JTSDK should not be copying any OpenSSL libraries anywhere, if it 
is then that should stop. The package I suggested in this thread is 
perfectly adequate and installing it to the recommended Windows system 
directories is preferable rather than trying to get the right files 
into an application binary directory. OpenSSL is one of the few 
non-Microsoft packages I would recommend installing into the Windows 
system directories.


73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ALL.txt idea

[Greg Beam]

Hi Mike,

I am not sure if the ALL.txt discussion has come up before (probably has 
at some point), but certainly CALL3.txt has made the rounds several 
times. I was able to get CALL3 Database functionality working with 
SQLite for WSJT, and have a stand alone application for WSPR to process 
millions of spots the archives produce monthly, however, it does add a 
level of complexity to the application that may be more than is needed 
for minimal operation.

It's hard to dismiss the simplicity of flat text files. On the other 
hand, having data in tables lends itself to many positive benefits. For 
example, the queries in this thread would be a fairly simple SQL query 
rather than requiring a Black Belt in command-line foo to extract it. 
Not to mention, the SQL language is cross-platform, and generally, no 
additional tools are required, but many exit at the users option.

I am not suggesting that WSJT-X integrate post processing tools, rather, 
I am merely suggesting that the data could be stored in a different 
format ( DB tables) that allows easy access by third party developers or 
primary users, in a more structured manner.


73's
Greg, KI7MT

On 11/7/2016 7:18 AM, Black Michael wrote:
> I wouldn't be inclined to add database support when the most common
> operations are achievable with the existing ALL.TXT.  Haven't we
> discussed this before?  Somebody said something about putting the
> messages in an sqlite database as I recall and had implemented something.
> Though I'm sure we could make it portable it's adding a fair bit of new
> stuff and overhead for doing this simple task.  Right now my logic is
> about 100 lines of code and can pick up non-standard end-of-qso messages
> to some degree right now.
>
> Is there some other function desirable from a database that would
> justify it?  I can see where adding a field for "Rx Frequency" window
> message presence would help in processing QSOs.  Non-standard QSO
> messages would be an SQL challenge.
>
>
> de Mike W9MDB
>
>
>
> 
> *From:* Greg Beam 
> *To:* Black Michael ; WSJT software development
> 
> *Sent:* Monday, November 7, 2016 12:37 AM
> *Subject:* Re: [wsjt-devel] ALL.txt idea
>
> Hi Mike,
>
> This is another email I just pulled out of the spam box. No wonder I was
> missing the other half of the conversation.
>
> Ive been thinking about these text files for some time now. There has to
> be a better way than exercising command-line foo to get the data folks
> need. Not that I mind the command line, I spend most of my time there,
> but that's not very helpful to the masses.
>
> There seems to be allot of different uses for CALL3.txt and the ALL.txt
> files. I keep circling back to database tables and I've played with the
> CALL.txt file a bit with WSJT, but the Qt / C++ deal with WSJT-X I've
> not gotten through yet.
>
> Maybe if we sit down and try to capture most or at least some of the
> requirements, we could start kicking around some DB integration design
> concepts.
>
> 73's
> Greg, KI7MT
>
>
> On 11/6/2016 11:03 AM, Black Michael wrote:
>> Pretty simplewhen, for example, on eQSL, you get a mismatched QSL
>> you can look at your messages to see if they got it wrong or you did.
>> And you can submit the evidence to them so they can correct or you
>> correct your own.
>>
>> I've also used it when noticing in JTAlert that a band isn't
>> confirmed...I can look them up and see the evidence again and either
>> correct my log or ask them to correct theirs.
>>
>> With LOTW you don't have that luxury.since there's no visibility of
>> mismatched QSOs
>>
>> And yes...this is a WSJT Dev list item as I'm proposing submitting a
>> patch to make this easy for everyone instead of just those with grep,
>> EMACS, or whatever they may be currently using.
>>
>> de Mike W9MDB
>>
>>
>> 
>> *From:* Greg Beam mailto:ki7m...@gmail.com>>
>> *To:* WSJT software development  <mailto:wsjt-devel@lists.sourceforge.net>>
>> *Sent:* Sunday, November 6, 2016 11:40 AM
>> *Subject:* Re: [wsjt-devel] ALL.txt idea
>>
>> Hello All,
>>
>> I'm not sure this is a WSJT Dev list item, and, I arrived late to the
>> party on this is seems, but:
>>
>> What is the end goal here? What are you trying accomplish with the
>> ALL.txt file?
>>
>> 73's
>> Greg, KI7MT
>>
>>
>> On 11/6/2016 10:05 AM, Claude Frantz wrote:
>>> On 11/05/2016 03:42 PM, Black Mi

Re: [wsjt-devel] ALL.txt idea

[Greg Beam]

Hi Mike,

This is another email I just pulled out of the spam box. No wonder I was 
missing the other half of the conversation.

Ive been thinking about these text files for some time now. There has to 
be a better way than exercising command-line foo to get the data folks 
need. Not that I mind the command line, I spend most of my time there, 
but that's not very helpful to the masses.

There seems to be allot of different uses for CALL3.txt and the ALL.txt 
files. I keep circling back to database tables and I've played with the 
CALL.txt file a bit with WSJT, but the Qt / C++ deal with WSJT-X I've 
not gotten through yet.

Maybe if we sit down and try to capture most or at least some of the 
requirements, we could start kicking around some DB integration design 
concepts.

73's
Greg, KI7MT


On 11/6/2016 11:03 AM, Black Michael wrote:
> Pretty simplewhen, for example, on eQSL, you get a mismatched QSL
> you can look at your messages to see if they got it wrong or you did.
> And you can submit the evidence to them so they can correct or you
> correct your own.
>
> I've also used it when noticing in JTAlert that a band isn't
> confirmed...I can look them up and see the evidence again and either
> correct my log or ask them to correct theirs.
>
> With LOTW you don't have that luxury.since there's no visibility of
> mismatched QSOs
>
> And yes...this is a WSJT Dev list item as I'm proposing submitting a
> patch to make this easy for everyone instead of just those with grep,
> EMACS, or whatever they may be currently using.
>
> de Mike W9MDB
>
>
> 
> *From:* Greg Beam 
> *To:* WSJT software development 
> *Sent:* Sunday, November 6, 2016 11:40 AM
> *Subject:* Re: [wsjt-devel] ALL.txt idea
>
> Hello All,
>
> I'm not sure this is a WSJT Dev list item, and, I arrived late to the
> party on this is seems, but:
>
> What is the end goal here? What are you trying accomplish with the
> ALL.txt file?
>
> 73's
> Greg, KI7MT
>
>
> On 11/6/2016 10:05 AM, Claude Frantz wrote:
>> On 11/05/2016 03:42 PM, Black Michael wrote:
>>
>> Hi Michael,
>>
>>> And how are you doing that?  I wrote a program so all I have to do is
>>> "qsos dj0ot"
>>
>> I'm simply using the emacs editor, which has fine search functions.
>>
>>> Don't have any with you but here's what the output for me looks like for
>>> DJ0TP -- it looks at two files (actually looks at every "ALL*.txt"
>>> wildcard match)
>>
>> OK ! The same result is possible using the grep utility, which is
>> available in nearly all Unix and Linux distributions. It's really a
>> standard tool.
>>
>> Best 88 de Claude (DJ0OT)
>>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK and hamlib

[Greg Beam]

Hi Mike,

I just checked my span filter box (monthly cleanup), and for whatever 
reason, all the your emails from Yahoo are landing in there.

That should not be to difficult. As a work around, comment out lines 
237-246 of msys-build-hamlib3.sh, that should skip the make clean step.

73's
Greg, KI7MT

On 11/4/2016 11:16 AM, Black Michael wrote:
> Could we get an option to build hamlib without doing a clean first?
>
> de Mike W9MDB
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel