Re: [wsjt-devel] Wish-Dream: Button to toggle between Normal- & Hound-Mode

[Grant VK5GR]

Folks,

I am going to speak heresy here - but I wonder if there are any bits left in
the protocols to have a flag bit that simply broadcasts what mode the
station is in that you are trying to work? The bit is set to "1" for Fox
mode or "0" for anything else. Then people's software can just pick up what
mode is required and automatically switch modes.

Too many times I see Fox QSOs fail because too many people are not in fox
mode and are QRMing the fox stations receive sub-channels. I lost 4 QSO
attempts to 7Q7RU on 17m last night because there were people calling them
on their TX sub-channel not in fox mode. 7Q7RU would hear me calling up n
the hounds section - give me a report of -8 or so and then when I QSYed they
couldn't hear me anymore because of the QRM of stations not clearing out
when they should.

Alternatively have a no QSY mode in Fox Mode so that the hounds answer in
place rather than QSY down. The theory being if they were heard once then
there perhaps is a higher probability of being heard the second time to take
the reply if the hound station doesn't do the QSY.

Just observations of what is going on, on the air.

Regards,
Grant VK5GR


-Original Message-
From: Dieter Dippel [mailto:dieter.dip...@online.de] 
Sent: Monday, 16 November 2020 8:42 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Wish-Dream: Button to toggle between Normal- &
Hound-Mode

Dear WSJT-X Developer-Team,
my main interest for 40 years plus is "DXing" in all modes. For FT8/FT4 
I'm using WSJT-X now for some years.

Since FOX-/Hound-Mode became more and more favourite, one of my wishes 
(dreams) is a Button on the Screen to toggle (switch) between 
Normal-Mode and Hound-Mode.

Maybe I don't know how improve it, but for me it's always very complex 
(cumbersome) to move to
1st => File
2nd => Settings
3rd => Advanced
4th => Special Operating Activity
5th => Hound-Mode
... well, and the same procedure to switch back to "Normal-Mode" ...

The Button could be placed on the same position as the ***RED*** White 
*** Hound *** is located as soon as you are starting the Hound-Mode.

If this doesen't make sense in your opinion, it would be great if you 
can discuss about a ***Keyboard-Shortcut***to make it much more 
comfortable ;-))

73 es good luck to all of you de Dieter, DF4RD







___
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] Wish-Dream: Button to toggle between Normal- & Hound-Mode

[Jim Shorney]

Hit F2 and you skip the first two. It Advanced was the last tab you were in you 
also skip the third. Quick and easy.

73

-Jim
NU0C


On Mon, 16 Nov 2020 11:12:04 +0100
Dieter Dippel  wrote:

> Maybe I don't know how improve it, but for me it's always very complex 
> (cumbersome) to move to
> 1st => File
> 2nd => Settings
> 3rd => Advanced
> 4th => Special Operating Activity
> 5th => Hound-Mode
> ... well, and the same procedure to switch back to "Normal-Mode" ...


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

Re: [wsjt-devel] WSJT-X 2.3.0-rc2

[Richard Shaw]

On Mon, Nov 16, 2020 at 3:07 PM Bill Somerville 
wrote:

> On 16/11/2020 12:43, Richard Shaw wrote:
>
> On Mon, Nov 16, 2020 at 6:36 AM Bill Somerville 
> wrote:
>
>> On 16/11/2020 12:27, Richard Shaw wrote:
>>
>> On Mon, Nov 16, 2020 at 5:44 AM Bill Somerville 
>> wrote:
>>
>>>
>>> Note that the 32-bit RPM package we provide is built on Fedora 30
>>> without issues.
>>>
>>
>> Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near future
>> now that Fedora 33 is released :)
>>
>> Thanks,
>> Richard
>> KF5OIM
>>
>> Hi Richard,
>>
>> on 32-bit machines?
>>
>
> While Fedora doesn't build official 32bit installations anymore, I don't
> believe there's been anything removed from the distro that would prevent
> end users from producing 32bit binaries (32bit libraries are still
> produced).
>
> I'm not sure how you're producing the RPMs but the recommended method of
> using mock still has chroots for i386 in current Rawhide/f33.
>
> Thanks,
> Richard
>
> Hi Richard,
>
> that would be alright for fully statically linked applications, but
> there's not much point for applications that are going to be run on Fedora
> 30 32-bit systems using dynamic linking to other packages. It's easier to
> keep a Fedora 30 32-bit system going to build on, at least until some
> package requirement forces us to keep an alternate version of the sources,
> at that point we would probably drop support. We already advertise our
> Intel Linux WSJT-X 32-bit support as deprecated.
>

Yes, I think 32bit operating systems days are numbered. I know a lot of
people don't know or even think about this, but from a packager/contributor
point of view, the Fedora project is several times smaller than the Debian
(and derivatives) ecosphere. Sometimes hard (and unpopular) decisions have
to be made.  I probably maintain over half the ham radio stack in Fedora by
myself and around 150 packages total between Fedora and RPM Fusion.

Thanks,
Richard
KF5OIM
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc2

[Roger Newey (K7GXB)]

Hi Bill,

 

It’s not a problem for me, I simply re-start WSJT-X after Tuning. I sent the 
report in case it could help.

Your checklist, All Confirmed.

*   Make sure "Settings->General->Allow Tx frequency changes while 
transmitting" is unchecked.
*   Check the "Settings->Radio->PTT Method->VOX" option,
*   Reduce the DELAY control on the SignaLink USB to minimum.

Further testing shows, at the end of Tune:
  ‘Enable Tx’ is cleared
  ‘Monitor’ is re-enabled
  There is no Rx sound signal shown on the PC’s|Sound|Recording tab.
Closing WSJT-X & Restarting fixes the issue.
73
Roger (K7GXB)

 

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, November 16, 2020 10:01
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 2.3.0-rc2

 

Hi Roger,

 

when using a SignaLink USB with rigs like the FT-817ND, that don't accept CAT 
QSY commands while transmitting, you must use particular settings:

*   Make sure "Settings->General->Allow Tx frequency changes while 
transmitting" is unchecked.
*   Check the "Settings->Radio->PTT Method->VOX" option, unless you have 
internally disabled the VOX PTT on your SignaLink USB in which case you would 
use "Settings->Radio->PTT Method" CAT.
*   Reduce the DELAY control on the SignaLink USB to minimum.

73
Bill
G4WJS.

 

On 16/11/2020 16:37, Roger Newey (K7GXB) wrote:

Hi Bill,

Possibly related to K0VM report: RC2, Mode=WSPR, Win10, FT-817ND via SignaLink:

 

Tune when ‘Enable Tx’ is active, resets the ‘Enable Tx’;

after the Tune ends, when GUI is used to re-enable ‘Enable Tx’:

MsgBox: “Rig failure: Hamlib error: Command rejected by the rig while 
exchanging VFOs”

 

NB: I can run a Debug version if it helps.

 

73

