[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#999470: wsjtx: Stable backport wsjt-x 2.5.2



Re: tony mancill
> > It would be great if you could make a backport of wsjtx 2.5.2 for bullseye.
> 
> The backport of wsjtx appears to be trivial once hamlib 4.1 or newer is
> available in bullseye, and that backport looks relatively simple too.
> 
> Looking at hamlib, I see that the backport of hamlib 4.3 includes
> libhamlib4, which declares "Breaks: wsjtx (<< 2.4.0~)".  This might be a
> little interesting for users who expect hamlib to remain at version 4.0
> for other reasons (although I don't know what those would be), since the
> upgrade will require hamlib and wsjtx to update at the same time.
> 
> Any thoughts or concerns from others on the team about proceeding with
> hamlib and wsjtx for bullseye-backports?

I'm not 100% sure, but I think I added that Breaks to make sure wsjtx
is upgraded if hamlib is upgraded. wsjtx in either version should work
fine with hamlib in either version, but the version at compile time
needs to be the same at run time.

So the wsjtx backport is likely just wsjtx, without hamlib. Testing
that just requires starting it up and checking if it can talk to your
TRX properly.

Hamlib doesn't seem as compatible as the no-soname-change suggests, I
also had to recompile fldigi to have it work with Hamlib 4.3 here (at
least via rigctld).

Christoph


Reply to: