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?

[Stephen Ireland]

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 
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 o

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?

[Bill Somerville]

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
<mailto: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 <mailto: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 th

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

[Marco Calistri via wsjt-devel]

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 your results, I am going to stay with what I
>>> have on Tumbleweed since it is working great.
>>>
>>> Ciao!
>>>
>>> --
>>>   Adam Schaible
>>>   kb3...@schibes.com 
>>>
>>>
>>>
>>> On Thu, Oct 25, 2018, at 11:16 AM, Adam Schaible wrote:
 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 your results, I am going to stay with what I
 have on Tumbleweed since it is working great.

 Ciao!

 --
   Adam Schaible
   a...@schibes.com 



 On Thu, Oct 25, 2018, at 10:20 AM, Marco Calistri via wsjt-devel wrote:
>
>
> Il 22/10/18 17:31, Adam Schaible ha scritto:
>> Buonasera Marco,
>>
>> OpenSUSE Tumbleweed you say? Sure I can handle that. Here is a tested 
>> and working script to build WSJT-X 2.0.0 RC3 on that distro. 
>>
>> First, disclaimers/notes and then, the script:
>>
>> 1) I am NOT a WSJT-X developer, I am just a regular ham radio operator 
>> who loves Linux. (I did meet K1JT once a few years ago at a speech he 
>> gave, it was fun!) So if you run my script below and it breaks your 
>> computer don't blame the wonderful WSJT-X devs, blame only me. By the 
>> 

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

[Adam Schaible]

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 your results, I am going to stay with what I
>> have on Tumbleweed since it is working great.>> 
>> Ciao!
>> 
>> --
>>   Adam Schaible
>>   kb3...@schibes.com
>> 
>> 
>> 
>> On Thu, Oct 25, 2018, at 11:16 AM, Adam Schaible wrote:
>>> 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 your results, I am going to stay with what I
>>> have on Tumbleweed since it is working great.>>> 
>>> Ciao!
>>> 
>>> --
>>>   Adam Schaible
>>>   a...@schibes.com
>>> 
>>> 
>>> 
>>> On Thu, Oct 25, 2018, at 10:20 AM, Marco Calistri via wsjt-devel
>>> wrote: 
 
 Il 22/10/18 17:31, Adam Schaible ha scritto:
> Buonasera Marco,  OpenSUSE Tumbleweed you say? Sure I can handle
> that. Here is a tested and working script to build WSJT-X 2.0.0
> RC3 on that distro.  First, disclaimers/notes and then, the
> script:  1) I am NOT a WSJT-X developer, I am just a regular ham
> radio operator who loves Linux. (I did meet K1JT once a few years
> ago at a speech he gave, it was fun!) So if you run my script
> below and it breaks your computer don't blame the wonderful WSJT-X
> devs, blame only me. By the way I have never tried Tumbleweed
> before today and I am very impressed, enough so that I may even
> use it to make a few contacts in WSJT-X :)  2) You do know there
> is an .rpm binary download of WSJT-X 2.0.0 RC3 available right? So
> we don't actually "need" to do any of this except for
> "educational" purposes.  3) The WSJT-X 2.0.0 RC3 build script
> below is tested and working on a 6 hours old bare metal install of
> OpenSUSE Tumbleweed (KDE) on my Lenovo ThinkPad T440. For purpose
> of comparison I also built it on OpenSUSE Leap 15 running in a VM
> (AWS t2.micro), process was almost identical with just a few small
> differences that keep it from being able to run as a non-
> interact

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

[Marco Calistri via wsjt-devel]

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 your results, I am going to stay with what I have on
> Tumbleweed since it is working great.
>
> Ciao!
>
> -- 
>   Adam Schaible
>   kb3...@schibes.com
>
>
>
> On Thu, Oct 25, 2018, at 11:16 AM, Adam Schaible wrote:
>> 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 your results, I am going to stay with what I
>> have on Tumbleweed since it is working great.
>>
>> Ciao!
>>
>> --
>>   Adam Schaible
>>   a...@schibes.com
>>
>>
>>
>> On Thu, Oct 25, 2018, at 10:20 AM, Marco Calistri via wsjt-devel wrote:
>>>
>>>
>>> Il 22/10/18 17:31, Adam Schaible ha scritto:
 Buonasera Marco,

 OpenSUSE Tumbleweed you say? Sure I can handle that. Here is a tested and 
 working script to build WSJT-X 2.0.0 RC3 on that distro. 

 First, disclaimers/notes and then, the script:

 1) I am NOT a WSJT-X developer, I am just a regular ham radio operator who 
 loves Linux. (I did meet K1JT once a few years ago at a speech he gave, it 
 was fun!) So if you run my script below and it breaks your computer don't 
 blame the wonderful WSJT-X devs, blame only me. By the way I have never 
 tried Tumbleweed before today and I am very impressed, enough so that I 
 may even use it to make a few contacts in WSJT-X :)

 2) You do know there is an .rpm binary download of WSJT-X 2.0.0 RC3 
 available right? So we don't actually "need" to do any of this except for 
 "educational" purposes. 
  
 3) The WSJT-X 2.0.0 RC3 build script below is tested and working on a 6 
 hours old bare metal install of OpenSUSE Tumbleweed (KDE) on my Lenovo 
 ThinkPad T440. For purpose of comparison I also built it on OpenSUSE Leap 
 15 running in a VM (AWS t2.micro), process was almost identical with just 
 a few small differences that keep it from being able to run as a 
 non-interactive script on Leap (repo update and devel-basis install both 
 need command-line interventions, and Leap compilers are g++-7/gfortran-7), 
 but it still builds fine. Given these positive results, without any 
 further knowledge I can only guess your previous build issues were caused 
 by (as usual) missing dependencies.

 GL es 73 de Adam KB3ZUV


 #!/bin/bash
 #-wsjtx2rc3-opensuseTW-build-script.sh---
 #--RUN ME WITH SUDO-
 #
 #first the obligatory OS patching
 #since this is Tumbleweed we do full distro upgrade
 zypper ref && zypper dup -y
 #add user to dialout group allowing rig CAT control on next login
 #(if you use VOX you don't actually need this)
 usermod -a -G dialout $SUDO_USER
 #install a whole bunch of dependencies to compile WSJT-X
 #g++, git, and automake are all in devel_basis
 zypper in -y --type pattern devel_basis && zypper in -y fftw3-devel \
 fftw3-threads-devel gcc-fortran cmake libqt5-qtbase-devel \
 libqt5-qtmultimedia-devel libqt5-qt

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

[Adam Schaible]

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 your results, I am going to stay with what I have on
Tumbleweed since it is working great.
Ciao!

-- 
  Adam Schaible
  kb3...@schibes.com



On Thu, Oct 25, 2018, at 11:16 AM, Adam Schaible wrote:
> 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 your results, I am going to stay with what I have on
> Tumbleweed since it is working great.> 
> Ciao!
> 
> --
>   Adam Schaible
>   a...@schibes.com
> 
> 
> 
> On Thu, Oct 25, 2018, at 10:20 AM, Marco Calistri via wsjt-
> devel wrote:>> 
>> 
>> Il 22/10/18 17:31, Adam Schaible ha scritto:
>>> Buonasera Marco,  OpenSUSE Tumbleweed you say? Sure I can handle
>>> that. Here is a tested and working script to build WSJT-X 2.0.0 RC3
>>> on that distro.  First, disclaimers/notes and then, the script:  1)
>>> I am NOT a WSJT-X developer, I am just a regular ham radio operator
>>> who loves Linux. (I did meet K1JT once a few years ago at a speech
>>> he gave, it was fun!) So if you run my script below and it breaks
>>> your computer don't blame the wonderful WSJT-X devs, blame only me.
>>> By the way I have never tried Tumbleweed before today and I am very
>>> impressed, enough so that I may even use it to make a few contacts
>>> in WSJT-X :)  2) You do know there is an .rpm binary download of WSJT-
>>> X 2.0.0 RC3 available right? So we don't actually "need" to do any
>>> of this except for "educational" purposes.  3) The WSJT-X 2.0.0 RC3
>>> build script below is tested and working on a 6 hours old bare metal
>>> install of OpenSUSE Tumbleweed (KDE) on my Lenovo ThinkPad T440. For
>>> purpose of comparison I also built it on OpenSUSE Leap 15 running in
>>> a VM (AWS t2.micro), process was almost identical with just a few
>>> small differences that keep it from being able to run as a non-
>>> interactive script on Leap (repo update and devel-basis install both
>>> need command-line interventions, and Leap compilers are g++-7/gfortran-
>>> 7), but it still builds fine. Given these positive results, without
>>> any further knowledge I can only guess your previous build issues
>>> were caused by (as usual) missing dependencies.  GL es 73 de Adam
>>> KB3ZUV   #!/bin/bash #-wsjtx2rc3-opensuseTW-build-script.sh---
>>> #--RUN ME WITH SUDO- # #first the obligatory
>>> OS patching #since this is Tumbleweed we do full distro upgrade
>>> zypper ref && zypper dup -y #add user to dialout group allowing rig
>>> CAT control on next login #(if you use VOX you don't actually need
>>> this) usermod -a -G dialout $SUDO_USER #install a whole bunch of
>>> dependencies to compile WSJT-X #g++, git, and automake are all in
>>> devel_basis zypper in -y --type pattern devel_basis && zypper in -y
>>> fftw3-devel \ fftw3-threads-devel gcc-fortran cmake libqt5-qtbase-
>>> devel \ libqt5-qtmultimedia-devel libqt5-qtconnectivity-devel \ 
>>> libqt5-qtserialport-
>>> devel libusb-1_0-devel asciidoc hamlib-devel \ ruby2.5-rubygem-
>>> asciidoctor libpulse-devel libudev-devel #create some directories
>>> for WSJT-X sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource sudo
>>> -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx #grab and unzip the
>>> source code from Princeton wget --no-check-certificate \
>>> https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz sudo
>>> -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \ -C
>>> /home/$SUDO_USER/jtsource cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-
>>> rc3 #set build options sudo -u $SUDO_USER cmake -D 
>>> CMAKE_CXX_COMPILER="/usr/bin/g++-
>>> 8" \ -D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-8" \ -D
>>> CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx . #build WSJT-X on
>>> OpenSUSE sudo -u $SUDO_USER cmake --build . --target install #after
>>> build, to run wsjtx2 RC3 type:  ~/.wsjtx/bin/wsjtx #-EOF---

> Hello Adam,
>> 
>> I verified on my system and I had already all dependencies installed,
>> but ruby2.5-rubygem-asciidoctor and  asciidoc.>> 
>> When I tried to install the latter package, zypper answers with a
>> warning that to accompany this, I would need to install *2207*
>> additio

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

[Marco Calistri via wsjt-devel]

Reply is at the bottom.

Il 25/10/18 11:20, Marco Calistri via wsjt-devel ha scritto:
>
>
> Il 22/10/18 17:31, Adam Schaible ha scritto:
>> Buonasera Marco,
>>
>> OpenSUSE Tumbleweed you say? Sure I can handle that. Here is a tested and 
>> working script to build WSJT-X 2.0.0 RC3 on that distro. 
>>
>> First, disclaimers/notes and then, the script:
>>
>> 1) I am NOT a WSJT-X developer, I am just a regular ham radio operator who 
>> loves Linux. (I did meet K1JT once a few years ago at a speech he gave, it 
>> was fun!) So if you run my script below and it breaks your computer don't 
>> blame the wonderful WSJT-X devs, blame only me. By the way I have never 
>> tried Tumbleweed before today and I am very impressed, enough so that I may 
>> even use it to make a few contacts in WSJT-X :)
>>
>> 2) You do know there is an .rpm binary download of WSJT-X 2.0.0 RC3 
>> available right? So we don't actually "need" to do any of this except for 
>> "educational" purposes. 
>>  
>> 3) The WSJT-X 2.0.0 RC3 build script below is tested and working on a 6 
>> hours old bare metal install of OpenSUSE Tumbleweed (KDE) on my Lenovo 
>> ThinkPad T440. For purpose of comparison I also built it on OpenSUSE Leap 15 
>> running in a VM (AWS t2.micro), process was almost identical with just a few 
>> small differences that keep it from being able to run as a non-interactive 
>> script on Leap (repo update and devel-basis install both need command-line 
>> interventions, and Leap compilers are g++-7/gfortran-7), but it still builds 
>> fine. Given these positive results, without any further knowledge I can only 
>> guess your previous build issues were caused by (as usual) missing 
>> dependencies.
>>
>> GL es 73 de Adam KB3ZUV
>>
>>
>> #!/bin/bash
>> #-wsjtx2rc3-opensuseTW-build-script.sh---
>> #--RUN ME WITH SUDO-
>> #
>> #first the obligatory OS patching
>> #since this is Tumbleweed we do full distro upgrade
>> zypper ref && zypper dup -y
>> #add user to dialout group allowing rig CAT control on next login
>> #(if you use VOX you don't actually need this)
>> usermod -a -G dialout $SUDO_USER
>> #install a whole bunch of dependencies to compile WSJT-X
>> #g++, git, and automake are all in devel_basis
>> zypper in -y --type pattern devel_basis && zypper in -y fftw3-devel \
>> fftw3-threads-devel gcc-fortran cmake libqt5-qtbase-devel \
>> libqt5-qtmultimedia-devel libqt5-qtconnectivity-devel \
>> libqt5-qtserialport-devel libusb-1_0-devel asciidoc hamlib-devel \
>> ruby2.5-rubygem-asciidoctor libpulse-devel libudev-devel
>> #create some directories for WSJT-X
>> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource 
>> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
>> #grab and unzip the source code from Princeton
>> wget --no-check-certificate \
>> https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
>> sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
>> -C /home/$SUDO_USER/jtsource
>> cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
>> #set build options
>> sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++-8" \
>> -D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-8" \
>> -D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
>> #build WSJT-X on OpenSUSE
>> sudo -u $SUDO_USER cmake --build . --target install
>> #after build, to run wsjtx2 RC3 type:  ~/.wsjtx/bin/wsjtx
>> #-EOF---
>>
> Hello Adam,
>
> I verified on my system and I had already all dependencies installed,
> but ruby2.5-rubygem-asciidoctor and  asciidoc.
>
> When I tried to install the latter package, zypper answers with a
> warning that to accompany this, I would need to install *2207*
> additional "texlive packages",
> then of course I didn't hit 'yes'!
>
> I suppose this requirement of having asciidoc installed can be easily
> omitted by telling to "configure" script to not install the
> "man-pages" and the "html docs".
>
> Thus I will try to build the WSJT-X source again following only
> partially your guidelines.
>
> Regards,
> -- 
> 73 de P1ZRJ
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
The error is exactly the same I faced all the times I tried to compile
WSJT-X from source.

It is related to hamlib and not to docs files as it should be due the
missing asciidocs package, so for now I will suspend my unsuccesfull
attempts

-- Building wsjtx-2.0.0-rc3
-- **
-- Building for for: Linux-x86_64
-- **
-- Boost version: 1.63.0
-- Found OpenMP_C: -fopenmp (found version "4.5")
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
-- Found OpenMP_Fortran: -fopenmp (found version "4.5")
-- Found OpenMP: TRUE (found version "4.5") 
-- Found FFTW3: /usr/lib64/libfftw3_threads.so 
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2")
-- Checking for module 'hamlib'
--   Found haml

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

[Marco Calistri via wsjt-devel]

Il 22/10/18 17:31, Adam Schaible ha scritto:
> Buonasera Marco,
>
> OpenSUSE Tumbleweed you say? Sure I can handle that. Here is a tested and 
> working script to build WSJT-X 2.0.0 RC3 on that distro. 
>
> First, disclaimers/notes and then, the script:
>
> 1) I am NOT a WSJT-X developer, I am just a regular ham radio operator who 
> loves Linux. (I did meet K1JT once a few years ago at a speech he gave, it 
> was fun!) So if you run my script below and it breaks your computer don't 
> blame the wonderful WSJT-X devs, blame only me. By the way I have never tried 
> Tumbleweed before today and I am very impressed, enough so that I may even 
> use it to make a few contacts in WSJT-X :)
>
> 2) You do know there is an .rpm binary download of WSJT-X 2.0.0 RC3 available 
> right? So we don't actually "need" to do any of this except for "educational" 
> purposes. 
>  
> 3) The WSJT-X 2.0.0 RC3 build script below is tested and working on a 6 hours 
> old bare metal install of OpenSUSE Tumbleweed (KDE) on my Lenovo ThinkPad 
> T440. For purpose of comparison I also built it on OpenSUSE Leap 15 running 
> in a VM (AWS t2.micro), process was almost identical with just a few small 
> differences that keep it from being able to run as a non-interactive script 
> on Leap (repo update and devel-basis install both need command-line 
> interventions, and Leap compilers are g++-7/gfortran-7), but it still builds 
> fine. Given these positive results, without any further knowledge I can only 
> guess your previous build issues were caused by (as usual) missing 
> dependencies.
>
> GL es 73 de Adam KB3ZUV
>
>
> #!/bin/bash
> #-wsjtx2rc3-opensuseTW-build-script.sh---
> #--RUN ME WITH SUDO-
> #
> #first the obligatory OS patching
> #since this is Tumbleweed we do full distro upgrade
> zypper ref && zypper dup -y
> #add user to dialout group allowing rig CAT control on next login
> #(if you use VOX you don't actually need this)
> usermod -a -G dialout $SUDO_USER
> #install a whole bunch of dependencies to compile WSJT-X
> #g++, git, and automake are all in devel_basis
> zypper in -y --type pattern devel_basis && zypper in -y fftw3-devel \
> fftw3-threads-devel gcc-fortran cmake libqt5-qtbase-devel \
> libqt5-qtmultimedia-devel libqt5-qtconnectivity-devel \
> libqt5-qtserialport-devel libusb-1_0-devel asciidoc hamlib-devel \
> ruby2.5-rubygem-asciidoctor libpulse-devel libudev-devel
> #create some directories for WSJT-X
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource 
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
> #grab and unzip the source code from Princeton
> wget --no-check-certificate \
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
> sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
> -C /home/$SUDO_USER/jtsource
> cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
> #set build options
> sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++-8" \
> -D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-8" \
> -D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
> #build WSJT-X on OpenSUSE
> sudo -u $SUDO_USER cmake --build . --target install
> #after build, to run wsjtx2 RC3 type:  ~/.wsjtx/bin/wsjtx
> #-EOF---
>
Hello Adam,

I verified on my system and I had already all dependencies installed,
but ruby2.5-rubygem-asciidoctor and  asciidoc.

When I tried to install the latter package, zypper answers with a
warning that to accompany this, I would need to install *2207*
additional "texlive packages",
then of course I didn't hit 'yes'!

I suppose this requirement of having asciidoc installed can be easily
omitted by telling to "configure" script to not install the "man-pages"
and the "html docs".

Thus I will try to build the WSJT-X source again following only
partially your guidelines.

Regards,
-- 
73 de P1ZRJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[Marco Calistri via wsjt-devel]

*Foreword:*

/Would like to know if the list maintainer wish we respond top or bottom.//
//I'm an opensuse mailing list member and there we use to respond bottom
the text of the OP, otherwise we went blamed!/


Il 22/10/18 17:31, Adam Schaible ha scritto:
> Buonasera Marco,
Ciao Adam!
>
> OpenSUSE Tumbleweed you say? Sure I can handle that. Here is a tested and 
> working script to build WSJT-X 2.0.0 RC3 on that distro. 
>
> First, disclaimers/notes and then, the script:
>
> 1) I am NOT a WSJT-X developer, I am just a regular ham radio operator who 
> loves Linux. (I did meet K1JT once a few years ago at a speech he gave, it 
> was fun!) So if you run my script below and it breaks your computer don't 
> blame the wonderful WSJT-X devs, blame only me. By the way I have never tried 
> Tumbleweed before today and I am very impressed, enough so that I may even 
> use it to make a few contacts in WSJT-X :)
Despite the word "Tumbleweed", the stability of this distro is amazing!
I have a sort of reverential respect for all devs in general and in
particular for K1JT, who was able to develop such a wonderful software
as the WSJT-X
>
> 2) You do know there is an .rpm binary download of WSJT-X 2.0.0 RC3 available 
> right? So we don't actually "need" to do any of this except for "educational" 
> purposes. 
Yes I know this and I'm using it, I get latest rpm from the following
repository:
http://download.opensuse.org/repositories/home:/jfrede:/hamradio/openSUSE_Tumbleweed/
>  
> 3) The WSJT-X 2.0.0 RC3 build script below is tested and working on a 6 hours 
> old bare metal install of OpenSUSE Tumbleweed (KDE) on my Lenovo ThinkPad 
> T440. For purpose of comparison I also built it on OpenSUSE Leap 15 running 
> in a VM (AWS t2.micro), process was almost identical with just a few small 
> differences that keep it from being able to run as a non-interactive script 
> on Leap (repo update and devel-basis install both need command-line 
> interventions, and Leap compilers are g++-7/gfortran-7), but it still builds 
> fine. Given these positive results, without any further knowledge I can only 
> guess your previous build issues were caused by (as usual) missing 
> dependencies.
>
> GL es 73 de Adam KB3ZUV
>
>
> #!/bin/bash
> #-wsjtx2rc3-opensuseTW-build-script.sh---
> #--RUN ME WITH SUDO-
> #
> #first the obligatory OS patching
> #since this is Tumbleweed we do full distro upgrade
> zypper ref && zypper dup -y
> #add user to dialout group allowing rig CAT control on next login
> #(if you use VOX you don't actually need this)
> usermod -a -G dialout $SUDO_USER
> #install a whole bunch of dependencies to compile WSJT-X
> #g++, git, and automake are all in devel_basis
> zypper in -y --type pattern devel_basis && zypper in -y fftw3-devel \
> fftw3-threads-devel gcc-fortran cmake libqt5-qtbase-devel \
> libqt5-qtmultimedia-devel libqt5-qtconnectivity-devel \
> libqt5-qtserialport-devel libusb-1_0-devel asciidoc hamlib-devel \
> ruby2.5-rubygem-asciidoctor libpulse-devel libudev-devel
> #create some directories for WSJT-X
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource 
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
> #grab and unzip the source code from Princeton
> wget --no-check-certificate \
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
> sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
> -C /home/$SUDO_USER/jtsource
> cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
> #set build options
> sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++-8" \
> -D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-8" \
> -D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
> #build WSJT-X on OpenSUSE
> sudo -u $SUDO_USER cmake --build . --target install
> #after build, to run wsjtx2 RC3 type:  ~/.wsjtx/bin/wsjtx
> #-EOF---
>
Thanks a lot for your script, I will try it on my Linux box; I'll let
you know the outcomes.

73!

-- 
Marco Calistri PY1ZRJ

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

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

[Adam Schaible]

Buonasera Marco,

OpenSUSE Tumbleweed you say? Sure I can handle that. Here is a tested and 
working script to build WSJT-X 2.0.0 RC3 on that distro. 

First, disclaimers/notes and then, the script:

1) I am NOT a WSJT-X developer, I am just a regular ham radio operator who 
loves Linux. (I did meet K1JT once a few years ago at a speech he gave, it was 
fun!) So if you run my script below and it breaks your computer don't blame the 
wonderful WSJT-X devs, blame only me. By the way I have never tried Tumbleweed 
before today and I am very impressed, enough so that I may even use it to make 
a few contacts in WSJT-X :)

2) You do know there is an .rpm binary download of WSJT-X 2.0.0 RC3 available 
right? So we don't actually "need" to do any of this except for "educational" 
purposes. 
 
3) The WSJT-X 2.0.0 RC3 build script below is tested and working on a 6 hours 
old bare metal install of OpenSUSE Tumbleweed (KDE) on my Lenovo ThinkPad T440. 
For purpose of comparison I also built it on OpenSUSE Leap 15 running in a VM 
(AWS t2.micro), process was almost identical with just a few small differences 
that keep it from being able to run as a non-interactive script on Leap (repo 
update and devel-basis install both need command-line interventions, and Leap 
compilers are g++-7/gfortran-7), but it still builds fine. Given these positive 
results, without any further knowledge I can only guess your previous build 
issues were caused by (as usual) missing dependencies.

GL es 73 de Adam KB3ZUV


#!/bin/bash
#-wsjtx2rc3-opensuseTW-build-script.sh---
#--RUN ME WITH SUDO-
#
#first the obligatory OS patching
#since this is Tumbleweed we do full distro upgrade
zypper ref && zypper dup -y
#add user to dialout group allowing rig CAT control on next login
#(if you use VOX you don't actually need this)
usermod -a -G dialout $SUDO_USER
#install a whole bunch of dependencies to compile WSJT-X
#g++, git, and automake are all in devel_basis
zypper in -y --type pattern devel_basis && zypper in -y fftw3-devel \
fftw3-threads-devel gcc-fortran cmake libqt5-qtbase-devel \
libqt5-qtmultimedia-devel libqt5-qtconnectivity-devel \
libqt5-qtserialport-devel libusb-1_0-devel asciidoc hamlib-devel \
ruby2.5-rubygem-asciidoctor libpulse-devel libudev-devel
#create some directories for WSJT-X
sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource 
sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
#grab and unzip the source code from Princeton
wget --no-check-certificate \
https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
-C /home/$SUDO_USER/jtsource
cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
#set build options
sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++-8" \
-D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-8" \
-D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
#build WSJT-X on OpenSUSE
sudo -u $SUDO_USER cmake --build . --target install
#after build, to run wsjtx2 RC3 type:  ~/.wsjtx/bin/wsjtx
#-EOF---

-- 
  Adam Schaible
  kb3...@schibes.com

On Mon, Oct 22, 2018, at 9:04 AM, Marco Calistri via wsjt-devel wrote:
> 
> 
> Il 21/10/18 07:22, Adam Schaible ha scritto:
> > Good morning Linux WSJT-X fans,
> >
> > Awesome discussion going on in this thread, using all the feedback so far 
> > I've gone and hacked up some build scripts for RC3 on a couple different 
> > Linux distros (Debian and Solus). First some banter and then, the scripts.
> >
> > 1) Scripts use Paul's cmake flags and attempt to be compliant with Bill's 
> > statement on build permissions. You do still need to run the scripts as 
> > sudo to install dependencies up top but I've reduced permissions down below 
> > where the actual build takes place. 
> >
> > 2) Scripts are tested and working on stock Debian 9 (AWS t2.micro 
> > instance), Raspbian Stretch (this is for you Evariste, I compiled it on my 
> > Pi 3+), and Solus 3. (my Dell laptop). Bill will probably be able to 
> > find several more superfluous packages in my script(s) beyond what Paul has 
> > mentioned but those can always be cleaned up later on, I just want to get 
> > something up and running to share with everyone ASAP. 
> >
> > 3) What is Solus? It's a new, cheerfully minimalist Linux distro that uses 
> > neither .deb nor .rpm files, so there is no other way to get WSJT-X RC3 
> > running on it other than to build from source. I had been using Mint for 
> > over five years and while Stan is considering migrating to it, I've moved 
> > completely off because of some very bad experiences upgrading to Mint 19 a 
> > couple months ago (particularly the new "Timeshift" feature which 
> > bludgeoned my hard drive almost beyond recognition). Hopefully Stan has 
> > better luck than I did. Meanwhile I plan on contacting the Solus devs to 
> > see if they will consider packaging WSJT-X in their own ".eopkg" format for 
> > when 2.0 is officially released, and if not, I'll probably move over 

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

[Marco Calistri via wsjt-devel]

Il 21/10/18 07:22, Adam Schaible ha scritto:
> Good morning Linux WSJT-X fans,
>
> Awesome discussion going on in this thread, using all the feedback so far 
> I've gone and hacked up some build scripts for RC3 on a couple different 
> Linux distros (Debian and Solus). First some banter and then, the scripts.
>
> 1) Scripts use Paul's cmake flags and attempt to be compliant with Bill's 
> statement on build permissions. You do still need to run the scripts as sudo 
> to install dependencies up top but I've reduced permissions down below where 
> the actual build takes place. 
>
> 2) Scripts are tested and working on stock Debian 9 (AWS t2.micro instance), 
> Raspbian Stretch (this is for you Evariste, I compiled it on my Pi 3+), and 
> Solus 3. (my Dell laptop). Bill will probably be able to find several 
> more superfluous packages in my script(s) beyond what Paul has mentioned but 
> those can always be cleaned up later on, I just want to get something up and 
> running to share with everyone ASAP. 
>
> 3) What is Solus? It's a new, cheerfully minimalist Linux distro that uses 
> neither .deb nor .rpm files, so there is no other way to get WSJT-X RC3 
> running on it other than to build from source. I had been using Mint for over 
> five years and while Stan is considering migrating to it, I've moved 
> completely off because of some very bad experiences upgrading to Mint 19 a 
> couple months ago (particularly the new "Timeshift" feature which bludgeoned 
> my hard drive almost beyond recognition). Hopefully Stan has better luck than 
> I did. Meanwhile I plan on contacting the Solus devs to see if they will 
> consider packaging WSJT-X in their own ".eopkg" format for when 2.0 is 
> officially released, and if not, I'll probably move over to the Arch Linux 
> distro family and write/maintain a WSJT-X 2.0 PKGBUILD for the AUR (Arch User 
> Repository) if someone else doesn't beat me to the punch.
>
> Tnx es 73 de Adam KB3ZUV
>
>
> #!/bin/bash
> #-wsjtx2rc3-debian-build-script.sh---
> #---RUN ME WITH SUDO-
> #
> #first the obligatory OS patches
> apt update && apt upgrade -y
> #add user to dialout group allowing rig CAT control on next login
> #(if you use VOX you don't actually need this)
> usermod -a -G dialout $SUDO_USER
> #install a whole bunch of dependencies to compile WSJT-X
> #g++ is in build-essential along with lots of other good stuff
> apt install -y build-essential gfortran-6 libfftw3-dev \
> libqt5x11extras5-dev libtool libudev-dev libusb-1.0.0-dev \
> python-pkgconfig python-pyqt5 qtmultimedia5-dev texinfo \
> libqt5serialport5 libqt5serialport5-dev cmake automake asciidoc \
> asciidoctor libxslt1-dev docbook-xsl xsltproc libxml2-utils git
> #create some directories for WSJT-X
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
> #grab and unzip the source code from Princeton
> wget --no-check-certificate \
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
> sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
> -C /home/$SUDO_USER/jtsource
> cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
> #set build options
> sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" \
> -D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-6" \
> -D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
> #build WSJT-X on Debian
> sudo -u $SUDO_USER cmake --build . --target install
> #-EOF---
>
>
> #!/bin/bash
> #-wsjtx2rc3-solus-build-script.sh---
> #--RUN ME WITH SUDO-
> #
> #first the obligatory OS patches
> eopkg -y up
> #add user to dialout group allowing rig CAT control on next login
> #(if you use VOX you don't actually need this)
> usermod -a -G dialout $SUDO_USER
> #install a whole bunch of dependencies to compile WSJT-X
> #g++ is in system.devel along with lots of other good stuff
> eopkg -y it -c system.devel && eopkg -y it git fftw-devel \
> qt5-multimedia-devel qt5-connectivity-devel qt5-serialport-devel \
> ruby-devel libusb-devel asciidoc
> #asciidoctor is not in Solus repo and has to be added as a Ruby gem
> gem install asciidoctor
> #create some directories for WSJT-X
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource 
> sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
> #grab and unzip the source code from Princeton
> wget --no-check-certificate \
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
> sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
> -C /home/$SUDO_USER/jtsource
> cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
> #set build options
> sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" \
> -D CMAKE_Fortran_COMPILER="/usr/bin/gfortran" \
> -D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
> #build WSJT-X on Solus
> sudo -u $SUDO_USER cmake --build . --target install
> #-EOF---
>
Sirs,

Unluckily on my openSUSE Tumbleweed 64bits the WSJTX  source compiling
attempt has failed repeatedly, also by using 

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

[Paul Bramscher]

Hi folks--

Thanks for the additional tips -- my earlier notes were from a rather hasty 
real-time effort.  I'll combine the additional commentary, clean up the notes, 
and try it again to validate.

I forget why I issued cmake as sudo.  Probably a perms issue at one point, most 
certainly my fault since I was also installing the additional packages ad hoc.  
Best to do that in a separate window or as a separate pre-build step.  I've got 
a better grasp on it at this point.  It would be easy enough to simply install 
the .deb, but it's gratifying (and a good learning exercise) to compile one's 
amateur radio apps from source also.

73, KD0KZE / Paul

> On October 21, 2018 at 3:03 AM Bill Somerville  wrote:
> 
> 
> On 21/10/2018 04:01, Paul Bramscher wrote:
> > These appeared to be necessary dependencies:
> > g++
> > gfortran-6
> > libfftw3-dev
> > libqt5x11extras5-dev
> > lib-qt5serialport
> > lib-qt5serialport-dev
> > libtool
> > libudev-dev
> > libusb-1.0.0-dev
> > python-pkgconfig
> > python-pyqt5
> > qtmultimedia5-dev
> > texinfo
> >
> > sudo cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" -D
> > CMAKE_Fortran_COMPILER="/usr/bin/gfortran-6" -D
> > CMAKE_INSTALL_PREFIX=~/.local .
> >
> > sudo cmake --build . --target install
> >
> > Possibly necessary also:
> >
> > python-pyqt5.qtmultimedia
> >
> Hi Paul,
> 
> you may find these comments helpful.
> 
> 1) there are no Python dependencies for WSJT-X,
> 2) there should be no need to install both a -dev and run tie version of 
> a package, installing the -dev package alone will also install the run 
> time components,
> 3) you can avoid having to install the large texinfo package by 
> configuring the WSJT-X build to skip the build of the manpages (-D 
> WSJT_SKIP_MANPAGES),
> 4) never run a CMake configuration with root privileges, also in your 
> case as your install prefix is in your home directory you so you do not 
> need root privileges for the CMake build command either,
> 5) CMake should discover the compilers it needs by itself,
> 6) you should create a build directory and run your CMake commands with 
> that as the current working directory, building in the source tree is 
> strongly discouraged. Simply select the source tree root in the CMake 
> configuration command by specifying it as the last parameter instead of 
> '.' as you have above.
> 
> 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

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

[Adam Schaible]

Good morning Linux WSJT-X fans,

Awesome discussion going on in this thread, using all the feedback so far I've 
gone and hacked up some build scripts for RC3 on a couple different Linux 
distros (Debian and Solus). First some banter and then, the scripts.

1) Scripts use Paul's cmake flags and attempt to be compliant with Bill's 
statement on build permissions. You do still need to run the scripts as sudo to 
install dependencies up top but I've reduced permissions down below where the 
actual build takes place. 

2) Scripts are tested and working on stock Debian 9 (AWS t2.micro instance), 
Raspbian Stretch (this is for you Evariste, I compiled it on my Pi 3+), and 
Solus 3. (my Dell laptop). Bill will probably be able to find several more 
superfluous packages in my script(s) beyond what Paul has mentioned but those 
can always be cleaned up later on, I just want to get something up and running 
to share with everyone ASAP. 

3) What is Solus? It's a new, cheerfully minimalist Linux distro that uses 
neither .deb nor .rpm files, so there is no other way to get WSJT-X RC3 running 
on it other than to build from source. I had been using Mint for over five 
years and while Stan is considering migrating to it, I've moved completely off 
because of some very bad experiences upgrading to Mint 19 a couple months ago 
(particularly the new "Timeshift" feature which bludgeoned my hard drive almost 
beyond recognition). Hopefully Stan has better luck than I did. Meanwhile I 
plan on contacting the Solus devs to see if they will consider packaging WSJT-X 
in their own ".eopkg" format for when 2.0 is officially released, and if not, 
I'll probably move over to the Arch Linux distro family and write/maintain a 
WSJT-X 2.0 PKGBUILD for the AUR (Arch User Repository) if someone else doesn't 
beat me to the punch.

Tnx es 73 de Adam KB3ZUV


#!/bin/bash
#-wsjtx2rc3-debian-build-script.sh---
#---RUN ME WITH SUDO-
#
#first the obligatory OS patches
apt update && apt upgrade -y
#add user to dialout group allowing rig CAT control on next login
#(if you use VOX you don't actually need this)
usermod -a -G dialout $SUDO_USER
#install a whole bunch of dependencies to compile WSJT-X
#g++ is in build-essential along with lots of other good stuff
apt install -y build-essential gfortran-6 libfftw3-dev \
libqt5x11extras5-dev libtool libudev-dev libusb-1.0.0-dev \
python-pkgconfig python-pyqt5 qtmultimedia5-dev texinfo \
libqt5serialport5 libqt5serialport5-dev cmake automake asciidoc \
asciidoctor libxslt1-dev docbook-xsl xsltproc libxml2-utils git
#create some directories for WSJT-X
sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource
sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
#grab and unzip the source code from Princeton
wget --no-check-certificate \
https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
-C /home/$SUDO_USER/jtsource
cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
#set build options
sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" \
-D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-6" \
-D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
#build WSJT-X on Debian
sudo -u $SUDO_USER cmake --build . --target install
#-EOF---


#!/bin/bash
#-wsjtx2rc3-solus-build-script.sh---
#--RUN ME WITH SUDO-
#
#first the obligatory OS patches
eopkg -y up
#add user to dialout group allowing rig CAT control on next login
#(if you use VOX you don't actually need this)
usermod -a -G dialout $SUDO_USER
#install a whole bunch of dependencies to compile WSJT-X
#g++ is in system.devel along with lots of other good stuff
eopkg -y it -c system.devel && eopkg -y it git fftw-devel \
qt5-multimedia-devel qt5-connectivity-devel qt5-serialport-devel \
ruby-devel libusb-devel asciidoc
#asciidoctor is not in Solus repo and has to be added as a Ruby gem
gem install asciidoctor
#create some directories for WSJT-X
sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource 
sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx
#grab and unzip the source code from Princeton
wget --no-check-certificate \
https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz
sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \
-C /home/$SUDO_USER/jtsource
cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3
#set build options
sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" \
-D CMAKE_Fortran_COMPILER="/usr/bin/gfortran" \
-D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx .
#build WSJT-X on Solus
sudo -u $SUDO_USER cmake --build . --target install
#-EOF---