Roger (K7GXB)

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, November 15, 2020 13:04
To: wsjt-devel@lists.sourceforge.net  
Subject: Re: [wsjt-devel] 2.3.0-rc2

 

On 15/11/2020 16:47, Al wrote:

RC2 still contains the Enable TX defect...
If Tune is activated while 'Enable TX' is active, then the next TX cycle keys 
the radio but WSJT-x (ft8) produces no audio.
Al, K0VM




Hi Al,
thanks for the issue report, we are still trying to track down the cause of 
that issue.
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 2.3.0-rc2

[Bill Somerville]

On 16/11/2020 12:43, Richard Shaw wrote:
On Mon, Nov 16, 2020 at 6:36 AM Bill Somerville > wrote:


On 16/11/2020 12:27, Richard Shaw wrote:

On Mon, Nov 16, 2020 at 5:44 AM Bill Somerville
mailto:g4...@classdesign.com>> wrote:


Note that the 32-bit RPM package we provide is built on
Fedora 30
without issues.


Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near
future now that Fedora 33 is released :)

Thanks,
Richard
KF5OIM


Hi Richard,

on 32-bit machines?


While Fedora doesn't build official 32bit installations anymore, I 
don't believe there's been anything removed from the distro that would 
prevent end users from producing 32bit binaries (32bit libraries are 
still produced).


I'm not sure how you're producing the RPMs but the recommended method 
of using mock still has chroots for i386 in current Rawhide/f33.


Thanks,
Richard


Hi Richard,

that would be alright for fully statically linked applications, but 
there's not much point for applications that are going to be run on 
Fedora 30 32-bit systems using dynamic linking to other packages. It's 
easier to keep a Fedora 30 32-bit system going to build on, at least 
until some package requirement forces us to keep an alternate version of 
the sources, at that point we would probably drop support. We already 
advertise our Intel Linux WSJT-X 32-bit support as deprecated.


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 2.3.0-rc2

[Richard Shaw]

On Mon, Nov 16, 2020 at 8:14 AM Claude Frantz 
wrote:

> On 11/16/20 2:24 PM, Richard Shaw wrote:
>
> Hi Richard,
>
> > I know re-installation can be a pain, but I wonder how many people
> running
> > a 32bit distro in 2020 are doing it on 64bit hardware... Likely most?
> No doubt, it's a pain, especially when we are not running a vanilla
> installation.
>
> At first, on this machine here, it was not recommanded to run the 64 bit
> mode, because of the many issues of the 64 bit OS. Therefore, I have
> installed the the 32 bit mode software and I have upgraded nearly on
> every release change. Then came GNOME 3 and I have switched to xfce
> because I have a computer and not a big circus game console. Now, the 32
> bit software is not more available on Fedora.
>
> If a reinstallation is necessary, I think I will prefer the 64 bit
> Debian, although Debian is still available for the 32 bit architecture.
> The short lifetime of a Fedora release is a problem for me. With Debian,
> the problem is different, because many packages are really outdated. I
> confess, that a reinstallation is not a very exciting job for me.
>

Well the two often go together don't they? Long support but outdated
software. Short support but the latest software.

An alternative may be CentOS 8. I try to keep most amateur radio packages
building on it either officially (if there's an EPEL branch) or
unofficially in my COPR and can include more by request as long as the
build dependencies exist, which they seem to be so far.

Thanks,
Richard
KF5OIM
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Italian translation

[Marco Calistri]

Il 15/11/20 15:21, Loyd via wsjt-devel ha scritto:
> Hello,
>
> Italian translation is very bad.
>
> WSJTX set his self automatic in Italian, can I set it in English? I use
> them on Raspberry.
>
> Thanks
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Hello I'm the translator for Italian; please be so kind to send me the 
wrong/bad parts of italian text so I will provide a new translation file 
version.


Thanks!

--
73 de Marco, PY1ZRJ (former IK5BCU)


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

Re: [wsjt-devel] [FT8-Digital-Mode] WSJT-X 2.3. RC2 on MacOS #wsjt-x

[Philippe Nicolas]

Hello Joe

My problem was on macOS not on Windows but with your response, you show me the 
way, and for that I thank you a lot !
Indeed I could TX but get nothing from the air despite I show signals on the 
rig.

I search in the system audio parameters and eventually discover in
“Security & Privacy” -> “Microphone” that WSJT-X was disable.
So WSJT-X do not have the right to use microphone, neither “USB Audio CODEC”.
I did not touch this parameter after install, so I don’t know why it is 
disable...

It take me some time to discover this issue because I didn’t have any problem 
at all with macOS and WSJT-X…

Thanks

Best regards

73
Philippe
F4IQP



> On 16 Nov 2020, at 19:42, Joe Hobart  wrote:
> 
> Hello Philippe,
> 
> It appears your FT8 program is not receiving audio.
> 
> Check your sound card settings.  Windows will reset the sound card or sound
> modem to default and/or change your level settings during updates.
> 
> If that does not work, completely uninstall ALL versions of WSJT-X and 
> reinstall
> the new version.  Do this from Windows Control Panel, Programs: Uninstall a
> program.  You should only have one version of WSJT-X installed on your 
> computer.
> 
> 73,
> Joe, W7LUX
> Flagstaff, Arizona
> 
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
> 



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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[John Nelson via wsjt-devel]

Hi Bill,

> the symbol namespace would include 'v2s' for a static link rather than ‘v2’

Agreed.  Which is why I am puzzled that, given all the libboost*.dylib 
libraries, that the linker cannot find a dynamic linked symbol in a dylib.

> Once I have a few more pressing issues resolved I will return to my Mac 
> upgrade.

Thank you…

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[Bill Somerville]

On 16/11/2020 18:57, John Nelson via wsjt-devel wrote:

Hi Bill,

Understood.   But then I will await your further investigations on the linking 
problem which I initially sent to you.

I would prefer not to have to modify files.
---
It has found what it seems to need.  The problem about linking remains:

Undefined symbols for architecture x86_64:
  "boost::log::v2_mt_posix::attributes::timer::timer()", referenced from:
  Logger::(anonymous 
namespace)::CommonInitialization::CommonInitialization() in 
libwsjt_cxx.a(Logger.cpp.o)
—

vt_mt_posix is part of a dynamic link library so it is a mystery why the 
symbols mentioned are undefined.

Hope you can solve this one.

— John G4KLA


Hi John,

the symbol namespace would include 'v2s' for a static link rather than 
'v2'. This probably because some headers are included in compiles that 
do not specify BOOST_LOG_DYN_LINK=1. I probably need to review the 
defines and which modules of WSJT-X they are applied to. Once I have a 
few more pressing issues resolved I will return to my Mac upgrade.


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[John Nelson via wsjt-devel]

Hi Bill,

Understood.   But then I will await your further investigations on the linking 
problem which I initially sent to you.

I would prefer not to have to modify files.
---
It has found what it seems to need.  The problem about linking remains:

Undefined symbols for architecture x86_64: 
 "boost::log::v2_mt_posix::attributes::timer::timer()", referenced from:
 Logger::(anonymous 
namespace)::CommonInitialization::CommonInitialization() in 
libwsjt_cxx.a(Logger.cpp.o)
—

vt_mt_posix is part of a dynamic link library so it is a mystery why the 
symbols mentioned are undefined.

Hope you can solve this one.

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[Bill Somerville]

On 16/11/2020 18:32, John Nelson via wsjt-devel wrote:

Hi Bill,

I have found a solution.

1.   remade the boost libraries with:b2  link=static  runtime-link=static  
install

2.   made three changes to  CMakeLists.txt

79,80d78
< # JMN Added next line
< set (Boost_USE_STATIC_RUNTIME ON)
1067c1065
< #target_compile_definitions (wsjt_cxx PUBLIC BOOST_LOG_DYN_LINK)
---

target_compile_definitions (wsjt_cxx PUBLIC BOOST_LOG_DYN_LINK)

1315c1313
< #target_compile_definitions (wsjt_qt PUBLIC UDP_STATIC_DEFINE 
BOOST_LOG_DYN_LINK)
---

target_compile_definitions (wsjt_qt PUBLIC UDP_STATIC_DEFINE BOOST_LOG_DYN_LINK)

Now linking uses static libraries.  Not sure why BOOST_LOG_DYN_LINK is there - 
contradicts  USE_STATIC_RUNTIIME

Compiled version is running but will make further tests…

— John G4KLA


Hi John,

BOOST_LOG_DYN_LINK does not contradict USE_STATIC_RUNTIME, the latter is 
to do with linking system libraries on platforms and toolchains where 
they are available, which is not macOS.


The intent was to dynamically link the Boost libraries, you are somewhat 
on your own if you statically link the ones that allow it.


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[John Nelson via wsjt-devel]

Hi Bill,

I have found a solution.

1.   remade the boost libraries with:b2  link=static  runtime-link=static  
install

2.   made three changes to  CMakeLists.txt

79,80d78
< # JMN Added next line
< set (Boost_USE_STATIC_RUNTIME ON)
1067c1065
< #target_compile_definitions (wsjt_cxx PUBLIC BOOST_LOG_DYN_LINK)
---
> target_compile_definitions (wsjt_cxx PUBLIC BOOST_LOG_DYN_LINK)
1315c1313
< #target_compile_definitions (wsjt_qt PUBLIC UDP_STATIC_DEFINE 
BOOST_LOG_DYN_LINK)
---
> target_compile_definitions (wsjt_qt PUBLIC UDP_STATIC_DEFINE 
> BOOST_LOG_DYN_LINK)

Now linking uses static libraries.  Not sure why BOOST_LOG_DYN_LINK is there - 
contradicts  USE_STATIC_RUNTIIME

Compiled version is running but will make further tests…

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Failed to run WSJT-X v2.3.0 r2

[Bill Somerville]

On 16/11/2020 17:40, Jesús Gutiérrez Rodríguez wrote:
Good afternoon, I just downloaded the new version 2.3.0 r2 (previous 
installed 2.3.0 r1) and everything normal, the program was run from 
the download itself, without any apparent problem. I closed it, 
everything ok.

Windows 10 application 
When I rerun it, it doesn't open the program, I don't get any error, 
it just doesn't open.

Any suggestion?

Cordially,
Jesus, EA1YR, Oviedo


Hi Jesús,

does a thumbnail appear on the Windows Task Bar? If not then you need to 
look in the Windows Event Viewer and see is an application error has 
been recorded.


73
Bill
G4WJS.



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

[wsjt-devel] Failed to run WSJT-X v2.3.0 r2

[Jesús Gutiérrez Rodríguez]

Good afternoon, I just downloaded the new version 2.3.0 r2 (previous
installed 2.3.0 r1) and everything normal, the program was run from the
download itself, without any apparent problem. I closed it, everything ok.
Windows 10 application 
When I rerun it, it doesn't open the program, I don't get any error, it
just doesn't open.
Any suggestion?

Cordially,
Jesus, EA1YR, Oviedo
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc2

[Bill Somerville]

Hi Roger,

when using a SignaLink USB with rigs like the FT-817ND, that don't 
accept CAT QSY commands while transmitting, you must use particular 
settings:


 * Make sure "Settings->General->Allow Tx frequency changes while
   transmitting" is unchecked.
 * Check the "Settings->Radio->PTT Method->VOX" option, unless you have
   internally disabled the VOX PTT on your SignaLink USB in which case
   you would use "Settings->Radio->PTT Method" CAT.
 * Reduce the DELAY control on the SignaLink USB to minimum.

73
Bill
G4WJS.

On 16/11/2020 16:37, Roger Newey (K7GXB) wrote:


Hi Bill,

Possibly related to K0VM report: RC2, Mode=WSPR, Win10, FT-817ND via 
SignaLink:


Tune when ‘Enable Tx’ is active, resets the ‘Enable Tx’;

after the Tune ends, when GUI is used to re-enable ‘Enable Tx’:

MsgBox: “Rig failure: Hamlib error: Command rejected by the rig while 
exchanging VFOs”


NB: I can run a Debug version if it helps.

73

Roger (K7GXB)

*From:*Bill Somerville [mailto:g4...@classdesign.com]
*Sent:* Sunday, November 15, 2020 13:04
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] 2.3.0-rc2

On 15/11/2020 16:47, Al wrote:

RC2 still contains the Enable TX defect...
If Tune is activated while 'Enable TX' is active, then the next TX
cycle keys the radio but WSJT-x (ft8) produces no audio.
Al, K0VM

Hi Al,
thanks for the issue report, we are still trying to track down the 
cause of that issue.

73
Bill
G4WJS.



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

Re: [wsjt-devel] 2.3.0-rc2

[Roger Newey (K7GXB)]

Hi Bill,

Possibly related to K0VM report: RC2, Mode=WSPR, Win10, FT-817ND via SignaLink:

 

Tune when ‘Enable Tx’ is active, resets the ‘Enable Tx’;

after the Tune ends, when GUI is used to re-enable ‘Enable Tx’:

MsgBox: “Rig failure: Hamlib error: Command rejected by the rig while 
exchanging VFOs”

 

NB: I can run a Debug version if it helps.

 

73

Roger (K7GXB)

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, November 15, 2020 13:04
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 2.3.0-rc2

 

On 15/11/2020 16:47, Al wrote:

RC2 still contains the Enable TX defect...
If Tune is activated while 'Enable TX' is active, then the next TX cycle keys 
the radio but WSJT-x (ft8) produces no audio.
Al, K0VM



Hi Al,
thanks for the issue report, we are still trying to track down the cause of 
that issue.
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 2.3.0-rc2 compile error w/Debian 10 Linux

[Bill Somerville]

Hi Paul,

thanks for the update, glad you are up and running.

73
Bill
G4WJS.

On 16/11/2020 15:53, Paul Bramscher wrote:

Hi Bill,

Thanks, this solved it.  I saw a thread on boost+MacOS but didn't 
connect the dots to Linux. libboost-all-dev added about 554 MB to the 
dependency size, and it seemed the compile took longer than usual.  
But it could be that there was some residual disk activity from 
bringing down these new dependencies and the next compile may go more 
swiftly.


At any rate, I'll test out rc2 now.

73, KD0KZE / Paul

On 11/16/2020 8:42 AM Bill Somerville  wrote:


On 16/11/2020 14:27, Paul Bramscher wrote:
I'm getting a compile error with Debian 10 Linux (amd64), fully 
patched.  No trouble compiling 2.3.0-rc1.  But here is what fails on 
rc2:


My cmake/compile commands:
cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON 
-DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.3.0-rc2
cmake --build ~/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2 --target 
install -- -j


Failure points:
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Failed
-- Configuring incomplete, errors occurred!
See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeOutput.log". 

See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeError.log". 

make[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:73: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-configure] Error 1
make[2]: *** [CMakeFiles/Makefile2:361: 
CMakeFiles/wsjtx-install.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:432: CMakeFiles/install.dir/rule] 
Error 2

make: *** [Makefile:261: install] Error 2


Hi Paul,

there is a new dependency for WSJT-X v2.3.0 RC2.

sudo apt-get install libboost-all-dev

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 2.3.0-rc2 compile error w/Debian 10 Linux

[Paul Bramscher]

Hi Bill,

Thanks, this solved it.  I saw a thread on boost+MacOS but didn't connect the 
dots to Linux.  libboost-all-dev added about 554 MB to the dependency size, and 
it seemed the compile took longer than usual.  But it could be that there was 
some residual disk activity from bringing down these new dependencies and the 
next compile may go more swiftly.

At any rate, I'll test out rc2 now.

73, KD0KZE / Paul

> On 11/16/2020 8:42 AM Bill Somerville  wrote:
> 
> 
> On 16/11/2020 14:27, Paul Bramscher wrote:
> 
> > > I'm getting a compile error with Debian 10 Linux (amd64), 
> fully patched.  No trouble compiling 2.3.0-rc1.  But here is what fails on 
> rc2:
> > 
> > My cmake/compile commands:
> > cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON 
> > -DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.3.0-rc2
> > cmake --build ~/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2 
> > --target install -- -j
> > 
> > Failure points:
> > -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
> > -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
> > -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
> > -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
> > -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
> > -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
> > -- Performing Test COMPILER_HAS_DEPRECATED
> > -- Performing Test COMPILER_HAS_DEPRECATED - Failed
> > -- Configuring incomplete, errors occurred!
> > See also 
> > "/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeOutput.log".
> > See also 
> > "/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeError.log".
> > make[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:73: 
> > wsjtx-prefix/src/wsjtx-stamp/wsjtx-configure] Error 1
> > make[2]: *** [CMakeFiles/Makefile2:361: 
> > CMakeFiles/wsjtx-install.dir/all] Error 2
> > make[1]: *** [CMakeFiles/Makefile2:432: 
> > CMakeFiles/install.dir/rule] Error 2
> > make: *** [Makefile:261: install] Error 2
> > 
> > 
> > > 
> Hi Paul,
> 
> there is a new dependency for WSJT-X v2.3.0 RC2.
> 
> sudo apt-get install libboost-all-dev
> 
> 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 2.3.0-rc2 Main window not keeping it's size

[Saku]

Thanks Bill !

Returned back to 2.2.2 and noticed that it's minimum height is *even 
smaller* than I ever can set with 2.3.0-rc2 (and it is also keeping it).
With quick look the layout is same (when in FT8), no different bells and 
whistles. But 2.2.2 RX frequency/Band activity can be set nearly to half 
height of 2.3.0rc2's minimum height.
What is desirable when companion programs are the ones to look at decode 
results.



Bill Somerville kirjoitti 16.11.2020 klo 13.42:

Hi Saku,

I am looking into a fix for the height issue with the WSJT-X main 
window, it is due to some normally hidden widgets that have been added 
for FST4 mode. It should be resolved for the next release.


73
Bill
G4WJS.


--
Saku
OH1KH



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

Re: [wsjt-devel] WSJT-X 2.3.0-rc2 compile error w/Debian 10 Linux

[Bill Somerville]

On 16/11/2020 14:27, Paul Bramscher wrote:
I'm getting a compile error with Debian 10 Linux (amd64), fully 
patched.  No trouble compiling 2.3.0-rc1.  But here is what fails on rc2:

My cmake/compile commands:
cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON 
-DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.3.0-rc2
cmake --build ~/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2 --target 
install -- -j

Failure points:
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Failed
-- Configuring incomplete, errors occurred!
See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeOutput.log". 

See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeError.log". 

make[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:73: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-configure] Error 1
make[2]: *** [CMakeFiles/Makefile2:361: 
CMakeFiles/wsjtx-install.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:432: CMakeFiles/install.dir/rule] 
Error 2

make: *** [Makefile:261: install] Error 2


Hi Paul,

there is a new dependency for WSJT-X v2.3.0 RC2.

sudo apt-get install libboost-all-dev

73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[Bill Somerville]

On 16/11/2020 14:25, John Nelson via wsjt-devel wrote:

Hi Bill,


How did you build and install he Boost C++ libraries?

bootstrap.sh —prefix=/usr/local/  —libdir=/usr/local/lib  
—includedir=/usr/local/include

b2 install

If my configure is finding the static libraries  — what change in configuration 
must be made to force it to find the dynamic libraries?

— John G4KLA


Hi John,

you should not need to do anything. I wonder if specifying the libdir 
and includedir have caused this, they should not be necessary as the 
prefix should be all that is needed. When I get a working Mac again I 
will try what you have and see if I can replicate the issue.


73
Bill
G4WJS.

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

[wsjt-devel] WSJT-X 2.3.0-rc2 compile error w/Debian 10 Linux

[Paul Bramscher]

I'm getting a compile error with Debian 10 Linux (amd64), fully patched.  No 
trouble compiling 2.3.0-rc1.  But here is what fails on rc2:

My cmake/compile commands:
cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON 
-DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.3.0-rc2
cmake --build ~/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2 --target install -- 
-j

Failure points:
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Failed
-- Configuring incomplete, errors occurred!
See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeOutput.log".
See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeError.log".
make[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:73: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-configure] Error 1
make[2]: *** [CMakeFiles/Makefile2:361: CMakeFiles/wsjtx-install.dir/all] Error 
2
make[1]: *** [CMakeFiles/Makefile2:432: CMakeFiles/install.dir/rule] Error 2
make: *** [Makefile:261: install] Error 2


Snippets from CMakeError.log:

Performing C SOURCE FILE Test HAVE_MATH failed with the following output:
Change Dir: 
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_3bcda/fast"
make[4]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_3bcda.dir/build.make 
CMakeFiles/cmTC_3bcda.dir/build
make[5]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_3bcda.dir/src.c.o
/usr/bin/cc -DHAVE_MATH -o CMakeFiles/cmTC_3bcda.dir/src.c.o -c 
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_3bcda
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_3bcda.dir/link.txt 
--verbose=1
/usr/bin/cc -DHAVE_MATH CMakeFiles/cmTC_3bcda.dir/src.c.o -o cmTC_3bcda
/usr/bin/ld: CMakeFiles/cmTC_3bcda.dir/src.c.o: in function `main':
src.c:(.text+0x11): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status
make[5]: *** [CMakeFiles/cmTC_3bcda.dir/build.make:87: cmTC_3bcda] Error 1
make[5]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
make[4]: *** [Makefile:121: cmTC_3bcda/fast] Error 2
make[4]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'

Also:

Run Build Command:"/usr/bin/make" "cmTC_32eb3/fast"
make[4]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_32eb3.dir/build.make 
CMakeFiles/cmTC_32eb3.dir/build
make[5]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_32eb3.dir/HAMLIB_OLD_CACHING.c.o
/usr/bin/cc 
-I/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/hamlib-prefix/include
 -I/usr/include/libusb-1.0 -o CMakeFiles/cmTC_32eb3.dir/HAMLIB_OLD_CACHING.c.o 
-c /home/myuser/wsjt$
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CheckTypeSize/HAMLIB_OLD_CACHING.c:24:22:
 error: ‘CACHE_ALL’ undeclared here (not in a function); d$
#define SIZE (sizeof(CACHE_ALL))
^
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CheckTypeSize/HAMLIB_OLD_CACHING.c:26:12:
 note: in expansion of macro ‘SIZE’
('0' + ((SIZE / 1)%10)),
^~~~
make[5]: *** [CMakeFiles/cmTC_32eb3.dir/build.make:66: 
CMakeFiles/cmTC_32eb3.dir/HAMLIB_OLD_CACHING.c.o] Error 1
make[5]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
make[4]: *** [Makefile:121: cmTC_32eb3/fast] Error 2
make[4]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CheckTypeSize/HAMLIB_OLD_CACHING.c:


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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[John Nelson via wsjt-devel]

Hi Bill,

> How did you build and install he Boost C++ libraries?

bootstrap.sh —prefix=/usr/local/ —libdir=/usr/local/lib  
—includedir=/usr/local/include

b2 install

If my configure is finding the static libraries  — what change in configuration 
must be made to force it to find the dynamic libraries?

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] TX Freq lockout

[WB5JJJ]

Interesting.  I had only put in a Tx freq below 1000 to see if it was
allowed and it stuck.  But if I put in something under 200, as soon as I
click outside the Tx box, it goes back to whatever was in there above
1000.  Never did an Enable TX since it was not normal to do so.  Just tried
it and yes, it does shift up to something over 1000.  I see, the range
200-1000 displays a bit differently than under 200.

73's
George - WB5JJJ


4


On Mon, Nov 16, 2020 at 12:31 AM 5p1kzx Michael <5p1...@gmail.com> wrote:

> Hi George
>
> It's already there. If you are in Hound Mode and try to call FOX under
> 1000 wsjt-x will move the TX over 1000 by it self. If one get a rpt from
> the DXP wsjt-x will automatic jump to one of the DXP TX Slots and give your
> rpt for max 3 times if no RR73 is received wsjt-x will jump to somewhere
> between 600-1000 and keep sending rpt until it get RR73 or TX-Watch Dog
> will be triggered.
>
>  JTDX is working a bit different. With JTDX in Hound or HoundFC Mode one
> can still TX Even/Odd and whereever you want too. If only in Hound Mode
> (not HoundFC) JTDX will keep the same TX-slot during the QSO.
>
> One can water the horse but not force it to drink
>
> 73 de Michael 5p1kzx
>
>
> Den 16-11-2020 kl. 06:46 skrev WB5JJJ:
>
> This was meant for HOUND mode only.  If they are not using HOUND, then
> they should not be calling the DXP when he's operating in F/H mode.
> Defeats the purpose of F/H and only confuses the issue.
>
> 73's
> George - WB5JJJ
>
>
> 4
>
>
> On Sun, Nov 15, 2020 at 11:32 PM Reino Talarmo 
> wrote:
>
>> Hi George,
>>
>> There is a minor problem with your lockout proposal as that operator may
>> not have used HOUND mode at all!
>>
>> 73, Reino OH3mA
>>
>>
>>
>> *From:* WB5JJJ [mailto:wb5...@gmail.com]
>> *Sent:* 16. marraskuuta 2020 0:45
>> *To:* WSJT software development 
>> *Subject:* [wsjt-devel] TX Freq lockout
>>
>>
>>
>> With the 7Q7 being the first major DXP since early in the year, there are
>> a lot of "new" hams to F/H that don't read the information available.  They
>> are hoping to "cut in line" by TXing initially below 1000, and even on the
>> DXP calling frequency, with their R-xx report.  This causes tons of QRM and
>> bad feelings toward these LID's.
>>
>>
>>
>> Can we get a Tx lockout to the selector, so entering anything below 1000
>> (similar to selecting 100) on the HOUND side of things will, at least stop
>> this in its tracks and still allow the FOX to move the HOUND to 300-900 for
>> the R-xx report?  Also perhaps lockout Tx3 as well.  These items would sure
>> help educate those users very quickly on procedures for the mode.
>>
>>
>>
>> Just as a comical observation, the other day I watched a guy call and
>> call with his R-xx report on the DXP calling frequency.  I never saw him
>> above 1000 calling with his grid square.  Someone "became" the FOX (to me a
>> +05 vs a -17) and gave him a signal report to get rid of him.  Illegal,
>> without a doubt, but it worked.  I suspect that in the future, he will
>> continue the same method since it "worked" once.  Now he's looking for a
>> QSL -- good luck on that one.
>>
>>
>>
>> 73's
>>
>> George - WB5JJJ
>>
>>
>>
>>
>>
>> 4
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://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] Wish-Dream: Button to toggle between Normal- & Hound-Mode

[WB5JJJ]

I would like to see when in the Hound mode, clicking on the red box would
revert to normal FT8.  I use configurations to do the switching between
them and those are just 2 clicks away and no hunting for the proper place
to click.  Plus with the configurations for DXP, I have all the frequencies
they tend to use and they don't clutter up my main FT8/FT4 frequency
selectors.

73's
George - WB5JJJ


4


On Mon, Nov 16, 2020 at 4:16 AM Dieter Dippel 
wrote:

> Dear WSJT-X Developer-Team,
> my main interest for 40 years plus is "DXing" in all modes. For FT8/FT4
> I'm using WSJT-X now for some years.
>
> Since FOX-/Hound-Mode became more and more favourite, one of my wishes
> (dreams) is a Button on the Screen to toggle (switch) between
> Normal-Mode and Hound-Mode.
>
> Maybe I don't know how improve it, but for me it's always very complex
> (cumbersome) to move to
> 1st => File
> 2nd => Settings
> 3rd => Advanced
> 4th => Special Operating Activity
> 5th => Hound-Mode
> ... well, and the same procedure to switch back to "Normal-Mode" ...
>
> The Button could be placed on the same position as the ***RED*** White
> *** Hound *** is located as soon as you are starting the Hound-Mode.
>
> If this doesen't make sense in your opinion, it would be great if you
> can discuss about a ***Keyboard-Shortcut***to make it much more
> comfortable ;-))
>
> 73 es good luck to all of you de Dieter, DF4RD
>
>
>
>
>
>
>
> ___
> 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.3.0-rc2

[Claude Frantz]

On 11/16/20 2:24 PM, Richard Shaw wrote:

Hi Richard,


I know re-installation can be a pain, but I wonder how many people running
a 32bit distro in 2020 are doing it on 64bit hardware... Likely most?
No doubt, it's a pain, especially when we are not running a vanilla 
installation.


At first, on this machine here, it was not recommanded to run the 64 bit 
mode, because of the many issues of the 64 bit OS. Therefore, I have 
installed the the 32 bit mode software and I have upgraded nearly on 
every release change. Then came GNOME 3 and I have switched to xfce 
because I have a computer and not a big circus game console. Now, the 32 
bit software is not more available on Fedora.


If a reinstallation is necessary, I think I will prefer the 64 bit 
Debian, although Debian is still available for the 32 bit architecture. 
The short lifetime of a Fedora release is a problem for me. With Debian, 
the problem is different, because many packages are really outdated. I 
confess, that a reinstallation is not a very exciting job for me.


Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[Bill Somerville]

On 16/11/2020 13:16, John Nelson via wsjt-devel wrote:

Hi Bill,


all that should be needed after building and installing the Boost libraries is 
to include the path where they are installed in the CMAKE_PREFIX_PATH

CMake knows there the boost libraries are.  For instance:

-- Building wsjtx v2.3.0.0-rc2
-- Found Boost 1.70.0 at /usr/local/lib/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS log_setup;log
-- Found boost_headers 1.70.0 at /usr/local/lib/cmake/boost_headers-1.70.0
-- Found boost_log_setup 1.70.0 at /usr/local/lib/cmake/boost_log_setup-1.70.0
--   libboost_log_setup.a
-- Adding boost_log_setup dependencies: 
atomic;chrono;date_time;filesystem;log;regex;thread;headers
-- Found boost_atomic 1.70.0 at /usr/local/lib/cmake/boost_atomic-1.70.0
--   libboost_atomic.a
…
-- Found boost_thread 1.70.0 at /usr/local/lib/cmake/boost_thread-1.70.0
--   libboost_thread.a
-- Adding boost_thread dependencies: headers

It has found what it seems to need.  The problem about linking remains:

Undefined symbols for architecture x86_64:
   "boost::log::v2_mt_posix::attributes::timer::timer()", referenced from:
   Logger::(anonymous 
namespace)::CommonInitialization::CommonInitialization() in 
libwsjt_cxx.a(Logger.cpp.o)

and many more similarly.

/usr/local/lib has:

file libboost*.dylib
libboost_atomic.dylib:   Mach-O 64-bit dynamically linked shared 
library x86_64
libboost_chrono.dylib:   Mach-O 64-bit dynamically linked shared 
library x86_64
libboost_container.dylib:Mach-O 64-bit dynamically linked shared 
library x86_64

What symbols are not defined in the dylibs…?

— John G4KLA


Hi John,

the symbols that are not being resolved should be in the 
libboost_log.dylib and possibly the libboost_log_setup.dylib. Sorry I 
can't check on my system at the moment as I half way through a Big Sur 
update with not enough spare disk space :( Your configure seems to be 
finding static Boost libraries but the link is looking for dynamic 
library symbols in static object libraries. The link is supposed to be 
using dynamic Boost libraries.


How did you build and install he Boost C++ libraries?

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 2.3.0-rc2

[Richard Shaw]

On Mon, Nov 16, 2020 at 6:46 AM Claude Frantz 
wrote:

> On 11/16/20 1:32 PM, Bill Somerville wrote:
>
> >> Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near
> >> future now that Fedora 33 is released :)
>
> No, Fedora 30 is the latest release supporting the 32 bit architecture.
> That's the problem !
>

I know re-installation can be a pain, but I wonder how many people running
a 32bit distro in 2020 are doing it on 64bit hardware... Likely most?

Also, my COPR builds for RC2 have completed for EL 8 and Fedora:

https://copr.fedorainfracloud.org/coprs/hobbes1069/WSJT/

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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[John Nelson via wsjt-devel]

Hi Bill,

> all that should be needed after building and installing the Boost libraries 
> is to include the path where they are installed in the CMAKE_PREFIX_PATH 

CMake knows there the boost libraries are.  For instance:

-- Building wsjtx v2.3.0.0-rc2
-- Found Boost 1.70.0 at /usr/local/lib/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS log_setup;log
-- Found boost_headers 1.70.0 at /usr/local/lib/cmake/boost_headers-1.70.0
-- Found boost_log_setup 1.70.0 at /usr/local/lib/cmake/boost_log_setup-1.70.0
--   libboost_log_setup.a
-- Adding boost_log_setup dependencies: 
atomic;chrono;date_time;filesystem;log;regex;thread;headers
-- Found boost_atomic 1.70.0 at /usr/local/lib/cmake/boost_atomic-1.70.0
--   libboost_atomic.a
…
-- Found boost_thread 1.70.0 at /usr/local/lib/cmake/boost_thread-1.70.0
--   libboost_thread.a
-- Adding boost_thread dependencies: headers

It has found what it seems to need.  The problem about linking remains:

Undefined symbols for architecture x86_64:
  "boost::log::v2_mt_posix::attributes::timer::timer()", referenced from:
  Logger::(anonymous 
namespace)::CommonInitialization::CommonInitialization() in 
libwsjt_cxx.a(Logger.cpp.o)

and many more similarly.

/usr/local/lib has:

file libboost*.dylib
libboost_atomic.dylib:   Mach-O 64-bit dynamically linked shared 
library x86_64
libboost_chrono.dylib:   Mach-O 64-bit dynamically linked shared 
library x86_64
libboost_container.dylib:Mach-O 64-bit dynamically linked shared 
library x86_64

What symbols are not defined in the dylibs…?

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.3.0-rc2

[Richard Shaw]

On Mon, Nov 16, 2020 at 6:36 AM Bill Somerville 
wrote:

> On 16/11/2020 12:27, Richard Shaw wrote:
>
> On Mon, Nov 16, 2020 at 5:44 AM Bill Somerville 
> wrote:
>
>>
>> Note that the 32-bit RPM package we provide is built on Fedora 30
>> without issues.
>>
>
> Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near future
> now that Fedora 33 is released :)
>
> Thanks,
> Richard
> KF5OIM
>
> Hi Richard,
>
> on 32-bit machines?
>

While Fedora doesn't build official 32bit installations anymore, I don't
believe there's been anything removed from the distro that would prevent
end users from producing 32bit binaries (32bit libraries are still
produced).

I'm not sure how you're producing the RPMs but the recommended method of
using mock still has chroots for i386 in current Rawhide/f33.

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

Re: [wsjt-devel] WSJT-X 2.3.0-rc2

[Claude Frantz]

On 11/16/20 1:32 PM, Bill Somerville wrote:

Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near 
future now that Fedora 33 is released :)


No, Fedora 30 is the latest release supporting the 32 bit architecture. 
That's the problem !


Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] WSJT-X 2.3.0-rc2

[Bill Somerville]

On 16/11/2020 12:27, Richard Shaw wrote:
On Mon, Nov 16, 2020 at 5:44 AM Bill Somerville > wrote:



Note that the 32-bit RPM package we provide is built on Fedora 30
without issues.


Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near 
future now that Fedora 33 is released :)


Thanks,
Richard
KF5OIM


Hi Richard,

on 32-bit machines?

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 2.3.0-rc2

[Richard Shaw]

On Mon, Nov 16, 2020 at 5:44 AM Bill Somerville 
wrote:

>
> Note that the 32-bit RPM package we provide is built on Fedora 30
> without issues.
>

Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near future now
that Fedora 33 is released :)

Thanks,
Richard
KF5OIM
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.3.0-rc2 Main window not keeping it's size

[Bill Somerville]

On 16/11/2020 11:12, Saku wrote:

Hi!

Fedora 32 Linux, LXDE desktop.

Compiled WSJT-X 2.3.0-rc2 from source, no problems.
Multicast UDP didn't work any more as expected. Fortunately it can be 
changed from Reporting/Outgoing interface. So that is OK, too.



But the main window height does not keep it's size. I have sized it to 
minimum (horizontal and vertical) and then it fits to my monitor 
leaving proper room for other open applications.
But when I close wsjtx and start it again on next time it is always 
bigger in vertical direction and must be minimized again. Quite 
annoying feature.


It seems that the extra size is coming from "Rx frequency" and "Band 
activity" views that are about 1/4 higher that what they were set at 
last usage time.
This did not happen with 2.2.2 (and earlier versions). I did not play 
with 2.3.0.rc1 so I can't say nothing about it.


Somewhere the height value does not get saved properly when program 
close.



Similar kind of effect has been there for ages with waterfall height. 
I once reported also that, but nobody paid any attention to it.
It is not tied to restarting the program, but if you minimize height 
of waterfall so small as it let's it to be when "controls" are 
unchecked and then check "controls" the height of waterfall window 
will grow the size of controls. But when you again uncheck "controls" 
waterfall vertical size does not go back to absolute minimal height. 
It leaves the height of "controls" higher than it was originally set.


There the the height of window is saved properly as it comes to right 
height at program start, but the value of of window height is not read 
and window redrawn after "controls" close or there is just one 
variable for height and it gets corrupted when "controls" open and 
need more space. There should be window height variable for "controls" 
visible and another for "controls" disabled.




Waterfall is a thing that can be lived with because of seldom need to 
touch the controls, but continued minimizing the main window height is 
very annoying.



--
Saku
OH1KH


Hi Saku,

I am looking into a fix for the height issue with the WSJT-X main 
window, it is due to some normally hidden widgets that have been added 
for FST4 mode. It should be resolved for the next release.


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 2.3.0-rc2

[Bill Somerville]

On 16/11/2020 08:32, Claude Frantz wrote:

On 11/15/20 4:01 PM, Joe Taylor wrote:

Hi Bill, Joe & all,

I'm on a 32 bit Fedora 30 here and I have tried to build using the git 
repo, as usual.


There is a problem, which is probably not located in WSJT-X itself.

[ 87%] Built target debian
[ 87%] Generating man/man1/wsjtx.1.gz
a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param 
man.endnotes.are.numbered 0 --stringparam callout.graphics 0 
--stringparam navig.graphics 0 --stringparam admon.textlabel 1 
--stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/home/claude/ham/JoeTaylor/wsjtx/build/manpages/man/man1/wsjtx.1.xml" 
returned non-zero exit status 5


make[2]: *** [manpages/CMakeFiles/manpages.dir/build.make:134: 
manpages/man/man1/wsjtx.1.gz] Error 1
make[2]: Target 'manpages/CMakeFiles/manpages.dir/build' not remade 
because of errors.
make[1]: *** [CMakeFiles/Makefile2:1974: 
manpages/CMakeFiles/manpages.dir/all] Error 2

Scanning dependencies of target fmtave

###

The error 5 is "Error in the stylesheet". Here, 
/etc/asciidoc/docbook-xsl/manpage.xsl is part of the package 
asciidoc-8.6.10-0.9.20180605git986f99d.fc30.noarch


It's interesting to note, that when I rerun "make", the error 
concerning "wsjtx.1.gz" has gone, but the same problem occurs now with 
"rigctld-wsjtx.1.gz".


Best wishes,
Claude (DJ0OT) 


Hi Claude,

unless you particularly want to build the manpages I would suggest 
adding "-D WSJT_SKIP_MANPAGES=ON" to your CMake configure command.


Note that the 32-bit RPM package we provide is built on Fedora 30 
without issues.


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[Bill Somerville]

On 16/11/2020 09:02, John Nelson via wsjt-devel wrote:

Hi Bill,

I have installed Boost 1.70 and updated CMake.   Could you send me the cmake 
build command that you use for Mac build?   Are there particular link options 
for boost?

Thanks…

— John G4KLA


Hi John,

all that should be needed after building and installing the Boost 
libraries is to include the path where they are installed in the 
CMAKE_PREFIX_PATH CMake configuration variable. From your other post I 
see you have installed the Boost libraries into /usr/local, I am not 
sure if CMake will automatically search there for Boost on macOS, I 
would have thought it would but there's no harm in adding it to 
CMAKE_PREFIX_PATH along with the Qt and Hamlib package locations.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Lookup of a DX call does not populate DX Grid

[Bill Somerville]

On 16/11/2020 07:45, Peter Sumner wrote:

Hello,
  I am not sure if this is a defect in behavior or done by design. 
When I use the 'Lookup' button from the main screen to get grid 
information from call3.txt for a new value in the "DX Call" field, 
should there be an existing "Dx Grid" value in the box from a previous 
QSO, the updated grid information from Call3.txt is not displayed (old 
information remains displayed).


If I clear the "Dx Grid" value, then using the Lookup button does then 
insert the correct information in "DX Grid".


Windows 10 x64 build 19042 (20H2) but has been like this on all 
previous Windows versions.


WSJT-X v2.3.0-rc1, tried using FT8, JT65 and MSK144

Regards,
Peter, vk5pj


Hi Peter,

that is the current intended behaviour. You can clear old DX Call and DX 
Grid information by hitting ESC and by checking the 
"Settings->Reporting->Clear DX call and grid after logging" option.


73
Bill
G4WJS.



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

[wsjt-devel] WSJT-X 2.3.0-rc2 Main window not keeping it's size

[Saku]

Hi!

Fedora 32 Linux, LXDE desktop.

Compiled WSJT-X 2.3.0-rc2 from source, no problems.
Multicast UDP didn't work any more as expected. Fortunately it can be 
changed from Reporting/Outgoing interface. So that is OK, too.



But the main window height does not keep it's size. I have sized it to 
minimum (horizontal and vertical) and then it fits to my monitor leaving 
proper room for other open applications.
But when I close wsjtx and start it again on next time it is always 
bigger in vertical direction and must be minimized again. Quite annoying 
feature.


It seems that the extra size is coming from "Rx frequency" and "Band 
activity" views that are about 1/4 higher that what they were set at 
last usage time.
This did not happen with 2.2.2 (and earlier versions). I did not play 
with 2.3.0.rc1 so I can't say nothing about it.


Somewhere the height value does not get saved properly when program close.


Similar kind of effect has been there for ages with waterfall height. I 
once reported also that, but nobody paid any attention to it.
It is not tied to restarting the program, but if you minimize height of 
waterfall so small as it let's it to be when "controls" are unchecked 
and then check "controls" the height of waterfall window will grow the 
size of controls. But when you again uncheck "controls" waterfall 
vertical size does not go back to absolute minimal height. It leaves the 
height of "controls" higher than it was originally set.


There the the height of window is saved properly as it comes to right 
height at program start, but the value of of window height is not read 
and window redrawn after "controls" close or there is just one variable 
for height and it gets corrupted when "controls" open and need more 
space. There should be window height variable for "controls" visible and 
another for "controls" disabled.




Waterfall is a thing that can be lived with because of seldom need to 
touch the controls, but continued minimizing the main window height is 
very annoying.



--
Saku
OH1KH



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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[John Nelson via wsjt-devel]

HI Bill,

Further to my previous email when I requested:

> Could you send me the cmake build command that you use for Mac build?   Are 
> there particular link options for boost?

The problem at link time is:

Undefined symbols for architecture x86_64:
  "boost::log::v2_mt_posix::attributes::timer::timer()", referenced from:
  Logger::(anonymous 
namespace)::CommonInitialization::CommonInitialization() in 
libwsjt_cxx.a(Logger.cpp.o)

/usr/local/lib has:

file libboost*.dylib
libboost_atomic.dylib:   Mach-O 64-bit dynamically linked shared 
library x86_64
libboost_chrono.dylib:   Mach-O 64-bit dynamically linked shared 
library x86_64
libboost_container.dylib:Mach-O 64-bit dynamically linked shared 
library x86_64
…. etc.

I must be missing something.

setenv BOOST_ALL_DYN_LINK 1   does not help.

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] [WSJTX] Unable to disable tx-1 and transmit tx 2 first in 2.3.0 rc2 #bug

[NS9I WI]

Same here.

73 Dwight NS9I

On 11/15/2020 3:10 PM, AB8WD-Willie via groups.io wrote:
I used to be able to double click on tx 1 under now and bypass it rc-2 
unable to do so.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#18359): https://WSJTX.groups.io/g/main/message/18359
Mute This Topic: https://groups.io/mt/78278751/361249
Mute #bug:https://WSJTX.groups.io/g/main/mutehashtag/bug
-=-=-
WSJT-X  Weak Signal Communication  . ©2001-2020 by Joe Taylor, K1JT.
References : https://physics.princeton.edu/pulsar/K1JT/refs.html
Unsubscribe: wsjtx+unsubscr...@groups.io
-=-=-
Group Owner: main+ow...@wsjtx.groups.io
Unsubscribe: https://WSJTX.groups.io/g/main/leave/5092158/270076858/xyzzy 
[n...@bayland.net]
-=-=-=-=-=-=-=-=-=-=-=-

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

[wsjt-devel] Wish-Dream: Button to toggle between Normal- & Hound-Mode

[Dieter Dippel]

Dear WSJT-X Developer-Team,
my main interest for 40 years plus is "DXing" in all modes. For FT8/FT4 
I'm using WSJT-X now for some years.


Since FOX-/Hound-Mode became more and more favourite, one of my wishes 
(dreams) is a Button on the Screen to toggle (switch) between 
Normal-Mode and Hound-Mode.


Maybe I don't know how improve it, but for me it's always very complex 
(cumbersome) to move to

1st => File
2nd => Settings
3rd => Advanced
4th => Special Operating Activity
5th => Hound-Mode
... well, and the same procedure to switch back to "Normal-Mode" ...

The Button could be placed on the same position as the ***RED*** White 
*** Hound *** is located as soon as you are starting the Hound-Mode.


If this doesen't make sense in your opinion, it would be great if you 
can discuss about a ***Keyboard-Shortcut***to make it much more 
comfortable ;-))


73 es good luck to all of you de Dieter, DF4RD







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

Re: [wsjt-devel] WSJTX-2.3.0-rc2 compile error

[John Nelson via wsjt-devel]

Hi Bill,

I have installed Boost 1.70 and updated CMake.   Could you send me the cmake 
build command that you use for Mac build?   Are there particular link options 
for boost?

Thanks…

— John G4KLA




smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.3.0-rc2

[Claude Frantz]

On 11/15/20 4:01 PM, Joe Taylor wrote:

Hi Bill, Joe & all,

I'm on a 32 bit Fedora 30 here and I have tried to build using the git 
repo, as usual.


There is a problem, which is probably not located in WSJT-X itself.

[ 87%] Built target debian
[ 87%] Generating man/man1/wsjtx.1.gz
a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param 
man.endnotes.are.numbered 0 --stringparam callout.graphics 0 
--stringparam navig.graphics 0 --stringparam admon.textlabel 1 
--stringparam admon.graphics 0  "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/home/claude/ham/JoeTaylor/wsjtx/build/manpages/man/man1/wsjtx.1.xml" 
returned non-zero exit status 5


make[2]: *** [manpages/CMakeFiles/manpages.dir/build.make:134: 
manpages/man/man1/wsjtx.1.gz] Error 1
make[2]: Target 'manpages/CMakeFiles/manpages.dir/build' not remade 
because of errors.
make[1]: *** [CMakeFiles/Makefile2:1974: 
manpages/CMakeFiles/manpages.dir/all] Error 2

Scanning dependencies of target fmtave

###

The error 5 is "Error in the stylesheet". Here, 
/etc/asciidoc/docbook-xsl/manpage.xsl is part of the package 
asciidoc-8.6.10-0.9.20180605git986f99d.fc30.noarch


It's interesting to note, that when I rerun "make", the error concerning 
"wsjtx.1.gz" has gone, but the same problem occurs now with 
"rigctld-wsjtx.1.gz".


Best wishes,
Claude (DJ0OT)


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