On Sat, Nov 13, 2021 at 12:49:11PM +0100, Christoph Berg wrote:
> 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.
Building against hamlib 4.0 (clean bullseye chroot) fails with errors
like this:
/<<PKGBUILDDIR>>/Transceiver/HamlibTransceiver.cpp:60:66: error:
‘RIG_CAPS_MFG_NAME_CPTR’ was not declared in this scope
60 | key = QString::fromLatin1 (rig_get_caps_cptr (rig_model,
RIG_CAPS_MFG_NAME_CPTR)).trimmed ()
|
^~~~~~~~~~~~~~~~~~~~~~
There are 51 errors in total.
> 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).
In that case, it sounds like the next step is try to backport to wsjtx
2.5.x to hamlib 4.0.
Cheers,
tony
