Re: [wsjt-devel] Polling hamlib when flrig is being used?

[Bill S. <g4...@cl...>]

On 26/03/2020 12:27, Richard Shaw wrote:
> On Thu, Mar 26, 2020 at 7:20 AM Bill Somerville <g4...@cl... 
> <mailto:g4...@cl...>> wrote:
>
>     Hi Mike and Richard,
>
>     that message was added in Hamlib commit 6fbe4a5f which means it
>     was used from WSJT-X v1.7.0. It was removed in commit 7062b67
>     which means it was no longer in WSJT-X from v2.0.1 onwards.
>
>     Unless this is in a pre-v2.0.1 WSJT-X version it must be a custom
>     build of WSJT-X not using the recommended Hamlib version, probably
>     some distribution's default Hamlib build which may be ancient.
>
>     The message is benign but we do not support WSJT-X built with
>     arbitrary versions of Hamlib, this will be particularly true for
>     the next release given that there have been a lot of changes in
>     Hamlib recently.
>
>
> As I'm one of the maintainers of wsjtx for Fedora I'm painfully aware 
> it likes git checkouts but distributions like releases, so I wouldn't 
> call it "arbitrary", it's the latest released version, just like I'm 
> running the latest "released" version of wsjtx.
>
> The fact there is 1240 commits[1] since 3.3 was released emphasizes my 
> point.
>
> Thanks,
> Richard
> KF5OIM
>
> [1] https://github.com/Hamlib/Hamlib/releases

Hi Richard,

the Hamlib sources used with WSJT-X releases are well defined, in fact 
they are bundled in the official source tarball that package maintainers 
should be using as a starting point. They are not just an arbitrary 
commit, each WSJT-X release is paired with tagged Hamlib sources. These 
tags are in my Hamlib fork:

https://sourceforge.net/u/bsomervi/hamlib/ref/master/tags/

and I make every effort to ensure that those tags track the Hamlib 
official master branch, if not then any changes present will be 
submitted to the Hamlib team for merge.

We wish to support as many rigs as possible and Hamlib helps greatly 
with that, but new rigs appear rather faster than Hamlib releases so 
sticking to official Hamlib releases who disappoint a lot of users with 
shiny new gear. Using a fork of Hamlib paired with WSJT-X releases 
allows us a bit more flexibility with this, but I fully understand some 
Linux distributions baulk at forked code for package releases. All I can 
say is that I think that type of restriction is wise with dynamically 
linked libraries, but with static linking there are no real issues since 
the forked content is fully encapsulated within the package using it.

73
Bill
G4WJS.