hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Greg T. <gd...@le...>]

Nate Bargmann <n0...@n0...> writes:

> As another data point we have PR 2008:
>
> https://github.com/Hamlib/Hamlib/pull/2008
>
> Mike clearly notes the use of Code QL to diagnose and offer a fix for
> using the return value of sscanf() correctly in the Codan backend.  A
> disclosure  regarding the use of AI is clearly stated in the commit
> message.
>
> As I see it, this is a useful use of LLM where our code base is examined
> and fixes offered in terms of C language best practices.

It was a useful fix, but the PR is full of LLM text that should have
been replaced by what a human would have written.  I have commented in
the PR.

(and +1 for getting off github, but I know it's hard; haven't done it
yet for the the project I maintain)

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Nate B. <n0...@n0...>]

As another data point we have PR 2008:

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

Mike clearly notes the use of Code QL to diagnose and offer a fix for
using the return value of sscanf() correctly in the Codan backend.  A
disclosure  regarding the use of AI is clearly stated in the commit
message.

As I see it, this is a useful use of LLM where our code base is examined
and fixes offered in terms of C language best practices.

On a related note.

Perhaps this deserves a thread of its own.  The Software Freedom
Conservancy is engaged in an effort to inform projects/developers of the
proprietary nature of GitHub:

https://sfconservancy.org/GiveUpGitHub/

Do note that I've no plans to change anything regarding the project
hosting sites in the near future, but I do think this does bear
watching.  Up to this point, the points outlined by SFC have not
impacted Hamlib negatively.  In fact, I think our presence on GitHub has
been quite positive for the project.  Of course, all things come to an
end eventually...

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] Rig control error from WSJT-X with new IC-7300MK2

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

Use the 4.7 version; it has a IC-7300MK2 specific rig type.  You could 
probably get the MK2 to work(mostly) by changing the default CI-V 
address with the -C option on older versions of Hamlib, but there are 
other differences in the commands between the two rigs.

73 n3gb

On 3/8/26 4:41 PM, Steve Ruedinger wrote:
>
> Greetings,
>
> I just received my new IC-7300MK2 and I’m trying to set it up for FT8 
> with WSJT-X version 2.7.
>
> I’m getting a persistent Rig Control Error, the details of the error 
> are below. I have tried libhamlib-4.dll version 4.6.1 and 4.7.0 with 
> the same results.
>
> Hamlib error: read_string_generic(): Timed out 2.040 seconds after 0 
> chars, direct=1
>
> ****4:frame.c(329):icom_one_transaction returning(-5) Communication 
> timed out
>
> Communication timed out
>
> Communication timed out
>
> ***3:frame.c(555):icom_transaction returning(-5) Communication timed out
>
> **2:icom.c(833):icom_get_usb_echo_off returning(-5) Communication 
> timed out
>
> icom_rig_open: echo status result=-5
>
> icom_rig_open: Unable to determine Icom echo status -- is rig on and 
> connected?
>
> *1:icom.c(1193):icom_rig_open returning(-5) Communication timed out
>
> ser_close: restoring options
>
> rig.c(1559):rig_open returning2(-5) Communication timed out
>
> Communication timed out
>
> Communication timed out
>
> while opening connection to rig
>
> Timestamp: 2026-03-08T20:20:05.834Z
>
> The radio is running firmware version 1.02 which seems to be the 
> latest version for the IC-7300MK2. I have installed the latest USB 
> drivers from the ICOM website which is version 1.70.
>
> I have selected IC-7300 in the radio settings tab in WSJT-X as there 
> is no listing for the IC-7300MK2.
>
> Radio configuration in WSJT-X is:
>
> RIG: Icom IC-7300
>
> Serial port: Com3
>
> Baud rate: 19200, I have also tried 9600
>
> Data Bits: 8
>
> Stop Bits: 1
>
> Handshake: None
>
> PTT Method: CAT
>
> Mode: Data/pkt
>
> Split Operation: Rig
>
> WSJT-X will receive and decode messages if I manually select a band. 
> It will continue to decode messages even after I get the rig control 
> error.
>
> Please let me know what I should do next.
>
> Thank you,
>
> Steve Ruedinger KG8OM
>
> 73
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] Rig control error from WSJT-X with new IC-7300MK2

[Steve R. <ste...@ch...>]

Greetings,

 

I just received my new IC-7300MK2 and I'm trying to set it up for FT8 with
WSJT-X version 2.7.

 

I'm getting a persistent Rig Control Error, the details of the error are
below. I have tried libhamlib-4.dll version 4.6.1 and 4.7.0 with the same
results.

 

Hamlib error: read_string_generic(): Timed out 2.040 seconds after 0 chars,
direct=1

****4:frame.c(329):icom_one_transaction returning(-5) Communication timed
out

 

Communication timed out

 

Communication timed out

 

***3:frame.c(555):icom_transaction returning(-5) Communication timed out

 

**2:icom.c(833):icom_get_usb_echo_off returning(-5) Communication timed out

 

icom_rig_open: echo status result=-5

icom_rig_open: Unable to determine Icom echo status -- is rig on and
connected?

*1:icom.c(1193):icom_rig_open returning(-5) Communication timed out

 

ser_close: restoring options

rig.c(1559):rig_open returning2(-5) Communication timed out

 

Communication timed out

Communication timed out

while opening connection to rig

 

Timestamp: 2026-03-08T20:20:05.834Z

 

 

The radio is running firmware version 1.02 which seems to be the latest
version for the IC-7300MK2. I have installed the latest USB drivers from the
ICOM website which is version 1.70.

 

I have selected IC-7300 in the radio settings tab in WSJT-X as there is no
listing for the IC-7300MK2.

 

Radio configuration in WSJT-X is:

 

RIG: Icom IC-7300

Serial port: Com3

Baud rate: 19200, I have also tried 9600

Data Bits: 8

Stop Bits: 1

Handshake: None

PTT Method: CAT

Mode: Data/pkt

Split Operation: Rig

 

WSJT-X will receive and decode messages if I manually select a band. It will
continue to decode messages even after I get the rig control error.

 

Please let me know what I should do next.

 

Thank you,

 

Steve Ruedinger KG8OM

 

73

 

 

[Hamlib-developer] [Hamlib/Hamlib] c25de9: Add support text from release email to RelNotes

[Nate B. <no...@gi...>]

  Branch: refs/heads/Hamlib-4.7
  Home:   https://github.com/Hamlib/Hamlib
  Commit: c25de9aafa033294c89c7d2c1707394401a70eef
      https://github.com/Hamlib/Hamlib/commit/c25de9aafa033294c89c7d2c1707394401a70eef
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-08 (Sun, 08 Mar 2026)

  Changed paths:
    M ReleaseNotes_4.7.md

  Log Message:
  -----------
  Add support text from release email to RelNotes

(cherry picked from commit f233d8a80079cb3aae752969d6c8ed33cbf48fb6)


  Commit: 0c82864ee0696f0a84ddd9c8838e8340ac318b82
      https://github.com/Hamlib/Hamlib/commit/0c82864ee0696f0a84ddd9c8838e8340ac318b82
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-08 (Sun, 08 Mar 2026)

  Changed paths:
    M Makefile.am

  Log Message:
  -----------
  Include Release Notes in tarball

Documentation isn't much good if nobody can see it. My bad.

(cherry picked from commit 2e0bc40c58ecb84cb65993b7be8b2bbb8eb2a17f)


  Commit: cca5d88b2b63bb11366e4e9e7e2715496fa28abd
      https://github.com/Hamlib/Hamlib/commit/cca5d88b2b63bb11366e4e9e7e2715496fa28abd
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-03-08 (Sun, 08 Mar 2026)

  Changed paths:
    M ReleaseNotes_5.0.md

  Log Message:
  -----------
  Rel notes update

(cherry picked from commit 9268dc7d80e96726b53ccb56d6ae91bf75ea713b)


  Commit: f2a104093bdaad1f2a0c5fb69aa125208636bed5
      https://github.com/Hamlib/Hamlib/commit/f2a104093bdaad1f2a0c5fb69aa125208636bed5
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-03-08 (Sun, 08 Mar 2026)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  Update NEWS for updated ReleaseNotes*.md


Compare: https://github.com/Hamlib/Hamlib/compare/d4cf00e14dc4...f2a104093bda

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] f233d8: Add support text from release email to RelNotes

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: f233d8a80079cb3aae752969d6c8ed33cbf48fb6
      https://github.com/Hamlib/Hamlib/commit/f233d8a80079cb3aae752969d6c8ed33cbf48fb6
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-28 (Sat, 28 Feb 2026)

  Changed paths:
    M ReleaseNotes_4.7.md

  Log Message:
  -----------
  Add support text from release email to RelNotes


  Commit: 2e0bc40c58ecb84cb65993b7be8b2bbb8eb2a17f
      https://github.com/Hamlib/Hamlib/commit/2e0bc40c58ecb84cb65993b7be8b2bbb8eb2a17f
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-28 (Sat, 28 Feb 2026)

  Changed paths:
    M Makefile.am

  Log Message:
  -----------
  Include Release Notes in tarball

Documentation isn't much good if nobody can see it. My bad.


  Commit: 9268dc7d80e96726b53ccb56d6ae91bf75ea713b
      https://github.com/Hamlib/Hamlib/commit/9268dc7d80e96726b53ccb56d6ae91bf75ea713b
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-28 (Sat, 28 Feb 2026)

  Changed paths:
    M ReleaseNotes_5.0.md

  Log Message:
  -----------
  Rel notes update


  Commit: ee949587d61b4d6fe1f6fe29b268ea66b830da9b
      https://github.com/Hamlib/Hamlib/commit/ee949587d61b4d6fe1f6fe29b268ea66b830da9b
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-03-08 (Sun, 08 Mar 2026)

  Changed paths:
    M Makefile.am
    M ReleaseNotes_4.7.md
    M ReleaseNotes_5.0.md

  Log Message:
  -----------
  Merge GitHub PR #2005


Compare: https://github.com/Hamlib/Hamlib/compare/0c061d5b2ede...ee949587d61b

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Hamlib/Hamlib] 0fc895: Use heap storage for all rig ports

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 0fc8954a093c77fdc8feef359495669470b0fef5
      https://github.com/Hamlib/Hamlib/commit/0fc8954a093c77fdc8feef359495669470b0fef5
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M include/hamlib/rig.h
    M src/rig.c

  Log Message:
  -----------
  Use heap storage for all rig ports

Allocates and frees buffers for CAT, PTT, and DCD.
Does *NOT* copy anything from STATE(rig)->rigport, so only works if
a) app uses rig_set_conf()   or
b) app uses HAMLIB_...() macros


  Commit: 1945e8db33bf5b0a83594014316ad19624b9c3a0
      https://github.com/Hamlib/Hamlib/commit/1945e8db33bf5b0a83594014316ad19624b9c3a0
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M src/conf.c
    M src/rig.c
    M tests/rigctl.c
    M tests/rigctld.c
    M tests/rigctltcp.c

  Log Message:
  -----------
  Remove all code references to (rig|ptt|dcd)port_deprecated.

The structures are no longer read or written.


  Commit: a475d697aab73cfa660ac5e2f227ebbe0ab799a6
      https://github.com/Hamlib/Hamlib/commit/a475d697aab73cfa660ac5e2f227ebbe0ab799a6
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M bindings/ignore.swg
    M include/hamlib/rig_state.h

  Log Message:
  -----------
  Deprecate ports in rig_state struct

Mark all ports in struct rig_state as deprecated.
Remove them from the bindings.


  Commit: 02ea4af57201b21db8d54b3aa3a176b4c8730baf
      https://github.com/Hamlib/Hamlib/commit/02ea4af57201b21db8d54b3aa3a176b4c8730baf
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M include/hamlib/rig.h
    M include/hamlib/rig_state.h
    M rigs/dummy/rot_pstrotator.c
    M src/rig.c
    M tests/rotctl_parse.c

  Log Message:
  -----------
  Move rig_state to heap storage.

Allocate and free it.
For access apps must
1) #include <hamlib/rig_state.h>  and
2) Use HAMLIB_STATE(rig) to get the address

Also fix a couple of misuses of STATE() macro.


  Commit: bdf70503c118e45589038d083b81abe48cb364f3
      https://github.com/Hamlib/Hamlib/commit/bdf70503c118e45589038d083b81abe48cb364f3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M src/rig.c

  Log Message:
  -----------
  Remove references to rig_state_deprecated.


  Commit: ba3c5624b60defbdb03f99f56b0d092c42cea936
      https://github.com/Hamlib/Hamlib/commit/ba3c5624b60defbdb03f99f56b0d092c42cea936
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M tests/ampctl.c

  Log Message:
  -----------
  Remove deprecated port references from ampctl.c

As a stand-alone program, ampctl has no need for that data.


  Commit: 1cabf8ccf21c4e247fa658b6351e754fbaff3c26
      https://github.com/Hamlib/Hamlib/commit/1cabf8ccf21c4e247fa658b6351e754fbaff3c26
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M src/amp_conf.c
    M src/amplifier.c
    M src/rot_conf.c
    M src/rotator.c

  Log Message:
  -----------
  Stop updating data in deprecated structures

They go away with 5.0


  Commit: 4b42f98078aed7c9eb446eed63f3466f10656fc3
      https://github.com/Hamlib/Hamlib/commit/4b42f98078aed7c9eb446eed63f3466f10656fc3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M include/hamlib/amp_state.h
    M include/hamlib/port.h
    M include/hamlib/rig.h
    M include/hamlib/rig_state.h
    M include/hamlib/rot_state.h

  Log Message:
  -----------
  Mark and #ifndef old structures that will disappear

Prepare for deprecation and removal of old embedded structures.

Note that the parameters NO_OLD_STRUCTS and NO_OLD_INCLUDES are
  temporary, and will be removed before 5.0 is released.  They are
  for test compiles to work through the codebase incrementally, so
  no compiler errors/warnings are generated by any committed/merged
  code during default builds.


  Commit: b01914aa3cdc1232ccbf8be2e8612e55afaedb12
      https://github.com/Hamlib/Hamlib/commit/b01914aa3cdc1232ccbf8be2e8612e55afaedb12
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M bindings/ignore.swg
    M include/hamlib/rig.h

  Log Message:
  -----------
  Mark some data as private and not safe for applications

The pointers may move, or the method to get the address may change.


  Commit: 2b3bb97dbf0a0e6825756da6c9ba4d0ae23c87b3
      https://github.com/Hamlib/Hamlib/commit/2b3bb97dbf0a0e6825756da6c9ba4d0ae23c87b3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M bindings/ignore.swg
    M include/hamlib/rig.h
    M include/hamlib/rot_state.h
    M include/hamlib/rotator.h
    M src/rotator.c

  Log Message:
  -----------
  Convert rotators to heap storage

Just like the rigs


  Commit: 7a1a0d35ec6267a1806d337b6a439100a4b2a681
      https://github.com/Hamlib/Hamlib/commit/7a1a0d35ec6267a1806d337b6a439100a4b2a681
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M bindings/ignore.swg
    M include/hamlib/amp_state.h
    M include/hamlib/amplifier.h
    M include/hamlib/rig.h
    M src/amplifier.c

  Log Message:
  -----------
  And finally, the amplifiers

Resolve conflicts with new amp code/
Why move the ampport, rather than adding stuff after it???


  Commit: 8137485f917d185da8614c29fb41fab27da0a3fe
      https://github.com/Hamlib/Hamlib/commit/8137485f917d185da8614c29fb41fab27da0a3fe
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M include/hamlib/rig_state.h
    M rigs/adat/adat.c
    M rigs/aor/aor.c
    M rigs/aor/ar3030.c
    M rigs/aor/ar7030p.c
    M rigs/aor/ar7030p.h
    M rigs/aor/sr2200.c
    M rigs/barrett/barrett.h
    M rigs/codan/codan.c
    M rigs/dorji/dra818.c
    M rigs/drake/drake.c
    M rigs/dummy/aclog.c
    M rigs/dummy/amp_dummy.c
    M rigs/dummy/dummy.c
    M rigs/dummy/flrig.c
    M rigs/dummy/gqrx.c
    M rigs/dummy/netrigctl.c
    M rigs/dummy/netrotctl.c
    M rigs/dummy/quisk.c
    M rigs/dummy/rot_dummy.c
    M rigs/dummy/rot_pstrotator.c
    M rigs/dummy/sdrsharp.c
    M rigs/dummy/tci1x.c
    M rigs/dummy/trxmanager.c

  Log Message:
  -----------
  Start adding needed(smaller) #includes

Compile with both NO_OLD_INCLUDES and NO_OLD_STRUCTS and
  repair the fallout. So far we're down to rigs/dummy/.

And fix formatting in rig_state.h


  Commit: 8132ec7b5b5ab48fc94dbcfcb4da8d3c7d49baf3
      https://github.com/Hamlib/Hamlib/commit/8132ec7b5b5ab48fc94dbcfcb4da8d3c7d49baf3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M rigs/elad/elad.c
    M rigs/flexradio/dttsp.c
    M rigs/flexradio/sdr1k.c
    M rigs/flexradio/smartsdr.c
    M rigs/icmarine/icm710.c
    M rigs/icmarine/icmarine.c
    M rigs/icom/frame.c
    M rigs/icom/icom.c
    M rigs/icom/icom.h
    M rigs/icom/optoscan.c
    M rigs/jrc/jrc.c
    M rigs/jrc/jst145.c
    M rigs/kenwood/kenwood.h
    M rigs/kenwood/ts450s.c
    M rigs/kenwood/xg3.c
    M rigs/kit/dds60.c
    M rigs/kit/drt1.c
    M rigs/kit/dwt.c
    M rigs/kit/elektor304.c
    M rigs/kit/elektor507.c
    M rigs/kit/fifisdr.c
    M rigs/kit/funcube.c
    M rigs/kit/hiqsdr.c
    M rigs/kit/rs_hfiq.c
    M rigs/kit/si570avrusb.c
    M rigs/lowe/lowe.c
    M rigs/pcr/pcr.c
    M rigs/prm80/prm80.c
    M rigs/racal/ra37xx.c
    M rigs/racal/racal.c
    M rigs/rs/rs.c
    M rigs/skanti/trp8255.c
    M rigs/tentec/jupiter.c
    M rigs/tentec/omnivii.c
    M rigs/tentec/orion.c
    M rigs/tentec/paragon.c
    M rigs/tentec/rx331.c
    M rigs/tentec/tentec.c
    M rigs/tentec/tt550.c
    M rigs/tuner/v4l.c
    M rigs/tuner/v4l2.c
    M rigs/uniden/uniden.c
    M rigs/uniden/uniden_digital.c
    M rigs/wj/wj.c

  Log Message:
  -----------
  Add more required includes to rigs/*

This does through rigs/wj


  Commit: aee4f07674695e6a83bee6e93e0e8ac10289346a
      https://github.com/Hamlib/Hamlib/commit/aee4f07674695e6a83bee6e93e0e8ac10289346a
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M rigs/anytone/anytone.c
    M rigs/commradio/commradio.c
    M rigs/gomspace/gs100.c
    M rigs/guohetec/guohetec.c
    M rigs/guohetec/pmr171.c
    M rigs/guohetec/q900.c
    M rigs/mds/mds.c
    M rigs/motorola/micom.c
    M rigs/winradio/g313-posix.c
    M rigs/winradio/winradio.c
    M rigs/yaesu/ft100.c
    M rigs/yaesu/ft1000d.c
    M rigs/yaesu/ft1000mp.c
    M rigs/yaesu/ft3000.c
    M rigs/yaesu/ft600.c
    M rigs/yaesu/ft736.c
    M rigs/yaesu/ft747.c
    M rigs/yaesu/ft757gx.c
    M rigs/yaesu/ft767gx.c
    M rigs/yaesu/ft817.c
    M rigs/yaesu/ft840.c
    M rigs/yaesu/ft847.c
    M rigs/yaesu/ft857.c
    M rigs/yaesu/ft890.c
    M rigs/yaesu/ft891.c
    M rigs/yaesu/ft897.c
    M rigs/yaesu/ft900.c
    M rigs/yaesu/ft920.c
    M rigs/yaesu/ft980.c
    M rigs/yaesu/ft990.c
    M rigs/yaesu/ft990v12.c
    M rigs/yaesu/ft991.c
    M rigs/yaesu/ftx1/ftx1.h
    M rigs/yaesu/ftx1/ftx1_cw.c
    M rigs/yaesu/ftx1/ftx1_freq.c
    M rigs/yaesu/ftx1/ftx1_preamp.c
    M rigs/yaesu/newcat.c
    M rigs/yaesu/vr5000.c
    M rigs/yaesu/vx1700.c
    M rigs/yaesu/yaesu.c
    M rotators/ioptron/rot_ioptron.c

  Log Message:
  -----------
  Finish add includes in rigs/ and rotators/


  Commit: 29c4ec4778fb54faef335d17db4c53d49cfb34d6
      https://github.com/Hamlib/Hamlib/commit/29c4ec4778fb54faef335d17db4c53d49cfb34d6
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M src/cm108.c
    M src/misc.c
    M tests/ampctl.c
    M tests/ampctl_parse.c
    M tests/ampctld.c
    M tests/dumpcaps_rot.c
    M tests/memcsv.c
    M tests/rig_tests.c
    M tests/rigctl.c
    M tests/rigctl_parse.c
    M tests/rigctlcom.c
    M tests/rigctld.c
    M tests/rigctlsync.c
    M tests/rigctltcp.c
    M tests/rigmem.c
    M tests/rigsmtr.c
    M tests/rigswr.c
    M tests/rigtestmcast.c
    M tests/rotctl.c
    M tests/rotctl_parse.c
    M tests/rotctld.c

  Log Message:
  -----------
  Finish adding #include's for things moving out of rig.h

Clean compile & execution with both NO_OLD_INCLUDES and NO_OLD_STRUCTS
  defined.


  Commit: be6b0086eb7f551a98db40a59b15609c42d651cf
      https://github.com/Hamlib/Hamlib/commit/be6b0086eb7f551a98db40a59b15609c42d651cf
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M bindings/ignore.swg
    M include/hamlib/port.h
    M include/hamlib/rig.h

  Log Message:
  -----------
  Mark more deprecated stuff for exclusion and removal

Also mark the bindings that will no longer need to be ignored.


  Commit: 7fadc49ef771cf2c4217d76325a6ccf6980ba5e3
      https://github.com/Hamlib/Hamlib/commit/7fadc49ef771cf2c4217d76325a6ccf6980ba5e3
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M bindings/rig.swg
    M bindings/rotator.swg
    M c++/ampclass.cc
    M c++/rigclass.cc
    M c++/rotclass.cc

  Log Message:
  -----------
  Fix some straggling state references

Add includes to the bindings skeleton
  and repair a cut&paste error


  Commit: 97a005d52e7f9d7aeee2bb7ef01f747af1f4ef9e
      https://github.com/Hamlib/Hamlib/commit/97a005d52e7f9d7aeee2bb7ef01f747af1f4ef9e
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M bindings/ignore.swg
    M include/hamlib/amp_state.h
    M include/hamlib/amplifier.h
    M include/hamlib/port.h
    M include/hamlib/rig.h
    M include/hamlib/rig_state.h
    M include/hamlib/rot_state.h
    M include/hamlib/rotator.h

  Log Message:
  -----------
  The big cut - Remove all old embedded structures

Drop all fixed structures in RIG and state. Clean out old definitions,
  purge all references to same.

Undo the other conflicts in amp_state.h


  Commit: a96fbef780f3454a1032f566b469add93b24086a
      https://github.com/Hamlib/Hamlib/commit/a96fbef780f3454a1032f566b469add93b24086a
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M tests/cachetest.c
    M tests/cachetest2.c
    M tests/dumpmem.c
    M tests/rig_bench.c
    M tests/testfreq.c
    M tests/testrig.c

  Log Message:
  -----------
  Fix the fallout of the big cut

Add needed includes to the diddly programs in tests.
Makes `make distcheck` work.


  Commit: 8a55457869f99f7b04f3a6cfce22c705958ce31b
      https://github.com/Hamlib/Hamlib/commit/8a55457869f99f7b04f3a6cfce22c705958ce31b
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M NEWS
    M ReleaseNotes_5.0.md
    M include/hamlib/port.h
    M include/hamlib/rig_state.h

  Log Message:
  -----------
  Cleanup - update NEWS and comments


  Commit: 1b2461aba99f0dde0531e1732c00e60aeee40657
      https://github.com/Hamlib/Hamlib/commit/1b2461aba99f0dde0531e1732c00e60aeee40657
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-23 (Mon, 23 Feb 2026)

  Changed paths:
    M amplifiers/expert/expert.c
    M rigs/dummy/amp_dummy.c
    M src/amp_settings.c
    M src/amplifier.c
    M tests/ampctl_parse.c
    M tests/dumpcaps_amp.c

  Log Message:
  -----------
  Cope with new amplifier code

Replace obsolete usages (search&replace)
Add required includes


  Commit: 1223ba19e29cbe673f1445bd676957a4dad64aab
      https://github.com/Hamlib/Hamlib/commit/1223ba19e29cbe673f1445bd676957a4dad64aab
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2026-02-24 (Tue, 24 Feb 2026)

  Changed paths:
    M rotators/indi/indi_wrapper.hpp

  Log Message:
  -----------
  Try to build indi


  Commit: 0c061d5b2edeb77f81ba8aecfdc557849d69d5b3
      https://github.com/Hamlib/Hamlib/commit/0c061d5b2edeb77f81ba8aecfdc557849d69d5b3
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-03-08 (Sun, 08 Mar 2026)

  Changed paths:
    M NEWS
    M ReleaseNotes_5.0.md
    M amplifiers/expert/expert.c
    M bindings/ignore.swg
    M bindings/rig.swg
    M bindings/rotator.swg
    M c++/ampclass.cc
    M c++/rigclass.cc
    M c++/rotclass.cc
    M include/hamlib/amp_state.h
    M include/hamlib/amplifier.h
    M include/hamlib/port.h
    M include/hamlib/rig.h
    M include/hamlib/rig_state.h
    M include/hamlib/rot_state.h
    M include/hamlib/rotator.h
    M rigs/adat/adat.c
    M rigs/anytone/anytone.c
    M rigs/aor/aor.c
    M rigs/aor/ar3030.c
    M rigs/aor/ar7030p.c
    M rigs/aor/ar7030p.h
    M rigs/aor/sr2200.c
    M rigs/barrett/barrett.h
    M rigs/codan/codan.c
    M rigs/commradio/commradio.c
    M rigs/dorji/dra818.c
    M rigs/drake/drake.c
    M rigs/dummy/aclog.c
    M rigs/dummy/amp_dummy.c
    M rigs/dummy/dummy.c
    M rigs/dummy/flrig.c
    M rigs/dummy/gqrx.c
    M rigs/dummy/netrigctl.c
    M rigs/dummy/netrotctl.c
    M rigs/dummy/quisk.c
    M rigs/dummy/rot_dummy.c
    M rigs/dummy/rot_pstrotator.c
    M rigs/dummy/sdrsharp.c
    M rigs/dummy/tci1x.c
    M rigs/dummy/trxmanager.c
    M rigs/elad/elad.c
    M rigs/flexradio/dttsp.c
    M rigs/flexradio/sdr1k.c
    M rigs/flexradio/smartsdr.c
    M rigs/gomspace/gs100.c
    M rigs/guohetec/guohetec.c
    M rigs/guohetec/pmr171.c
    M rigs/guohetec/q900.c
    M rigs/icmarine/icm710.c
    M rigs/icmarine/icmarine.c
    M rigs/icom/frame.c
    M rigs/icom/icom.c
    M rigs/icom/icom.h
    M rigs/icom/optoscan.c
    M rigs/jrc/jrc.c
    M rigs/jrc/jst145.c
    M rigs/kenwood/kenwood.h
    M rigs/kenwood/ts450s.c
    M rigs/kenwood/xg3.c
    M rigs/kit/dds60.c
    M rigs/kit/drt1.c
    M rigs/kit/dwt.c
    M rigs/kit/elektor304.c
    M rigs/kit/elektor507.c
    M rigs/kit/fifisdr.c
    M rigs/kit/funcube.c
    M rigs/kit/hiqsdr.c
    M rigs/kit/rs_hfiq.c
    M rigs/kit/si570avrusb.c
    M rigs/lowe/lowe.c
    M rigs/mds/mds.c
    M rigs/motorola/micom.c
    M rigs/pcr/pcr.c
    M rigs/prm80/prm80.c
    M rigs/racal/ra37xx.c
    M rigs/racal/racal.c
    M rigs/rs/rs.c
    M rigs/skanti/trp8255.c
    M rigs/tentec/jupiter.c
    M rigs/tentec/omnivii.c
    M rigs/tentec/orion.c
    M rigs/tentec/paragon.c
    M rigs/tentec/rx331.c
    M rigs/tentec/tentec.c
    M rigs/tentec/tt550.c
    M rigs/tuner/v4l.c
    M rigs/tuner/v4l2.c
    M rigs/uniden/uniden.c
    M rigs/uniden/uniden_digital.c
    M rigs/winradio/g313-posix.c
    M rigs/winradio/winradio.c
    M rigs/wj/wj.c
    M rigs/yaesu/ft100.c
    M rigs/yaesu/ft1000d.c
    M rigs/yaesu/ft1000mp.c
    M rigs/yaesu/ft3000.c
    M rigs/yaesu/ft600.c
    M rigs/yaesu/ft736.c
    M rigs/yaesu/ft747.c
    M rigs/yaesu/ft757gx.c
    M rigs/yaesu/ft767gx.c
    M rigs/yaesu/ft817.c
    M rigs/yaesu/ft840.c
    M rigs/yaesu/ft847.c
    M rigs/yaesu/ft857.c
    M rigs/yaesu/ft890.c
    M rigs/yaesu/ft891.c
    M rigs/yaesu/ft897.c
    M rigs/yaesu/ft900.c
    M rigs/yaesu/ft920.c
    M rigs/yaesu/ft980.c
    M rigs/yaesu/ft990.c
    M rigs/yaesu/ft990v12.c
    M rigs/yaesu/ft991.c
    M rigs/yaesu/ftx1/ftx1.h
    M rigs/yaesu/ftx1/ftx1_cw.c
    M rigs/yaesu/ftx1/ftx1_freq.c
    M rigs/yaesu/ftx1/ftx1_preamp.c
    M rigs/yaesu/newcat.c
    M rigs/yaesu/vr5000.c
    M rigs/yaesu/vx1700.c
    M rigs/yaesu/yaesu.c
    M rotators/indi/indi_wrapper.hpp
    M rotators/ioptron/rot_ioptron.c
    M src/amp_conf.c
    M src/amp_settings.c
    M src/amplifier.c
    M src/cm108.c
    M src/conf.c
    M src/misc.c
    M src/rig.c
    M src/rot_conf.c
    M src/rotator.c
    M tests/ampctl.c
    M tests/ampctl_parse.c
    M tests/ampctld.c
    M tests/cachetest.c
    M tests/cachetest2.c
    M tests/dumpcaps_amp.c
    M tests/dumpcaps_rot.c
    M tests/dumpmem.c
    M tests/memcsv.c
    M tests/rig_bench.c
    M tests/rig_tests.c
    M tests/rigctl.c
    M tests/rigctl_parse.c
    M tests/rigctlcom.c
    M tests/rigctld.c
    M tests/rigctlsync.c
    M tests/rigctltcp.c
    M tests/rigmem.c
    M tests/rigsmtr.c
    M tests/rigswr.c
    M tests/rigtestmcast.c
    M tests/rotctl.c
    M tests/rotctl_parse.c
    M tests/rotctld.c
    M tests/testfreq.c
    M tests/testrig.c

  Log Message:
  -----------
  Merge GitHub PR #2003


Compare: https://github.com/Hamlib/Hamlib/compare/adc3012eccc9...0c061d5b2ede

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] Possible change request - "Powerdown" FlRig

[<gm...@bt...>]

My objective is to be able to powerdown my rigs and disconnect the FlRig connection from my app.

It looks like set_powerstat is not enabled for FlRig. I would like to add support for set_powerstat(rig, RIG_POWER_OFF) to flrig.c.

As far as I can see implementing set_powerstat(rig, RIG_POWER_ON) is a non-starter for FlRig as there is no way
of defining how to start and configure FlRig from hamlib.  In this case I would return the appropriate error code (EINVAL?).

FlRig itself has a command "rig.shutdown" that is supposed to close FlRig and, if FlRig is so configured, power down the connected rig.

At the moment get_powerstat returns RIG_POWER_ON by default. I am not proposing to change this.

If no-one sees an issue with this I will go ahead and code and test this preparing a PR or patch on the current hamlib-4.7.

Regards Phil GM3ZZA.

[Hamlib-developer] KD8HFX - Issues with IC-746Pro - Data Mode

[Jim K. <kd...@gm...>]

Good afternoon.

I'm using an IC746-Pro, and each time I try to use WSJTX, the software
boots me out of USB-D mode and puts the radio into standard USB mode.
Manually re-enabling the USB-D mode works until the radio switches to TX
mode, then USB mode is forced through the radio.

Here is a screenshot of the radio config panel.
[image: image.png]


The rig control does everything else fine. I'm using a WestMtn radio Plug
and Play that works perfectly with Ham Radio Deluxe and other digital mode
software. So I'm confident that the rig control is working.

Attached are the diagnostic log files. Any help you can provide would be
greatly appreciated.

--
73 - Jim - KD8HFX

KD8HFX PGP Key
<https://keys.mailvelope.com/pks/lookup?op=get&sea...@gm...>

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Nate B. <n0...@n0...>]

Thank you, Greg.

At the end of the day, trying to verify the license compatibility of LLM
output may well prove to be an impossible task.

Free/Open Source software projects have functioned in a high trust
manner up until this point.  The present inability to adequately trust
the output from LLMs and the desire by many contributors to use LLMs
almost exclusively threatens this high trust model.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Greg T. <gd...@le...>]

Nate Bargmann <n0...@n0...> writes:

[agreed that clueless vibe coding is the biggest issue]

[agreed that finding something, like search, is fine]

As background, I am seeing comments on the net that when there is a very
sparse amount of information about something, LLM outputs are clearly
faithful to that limited input.   Recently there was some youtube video
mentioned on a list, and then someone pointed out the older paper that
the video was plagiarizing, almost entirely.

> When a contributor is prompting an LLM, he needs to be savvy enough to
> recognize when something clever is being offered and then stop and
> investigate.  It could be the LLM is offering up something that is
> either not licensed for Free Software distribution or is patent
> encumbered.

But how does someone do that?  If I, as someone who can program and who
understands copyright law, ask an LLM for code and get some back, I can
review it for correctness.  But how do I assess licensing?  My
assessment today is that it's a derived work of the training data, and
that data was collected both nonconsensually and without regard to
licensing.  So while there are unsettled legal questions, there is
absolutely no basis to conclude that the code meets the DCO.

I don't see how anyone could conclude that LLM output is ok, unless it's
below the threshold of copyright.

[Hamlib-developer] [Hamlib/Hamlib] 946aad: Update ampctl/ampctld man page documentation with ...

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 946aadc10634efe18750f9d0d86b860b1ebc1fca
      https://github.com/Hamlib/Hamlib/commit/946aadc10634efe18750f9d0d86b860b1ebc1fca
  Author: Mikael Nousiainen <mik...@ik...>
  Date:   2026-02-22 (Sun, 22 Feb 2026)

  Changed paths:
    M doc/man1/ampctl.1
    M doc/man1/ampctld.1

  Log Message:
  -----------
  Update ampctl/ampctld man page documentation with the new commands recently introduced


  Commit: 613a620fbe97886caee842974bc1552f42ded14c
      https://github.com/Hamlib/Hamlib/commit/613a620fbe97886caee842974bc1552f42ded14c
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-02-26 (Thu, 26 Feb 2026)

  Changed paths:
    M doc/man1/ampctl.1
    M doc/man1/ampctld.1

  Log Message:
  -----------
  Merge GitHub PR #2002


  Commit: adc3012eccc923c507bfa0720a10c4322f6d2cb5
      https://github.com/Hamlib/Hamlib/commit/adc3012eccc923c507bfa0720a10c4322f6d2cb5
  Author: Nate Bargmann <n0...@n0...>
  Date:   2026-03-03 (Tue, 03 Mar 2026)

  Changed paths:
    M doc/man1/ampctl.1
    M doc/man1/ampctld.1

  Log Message:
  -----------
  Fix line continuation in ampctl.1

Bump copyright year in ampctl.1 and ampctld.1.


Compare: https://github.com/Hamlib/Hamlib/compare/5a87f7e415ee...adc3012eccc9

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Nate B. <n0...@n0...>]

* On 2026 27 Feb 09:01 -0600, Mikael Nousiainen wrote:
> On Fri, Feb 27, 2026, at 16:16, Greg Troxel wrote:
> > "Mikael Nousiainen" <mik...@fa...> writes:
> >> I'd rephrase the question as: How can Hamlib "keep up" and do it in a
> >> responsible and ethical way?
> >
> > My take is that saying "how do we keep up" is presupposing the answer to
> > the fundamental question.
> >
> > 73 de n1dam
> 
> That's not really what I meant, it's likely me as a non-native English
> speaker ending up with bad word choices. :)
> 
> My intent was more like: How can we keep Hamlib alive and thriving
> when we know masses (including many of Hamlib's current and potential
> future contributors) are going for genAI? And: can we find
> responsible/ethical ways of using genAI?
> 
> The same goes for majority of open-source projects, of course.

All Free Software projects have three choices as I see it.

Blanket prohibition on LLM generated code.  That might work in a very
small/solo project, but for a project of any size, I don't see how such
could be enforced.

Accept contributions that have LLM content.  Where to draw this line is
what many projects are grappling with now.  This line will likely be
adjusted a few times in the near term.

Accept everything without a care.  Seems like a recipe for future
disaster.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Nate B. <n0...@n0...>]

* On 2026 27 Feb 02:51 -0600, Mikael Nousiainen wrote:
> Hi everyone!
> 
> Did we ever land to any decision regarding LLM usage in Hamlib?
> 
> I see there is some form of acceptance to the general idea of
> accepting **thoroughly-reviewed** code generated by an AI agent in
> Hamlib, since the FTX-1 backend was already merged and it was
> partially generated using LLMs. Please see the discussions in the
> merged PR if you need more context:
> https://github.com/Hamlib/Hamlib/pull/1961
> 
> But where do we draw the lines here? Who will decide? Is this a
> maintainer or a community based decision?

I'm certainly not up to the task of trying to verify anything against
all the permutations of bots now available to everyone.  As I see it,
the primary party responsible for assuring any contribution is
legal/ethical/unencumbered is the one submitting the code.

What I think we all want to avoid is someone prompting an LLM, "Write a
Hamlib backend for the Moon Melter 6000", and then issue a PR of the
result without examination or testing.

I am beginning to soften just a bit (old age an all that) in that I can
recognize that an LLM can be a useful tool to assist, though I've not
tried it myself.  What it can do is save hours of searching for some bit
of code that is buried in the bowels of Stack Overflow and such.  In
that regard LLMs can serve very usefully as an extraordinarily powerful
search engine that provides context to the problem being resolved.  In
that sense, is it much different than hours spent searching Stack
Overflow, various blogs, or GitHub?

> Hypothetically, how can project maintainers even know some code has
> been generated by an LLM - especially if there's a skilled developer
> reviewing and cleaning up the code before sharing it? I think this
> goes to the same category as using StackOverflow or "whatever Google
> results give you" as a starting point.

That is really where I am willing to accept contributors using LLM
assistance.  The key here is LLM being assistance, not doing it all.

The sense I get of "vibe coding" is prompting an LLM until the offered
program does what the user asks for and then the user turning around and
stating, "Look what I coded!"  No, I don't want that.

> I think it's still up to the to the contributors (submitting code
> changes) and the project maintainers to take responsibility of what
> gets merged/published. And the fact is that the number of AI agent
> users and the amount of LLM-produced code around will only keep
> increasing rapidly - there's no way avoiding it.

When a contributor is prompting an LLM, he needs to be savvy enough to
recognize when something clever is being offered and then stop and
investigate.  It could be the LLM is offering up something that is
either not licensed for Free Software distribution or is patent
encumbered.

In reality, I'm not sure that is really an issue with Hamlib as we're
not trying to solve deep problems or obscure algorithms.  A backend is
mostly an exercise in translating the physical radio to Hamlib.  An LLM
can likely provide analysis to a new contributor to make that task much
easier/faster.  That seems reasonable to me.

> I'd rephrase the question as: How can Hamlib "keep up" and do it in a
> responsible and ethical way?

I think you might have expanded on this down thread.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] Hamlib unit testing and daemon protocol improvements

[Mikael N. <mik...@fa...>]

I created GitHub issues about two topics, which (for a change) should not be complex decisions - see the linked GH issues below. The reason is that the ARDC improvement project that I'm working on will result in addition of new Hamlib rigctld daemon commands and I'm also planning to add unit test code for the new features, which would benefit from introduction of at least a simple unit test framework in the Hamlib codebase.

Hamlib unit testing framework/approach:

https://github.com/Hamlib/Hamlib/issues/2004

Stop support for non-extended daemon responses for new commands (keeps current daemon command/API compatibility):

https://github.com/Hamlib/Hamlib/issues/2006

As a lot of the development-related discussion is already in GitHub issues - it would be great if folks here on the mailing list could participate the discussion in GitHub - if at all possible.

73,
Mikael OH3BHX

P.S. I somehow assumed also the GH issues will be posted to this mailing list, but it looks like only PR activity is relayed here. This split between GH and the mailing list is a bit annoying to me - especially, as I personally see GitHub being a more organized and structured way of working with the codebase and it's easier to keep track of multiple on-going discussions. Anyway, right now I'm not sure how the GH issues vs mailing list should be used exactly (what's the intended purpose) ...

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Mikael N. <mik...@fa...>]

Answering myself with this FSFE article about source code, copyrights and some considerations about AI:

Legal Corner: The threshold of originality for copyrightable source code:

https://fsfe.org/news/2025/news-20250515-01.en.html

This topic is a rabbit hole...

73,
Mikael OH3BHX

On Sat, Feb 28, 2026, at 01:23, Mikael Nousiainen wrote:
> Thanks Nate, enjoy the fine weather and time outside! Here in Finland 
> spring is still 1-2 months away ...
>
> I spent some more time reading the Debian mailing list, which has some 
> good discussion on the genAI topic and found this message, which also 
> discusses potential accidental plagiarism and code cloning, please have 
> a look:
>
> https://lists.debian.org/debian-vote/2026/02/msg00032.html
>
> More specifically, there are links in that message to the Linux kernel 
> code generation and assisted coding guidelines:
>
> - Kernel Guidelines for Tool-Generated Content:
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/generated-content.rst
>
> - AI Coding Assistants:
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-assistants.rst
>
> Especially the latter document is rather clearly worded and simple - 
> and still gives the option for developers to use coding assistants and, 
> most importantly, emphasizes that contributors must use their best 
> knowledge and skills to assess the output for potential suspicious code 
> (regarding cloning/plagiarism/correctness/security/...).
>
> My personal thoughts about Hamlib and the risk of code cloning and plagiarism:
>
> Regarding potential license incompatibility and plagiarism caused by AI 
> code, I think the _vast_ majority of code that should ever end up in 
> Hamlib is likely to be rather simple in terms of what it does - and 
> very specific to the "niche" of controlling (ham) radio devices: we're 
> talking about (mostly) trivial abstraction layers for devices, Hamlib 
> command parsing, device-specific command generation and response 
> parsing. Of course, the documentation used for controlling devices must 
> originate from a freely available/compatible source, but that's what we 
> trust contributors to do anyway - even if they write all the code 
> without genAI.
>
> Anything more advanced - let's say we'd add a custom implementation of 
> an audio codec for a network rig or maybe a custom, non-trivial 
> algorithm for doing some data transformations - deserves more attention 
> and research on the origin of the code and I'd argue it is rather easy 
> to spot this kind of changes. Here is where the responsibility of the 
> contributor(s), reviewer(s) and maintainer(s) matters - just like with 
> any code contribution.
>
> Additionally, for many cases that need more complex/advanced features, 
> there are freely available libraries available (ones that have a 
> compatible license). As an example, FlexRadio rigs seem to support Opus 
> audio codec in their RX audio streams (in addition to PCM). Here, 
> instead of trying to "blindly prompt the LLM and generate an Opus 
> decoder", a good choice would be to add libopus (with MIT-style 
> license) as an (optional) dependency. The code generated as the result 
> would only involve calls to libopus, which make the contribution 
> significantly easier to review.
>
> What I'm trying to say is that even with code generated by coding 
> assistants, it's still possible to see whether a piece of code (e.g. a 
> pull request) consists of what I'd call "trivial" changes and that it 
> follows Hamlib code conventions/patterns (arguably indicating 
> negligible risk of license violations or code plagiarism) - or whether 
> it's a larger or a significantly more complex contribution.
>
> -> There are ways to use genAI where it's practically impossible to end 
> up with code output that would cause issues regarding license 
> compatibility.
>
> It's also worth thinking for a moment: what can even be interpreted as 
> plagiarism or a license violation? It has to be something non-trivial 
> and/or a larger piece of code. I have to admit my knowledge is limited 
> here. Does anyone here happen to know if there are any reliable sources 
> for guidelines on what can be considered a "work of art", something 
> that can be licensed and something that's clearly copyrightable? After 
> all, source code often contains lots of patterns that are common to 
> thousands of applications - so simply looking at individual snippets of 
> code that look similar or even identical doesn't always count.
>
> Seems I ended up writing here a lot more than I originally intended - 
> oh well - I'll stop writing/posting now for some days and wait for 
> everyone to consider their opinions and chime in.
>
> 73,
> Mikael OH3BHX
>
> On Fri, Feb 27, 2026, at 21:22, Nate Bargmann wrote:
>> Thanks, Greg.
>>
>> I'm not ignoring the discussions!  The weather has been too nice and
>> with the lengthening of the days, I'm spending more time outside as we
>> turn the corner into spring farm work.  As an example I need to get back
>> outside and put a wheel bearing assembly back together with new bearings
>> and seal.
>>
>> Next week the weather is supposed to be wet so I'll likely have more
>> time to sit and collect more thoughts and merge PRs.
>>
>> 73, Nate
>>
>> -- 
>> "The optimist proclaims that we live in the best of all
>> possible worlds.  The pessimist fears this is true."
>> Web: https://www.n0nb.us
>> Projects: https://github.com/N0NB
>> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>>
>>
>> _______________________________________________
>> Hamlib-developer mailing list
>> Ham...@li...
>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>>
>> Attachments:
>> * signature.asc
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Mikael N. <mik...@fa...>]

Thanks Nate, enjoy the fine weather and time outside! Here in Finland spring is still 1-2 months away ...

I spent some more time reading the Debian mailing list, which has some good discussion on the genAI topic and found this message, which also discusses potential accidental plagiarism and code cloning, please have a look:

https://lists.debian.org/debian-vote/2026/02/msg00032.html

More specifically, there are links in that message to the Linux kernel code generation and assisted coding guidelines:

- Kernel Guidelines for Tool-Generated Content:
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/generated-content.rst

- AI Coding Assistants:
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-assistants.rst

Especially the latter document is rather clearly worded and simple - and still gives the option for developers to use coding assistants and, most importantly, emphasizes that contributors must use their best knowledge and skills to assess the output for potential suspicious code (regarding cloning/plagiarism/correctness/security/...).

My personal thoughts about Hamlib and the risk of code cloning and plagiarism:

Regarding potential license incompatibility and plagiarism caused by AI code, I think the _vast_ majority of code that should ever end up in Hamlib is likely to be rather simple in terms of what it does - and very specific to the "niche" of controlling (ham) radio devices: we're talking about (mostly) trivial abstraction layers for devices, Hamlib command parsing, device-specific command generation and response parsing. Of course, the documentation used for controlling devices must originate from a freely available/compatible source, but that's what we trust contributors to do anyway - even if they write all the code without genAI.

Anything more advanced - let's say we'd add a custom implementation of an audio codec for a network rig or maybe a custom, non-trivial algorithm for doing some data transformations - deserves more attention and research on the origin of the code and I'd argue it is rather easy to spot this kind of changes. Here is where the responsibility of the contributor(s), reviewer(s) and maintainer(s) matters - just like with any code contribution.

Additionally, for many cases that need more complex/advanced features, there are freely available libraries available (ones that have a compatible license). As an example, FlexRadio rigs seem to support Opus audio codec in their RX audio streams (in addition to PCM). Here, instead of trying to "blindly prompt the LLM and generate an Opus decoder", a good choice would be to add libopus (with MIT-style license) as an (optional) dependency. The code generated as the result would only involve calls to libopus, which make the contribution significantly easier to review.

What I'm trying to say is that even with code generated by coding assistants, it's still possible to see whether a piece of code (e.g. a pull request) consists of what I'd call "trivial" changes and that it follows Hamlib code conventions/patterns (arguably indicating negligible risk of license violations or code plagiarism) - or whether it's a larger or a significantly more complex contribution.

-> There are ways to use genAI where it's practically impossible to end up with code output that would cause issues regarding license compatibility.

It's also worth thinking for a moment: what can even be interpreted as plagiarism or a license violation? It has to be something non-trivial and/or a larger piece of code. I have to admit my knowledge is limited here. Does anyone here happen to know if there are any reliable sources for guidelines on what can be considered a "work of art", something that can be licensed and something that's clearly copyrightable? After all, source code often contains lots of patterns that are common to thousands of applications - so simply looking at individual snippets of code that look similar or even identical doesn't always count.

Seems I ended up writing here a lot more than I originally intended - oh well - I'll stop writing/posting now for some days and wait for everyone to consider their opinions and chime in.

73,
Mikael OH3BHX

On Fri, Feb 27, 2026, at 21:22, Nate Bargmann wrote:
> Thanks, Greg.
>
> I'm not ignoring the discussions!  The weather has been too nice and
> with the lengthening of the days, I'm spending more time outside as we
> turn the corner into spring farm work.  As an example I need to get back
> outside and put a wheel bearing assembly back together with new bearings
> and seal.
>
> Next week the weather is supposed to be wet so I'll likely have more
> time to sit and collect more thoughts and merge PRs.
>
> 73, Nate
>
> -- 
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
> Attachments:
> * signature.asc

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Nate B. <n0...@n0...>]

Thanks, Greg.

I'm not ignoring the discussions!  The weather has been too nice and
with the lengthening of the days, I'm spending more time outside as we
turn the corner into spring farm work.  As an example I need to get back
outside and put a wheel bearing assembly back together with new bearings
and seal.

Next week the weather is supposed to be wet so I'll likely have more
time to sit and collect more thoughts and merge PRs.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Greg T. <gd...@le...>]

"Mikael Nousiainen" <mik...@fa...> writes:

> On Fri, Feb 27, 2026, at 16:16, Greg Troxel wrote:
>> "Mikael Nousiainen" <mik...@fa...> writes:
>>
>>> Did we ever land to any decision regarding LLM usage in Hamlib?
>>
>> This is an interesting opinion, and I think it has considerable merit.
>>
>> https://lists.debian.org/debian-vote/2026/02/msg00060.html
>
> Thanks for noting this. However, I read this particular opinion
> saying: "there is no way genAI can be done right and we should
> therefore abandon it" - which is a rather extreme viewpoint that I
> don't share. The fact that many large AI companies are not doing a
> particularly good job ethically (training their models) should _not_
> mean automatically that "all genAI is bad and will be like that
> forever". Not sure if I understood something incorrectly?

I think you're technically correct but not correct in practice.  I agree
that it is theoretically possible that genAI could be done properly.

(Separating ethics from unsettled questions of copyright law.)

Can you point to a single example of an LLM that has been trained solely
with content where the author/copyright-holder has truly consented to
such use?  I don't mean technically clicked through something they don't
understand, but true consent.

> Exactly. How can we trust any contributor, since "faking it" (=
> generating the code) is easier than ever and requires practically no
> effort? Also, I'd argue not all LLM-generated code is automatically
> proprietary - just like not all StackOverflow or "whatever Google
> gives you" is proprietary. It's a rather complex issue.

Sorry, I didn't mean to say LLM code was proprietary here.  I just meant
if there are rules, we currently trust people to follow them.

> My intent was more like: How can we keep Hamlib alive and thriving
> when we know masses (including many of Hamlib's current and potential
> future contributors) are going for genAI? And: can we find
> responsible/ethical ways of using genAI?

The first part I think is the key question.

I guess it's a real question how much is lost by saying no.

The larger question is if it's a generational thing and that in 20 years
will everyone who participates think it's fine to use LLM code.  I think
it's to early to presume a societal outcome.

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Mikael N. <mik...@fa...>]

Thanks Phil!

I really like what this proposal - and especially the policies linked (see below) from Linux Foundation, Fedora and Matplotlib - attempts to accomplish: to find solutions for embracing ethical use of genAI (instead of simply stating it would never work). 

Copied from https://lists.debian.org/debian-vote/2026/02/msg00000.html:

    * Linux Foundation -- Guidance Regarding Use of Generative AI Tools
      for Open Source Software Development
      https://www.linuxfoundation.org/legal/generative-ai
    * Fedora -- AI-assisted Contributions Policy
      https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/
    * Matplotlib -- Restrictions on Generative AI Usage
      https://matplotlib.org/devdocs/devel/contribute.html#restrictions-on-generative-ai-usage

Repeating what Phil stated: "The genie is out of the bottle. How we can all ethically command that genie should now be the topic of discussion."

Well said :)

73,
Mikael OH3BHX

On Fri, Feb 27, 2026, at 16:38, gm...@bt... wrote:
> That quote from the Debian community is actually a response to the more considered proposal:
> https://lists.debian.org/debian-vote/2026/02/msg00000.html
> Which lays out a set of guidelines for the use of LLM generated code in contributions to Debian.
> 
> The genie is out of the bottle. How we can all ethically command that genie should now be the topic of discussion.
> 
> 73 Phil GM3ZZA
> 
> 
> 
> *From:* Greg Troxel <gd...@le...>
> *Sent:* 27 February 2026 2:16 PM
> *To:* Mikael Nousiainen <mik...@fa...>
> *Cc:* Daniele Forsi <iu...@gm...>; gm...@bt... <gm...@bt...>; Nate Bargmann <n0...@n0...>; mik...@ik... <mik...@ik...>; Hamlib Developers <ham...@li...>
> *Subject:* Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)
>  
> "Mikael Nousiainen" <mik...@fa...> writes:
> 
> > Did we ever land to any decision regarding LLM usage in Hamlib?
> 
> This is an interesting opinion, and I think it has considerable merit.
> 
> https://lists.debian.org/debian-vote/2026/02/msg00060.html
> 
> > Hypothetically, how can project maintainers even know some code has
> > been generated by an LLM - especially if there's a skilled developer
> > reviewing and cleaning up the code before sharing it? I think this
> > goes to the same category as using StackOverflow or "whatever Google
> > results give you" as a starting point.
> 
> It's also similar to someone taking proprietary code and submitting it.
> At some point we are believing people when they offer code with
> Signed-Off-By: or implicitly under the inbound=outbound convention.
> Whether that trust is misplaced is a general issue, and it's not
> particularly about LLM code.
> 
> > I'd rephrase the question as: How can Hamlib "keep up" and do it in a
> > responsible and ethical way?
> 
> My take is that saying "how do we keep up" is presupposing the answer to
> the fundamental question.
> 
> 73 de n1dam

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Mikael N. <mik...@fa...>]

On Fri, Feb 27, 2026, at 16:16, Greg Troxel wrote:
> "Mikael Nousiainen" <mik...@fa...> writes:
>
>> Did we ever land to any decision regarding LLM usage in Hamlib?
>
> This is an interesting opinion, and I think it has considerable merit.
>
> https://lists.debian.org/debian-vote/2026/02/msg00060.html

Thanks for noting this. However, I read this particular opinion saying: "there is no way genAI can be done right and we should therefore abandon it" - which is a rather extreme viewpoint that I don't share. The fact that many large AI companies are not doing a particularly good job ethically (training their models) should _not_ mean automatically that "all genAI is bad and will be like that forever". Not sure if I understood something incorrectly?

I'll have to read the full discussion on that mailing list, as I'm interested to know the details, but it'll take some time.

>
>> Hypothetically, how can project maintainers even know some code has
>> been generated by an LLM - especially if there's a skilled developer
>> reviewing and cleaning up the code before sharing it? I think this
>> goes to the same category as using StackOverflow or "whatever Google
>> results give you" as a starting point.
>
> It's also similar to someone taking proprietary code and submitting it.
> At some point we are believing people when they offer code with
> Signed-Off-By: or implicitly under the inbound=outbound convention.
> Whether that trust is misplaced is a general issue, and it's not
> particularly about LLM code.

Exactly. How can we trust any contributor, since "faking it" (= generating the code) is easier than ever and requires practically no effort? Also, I'd argue not all LLM-generated code is automatically proprietary - just like not all StackOverflow or "whatever Google gives you" is proprietary. It's a rather complex issue.

>
>> I'd rephrase the question as: How can Hamlib "keep up" and do it in a
>> responsible and ethical way?
>
> My take is that saying "how do we keep up" is presupposing the answer to
> the fundamental question.
>
> 73 de n1dam

That's not really what I meant, it's likely me as a non-native English speaker ending up with bad word choices. :)

My intent was more like: How can we keep Hamlib alive and thriving when we know masses (including many of Hamlib's current and potential future contributors) are going for genAI? And: can we find responsible/ethical ways of using genAI?

The same goes for majority of open-source projects, of course.

73,
Mikael OH3BHX

Re: [Hamlib-developer] Hamlib backend file structure for large backends

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

On 2/27/26 4:00 AM, Mikael Nousiainen wrote:
> The related PR that started this discussion - seehttps://github.com/Hamlib/Hamlib/pull/1961 - has now been merged and it seems we have an example case of what a larger backend could preferably look like.
>
> The complete FTX-1 backend was placed to a subdirectory - rigs/yaesu/ftx1 - and the previously added FTX-1 backend files in rigs/yaesu were removed. Please see the GitHub PR merge file listing below.
>
>    Date:   2026-01-27 (Tue, 27 Jan 2026)
>
>    Changed paths:
>      M rigs/yaesu/Makefile.am
>      R rigs/yaesu/ftx1.c
>      R rigs/yaesu/ftx1.h
>      A rigs/yaesu/ftx1/ftx1-cat-commands.txt
>      A rigs/yaesu/ftx1/ftx1.c
>      A rigs/yaesu/ftx1/ftx1.h
>      A rigs/yaesu/ftx1/ftx1_audio.c
>      A rigs/yaesu/ftx1/ftx1_clarifier.c
>      A rigs/yaesu/ftx1/ftx1_ctcss.c
>      A rigs/yaesu/ftx1/ftx1_cw.c
>      A rigs/yaesu/ftx1/ftx1_ext.c
>      A rigs/yaesu/ftx1/ftx1_filter.c
>      A rigs/yaesu/ftx1/ftx1_freq.c
>      A rigs/yaesu/ftx1/ftx1_func.c
>      A rigs/yaesu/ftx1/ftx1_info.c
>      A rigs/yaesu/ftx1/ftx1_mem.c
>      A rigs/yaesu/ftx1/ftx1_menu.c
>      A rigs/yaesu/ftx1/ftx1_menu.h
>      A rigs/yaesu/ftx1/ftx1_mode.c
>      A rigs/yaesu/ftx1/ftx1_noise.c
>      A rigs/yaesu/ftx1/ftx1_preamp.c
>      A rigs/yaesu/ftx1/ftx1_readme.txt
>      A rigs/yaesu/ftx1/ftx1_scan.c
>      A rigs/yaesu/ftx1/ftx1_tx.c
>      A rigs/yaesu/ftx1/ftx1_vfo.c
>      M rigs/yaesu/level_gran_yaesu.h
>      M rigs/yaesu/newcat.h
>
> Any (final) comments on this?
>
> 73,
> Mikael OH3BHX

I finally ran cppcheck.sh after this was committed - 146 new gripes(!) 
but the ones germane to this question:

gwb@stitch:~/OSS/src/Hamlib> grep ftx cppcheck.log | grep -i include
rigs/yaesu/ftx1/ftx1.c:48,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1.c:49,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1.c:998,information,missingInclude,Includefile: 
"level_gran_yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_audio.c:27,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_audio.c:28,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_clarifier.c:27,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_clarifier.c:28,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_ctcss.c:32,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_ctcss.c:33,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_cw.c:26,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_cw.c:27,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_ext.c:31,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_ext.c:32,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_filter.c:24,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_filter.c:25,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_freq.c:17,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_freq.c:18,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_func.c:49,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_func.c:50,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_info.c:38,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_info.c:39,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_mem.c:48,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_mem.c:49,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_menu.c:14,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_menu.c:15,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_noise.c:21,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_noise.c:22,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_preamp.c:20,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_preamp.c:21,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_scan.c:43,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_scan.c:44,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_tx.c:23,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_tx.c:24,information,missingInclude,Includefile: 
"newcat.h" not found.
rigs/yaesu/ftx1/ftx1_vfo.c:24,information,missingInclude,Includefile: 
"yaesu.h" not found.
rigs/yaesu/ftx1/ftx1_vfo.c:25,information,missingInclude,Includefile: 
"newcat.h" not found.

|should those have a '../' added to the filename?|

>
> On Mon, Dec 22, 2025, at 09:56, Mikael Nousiainen wrote:
>> Hi George,
>>
>> Thanks for your input, please see my comments below!
>>
>> On Sun, Dec 21, 2025, at 20:55, George Baltz wrote:
>>> [Sorry, personal/ham time is in short supply this time of year, so this
>>> is a bit rushed. More may follow]
>>>
>>> On 12/20/25 12:07 PM, Mikael Nousiainen wrote:
>>>> Hello Hamlib developers!
>>>>
>>>> There's been some recent discussion in Hamlib PR #1961 (seehttps://github.com/Hamlib/Hamlib/pull/1961) about the device backend file structure. Some backend, such as the new Yaesu FTX-1 backend have grown rather complex and with the upcoming addition of Icom network protocol support and full-featured FlexRadio backend (with audio and I/Q data streaming!) are only likely to make the backend sizes larger (these will be part of the ARDC Hamlib improvement project, also announced recently on this mailing list and in the GitHub PRs).
>>>>
>>>> Traditionally, most of the backends (for a single device type - or its variants) has been placed in a single source file. However, as these files grow up to several thousand lines long - or possibly even larger, to over 10k lines - it can be argued that managing the source code becomes more difficult. Additionally, splitting backend code into logical parts might make sharing common code across similar backends easier.
>>> Missing one very important detail - backends for most rigs are made up
>>> of *two* files; one specifically for the rig and one for the
>>> vendor(e.g., rigs/icom/icom.c, rigs/yaesu/newcat.c, etc) that is shared
>>> by all rigs from that manufacturer. AFAICT the previous development
>>> would start with the common file and add replacements for any of the
>>> common routines necessary to handle the new rig. Checking if a similar
>>> function existed in another rig file may not have happened.
>> Agreed - though there are some significant inconsistencies here: in
>> some cases the "common routines" simply contain huge if-else blocks to
>> handle each specific rig, which is not really optimal regarding what I
>> think a clean backend implementation would be. In an optimal case, the
>> "common routines" would only contain code that can be directly re-used
>> by the individual backends (or somehow parameterized, e.g. with custom
>> subcommand numbers as parameters - like a Yaesu EX-menu command could
>> work) - and it wouldn't handle any specific model, maybe unless there
>> are only a handful of variations to a command.
>>
>>>> As potential alternatives to single-file backends, there is already one proposal in the FTX-1 backend PR and I personally added another one.
>>>>
>>>> Here are all of the 3 options that have been discussed so far:
>>>>
>>>> 1) Traditional, single-file backend - no matter the size of the file
>>>>
>>>> 2) The current PR # structure (files split in two directories): main backend files (ftx1.c and ftx1.h) + README are in rigs/yaesu directory and the rest of the files are in rigs/yaesu/ftx1 directory
>>>>
>>>> 3) Similar multi-file backend as in PR #1961, but all of the files (including ftx1.c, ftx1.h and README) are placed in a backend-specific subdirectory, e,.g. rigs/yaesu/ftx1.
>>>>
>>>> Personally, I'd prefer option 3 - but *only* for multi-file backends.
>>> Personally, I'd prefer option 1.  Putting these files into a
>>> subdirectory means the chances of reusing them (or even looking at them)
>>> drops to about zero.
>>>> For a single-file backend, we could still use the current convention (of not having a separate subdirectory for the backend). So as a summary, this is a question of adding subdirectory for multi-file backend. And IMO there's definitely no point in starting to convert any of the existing backends - unless changes are being made to them and they grow significantly larger.
>>>>
>>>> Since there's already the FTX-1 backend PR under review that would benefit from this discussion, I think everyone would appreciate if we can make a decision reasonably quickly :)
>>>>
>>>> Please share your thoughts!
>>> You asked for it :-)
>>>
>>> Part of the problem with the size of backends is that although Hamlib
>>> has data structures to describe the capabilities of the rig, there is no
>>> table-driven description of the command structure/syntax to actually do
>>> anything.  So it all is done by individual code paths.  Tie together the
>>> Hamlib function, the rig model and the command, and a lot of that code
>>> could go away.
>> True - there's a lot of simple refactoring that could be done.
>>
>>> Case in point: PR #1952.  Replaces almost all of the logic that computes
>>> which command to send with preset templates ready to apply the function
>>> values to and ship out to the rig; uses data already in the rig
>>> capabilities to define those templates.  And I noticed (after the fact)
>>> that 3 of the 4 voice_mem() functions in the Elecraft backend can now be
>>> removed by adding a few more lines to kenwood_init() and using the
>>> common code in kenwood.c.
>> Exactly. There is indeed a lot of cleanup to be done.
>>
>> However, what I'm after with my file structure proposal (option 3) is
>> that, even WITH your points considered (clear separation between common
>> and model-specific code + refactoring of repetitive code constructs
>> done), more complex transceivers end up having complex backends with
>> usually plenty of model-specific code (no manufacturer seems to case
>> about consistency, there will be lots of exceptions to "rules"). In
>> this case, I think having multiple files for a single backend will help
>> maintainability and readability.
>>
>> I'm already seeing this is the case with FTX-1 - lots of the commands
>> are FTX-1-specific (although some smaller parts of the FTX-1 backend
>> could probably made more generic, e.g. the EX menu command routines).
>>
>> What I'm after here is to establish a guideline for larger backends:
>> what's the convention we should follow with more complex backends. Most
>> backends would do just fine with a single file!
>>
>> Additionally, we could document some of the backend development process
>> rules where what you've stated in your message are top priority: making
>> sure the "common routines" are used to full extent and that the code
>> doesn't use repetitive constructs (that are also prone to bugs).
>>
>> We could certainly extend the existing developer docs with these
>> guidelines:
>> https://github.com/Hamlib/Hamlib/blob/master/README.developer
>>
>> 73,
>> Mikael OH3BHX
>>
>>
>> _______________________________________________
>> Hamlib-developer mailing list
>> Ham...@li...
>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[<gm...@bt...>]

That quote from the Debian community is actually a response to the more considered proposal:
https://lists.debian.org/debian-vote/2026/02/msg00000.html
Which lays out a set of guidelines for the use of LLM generated code in contributions to Debian.

The genie is out of the bottle. How we can all ethically command that genie should now be the topic of discussion.

73 Phil GM3ZZA

________________________________
From: Greg Troxel <gd...@le...>
Sent: 27 February 2026 2:16 PM
To: Mikael Nousiainen <mik...@fa...>
Cc: Daniele Forsi <iu...@gm...>; gm...@bt... <gm...@bt...>; Nate Bargmann <n0...@n0...>; mik...@ik... <mik...@ik...>; Hamlib Developers <ham...@li...>
Subject: Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

"Mikael Nousiainen" <mik...@fa...> writes:

> Did we ever land to any decision regarding LLM usage in Hamlib?

This is an interesting opinion, and I think it has considerable merit.

https://lists.debian.org/debian-vote/2026/02/msg00060.html

> Hypothetically, how can project maintainers even know some code has
> been generated by an LLM - especially if there's a skilled developer
> reviewing and cleaning up the code before sharing it? I think this
> goes to the same category as using StackOverflow or "whatever Google
> results give you" as a starting point.

It's also similar to someone taking proprietary code and submitting it.
At some point we are believing people when they offer code with
Signed-Off-By: or implicitly under the inbound=outbound convention.
Whether that trust is misplaced is a general issue, and it's not
particularly about LLM code.

> I'd rephrase the question as: How can Hamlib "keep up" and do it in a
> responsible and ethical way?

My take is that saying "how do we keep up" is presupposing the answer to
the fundamental question.

73 de n1dam

Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Greg T. <gd...@le...>]

"Mikael Nousiainen" <mik...@fa...> writes:

> Did we ever land to any decision regarding LLM usage in Hamlib?

This is an interesting opinion, and I think it has considerable merit.

https://lists.debian.org/debian-vote/2026/02/msg00060.html

> Hypothetically, how can project maintainers even know some code has
> been generated by an LLM - especially if there's a skilled developer
> reviewing and cleaning up the code before sharing it? I think this
> goes to the same category as using StackOverflow or "whatever Google
> results give you" as a starting point.

It's also similar to someone taking proprietary code and submitting it.
At some point we are believing people when they offer code with
Signed-Off-By: or implicitly under the inbound=outbound convention.
Whether that trust is misplaced is a general issue, and it's not
particularly about LLM code.

> I'd rephrase the question as: How can Hamlib "keep up" and do it in a
> responsible and ethical way?

My take is that saying "how do we keep up" is presupposing the answer to
the fundamental question.

73 de n1dam

[Hamlib-developer] Hamlib 5.0 roadmap, goals and schedule + API/ABI breakage?

[Mikael N. <mik...@fa...>]

Hello all Hamlib developers!

I'd like to raise a discussion here that originated from GeoBaltz's long-awaited work on some ABI changes to make Hamlib more stable by, for example, modifying some internal data structures to be accessed via pointers.

It seems Hamlib development is seeing a rush of activity now, which is definitely a good thing.

As background, I've been involved in Hamlib development (for a couple of years already) by mainly introducing and extending backends + adding the UDP rig state snapshots / spectrum data API + more recently working on the ARDC improvement project (still very much in progress).

However, I've never really been aware of what the Hamlib release process actually is:

a) What are the "development windows" (schedule)?
b) When does release stabilization occur (when to stop accepting new proposals/features to a release)?
c) Where does Hamlib gather the roadmap for a particular release?

Regarding the roadmap, we have this release goals issue for 5.0: https://github.com/Hamlib/Hamlib/issues/1773 - but the discussion seems rather open-ended (+ issue is open), suggesting the release goals are not yet fixed.

There's also this list of issues tagged for 5.0 milestone: https://github.com/Hamlib/Hamlib/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A5.0

Apart from those, the only documentation related to Hamlib releases I know of is simply the technical instructions for a release: https://github.com/Hamlib/Hamlib/blob/master/README.release

My main questions here are:

1. What's the status of the current master branch?
2. Is "master" supposed to be the development branch for 5.0 where we can still make API and ABI changes?
3. Do we have any target date for 5.0 in the **very near future** or can we keep the development window open maybe for at least a couple of months more until stabilization begins?

Hamlib 4.7 (the latest stable release) was only recently branched, so I'm assuming 5.0 development is still going on in master and we can still accept larger changes, even ones that break API / ABI if there is a good reason for that.

More background on the discussion:

The underlying reason for this discussion is that I'd really like to go forward with some additional API changes, specifically regarding device state in structs `rig_state`, `rot_state` and `amp_state`: currently these data structures are meant to be state internal to Hamlib, but many apps still access them directly, making it difficult to add new features or simply to make changes in these internal data structures (even in minor Hamlib releases) without breaking apps. Accidental ABI breakage has happened in the 4.x releases a couple of times with bugfix releases needed to fix them.

Making device state structs closed for direct access would mean that apps linking to Hamlib would need some targeted changes, e.g. using accessor functions or something similar to access the rig state when needed. I'm happy to share a more detailed plan in a GitHub issue + link it here later. This simply serves as an example of a change that would benefit from the API/ABI breakage that the new major version 5.0 allows.

In any case, even with the current ABI changes, the way forward seems to be that Hamlib 4.x and 5.x should be able to co-exist on a system (with proper versioning for dynamically linked libraries), since they're not binary-compatible anymore. My question is more about API compatibility: can we introduce breaking changes? So far there have not been many - if any?

Happy to hear what the consensus regarding Hamlib release schedule and API/ABI breakage is.

73,
Mikael OH3BHX