-- 
  Adam Schaible
  kb3...@schibes.com

On Sun, Oct 21, 2018, at 4:03 AM, Bill Somerville wrote:
> On 21/10/2018 04:01, Paul Bramscher wrote:
> > These appeared to be necessary dependencies:
> > g++
> > gfortran-6
> > libfftw3-dev
> > libqt5x11extras5-dev
> > lib-qt5serialport
> > lib-qt5serialport-dev
> > libtool
> > libudev-dev
> > libusb-1.0.0-dev
> > pyth

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

[Bill Somerville]

On 21/10/2018 04:01, Paul Bramscher wrote:

These appeared to be necessary dependencies:
g++
gfortran-6
libfftw3-dev
libqt5x11extras5-dev
lib-qt5serialport
lib-qt5serialport-dev
libtool
libudev-dev
libusb-1.0.0-dev
python-pkgconfig
python-pyqt5
qtmultimedia5-dev
texinfo

sudo cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" -D
CMAKE_Fortran_COMPILER="/usr/bin/gfortran-6" -D
CMAKE_INSTALL_PREFIX=~/.local .

sudo cmake --build . --target install

Possibly necessary also:

python-pyqt5.qtmultimedia


Hi Paul,

you may find these comments helpful.

1) there are no Python dependencies for WSJT-X,
2) there should be no need to install both a -dev and run tie version of 
a package, installing the -dev package alone will also install the run 
time components,
3) you can avoid having to install the large texinfo package by 
configuring the WSJT-X build to skip the build of the manpages (-D 
WSJT_SKIP_MANPAGES),
4) never run a CMake configuration with root privileges, also in your 
case as your install prefix is in your home directory you so you do not 
need root privileges for the CMake build command either,

5) CMake should discover the compilers it needs by itself,
6) you should create a build directory and run your CMake commands with 
that as the current working directory, building in the source tree is 
strongly discouraged. Simply select the source tree root in the CMake 
configuration command by specifying it as the last parameter instead of 
'.' as you have above.


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?

[Stan Gammons]

Long time Linux user here too. I'm running Kubuntu 18.04, but have 
considered switching to Linux Mint with the XFCE desktop. Being a long 
time Linux user, I tend to compile from source 99+ percent of the time.  
Old habits are hard to break :)   I haven't seen many of the problems 
compiling or running RC3 that other users are reporting.  For me it 
compiles fine, seems to receive fine and transmit fine. There does seem 
to be a hiccup that occurs at times when one double clicks on a call 
calling CQ.  Seems like they don't hear you at first and the auto 
sequence calls again. At times during a QSO, something similar happens 
at times when your QSO partner expects a signal report. I've seen it 
infrequent enough that I figure it's just band conditions.


At any rate, I'm looking forward to the test next week.

As a side note, would someone tell me where in the source code is the 
code located that displays the popup help when you mouse over an 
option?  Is that done with the JAVA code?



73

Stan
KM4HQE


On 10/20/18 10:01 PM, Paul Bramscher wrote:

Hi Adam--

I compiled it yesterday, but these notes are not guaranteed to be 100%.
This was done to a Debian 9 machine, fully patched, which had previously
used the JTSDK to build WSJT-X 1.9.1.  I took the latest source snapshot
for 2.0.0 RC3.  These are new dependencies and musings/considerations
(written for myself):

Create a jtsource directory and decompress the source there.
Decide on a destination executable directory and create that also.
For example .local and/or a version-specific directory name.  And that
should be indicated in the later cmake command (example below is only
.local):

These appeared to be necessary dependencies:
g++
gfortran-6
libfftw3-dev
libqt5x11extras5-dev
lib-qt5serialport
lib-qt5serialport-dev
libtool
libudev-dev
libusb-1.0.0-dev
python-pkgconfig
python-pyqt5
qtmultimedia5-dev
texinfo

sudo cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" -D
CMAKE_Fortran_COMPILER="/usr/bin/gfortran-6" -D
CMAKE_INSTALL_PREFIX=~/.local .

sudo cmake --build . --target install

Possibly necessary also:

python-pyqt5.qtmultimedia

I'm not sure this helps anyone, but it compiled on Debian for me -- and
something similar should work for most Debian-based distros.

73, KD0KZE / Paul


On 10/20/2018 1:56 PM, Adam Schaible wrote:

Paul -

Totally new to this list (in fact this is my first post here) but I've
also been compiling the 2.0.0 RC releases from source for Linux, not by
choice but by necessity (my current desktop distro of choice uses
neither .deb nor .rpm installers) and have run into the usual dependency
wackiness at build time. I decided early on to ignore JTSDK as the new
version doesn't support Linux and the older version is several years old.

I've powered through the error messages line by line, installing all the
needed dependencies one by one and WSJT-X is now usable but a bit buggy,
was planning a side-by-side test with the latest RC3 .rpm on my Fedora
box some time in the next couple days. Not sure how much the rest of
this list (as majority non-Linux users) is interested in our adventures,
but I'd be interested in sharing build notes with you either here or
outside the list if you're game.

73 de Adam KB3ZUV



On Sat, Oct 20, 2018, at 11:13 AM, Paul Bramscher wrote:

Great to hear about the upcoming 2.0.0 major release of WSJT-X.  I've
been compiling my own versions of WSJT-X with the JTSDK for the past
few years (Debian Linux, AMD64).  Will that project on SourceForge be
updated when the new general release becomes available?  The JTSDK
is/was a really handy tool for keeping things (incl. hamlib) up to date.


I was able to compile 2.0.0 RC3 manually from source yesterday, but it
was a bit tedious (and some guesswork) to chase down all necessary
dependencies.


Thanks,

73, KD0KZE / Paul

  
_

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] WSJT-X & JTSDK future?

[Paul Bramscher]

Hi Adam--

I compiled it yesterday, but these notes are not guaranteed to be 100%.
This was done to a Debian 9 machine, fully patched, which had previously
used the JTSDK to build WSJT-X 1.9.1.  I took the latest source snapshot
for 2.0.0 RC3.  These are new dependencies and musings/considerations
(written for myself):

Create a jtsource directory and decompress the source there.
Decide on a destination executable directory and create that also.
For example .local and/or a version-specific directory name.  And that
should be indicated in the later cmake command (example below is only
.local):

These appeared to be necessary dependencies:
g++
gfortran-6
libfftw3-dev
libqt5x11extras5-dev
lib-qt5serialport
lib-qt5serialport-dev
libtool
libudev-dev
libusb-1.0.0-dev
python-pkgconfig
python-pyqt5
qtmultimedia5-dev
texinfo

sudo cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++" -D
CMAKE_Fortran_COMPILER="/usr/bin/gfortran-6" -D
CMAKE_INSTALL_PREFIX=~/.local .

sudo cmake --build . --target install

Possibly necessary also:

python-pyqt5.qtmultimedia

I'm not sure this helps anyone, but it compiled on Debian for me -- and
something similar should work for most Debian-based distros.

73, KD0KZE / Paul


On 10/20/2018 1:56 PM, Adam Schaible wrote:
> Paul - 
> 
> Totally new to this list (in fact this is my first post here) but I've
> also been compiling the 2.0.0 RC releases from source for Linux, not by
> choice but by necessity (my current desktop distro of choice uses
> neither .deb nor .rpm installers) and have run into the usual dependency
> wackiness at build time. I decided early on to ignore JTSDK as the new
> version doesn't support Linux and the older version is several years old.
> 
> I've powered through the error messages line by line, installing all the
> needed dependencies one by one and WSJT-X is now usable but a bit buggy,
> was planning a side-by-side test with the latest RC3 .rpm on my Fedora
> box some time in the next couple days. Not sure how much the rest of
> this list (as majority non-Linux users) is interested in our adventures,
> but I'd be interested in sharing build notes with you either here or
> outside the list if you're game.
> 
> 73 de Adam KB3ZUV
> 
> 
> 
> On Sat, Oct 20, 2018, at 11:13 AM, Paul Bramscher wrote:
>>
>> Great to hear about the upcoming 2.0.0 major release of WSJT-X.  I've
>> been compiling my own versions of WSJT-X with the JTSDK for the past
>> few years (Debian Linux, AMD64).  Will that project on SourceForge be
>> updated when the new general release becomes available?  The JTSDK
>> is/was a really handy tool for keeping things (incl. hamlib) up to date.
>>
>>
>> I was able to compile 2.0.0 RC3 manually from source yesterday, but it
>> was a bit tedious (and some guesswork) to chase down all necessary
>> dependencies. 
>>
>>
>> Thanks,
>>
>> 73, KD0KZE / Paul
>>
>>  
>> _
>> 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 & JTSDK future?

[Evariste Courjaud]

I gave it a try some months ago and JTSDK was completly out of sync with
current WSJT-X. Nice to see that it is now possible to compile an up to
date versio for linux. My favorite platform is Raspberry on Debian based
and I am very interested if you can share your dependencies and fixes.

73 de F5OEO

Le sam. 20 oct. 2018 à 21:14, Adam Schaible  a écrit :

> Paul -
>
> Totally new to this list (in fact this is my first post here) but I've
> also been compiling the 2.0.0 RC releases from source for Linux, not by
> choice but by necessity (my current desktop distro of choice uses neither
> .deb nor .rpm installers) and have run into the usual dependency wackiness
> at build time. I decided early on to ignore JTSDK as the new version
> doesn't support Linux and the older version is several years old.
>
> I've powered through the error messages line by line, installing all the
> needed dependencies one by one and WSJT-X is now usable but a bit buggy,
> was planning a side-by-side test with the latest RC3 .rpm on my Fedora box
> some time in the next couple days. Not sure how much the rest of this list
> (as majority non-Linux users) is interested in our adventures, but I'd be
> interested in sharing build notes with you either here or outside the list
> if you're game.
>
> 73 de Adam KB3ZUV
>
>
>
> On Sat, Oct 20, 2018, at 11:13 AM, Paul Bramscher wrote:
>
> Great to hear about the upcoming 2.0.0 major release of WSJT-X.  I've been
> compiling my own versions of WSJT-X with the JTSDK for the past few years
> (Debian Linux, AMD64).  Will that project on SourceForge be updated when
> the new general release becomes available?  The JTSDK is/was a really handy
> tool for keeping things (incl. hamlib) up to date.
>
>
> I was able to compile 2.0.0 RC3 manually from source yesterday, but it was
> a bit tedious (and some guesswork) to chase down all necessary
> dependencies.
>
>
> Thanks,
>
> 73, KD0KZE / Paul
>
> *___*
> 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 & JTSDK future?

[Adam Schaible]

Paul - 

Totally new to this list (in fact this is my first post here) but I've
also been compiling the 2.0.0 RC releases from source for Linux, not by
choice but by necessity (my current desktop distro of choice uses
neither .deb nor .rpm installers) and have run into the usual
dependency wackiness at build time. I decided early on to ignore JTSDK
as the new version doesn't support Linux and the older version is
several years old.
 I've powered through the error messages line by line, installing all
 the needed dependencies one by one and WSJT-X is now usable but a bit
 buggy, was planning a side-by-side test with the latest RC3 .rpm on my
 Fedora box some time in the next couple days. Not sure how much the
 rest of this list (as majority non-Linux users) is interested in our
 adventures, but I'd be interested in sharing build notes with you
 either here or outside the list if you're game.
 73 de Adam KB3ZUV



On Sat, Oct 20, 2018, at 11:13 AM, Paul Bramscher wrote:
> Great to hear about the upcoming 2.0.0 major release of WSJT-X.
> I've been compiling my own versions of WSJT-X with the JTSDK for the
> past few years (Debian Linux, AMD64).  Will that project on
> SourceForge be updated when the new general release becomes
> available?  The JTSDK is/was a really handy tool for keeping things
> (incl. hamlib) up to date.> 


> I was able to compile 2.0.0 RC3 manually from source yesterday, but it
> was a bit tedious (and some guesswork) to chase down all necessary
> dependencies.> 


> Thanks,


> 73, KD0KZE / Paul


>  
> _
> 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 & JTSDK future?

[Paul Bramscher]

Great to hear about the upcoming 2.0.0 major release of WSJT-X.  I've been 
compiling my own versions of WSJT-X with the JTSDK for the past few years 
(Debian Linux, AMD64).  Will that project on SourceForge be updated when the 
new general release becomes available?  The JTSDK is/was a really handy tool 
for keeping things (incl. hamlib) up to date.


I was able to compile 2.0.0 RC3 manually from source yesterday, but it was a 
bit tedious (and some guesswork) to chase down all necessary dependencies. 


Thanks,

73, KD0KZE / Paul
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel