wsjt-devel — WSJT software development

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[Marco C. <PY...@ou...>]

Based on cmake documentation, I found the following rule:

Changed in version 4.0: Compatibility with versions of CMake older than 3.5 is removed. Calls to cmake_minimum_required(VERSION) or cmake_policy(VERSION) that do not specify at least 3.5 as their policy version (optionally via ...<max>) will produce an error in CMake 4.0 and above.

Then, since my installed cmake version is the 4.1, how do I set the variable?

(VERSION 3.5...4.1) ???

I'm a bit confused about that.

Regards,

Marco PY1ZRJ

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: Marco Calistri via wsjt-devel <wsj...@li...>
Sent: Wednesday, September 17, 2025 2:35:57 PM
To: WSJT software development <wsj...@li...>
Cc: Marco Calistri <PY...@ou...>; George Baltz <Geo...@gm...>
Subject: Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

Will try that George,

Thanks for the heads-up!

73s PY1ZRJ

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: George Baltz via wsjt-devel <wsj...@li...>
Sent: Wednesday, September 17, 2025 2:19:57 PM
To: wsj...@li... <wsj...@li...>
Cc: George Baltz <Geo...@gm...>
Subject: Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

Add the max version to the same addition -
  -DCMAKE_POLICY_VERSION_MINIMUM=3.5...3.11

On 9/16/25 20:58, Marco Calistri via wsjt-devel wrote:
> Hello,
>
> I attempted to compile the new source WSJTX 3.0.0-rc1 code as always I
> did so far, but now cmake is giving an error.
>
> This is the sequence of commands I alway launch (in this specific case I
> added the POLICY_VERSION=3.5):
>
> tar -xzvf /home/marco/Scaricati/wsjtx-3.0.0-rc1.tgz -C /home/marco/WSJT-
> X_build/build/
> cd /home/marco/WSJT-X_build/build/wsjtx-3.0.0-rc1/
> /usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
>   -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
>   -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
>   -DWSJT_GENERATE_DOCS=OFF \
>   -DWSJT_SKIP_MANPAGES=ON \
>   -DWSJT_QMAP=NO \
>   -Werror=deprecated-declarations \
>   -Wno-error \
>   -DCMAKE_POLICY_VERSION_MINIMUM=3.5
>   -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
>
> This is the answer of cmake:
>
> CMake Warning:
>    No source or binary directory provided.  Both will be assumed to be the
>    same as the current working directory, but note that this warning will
>    become a fatal error in future CMake releases.
>
>
> CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
>    Compatibility with CMake < 3.10 will be removed from a future version of
>    CMake.
>
>    Update the VERSION argument <min> value.  Or, use the <min>...<max>
> syntax
>    to tell CMake that the project requires at least <min> but has been
> updated
>    to work with policies introduced by <max> or earlier.
>
>
> -- The C compiler identification is GNU 15.2.0
> -- The CXX compiler identification is GNU 15.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Git: /usr/bin/git (found version "2.51.0")
> CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/
> shared_internal_commands.cmake:1261 (message):
>    The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>    not set.  The policy's OLD behavior will be used.  When using a URL
>    download, the timestamps of extracted files should preferably be that of
>    the time of extraction, otherwise code that depends on the extracted
>    contents might not be rebuilt if the URL changes.  The OLD behavior
>    preserves the timestamps from the archive instead, but this is
> usually not
>    what you want.  Update your project to the NEW behavior or specify the
>    DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>    robustness issue.
> Call Stack (most recent call first):
>    /usr/share/cmake/Modules/ExternalProject.cmake:3080
> (_ep_add_download_command)
>    CMakeLists.txt:112 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/
> shared_internal_commands.cmake:1261 (message):
>    The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>    not set.  The policy's OLD behavior will be used.  When using a URL
>    download, the timestamps of extracted files should preferably be that of
>    the time of extraction, otherwise code that depends on the extracted
>    contents might not be rebuilt if the URL changes.  The OLD behavior
>    preserves the timestamps from the archive instead, but this is
> usually not
>    what you want.  Update your project to the NEW behavior or specify the
>    DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>    robustness issue.
> Call Stack (most recent call first):
>    /usr/share/cmake/Modules/ExternalProject.cmake:3080
> (_ep_add_download_command)
>    CMakeLists.txt:165 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Error at CMakeLists.txt:199 (add_custom_target):
>    The target name "install" is reserved or not valid for certain CMake
>    features, such as generator expressions, and may result in undefined
>    behavior.
>
>
> -- Configuring incomplete, errors occurred!
> marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> -
> DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
>
>
> Could someone kindly clarify to me what I need to change, in order the
> code being compiled without error, please?
> Note: marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> cmake
> --version
> cmake version 4.1.1
>
> TNX!
>
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)*
> **
>
>
>
> Il 15/09/25 11:02, Joseph Taylor via wsjt-devel ha scritto:



_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[Marco C. <PY...@ou...>]

Will try that George,

Thanks for the heads-up!

73s PY1ZRJ

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: George Baltz via wsjt-devel <wsj...@li...>
Sent: Wednesday, September 17, 2025 2:19:57 PM
To: wsj...@li... <wsj...@li...>
Cc: George Baltz <Geo...@gm...>
Subject: Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

Add the max version to the same addition -
  -DCMAKE_POLICY_VERSION_MINIMUM=3.5...3.11

On 9/16/25 20:58, Marco Calistri via wsjt-devel wrote:
> Hello,
>
> I attempted to compile the new source WSJTX 3.0.0-rc1 code as always I
> did so far, but now cmake is giving an error.
>
> This is the sequence of commands I alway launch (in this specific case I
> added the POLICY_VERSION=3.5):
>
> tar -xzvf /home/marco/Scaricati/wsjtx-3.0.0-rc1.tgz -C /home/marco/WSJT-
> X_build/build/
> cd /home/marco/WSJT-X_build/build/wsjtx-3.0.0-rc1/
> /usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
>   -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
>   -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
>   -DWSJT_GENERATE_DOCS=OFF \
>   -DWSJT_SKIP_MANPAGES=ON \
>   -DWSJT_QMAP=NO \
>   -Werror=deprecated-declarations \
>   -Wno-error \
>   -DCMAKE_POLICY_VERSION_MINIMUM=3.5
>   -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
>
> This is the answer of cmake:
>
> CMake Warning:
>    No source or binary directory provided.  Both will be assumed to be the
>    same as the current working directory, but note that this warning will
>    become a fatal error in future CMake releases.
>
>
> CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
>    Compatibility with CMake < 3.10 will be removed from a future version of
>    CMake.
>
>    Update the VERSION argument <min> value.  Or, use the <min>...<max>
> syntax
>    to tell CMake that the project requires at least <min> but has been
> updated
>    to work with policies introduced by <max> or earlier.
>
>
> -- The C compiler identification is GNU 15.2.0
> -- The CXX compiler identification is GNU 15.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Git: /usr/bin/git (found version "2.51.0")
> CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/
> shared_internal_commands.cmake:1261 (message):
>    The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>    not set.  The policy's OLD behavior will be used.  When using a URL
>    download, the timestamps of extracted files should preferably be that of
>    the time of extraction, otherwise code that depends on the extracted
>    contents might not be rebuilt if the URL changes.  The OLD behavior
>    preserves the timestamps from the archive instead, but this is
> usually not
>    what you want.  Update your project to the NEW behavior or specify the
>    DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>    robustness issue.
> Call Stack (most recent call first):
>    /usr/share/cmake/Modules/ExternalProject.cmake:3080
> (_ep_add_download_command)
>    CMakeLists.txt:112 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/
> shared_internal_commands.cmake:1261 (message):
>    The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>    not set.  The policy's OLD behavior will be used.  When using a URL
>    download, the timestamps of extracted files should preferably be that of
>    the time of extraction, otherwise code that depends on the extracted
>    contents might not be rebuilt if the URL changes.  The OLD behavior
>    preserves the timestamps from the archive instead, but this is
> usually not
>    what you want.  Update your project to the NEW behavior or specify the
>    DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>    robustness issue.
> Call Stack (most recent call first):
>    /usr/share/cmake/Modules/ExternalProject.cmake:3080
> (_ep_add_download_command)
>    CMakeLists.txt:165 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Error at CMakeLists.txt:199 (add_custom_target):
>    The target name "install" is reserved or not valid for certain CMake
>    features, such as generator expressions, and may result in undefined
>    behavior.
>
>
> -- Configuring incomplete, errors occurred!
> marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> -
> DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
>
>
> Could someone kindly clarify to me what I need to change, in order the
> code being compiled without error, please?
> Note: marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> cmake
> --version
> cmake version 4.1.1
>
> TNX!
>
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)*
> **
>
>
>
> Il 15/09/25 11:02, Joseph Taylor via wsjt-devel ha scritto:



_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[George B. <Geo...@gm...>]

Add the max version to the same addition -
  -DCMAKE_POLICY_VERSION_MINIMUM=3.5...3.11

On 9/16/25 20:58, Marco Calistri via wsjt-devel wrote:
> Hello,
> 
> I attempted to compile the new source WSJTX 3.0.0-rc1 code as always I 
> did so far, but now cmake is giving an error.
> 
> This is the sequence of commands I alway launch (in this specific case I 
> added the POLICY_VERSION=3.5):
> 
> tar -xzvf /home/marco/Scaricati/wsjtx-3.0.0-rc1.tgz -C /home/marco/WSJT- 
> X_build/build/
> cd /home/marco/WSJT-X_build/build/wsjtx-3.0.0-rc1/
> /usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
>   -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
>   -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
>   -DWSJT_GENERATE_DOCS=OFF \
>   -DWSJT_SKIP_MANPAGES=ON \
>   -DWSJT_QMAP=NO \
>   -Werror=deprecated-declarations \
>   -Wno-error \
>   -DCMAKE_POLICY_VERSION_MINIMUM=3.5
>   -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
> 
> This is the answer of cmake:
> 
> CMake Warning:
>    No source or binary directory provided.  Both will be assumed to be the
>    same as the current working directory, but note that this warning will
>    become a fatal error in future CMake releases.
> 
> 
> CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
>    Compatibility with CMake < 3.10 will be removed from a future version of
>    CMake.
> 
>    Update the VERSION argument <min> value.  Or, use the <min>...<max> 
> syntax
>    to tell CMake that the project requires at least <min> but has been 
> updated
>    to work with policies introduced by <max> or earlier.
> 
> 
> -- The C compiler identification is GNU 15.2.0
> -- The CXX compiler identification is GNU 15.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Git: /usr/bin/git (found version "2.51.0")
> CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/ 
> shared_internal_commands.cmake:1261 (message):
>    The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>    not set.  The policy's OLD behavior will be used.  When using a URL
>    download, the timestamps of extracted files should preferably be that of
>    the time of extraction, otherwise code that depends on the extracted
>    contents might not be rebuilt if the URL changes.  The OLD behavior
>    preserves the timestamps from the archive instead, but this is 
> usually not
>    what you want.  Update your project to the NEW behavior or specify the
>    DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>    robustness issue.
> Call Stack (most recent call first):
>    /usr/share/cmake/Modules/ExternalProject.cmake:3080 
> (_ep_add_download_command)
>    CMakeLists.txt:112 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/ 
> shared_internal_commands.cmake:1261 (message):
>    The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>    not set.  The policy's OLD behavior will be used.  When using a URL
>    download, the timestamps of extracted files should preferably be that of
>    the time of extraction, otherwise code that depends on the extracted
>    contents might not be rebuilt if the URL changes.  The OLD behavior
>    preserves the timestamps from the archive instead, but this is 
> usually not
>    what you want.  Update your project to the NEW behavior or specify the
>    DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>    robustness issue.
> Call Stack (most recent call first):
>    /usr/share/cmake/Modules/ExternalProject.cmake:3080 
> (_ep_add_download_command)
>    CMakeLists.txt:165 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> CMake Error at CMakeLists.txt:199 (add_custom_target):
>    The target name "install" is reserved or not valid for certain CMake
>    features, such as generator expressions, and may result in undefined
>    behavior.
> 
> 
> -- Configuring incomplete, errors occurred!
> marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> - 
> DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
> 
> 
> Could someone kindly clarify to me what I need to change, in order the 
> code being compiled without error, please?
> Note: marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> cmake 
> --version
> cmake version 4.1.1
> 
> TNX!
> 
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)*
> **
> 
> 
> 
> Il 15/09/25 11:02, Joseph Taylor via wsjt-devel ha scritto:

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[Marco C. <PY...@ou...>]

My 2.7.0 is running perfectly and so far is the latest version which gets compiled flawlessly on my Linux Opensuse Tumbleweed.

For version 3.0.0, I guess I need to wait for any eventuals corrections/additions to the source code by the dev team.

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: WB5JJJ via wsjt-devel <wsj...@li...>
Sent: Wednesday, September 17, 2025 12:11:24 PM
To: WSJT software development <wsj...@li...>
Cc: WB5JJJ <wb...@gm...>
Subject: Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

I posted this on the wsjtgroup on groups.io<http://groups.io> yesterday...

After no joy with the v2.7.x version to run the compiler to completion successfully, I finally have WSJTX v3.0.0 rc1 working on my LM v22.2 machines.  Currently running the Decodes at Stage 3 with no apparent problems.  With all the flaky band conditions, it's going to be difficult to realize any immediate benefit, but I'm sure that if the developers say it's better, then I believe them.  CPU usage is very low, about what it was with Stages turned off.  But, I'm not getting more than 50 decodes as I was a few days ago either.  Others in the area that have not upgraded to v3.0.0, are seeing about the same numbers of decodes and signal strengths (when adjusted for location, antenna and HAAT) right now.

Attempts with v2.7.x failed and the errors were ambiguous, at best, for a novice programmer.  Previous version compiled and ran as expected.  So yesterday I decided to give v3.0.0 a shot.  During the first compile run, errors indicated that the "Qt5WebSockets" and "libqt5websockets5-dev" files were not found  and the compiler told me this in pretty straight forward English terms.  These were corrected (installed) and then the compile, build and install ran flawlessly.  My desktop is a Ryzen 5600G with 32Gb RAM and 1Tb SSD on which the compile took about 8 minutes.  However, my repurposed 10 year old ChromeBook Laptops took about 20 minutes each to complete successfully after installing the most likely, missing files.

I don't know if my current LM v22.2 vs the LM v22.1 I had been trying the compile on, had anything do with yesterdays success, but whatever, all is good now.

-----

73's
George - WB5JJJ
HoIP - 100105
Cell - 479.857.7737


On Wed, Sep 17, 2025 at 10:03 AM Marco Calistri via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> wrote:
Good day!

Anybody succeeded to compile WSJTX 3.0 on Linux?

I've tried also the Uwe Enhanced version, but the cmake error has been the same.

May be just Windows and prepackaged Linux versions are being useable so far...(?).

73, Marco PY1ZRJ

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: Marco Calistri via wsjt-devel <wsj...@li...<mailto:wsj...@li...>>
Sent: Tuesday, September 16, 2025 9:58:08 PM
To: wsj...@li...<mailto:wsj...@li...> <wsj...@li...<mailto:wsj...@li...>>
Cc: Marco Calistri <PY...@ou...<mailto:PY...@ou...>>
Subject: Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

Hello,

I attempted to compile the new source WSJTX 3.0.0-rc1 code as always I did so far, but now cmake is giving an error.

This is the sequence of commands I alway launch (in this specific case I added the POLICY_VERSION=3.5):

tar -xzvf /home/marco/Scaricati/wsjtx-3.0.0-rc1.tgz -C /home/marco/WSJT-X_build/build/
cd /home/marco/WSJT-X_build/build/wsjtx-3.0.0-rc1/
/usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
 -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
 -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
 -DWSJT_GENERATE_DOCS=OFF \
 -DWSJT_SKIP_MANPAGES=ON \
 -DWSJT_QMAP=NO \
 -Werror=deprecated-declarations \
 -Wno-error \
 -DCMAKE_POLICY_VERSION_MINIMUM=3.5
 -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .

This is the answer of cmake:

CMake Warning:
  No source or binary directory provided.  Both will be assumed to be the
  same as the current working directory, but note that this warning will
  become a fatal error in future CMake releases.


CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.


-- The C compiler identification is GNU 15.2.0
-- The CXX compiler identification is GNU 15.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.51.0")
CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/ExternalProject.cmake:3080 (_ep_add_download_command)
  CMakeLists.txt:112 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/ExternalProject.cmake:3080 (_ep_add_download_command)
  CMakeLists.txt:165 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at CMakeLists.txt:199 (add_custom_target):
  The target name "install" is reserved or not valid for certain CMake
  features, such as generator expressions, and may result in undefined
  behavior.


-- Configuring incomplete, errors occurred!
marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1<mailto:marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1>>  -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .


Could someone kindly clarify to me what I need to change, in order the code being compiled without error, please?
Note: marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1<mailto:marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1>> cmake --version
cmake version 4.1.1

TNX!

---
73 de Marco, PY1ZRJ (former IK5BCU)
[cid:ii_1995834c6c21a89d51b1]



Il 15/09/25 11:02, Joseph Taylor via wsjt-devel ha scritto:
Dear WSJT-X Users,


The WSJT Development Team has been working hard to complete preparation of WSJT-X 3.0.0, a major revision offering many new features and capabilities.  Many of the new features have already been tested in WSJT-X Improved 2.8.0 and will be familiar to users of that edition, while others are entirely new.

For a full summary and overview of changes, see the new Release Notes https://wsjt.sourceforge.io/Release_Notes.txt and Section 1.1 of the WSJT-X User Guide https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#NEW_FEATURES.


Candidate release WSJT-X 3.0.0-RC1 is now available for download. Candidate releases are intended for users interested in exercising the new features and willing to provide feedback to the developers.  Direct links for downloading pre-built installation packages for Windows, Linux, and macOS can be found on the WSJT-X web page: https://wsjt.sourceforge.io/wsjtx.html. For those who like to compile from source, a complete source-code tarball is available there as well.



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



The authors and Copyright holders of WSJT-X request that derivative works should not publish programs based on features in WSJT-X before those features are made available in a General Availability (GA) release of WSJT-X. We will cease making public Release Candidates if this request is ignored.



Feedback and bug reports should be sent to this email list or one of the of the others mentioned here in the User Guide: https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#SUPPORT .


We hope you will enjoy using WSJT-X 3.0.0-RC1, and we look forward to receiving your feedback.



       -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG2YCB; Brian, N9ADG;

                                 John, G4KLA; Charlie, DL3WDG; and Roger, W3SZ.



_______________________________________________
wsjt-devel mailing list
wsj...@li...<mailto:wsj...@li...>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[WB5JJJ <wb...@gm...>]

I posted this on the wsjtgroup on groups.io yesterday...

After no joy with the v2.7.x version to run the compiler to completion
successfully, I finally have WSJTX v3.0.0 rc1 working on my LM v22.2
machines.  Currently running the Decodes at Stage 3 with no apparent
problems.  With all the flaky band conditions, it's going to be difficult
to realize any immediate benefit, but I'm sure that if the developers say
it's better, then I believe them.  CPU usage is very low, about what it was
with Stages turned off.  But, I'm not getting more than 50 decodes as I was
a few days ago either.  Others in the area that have not upgraded to
v3.0.0, are seeing about the same numbers of decodes and signal strengths
(when adjusted for location, antenna and HAAT) right now.

Attempts with v2.7.x failed and the errors were ambiguous, at best, for a
novice programmer.  Previous version compiled and ran as expected.  So
yesterday I decided to give v3.0.0 a shot.  During the first compile run,
errors indicated that the "Qt5WebSockets" and "libqt5websockets5-dev" files
were not found  and the compiler told me this in pretty straight forward
English terms.  These were corrected (installed) and then the compile,
build and install ran flawlessly.  My desktop is a Ryzen 5600G with 32Gb
RAM and 1Tb SSD on which the compile took about 8 minutes.  However, my
repurposed 10 year old ChromeBook Laptops took about 20 minutes each to
complete successfully after installing the most likely, missing files.

I don't know if my current LM v22.2 vs the LM v22.1 I had been trying the
compile on, had anything do with yesterdays success, but whatever, all is
good now.

-----

73's
George - WB5JJJ
HoIP - 100105
Cell - 479.857.7737


On Wed, Sep 17, 2025 at 10:03 AM Marco Calistri via wsjt-devel <
wsj...@li...> wrote:

> Good day!
>
> Anybody succeeded to compile WSJTX 3.0 on Linux?
>
> I've tried also the Uwe Enhanced version, but the cmake error has been the
> same.
>
> May be just Windows and prepackaged Linux versions are being useable so
> far...(?).
>
> 73, Marco PY1ZRJ
>
> Inviato da Outlook per Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* Marco Calistri via wsjt-devel <wsj...@li...>
> *Sent:* Tuesday, September 16, 2025 9:58:08 PM
> *To:* wsj...@li... <wsj...@li...>
> *Cc:* Marco Calistri <PY...@ou...>
> *Subject:* Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1
>
> Hello,
>
> I attempted to compile the new source WSJTX 3.0.0-rc1 code as always I did
> so far, but now cmake is giving an error.
>
> This is the sequence of commands I alway launch (in this specific case I
> added the POLICY_VERSION=3.5):
>
> tar -xzvf /home/marco/Scaricati/wsjtx-3.0.0-rc1.tgz -C
> /home/marco/WSJT-X_build/build/
> cd /home/marco/WSJT-X_build/build/wsjtx-3.0.0-rc1/
> /usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
>  -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
>  -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
>  -DWSJT_GENERATE_DOCS=OFF \
>  -DWSJT_SKIP_MANPAGES=ON \
>  -DWSJT_QMAP=NO \
>  -Werror=deprecated-declarations \
>  -Wno-error \
>  -DCMAKE_POLICY_VERSION_MINIMUM=3.5
>  -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
>
> This is the answer of cmake:
>
> CMake Warning:
>   No source or binary directory provided.  Both will be assumed to be the
>   same as the current working directory, but note that this warning will
>   become a fatal error in future CMake releases.
>
>
> CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
>   Compatibility with CMake < 3.10 will be removed from a future version of
>   CMake.
>
>   Update the VERSION argument <min> value.  Or, use the <min>...<max>
> syntax
>   to tell CMake that the project requires at least <min> but has been
> updated
>   to work with policies introduced by <max> or earlier.
>
>
> -- The C compiler identification is GNU 15.2.0
> -- The CXX compiler identification is GNU 15.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Git: /usr/bin/git (found version "2.51.0")
> CMake Warning (dev) at
> /usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261
> (message):
>   The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>   not set.  The policy's OLD behavior will be used.  When using a URL
>   download, the timestamps of extracted files should preferably be that of
>   the time of extraction, otherwise code that depends on the extracted
>   contents might not be rebuilt if the URL changes.  The OLD behavior
>   preserves the timestamps from the archive instead, but this is usually
> not
>   what you want.  Update your project to the NEW behavior or specify the
>   DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>   robustness issue.
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/ExternalProject.cmake:3080
> (_ep_add_download_command)
>   CMakeLists.txt:112 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261
> (message):
>   The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
>   not set.  The policy's OLD behavior will be used.  When using a URL
>   download, the timestamps of extracted files should preferably be that of
>   the time of extraction, otherwise code that depends on the extracted
>   contents might not be rebuilt if the URL changes.  The OLD behavior
>   preserves the timestamps from the archive instead, but this is usually
> not
>   what you want.  Update your project to the NEW behavior or specify the
>   DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
>   robustness issue.
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/ExternalProject.cmake:3080
> (_ep_add_download_command)
>   CMakeLists.txt:165 (ExternalProject_Add)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Error at CMakeLists.txt:199 (add_custom_target):
>   The target name "install" is reserved or not valid for certain CMake
>   features, such as generator expressions, and may result in undefined
>   behavior.
>
>
> -- Configuring incomplete, errors occurred!
> marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1>
> -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .
>
>
> Could someone kindly clarify to me what I need to change, in order the
> code being compiled without error, please?
> Note: marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> cmake
> --version
> cmake version 4.1.1
>
> TNX!
>
> ---
>
> *73 de Marco, PY1ZRJ (former IK5BCU) *
>
>
>
> Il 15/09/25 11:02, Joseph Taylor via wsjt-devel ha scritto:
>
> Dear WSJT-X Users,
>
> The WSJT Development Team has been working hard to complete preparation of *WSJT-X
> 3.0.0*, a major revision offering many new features and capabilities.
> Many of the new features have already been tested in *WSJT-X
> Improved 2.8.0* and will be familiar to users of that edition, while
> others are entirely new.
>
> For a full summary and overview of changes, see the new Release Notes *https://wsjt.sourceforge.io/Release_Notes.txt
> <https://wsjt.sourceforge.io/Release_Notes.txt>* and Section 1.1 of the
> WSJT-X User Guide
> https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#NEW_FEATURES
> .
>
> Candidate release WSJT-X 3.0.0-RC1 is now available for download.
> Candidate releases are intended for users interested in exercising the new
> features and willing to provide feedback to the developers.  Direct links
> for downloading pre-built installation packages for Windows, Linux, and
> macOS can be found on the WSJT-X web page: *https://wsjt.sourceforge.io/wsjtx.html
> <https://wsjt.sourceforge.io/wsjtx.html>*. For those who like to compile
> from source, a complete source-code tarball is available there as well.
>
>
> WSJT-X is licensed under the terms of Version 3 of the GNU General Public
> License (GPL). Development of this software is a cooperative project to
> which many amateur radio operators have contributed. If you use our code,
> please have the courtesy to let us know about it.
>
>
>
> The authors and Copyright holders of WSJT-X request that derivative works
> should not publish programs based on features in WSJT-X before those
> features are made available in a General Availability (GA) release of
> WSJT-X. We will cease making public Release Candidates if this request is
> ignored.
>
>
>
> Feedback and bug reports should be sent to this email list or one of the
> of the others mentioned here in the User Guide:
> https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#SUPPORT .
>
>
> We hope you will enjoy using WSJT-X 3.0.0-RC1, and we look forward to
> receiving your feedback.
>
>
>
>        -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG2YCB;
> Brian, N9ADG;
>
>                                  John, G4KLA; Charlie, DL3WDG; and Roger,
> W3SZ.
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[Marco C. <PY...@ou...>]

Good day!

Anybody succeeded to compile WSJTX 3.0 on Linux?

I've tried also the Uwe Enhanced version, but the cmake error has been the same.

May be just Windows and prepackaged Linux versions are being useable so far...(?).

73, Marco PY1ZRJ

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: Marco Calistri via wsjt-devel <wsj...@li...>
Sent: Tuesday, September 16, 2025 9:58:08 PM
To: wsj...@li... <wsj...@li...>
Cc: Marco Calistri <PY...@ou...>
Subject: Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

Hello,

I attempted to compile the new source WSJTX 3.0.0-rc1 code as always I did so far, but now cmake is giving an error.

This is the sequence of commands I alway launch (in this specific case I added the POLICY_VERSION=3.5):

tar -xzvf /home/marco/Scaricati/wsjtx-3.0.0-rc1.tgz -C /home/marco/WSJT-X_build/build/
cd /home/marco/WSJT-X_build/build/wsjtx-3.0.0-rc1/
/usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
 -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
 -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
 -DWSJT_GENERATE_DOCS=OFF \
 -DWSJT_SKIP_MANPAGES=ON \
 -DWSJT_QMAP=NO \
 -Werror=deprecated-declarations \
 -Wno-error \
 -DCMAKE_POLICY_VERSION_MINIMUM=3.5
 -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .

This is the answer of cmake:

CMake Warning:
  No source or binary directory provided.  Both will be assumed to be the
  same as the current working directory, but note that this warning will
  become a fatal error in future CMake releases.


CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.


-- The C compiler identification is GNU 15.2.0
-- The CXX compiler identification is GNU 15.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.51.0")
CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/ExternalProject.cmake:3080 (_ep_add_download_command)
  CMakeLists.txt:112 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/ExternalProject.cmake:3080 (_ep_add_download_command)
  CMakeLists.txt:165 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at CMakeLists.txt:199 (add_custom_target):
  The target name "install" is reserved or not valid for certain CMake
  features, such as generator expressions, and may result in undefined
  behavior.


-- Configuring incomplete, errors occurred!
marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1<mailto:marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1>>  -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .


Could someone kindly clarify to me what I need to change, in order the code being compiled without error, please?
Note: marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1<mailto:marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1>> cmake --version
cmake version 4.1.1

TNX!

---
73 de Marco, PY1ZRJ (former IK5BCU)
[cid:par...@ou...]



Il 15/09/25 11:02, Joseph Taylor via wsjt-devel ha scritto:
Dear WSJT-X Users,


The WSJT Development Team has been working hard to complete preparation of WSJT-X 3.0.0, a major revision offering many new features and capabilities.  Many of the new features have already been tested in WSJT-X Improved 2.8.0 and will be familiar to users of that edition, while others are entirely new.

For a full summary and overview of changes, see the new Release Notes https://wsjt.sourceforge.io/Release_Notes.txt and Section 1.1 of the WSJT-X User Guide https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#NEW_FEATURES.


Candidate release WSJT-X 3.0.0-RC1 is now available for download. Candidate releases are intended for users interested in exercising the new features and willing to provide feedback to the developers.  Direct links for downloading pre-built installation packages for Windows, Linux, and macOS can be found on the WSJT-X web page: https://wsjt.sourceforge.io/wsjtx.html. For those who like to compile from source, a complete source-code tarball is available there as well.



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



The authors and Copyright holders of WSJT-X request that derivative works should not publish programs based on features in WSJT-X before those features are made available in a General Availability (GA) release of WSJT-X. We will cease making public Release Candidates if this request is ignored.



Feedback and bug reports should be sent to this email list or one of the of the others mentioned here in the User Guide: https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#SUPPORT .


We hope you will enjoy using WSJT-X 3.0.0-RC1, and we look forward to receiving your feedback.



       -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG2YCB; Brian, N9ADG;

                                 John, G4KLA; Charlie, DL3WDG; and Roger, W3SZ.

Re: [wsjt-devel] FLRig missing from 3.0rc

[Charles S. <g3...@gm...>]

*Hi Arkadiusz*

*Thanks for this link - seems other rigs may be affected also.*

*73*

*Charlie DL3WDG*

On Wed, 17 Sept 2025 at 10:59, Arkadiusz Miśkiewicz via wsjt-devel <
wsj...@li...> wrote:

> On 17/09/2025 04:47, Laurie, VK3AMA via wsjt-devel wrote:
> >
> >
> > On 17/09/2025 11:23 am, Michael Morgan via wsjt-devel wrote:
> >> It is still there is is listed under W1HKF Flrig.
> >>
> >
> > IMO it would have been better to name the new FLRig entry "FLRig
> > (W1KHJ)".
>
> It's hamlib naming scheme - "manufacturer model" (hamlib is a library
> that wsjtx uses). wsjtx has no influence on that name - just gets it
> from hamlib.
>
> https://github.com/Hamlib/Hamlib/pull/1823/commits/a9ecd503294b60aed1874cd962c23a9655f3432d
>
> --
> Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] FLRig missing from 3.0rc

[Arkadiusz M. <ar...@ma...>]

On 17/09/2025 04:47, Laurie, VK3AMA via wsjt-devel wrote:
> 
> 
> On 17/09/2025 11:23 am, Michael Morgan via wsjt-devel wrote:
>> It is still there is is listed under W1HKF Flrig.
>>
> 
> IMO it would have been better to name the new FLRig entry "FLRig 
> (W1KHJ)". 

It's hamlib naming scheme - "manufacturer model" (hamlib is a library 
that wsjtx uses). wsjtx has no influence on that name - just gets it 
from hamlib.
https://github.com/Hamlib/Hamlib/pull/1823/commits/a9ecd503294b60aed1874cd962c23a9655f3432d

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: [wsjt-devel] FLRig missing from 3.0rc

[Laurie, V. <_vk...@vk...>]

On 17/09/2025 11:23 am, Michael Morgan via wsjt-devel wrote:
> It is still there is is listed under W1HKF Flrig.
>

IMO it would have been better to name the new FLRig entry "FLRig 
(W1KHJ)". This way it is easily found alphabetically in the list, people 
don't need to search the whole list of rigs especially if they have no 
knowledge of the authors callsign. If there is ever an alternate FLRig 
by a different callsign and it is named similarly they would be found 
grouped together in the listing.

de Laurie VK3AMA
(JTAlert author)

Re: [wsjt-devel] FLRig missing from 3.0rc

[Michael M. <cmo...@gm...>]

It is still there is is listed under W1HKF Flrig.

Michael, AA5SH

On Tue, Sep 16, 2025 at 8:11 PM Josh Rovero via wsjt-devel <
wsj...@li...> wrote:

> Was able to build fine on Fedora Core 64-bit after adding one package, but
> can't run in my last good configuration since FLRig is missing.
>
>
> Josh Rovero
> KK1D
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

[wsjt-devel] FLRig missing from 3.0rc

[Josh R. <jos...@gm...>]

Was able to build fine on Fedora Core 64-bit after adding one package, but
can't run in my last good configuration since FLRig is missing.


Josh Rovero
KK1D

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[Marco C. <PY...@ou...>]

Hello,

I attempted to compile the new source WSJTX 3.0.0-rc1 code as always I 
did so far, but now cmake is giving an error.

This is the sequence of commands I alway launch (in this specific case I 
added the POLICY_VERSION=3.5):

tar -xzvf /home/marco/Scaricati/wsjtx-3.0.0-rc1.tgz -C 
/home/marco/WSJT-X_build/build/
cd /home/marco/WSJT-X_build/build/wsjtx-3.0.0-rc1/
/usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
  -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
  -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
  -DWSJT_GENERATE_DOCS=OFF \
  -DWSJT_SKIP_MANPAGES=ON \
  -DWSJT_QMAP=NO \
  -Werror=deprecated-declarations \
  -Wno-error \
  -DCMAKE_POLICY_VERSION_MINIMUM=3.5
  -DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .

This is the answer of cmake:

CMake Warning:
   No source or binary directory provided.  Both will be assumed to be the
   same as the current working directory, but note that this warning will
   become a fatal error in future CMake releases.


CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
   Compatibility with CMake < 3.10 will be removed from a future version of
   CMake.

   Update the VERSION argument <min> value.  Or, use the <min>...<max> 
syntax
   to tell CMake that the project requires at least <min> but has been 
updated
   to work with policies introduced by <max> or earlier.


-- The C compiler identification is GNU 15.2.0
-- The CXX compiler identification is GNU 15.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.51.0")
CMake Warning (dev) at 
/usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261 
(message):
   The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
   not set.  The policy's OLD behavior will be used.  When using a URL
   download, the timestamps of extracted files should preferably be that of
   the time of extraction, otherwise code that depends on the extracted
   contents might not be rebuilt if the URL changes.  The OLD behavior
   preserves the timestamps from the archive instead, but this is 
usually not
   what you want.  Update your project to the NEW behavior or specify the
   DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
   robustness issue.
Call Stack (most recent call first):
   /usr/share/cmake/Modules/ExternalProject.cmake:3080 
(_ep_add_download_command)
   CMakeLists.txt:112 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at 
/usr/share/cmake/Modules/ExternalProject/shared_internal_commands.cmake:1261 
(message):
   The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
   not set.  The policy's OLD behavior will be used.  When using a URL
   download, the timestamps of extracted files should preferably be that of
   the time of extraction, otherwise code that depends on the extracted
   contents might not be rebuilt if the URL changes.  The OLD behavior
   preserves the timestamps from the archive instead, but this is 
usually not
   what you want.  Update your project to the NEW behavior or specify the
   DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
   robustness issue.
Call Stack (most recent call first):
   /usr/share/cmake/Modules/ExternalProject.cmake:3080 
(_ep_add_download_command)
   CMakeLists.txt:165 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at CMakeLists.txt:199 (add_custom_target):
   The target name "install" is reserved or not valid for certain CMake
   features, such as generator expressions, and may result in undefined
   behavior.


-- Configuring incomplete, errors occurred!
marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> 
-DCMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .


Could someone kindly clarify to me what I need to change, in order the 
code being compiled without error, please?
Note: marco@linux-turion64:~/WSJT-X_build/build/wsjtx-3.0.0-rc1> cmake 
--version
cmake version 4.1.1

TNX!

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**



Il 15/09/25 11:02, Joseph Taylor via wsjt-devel ha scritto:
> Dear WSJT-X Users,
>
> The WSJT Development Team has been working hard to complete 
> preparation of /WSJT-X 3.0.0/, a major revision offering many new 
> features and capabilities.  Many of the new features have already been 
> tested in /WSJT-X Improved 2.8.0/ and will be familiar to users of 
> that edition, while others are entirely new.
>
> For a full summary and overview of changes, see the new Release Notes 
> _https://wsjt.sourceforge.io/Release_Notes.txt 
> <https://wsjt.sourceforge.io/Release_Notes.txt>_ and Section 1.1 of 
> the WSJT-X User Guide 
> https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#NEW_FEATURES 
> <https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#NEW_FEATURES>.
>
>
> Candidate release WSJT-X 3.0.0-RC1 is now available for download. 
> Candidate releases are intended for users interested in exercising the 
> new features and willing to provide feedback to the developers.  
> Direct links for downloading pre-built installation packages for 
> Windows, Linux, and macOS can be found on the WSJT-X web page: 
> _https://wsjt.sourceforge.io/wsjtx.html 
> <https://wsjt.sourceforge.io/wsjtx.html>_. For those who like to 
> compile from source, a complete source-code tarball is available there 
> as well.
>
> WSJT-X is licensed under the terms of Version 3 of the GNU General 
> Public License (GPL). Development of this software is a cooperative 
> project to which many amateur radio operators have contributed. If you 
> use our code, please have the courtesy to let us know about it.
>
> The authors and Copyright holders of WSJT-X request that derivative 
> works should not publish programs based on features in WSJT-X before 
> those features are made available in a General Availability (GA) 
> release of WSJT-X. We will cease making public Release Candidates if 
> this request is ignored.
>
> Feedback and bug reports should be sent to this email list or one of 
> the of the others mentioned here in the User Guide: 
> https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#SUPPORT 
> <https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#SUPPORT> . 
>
>
>
> We hope you will enjoy using WSJT-X 3.0.0-RC1, and we look forward to 
> receiving your feedback.
>
> -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG2YCB; Brian, 
> N9ADG;
>
>                                John, G4KLA; Charlie, DL3WDG; and 
> Roger, W3SZ.
>
>
>

Re: [wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[Arkadiusz M. <ar...@ma...>]

On 15/09/2025 16:02, Joseph Taylor via wsjt-devel wrote:

> Candidate release WSJT-X 3.0.0-RC1 is now available for download.
[...]

> Feedback and bug reports should be sent to this email list or[...]

Noticed one thing - wsjt-x remembers rig in config by rig name. 
Unfortunately names are not stable in hamlib, example:

https://github.com/Hamlib/Hamlib/pull/1823

Only IDs are stable. Future name changes in hamlib can be expected.


When rig name changes wsjt-x silently switches to first rig on the list, 
ADAT rig, and from user point of view silently stops working (assuming 
user had something else set in his setup).

wsjt-x could warn that "XYZ rig found in configuration file is not 
supported by your Hamlib. Please update Rig in Preferences->Radio 
settings." in such case.


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: [wsjt-devel] A missing Jason

[Kari S. <kai...@gm...>]

Hi Reino,

The 3.0.0.json has magically appeared there about an hour ago.

The new  file is identical with that of v 2.8, so alas, no additional 
samples...

73's de Kari, oh2gqc

On 9/16/25 11:05, Reino Talarmo via wsjt-devel wrote:
> Hi,
>
> Just checked the downloading of the samples in
> V3.0.0-rc1 and got answer
> Error transferring
> http://downloads.sourceforge.net/project/wsjt/samples/co
> ntents_3.0.json - server replied: Not Found
> Most probably there is no new samples available  at the
> moment and the existing contents_2.8.json should be
> fine, but perhaps some SuperFox sample should be added.
>
> 73, Reino OH3mA
>
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] A missing Jason

[Reino T. <rei...@ko...>]

Hi,

Just checked the downloading of the samples in
V3.0.0-rc1 and got answer
Error transferring
http://downloads.sourceforge.net/project/wsjt/samples/co
ntents_3.0.json - server replied: Not Found
Most probably there is no new samples available  at the
moment and the existing contents_2.8.json should be
fine, but perhaps some SuperFox sample should be added.

73, Reino OH3mA

[wsjt-devel] Candidate Release WSJT-X 3.0.0-rc1

[Joseph T. <jo...@Pr...>]

Dear WSJT-X Users,


The WSJT Development Team has been working hard to complete preparation of WSJT-X 3.0.0, a major revision offering many new features and capabilities.  Many of the new features have already been tested in WSJT-X Improved 2.8.0 and will be familiar to users of that edition, while others are entirely new.

For a full summary and overview of changes, see the new Release Notes https://wsjt.sourceforge.io/Release_Notes.txt and Section 1.1 of the WSJT-X User Guide https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#NEW_FEATURES.


Candidate release WSJT-X 3.0.0-RC1 is now available for download. Candidate releases are intended for users interested in exercising the new features and willing to provide feedback to the developers.  Direct links for downloading pre-built installation packages for Windows, Linux, and macOS can be found on the WSJT-X web page: https://wsjt.sourceforge.io/wsjtx.html. For those who like to compile from source, a complete source-code tarball is available there as well.



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



The authors and Copyright holders of WSJT-X request that derivative works should not publish programs based on features in WSJT-X before those features are made available in a General Availability (GA) release of WSJT-X. We will cease making public Release Candidates if this request is ignored.



Feedback and bug reports should be sent to this email list or one of the of the others mentioned here in the User Guide: https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#SUPPORT .


We hope you will enjoy using WSJT-X 3.0.0-RC1, and we look forward to receiving your feedback.



       -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG2YCB; Brian, N9ADG;

                                 John, G4KLA; Charlie, DL3WDG; and Roger, W3SZ.

Re: [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD

[Marco C. <PY...@ou...>]

I wrote O.T. in the subject and expressed my apologies, just because this is just a personal complain.

Cheers,

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: Tom M0LTE via wsjt-devel <wsj...@li...>
Sent: Sunday, September 7, 2025 8:51:11 AM
To: WSJT software development <wsj...@li...>
Cc: Tom M0LTE <to...@m0...>
Subject: Re: [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD

Unpleasant experience- but what relevance is this to wsjtx-devel?

On Sun, 7 Sep 2025 at 12:48, Marco Calistri via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> wrote:
Hey Dan!

Of course: this kind of unpleasant episode will not be able to thread my pure passion for ham-radio!

I'm ham-radio from 43 years now and I hope to continue to be for the rest of my life.

Nothing against people using e-mail QSL services, personally I dislike, for this reason my message here.

Thanks for your feedback!

Best,

Marco, PY1ZRJ



Il 07/09/25 08:23, Dan Malcolm ha scritto:

Marco,

Sorry you received this response.  I use an email QSL service.  Two actually.  But I understand the wish to receive QSL’s that way.  I don't use the service you are having trouble with, but if I did it would be past tense.  I have no patience for ill-mannered people.

I hope this a one-off experience and you continue to enjoy the wonderful hobby we have.



73

__________

Dan – K4SHQ

CFI/II



From: Marco Calistri via wsjt-devel <wsj...@li...><mailto:wsj...@li...>
Sent: Sunday, September 7, 2025 5:53 AM
To: 'WSJT software development' <wsj...@li...><mailto:wsj...@li...>
Cc: Marco Calistri <PY...@ou...><mailto:PY...@ou...>
Subject: [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD



First of all:

My sincere apologies to use this respectful list of serious ham-radio people, to report the very disrespectful and offensive answer I received by hamradiodx.es<http://hamradiodx.es> support (mailto:so...@ha...).

In addition, for any eventual users of such automatic e-mail systems to send QSL cards, or even similar systems, please:

Avoid to send me QSL cards via e-mail because I will not reply to it!


Well, I simply requested to the hamradiodx.es<http://hamradiodx.es> support to remove my email address from their server or even apply a block rule to avoid their server sending me e-mails containing QSL cards sent to me by other ham-stations.

Well this is the answer I received by them:

---ORIGINAL---

[cid:ii_19924038515ad7999131]
---Translation:---

Hey, clown... this isn't SPAM. You're so dumb you don't even know what an online QSL sending system is. Users are the ones who send the confirmations, not us, you fucking clown. If you don't want to receive QSLs, block them from your fucking email, you fucking retard.

-------------------------------------------------------------------------

Please make your considerations about this site and their personnel!

---
73 de Marco, PY1ZRJ (former IK5BCU)
[cid:ii_19924038515b11963102]


---
73 de Marco, PY1ZRJ (former IK5BCU)
[cid:ii_19924038515cb0a67683]
_______________________________________________
wsjt-devel mailing list
wsj...@li...<mailto:wsj...@li...>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD

[Tom M. <to...@m0...>]

Unpleasant experience- but what relevance is this to wsjtx-devel?

On Sun, 7 Sep 2025 at 12:48, Marco Calistri via wsjt-devel <
wsj...@li...> wrote:

> Hey Dan!
>
> Of course: this kind of unpleasant episode will not be able to thread my
> pure passion for ham-radio!
>
> I'm ham-radio from 43 years now and I hope to continue to be for the rest
> of my life.
>
> Nothing against people using e-mail QSL services, personally I dislike,
> for this reason my message here.
>
> Thanks for your feedback!
>
> Best,
>
> Marco, PY1ZRJ
>
>
>
> Il 07/09/25 08:23, Dan Malcolm ha scritto:
>
> Marco,
>
> Sorry you received this response.  I use an email QSL service.  Two
> actually.  But I understand the wish to receive QSL’s that way.  I don't
> use the service you are having trouble with, but if I did it would be past
> tense.  I have no patience for ill-mannered people.
>
> I hope this a one-off experience and you continue to enjoy the wonderful
> hobby we have.
>
>
>
> 73
>
> __________
>
> Dan – K4SHQ
>
> CFI/II
>
>
>
> *From:* Marco Calistri via wsjt-devel <wsj...@li...>
> <wsj...@li...>
> *Sent:* Sunday, September 7, 2025 5:53 AM
> *To:* 'WSJT software development' <wsj...@li...>
> <wsj...@li...>
> *Cc:* Marco Calistri <PY...@ou...> <PY...@ou...>
> *Subject:* [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD
>
>
>
> First of all:
>
> My sincere apologies to use this respectful list of serious ham-radio
> people, to report the very disrespectful and offensive answer I received by *hamradiodx.es
> <http://hamradiodx.es>* support (mailto:so...@ha...
> <so...@ha...>).
>
> In addition, for any eventual users of such automatic e-mail systems to
> send QSL cards, or even similar systems, please:
>
>
>
> * Avoid to send me QSL cards via e-mail because I will not reply to it! *
> Well, I simply requested to the hamradiodx.es support to remove my email
> address from their server or even apply a block rule to avoid their server
> sending me e-mails containing QSL cards sent to me by other ham-stations.
>
> Well this is the answer I received by them:
>
> ---ORIGINAL---
>
>
> ---Translation:---
>
>
>
>
>
> *Hey, clown... this isn't SPAM. You're so dumb you don't even know what an
> online QSL sending system is. Users are the ones who send the
> confirmations, not us, you fucking clown. If you don't want to receive
> QSLs, block them from your fucking email, you fucking retard.
> ------------------------------------------------------------------------- *Please
> make your considerations about this site and their personnel!
>
> ---
>
> *73 de Marco, PY1ZRJ (former IK5BCU) *
>
>
>
> ---
>
> *73 de Marco, PY1ZRJ (former IK5BCU) *
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD

[Marco C. <PY...@ou...>]

Hey Dan!

Of course: this kind of unpleasant episode will not be able to thread my 
pure passion for ham-radio!

I'm ham-radio from 43 years now and I hope to continue to be for the 
rest of my life.

Nothing against people using e-mail QSL services, personally I dislike, 
for this reason my message here.

Thanks for your feedback!

Best,

Marco, PY1ZRJ



Il 07/09/25 08:23, Dan Malcolm ha scritto:
>
> Marco,
>
> Sorry you received this response.  I use an email QSL service. Two 
> actually.  But I understand the wish to receive QSL’s that way.  I 
> don't use the service you are having trouble with, but if I did it 
> would be past tense.  I have no patience for ill-mannered people.
>
> I hope this a one-off experience and you continue to enjoy the 
> wonderful hobby we have.
>
> 73
>
> __________
>
> Dan – K4SHQ
>
> CFI/II
>
> *From:*Marco Calistri via wsjt-devel <wsj...@li...>
> *Sent:* Sunday, September 7, 2025 5:53 AM
> *To:* 'WSJT software development' <wsj...@li...>
> *Cc:* Marco Calistri <PY...@ou...>
> *Subject:* [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD
>
> First of all:
>
> My sincere apologies to use this respectful list of serious ham-radio 
> people, to report the very disrespectful and offensive answer I 
> received by *hamradiodx.es* support (mailto:so...@ha... 
> <mailto:so...@ha...>).
>
> In addition, for any eventual users of such automatic e-mail systems 
> to send QSL cards, or even similar systems, please: */
>
> Avoid to send me QSL cards via e-mail because I will not reply to it!
>
> /*
> Well, I simply requested to the hamradiodx.es support to remove my 
> email address from their server or even apply a block rule to avoid 
> their server sending me e-mails containing QSL cards sent to me by 
> other ham-stations.
>
> Well this is the answer I received by them:
>
> ---ORIGINAL---
>
>
> ---Translation:---
>
> */Hey, clown... this isn't SPAM. You're so dumb you don't even know 
> what an online QSL sending system is. Users are the ones who send the 
> confirmations, not us, you fucking clown. If you don't want to receive 
> QSLs, block them from your fucking email, you fucking retard.
>
> -------------------------------------------------------------------------
>
> /*Please make your considerations about this site and their personnel!
>
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)
> ***
>


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**

Re: [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD

[Dan M. <k4...@ou...>]

Marco,
Sorry you received this response.  I use an email QSL service.  Two actually.  But I understand the wish to receive QSL’s that way.  I don't use the service you are having trouble with, but if I did it would be past tense.  I have no patience for ill-mannered people.
I hope this a one-off experience and you continue to enjoy the wonderful hobby we have.

73
__________
Dan – K4SHQ
CFI/II

From: Marco Calistri via wsjt-devel <wsj...@li...>
Sent: Sunday, September 7, 2025 5:53 AM
To: 'WSJT software development' <wsj...@li...>
Cc: Marco Calistri <PY...@ou...>
Subject: [wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD

First of all:

My sincere apologies to use this respectful list of serious ham-radio people, to report the very disrespectful and offensive answer I received by hamradiodx.es support (mailto:so...@ha...).

In addition, for any eventual users of such automatic e-mail systems to send QSL cards, or even similar systems, please:

Avoid to send me QSL cards via e-mail because I will not reply to it!


Well, I simply requested to the hamradiodx.es support to remove my email address from their server or even apply a block rule to avoid their server sending me e-mails containing QSL cards sent to me by other ham-stations.

Well this is the answer I received by them:

---ORIGINAL---

[cid:image001.png@01DC1FBF.F36F1430]
---Translation:---

Hey, clown... this isn't SPAM. You're so dumb you don't even know what an online QSL sending system is. Users are the ones who send the confirmations, not us, you fucking clown. If you don't want to receive QSLs, block them from your fucking email, you fucking retard.

-------------------------------------------------------------------------

Please make your considerations about this site and their personnel!
---
73 de Marco, PY1ZRJ (former IK5BCU)
[cid:image002.jpg@01DC1FBF.F36F1430]

[wsjt-devel] O.T. (Off-Thread) THEY SENT YOU A QSL CONTACT CARD

[Marco C. <PY...@ou...>]

First of all:

My sincere apologies to use this respectful list of serious ham-radio 
people, to report the very disrespectful and offensive answer I received 
by *hamradiodx.es* support (mailto:so...@ha...).

In addition, for any eventual users of such automatic e-mail systems to 
send QSL cards, or even similar systems, please: */

Avoid to send me QSL cards via e-mail because I will not reply to it!

/*
Well, I simply requested to the hamradiodx.es support to remove my email 
address from their server or even apply a block rule to avoid their 
server sending me e-mails containing QSL cards sent to me by other 
ham-stations.

Well this is the answer I received by them:

---ORIGINAL---


---Translation:---

/*Hey, clown... this isn't SPAM. You're so dumb you don't even know what 
an online QSL sending system is. Users are the ones who send the 
confirmations, not us, you fucking clown. If you don't want to receive 
QSLs, block them from your fucking email, you fucking retard.

-------------------------------------------------------------------------

*/Please make your considerations about this site and their personnel!/*
*/
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**

Re: [wsjt-devel] Icom IC-910 rig failure

[Kyle Y <yo...@gm...>]

Good evening. Following up on this issue. Today I downloaded the most
recent Hamlib (4.7~GIT 2025-08-30T09) and I am happy to report that CAT
control now works on my Icom 910 directly, without having to use Ham Radio
Deluxe!

I did notice that TX via CAT does not work however. It does work using CAT
in Ham Radio Deluxe.

Thanks. 73

Kyle
K0KN

On Sat, Jul 19, 2025 at 11:29 AM Kyle Y <yo...@gm...> wrote:

> Hello all. Thanks for the comments and suggestions. I am using the 64 bit
> version of WSJT-x 2.7.0 b4f9a4 on a Windows 10 machine. I have tried both
> auto Baud rate and a fixed baud rate on the radio. Today's attempt was from
> a fresh reboot and WSJT-x was ran before Ham Radio Deluxe or any other
> program that uses the CI-v protocol to talk to the radios. I am able to
> control my Icom 706mk2g with WSJT-x and the same interface but not my
> IC-910.
>
> After noting the failures here, I closed WSJT-x and opened Ham Radio
> Deluxe, It connects to my IC-910 no problem.
>
> I have attached part of my syslog from today's attempt to use the Icom
> 910. One thing I've noticed is that the errors mention both the IC7300 and
> IC9700:
>
> Command rejected by the rig
> [SYSLOG][2025-07-19 16:00:35.121753][00:00:24.063441][error]
> handle_transceiver_failure: reason: Hamlib error:
> **2:ic7300.c(2390):ic9700_set_vfo returning(-9) Command rejected by the rig
>
> Command rejected by the rig
>
> Thanks for any suggestions. 73
>
> Kyle
> K0KN
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_-7299603936670984440_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sat, Jul 19, 2025 at 2:27 AM Peter Sumner via wsjt-devel <
> wsj...@li...> wrote:
>
>> Hi Kyle,
>>  seems odd for Hamlib to throw an error for a 910 connection, I use it
>> every week in MSK144 skeds without ever seeing an error (i know that does
>> not help you). To check I just updated HAMLIB too, I now have 4.7~git
>> 2025-07-15T in use and that works well too.
>>
>> Are you on Windows X64 or a 32bit version?
>>
>> Can you try a reboot and NOT open HRD before you try WSJT-X to see if it
>> works?
>>
>> Hope you find an answer soon.
>> Peter, VK5PJ
>>
>> On Sat, Jul 19, 2025 at 8:27 AM Kyle Y via wsjt-devel <
>> wsj...@li...> wrote:
>>
>>> [image: image.png]
>>>
>>> Hello,
>>>
>>> I am having trouble using WSJT-x version 2.7.0 with my Icom IC-910.
>>>
>>> I can connect via Ham Radio Deluxe but attempting to connect directly
>>> gives me the following error. Looks like maybe WSJT-x is using the IC-9700
>>> radio info instead of the IC-910. See attached. I updated Hamlib within
>>> WSJT-x to the latest version 4.7~git 2025-0710
>>>
>>> Thanks. 73
>>>
>>> Kyle
>>> K0KN
>>>
>>>
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>> Virus-free.www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>> <#m_-7299603936670984440_m_-3255328679627688007_m_2584336365070807127_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsj...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>

Re: [wsjt-devel] Q65 Pileup Feature Request

[Lance C. W. <w7...@bi...>]

Thanks everyone for all the information. It appears that the only way to 
implement this feature would be to do a second decode with the inverse 
of the timing sequence, the way Joe did with JT65. That sure would be a 
great feature for Q65 Pileup!!!  TNX and VY 73, Lance

On 19 Aug 2025 22:11, Lance Collister, W7GJ wrote:
> Hi Reino,
>
> MNI TNX for the background. No, we need the grid for the contact 
> exchange. So the message would have to be TX2 PLUS some other 
> indicator such as a hyphen (-) between the calls and the grid. I was 
> hoping this could be done instead of the R, but I understand that 
> apparently there is not enough available bits to send - instead of R 
> 🙁  It is only valuable to know if a trace was copied (yellow spike 
> received) during the immediately preceding sequence...
>
> VY 73, Lance
>
> On 19 Aug 2025 21:07, Reino Talarmo wrote:
>> Lance Collister, W7GJ, Tuesday, August 19, 2025 8:25 AM wrote
>>> I thought
>>> that there might be room for this information the way the R
>>> report is inserted in TX3. I wonder if the program could
>>> automatically send a message in place of TX2, but similar to
>>> TX2 except with some other character (perhaps just a dash
>>> instead of a space) to indicate that the station copied a
>>> yellow spike during the receive cycle immediately
>>> preceding their transmit cycle.
>> Hello Lance and Charlie,
>>
>> Unfortunately, that message or all standard messages support the 'R' 
>> using a single bit and there is no easy way to add another bit for 
>> that message. On the other hand, the field that conveys the report, 
>> grid or any of 'RRR', 'RR73', '73' and 'space' have available some 
>> unused bit combinations.
>> If the grid is important for the QSO one possibility is to allocate a 
>> value that is presented to the user as '*' or any text. That new 
>> message could indicate that the station has *not* received the yellow 
>> spike in the immediately preceding slot. Or we could have even more 
>> values:
>> 'BLIND ONLY', 'THREE OR MORE CYCLES AGO', TWO CYCLES AGO' and 'ONE 
>> CYCLE AGO' or something similar. The previous cycle would be 
>> indicated by the use of the grid i.e. normal Tx2.
>>
>> That method may not be best. if you need the grid value in the list 
>> for any transmission or reception purposes. In the case EME it may 
>> not be so important as it will be there once you want to contact that 
>> station.
>>
>> Whatever it is a program update, I leave it to the designers.
>>
>> 73, Reino OH3mA
>>
>>
-- 
Lance Collister, W7GJ (ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!

Re: [wsjt-devel] Q65 Pileup Feature Request

[Lance C. W. <w7...@bi...>]

Hi Reino,

MNI TNX for the background. No, we need the grid for the contact 
exchange. So the message would have to be TX2 PLUS some other indicator 
such as a hyphen (-) between the calls and the grid. I was hoping this 
could be done instead of the R, but I understand that apparently there 
is not enough available bits to send - instead of R 🙁  It is only 
valuable to know if a trace was copied (yellow spike received) during 
the immediately preceding sequence...

VY 73, Lance

On 19 Aug 2025 21:07, Reino Talarmo wrote:
> Lance Collister, W7GJ, Tuesday, August 19, 2025 8:25 AM wrote
>> I thought
>> that there might be room for this information the way the R
>> report is inserted in TX3. I wonder if the program could
>> automatically send a message in place of TX2, but similar to
>> TX2 except with some other character (perhaps just a dash
>> instead of a space) to indicate that the station copied a
>> yellow spike during the receive cycle immediately
>> preceding their transmit cycle.
> Hello Lance and Charlie,
>
> Unfortunately, that message or all standard messages support the 'R' using a single bit and there is no easy way to add another bit for that message. On the other hand, the field that conveys the report, grid or any of 'RRR', 'RR73', '73' and 'space' have available some unused bit combinations.
> If the grid is important for the QSO one possibility is to allocate a value that is presented to the user as '*' or any text. That new message could indicate that the station has *not* received the yellow spike in the immediately preceding slot. Or we could have even more values:
> 'BLIND ONLY', 'THREE OR MORE CYCLES AGO', TWO CYCLES AGO' and 'ONE CYCLE AGO' or something similar. The previous cycle would be indicated by the use of the grid i.e. normal Tx2.
>
> That method may not be best. if you need the grid value in the list for any transmission or reception purposes. In the case EME it may not be so important as it will be there once you want to contact that station.
>
> Whatever it is a program update, I leave it to the designers.
>
> 73, Reino OH3mA
>
>
-- 
Lance Collister, W7GJ (ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!

Re: [wsjt-devel] Q65 Pileup Feature Request

[Reino T. <rei...@ko...>]

Lance Collister, W7GJ, Tuesday, August 19, 2025 8:25 AM wrote
> I thought
> that there might be room for this information the way the R
> report is inserted in TX3. I wonder if the program could
> automatically send a message in place of TX2, but similar to
> TX2 except with some other character (perhaps just a dash
> instead of a space) to indicate that the station copied a
> yellow spike during the receive cycle immediately
> preceding their transmit cycle.

Hello Lance and Charlie,

Unfortunately, that message or all standard messages support the 'R' using a single bit and there is no easy way to add another bit for that message. On the other hand, the field that conveys the report, grid or any of 'RRR', 'RR73', '73' and 'space' have available some unused bit combinations. 
If the grid is important for the QSO one possibility is to allocate a value that is presented to the user as '*' or any text. That new message could indicate that the station has *not* received the yellow spike in the immediately preceding slot. Or we could have even more values:
'BLIND ONLY', 'THREE OR MORE CYCLES AGO', TWO CYCLES AGO' and 'ONE CYCLE AGO' or something similar. The previous cycle would be indicated by the use of the grid i.e. normal Tx2. 

That method may not be best. if you need the grid value in the list for any transmission or reception purposes. In the case EME it may not be so important as it will be there once you want to contact that station.

Whatever it is a program update, I leave it to the designers.

73, Reino OH3mA