Re: Hamlib 4.0 in experimental
hi there,
On Sat, Jan 02, 2021 at 02:07:10PM +0100, Christoph Berg wrote:
> [Moving to debian-hams]
>
> Re: Ervin Hegedüs
> > as I know the sources (which uses Hamlib) don't need any patch,
> > the functions are same - but there are so many constans had
> > changed. Eg. all RIG models got an extra digit, eg. my rig is a
> > TS850, that was the 209, not it's 2009. K3 was 229, not it's
> > 2029.
>
> My IC706 moved from 309 to 3009...
>
> We should probably put a NEWS.Debian item about that somewhere, but I
> have no idea where to put it as libhamlib4 is new, and libhamlib2
> (where it would make sense) is gone.
I also don't have any idea - I'll try to check the available
solutions.
> I rebuilt everything and there were little problems:
>
> > So, the rebuild is need, but patch not required.
> >
> > > Reverse Depends:
> > > xlog,libhamlib2
> > > wsjtx,libhamlib2 3.1
>
> wsjtx works when talking directly to the rig, but has problems talking
> to rigctld ("Hamlib error: Invalid parameter while exchanging VFOs")
I don't use wsjtx, so I can't help this,
> > > tucnak,libhamlib2
> > > tlf,libhamlib2
>
> "multiple definitions" is a gcc-9 change, a workaround is -fno-common.
> (Or of course better, fix the duplicated definitions of global
> variables.)
I'll check out this soon.
> > > js8call,libhamlib2 3.1
>
> js8call already has a switch for hamlib3/4 compatibility, it just
> needs flipping (or rather removing) in debian/rules.
same as wsjtx...
> > > cqrlog,libhamlib2 1.2.10
>
> That's a weird one, written in freepascal and opening libhamlib.so via
> dlopen. I upgraded libhamlib2 to libhamlib2 in debian/control and it
> compiles and runs, but I didn't test it long enough to have it
> actually talk to my rig. (I wonder if it doesn't actually need a
> *runtime* dependency on the -dev package since it seems to look for
> libhamlib.so, but if that is a problem, it's already broken now.)
I don't follow CQRLog, but what as I remember there are few
problems with that.
> > > grig,libhamlib2
>
> grig has problems:
>
> rig-daemon.c: In function ‘rig_daemon_exec_cmd’:
> rig-daemon.c:1677:56: error: ‘freq_range_t’ {aka ‘struct freq_range_list’} has no member named ‘start’; did you mean ‘startf’?
> 1677 | (get->freq1 >= myrig->state.rx_range_list[i].start) &&
> | ^~~~~
> | startf
> ... and more.
I'll check that too.
> Afaict grig is totally dead upstream so it's probably time to remove
> it.
yeah, may be... but there isn't so much alternatives. May be
Flrig?
Any idea?
> > > fldigi,libhamlib2
>
> Fldigi works.
have you checked with Hamlib? As I know Fldigi uses own
implementations for CAT control, you have to choose the hamlib
explicit.
> > > direwolf,libhamlib2
> > > cubicsdr,libhamlib2
> > >
> > > (15 packages, not too bad)
> >
> > yeah, it's not so much.
> >
> > Just let me know if I can help you anything!
>
> Testing packages with the libhamlib4 from experimental would be nice.
on my SID systems I don't have any X-window system and most of
them aren't used here. But I'll try to check few of them.
73, Ervin
HA2OS
Reply to: