|
+1
On 2019-07-29 10:50 p.m., vk2tv wrote:
Hello Ian,
On 27/7/19 4:10 am, Iain Learmonth
wrote:
Hi,
I am a maintainer for the libax25 and ax25-apps packages, and these
packages are not in great shape. These are userspace packages that
compliment the AX.25 networking support in the Linux kernel. I would
like to propose that we do not ship these packages, or otherwise use the
kernel AX.25 support, in the next Debian release.
I've delayed this reply for a few days so that my initial
disbelief and anger didn't taint my reply (;->) As a user of
Debian and kernel ax25 continuously since 1994, to say your news
shattered me is a gross understatement.
Support for the AX.25 stack is currently not present on arm64 (#920651).
I am not sure if this is due to it being broken there or it simply
wasn't enabled. Regardless, it has been broken recently in ways that
seriously affect its usability. There are just not enough people looking
at it or taking care of it.
I have various arm SBCs in addition to some early Raspberry Pi's -
Odroid C1+, Odroid XU4 and Olimex A13. Both Odroids came with
kernels that didn't have "ham radio" enabled, but after compiling
a new kernel for the XU4 I was able to compile libax25, etc. The
kernel for the Olimex had ham radio compiled as modules, but not
for mkiss (go figure), so it's a distinct possibility that 64 bit
SBC's also don't have "ham radio" enabled in some stock kernels,
or, "ham radio" might be broken on those systems! I had an Odroid
C2 (64 bit) but my recollections about ax25 for it are at best
dim, and at worst, completely wrong so they're best kept to
myself.What is beyond doubt is I compiled DireWolf on it but
DireWolf wouldn't run, but that's not relevant to the ax25
question.
The userspace packages also have long standing bugs (#605946) that have
not been fixed by the upstream. In the last 2 releases of Debian we have
shipped release candidate packages as no release has been made.
Not an ideal situation. Is the real issue here a lack of
motivation, or lack of understanding of the urgency to get things
fixed, or an unwillingness by some to pass their "baby" to someone
else who can act in a timely manner? I worked as and with
volunteers for forty years so I have an understanding of how
difficult (and frustrating) it can be at times to get things done.
I'm not being critical, I'm just trying to get some understanding
of what creates these problems
The following packages would be affected and I propose would be removed:
libax25-dev
ax25mail-utils
ax25-tools
ax25-apps
The following packages would be affected and I propose should be built
without support for kernel AX.25:
xastir (checked, it's fine)
uronode (checked, it's fine)
aprsdigi (did not check if possible yet)
fbb (did not check if possible yet)
But the bigger picture extends beyond users running a single
application in a simple installation. What kernel ax25 offers is
configuration flexibility to run multiple applications and have
them cooperating seamlessly. Which alternative program(s) provide
TCP/IP, ax25, Netrom, Rose and Flexnet routing and/or nodes, and
44net routing in a single package that also supports ax25ipd,
multiple TNCs (hardware and/or software) that can be shared by all
applications, pseudo ports, and with an interface standard that's
freely available for use by anyone with the programming skills to
write user software. And there is the convenience of tools like
listen, mheard, call, all of which facilitate testing and fault
finding when things "don't work", as well as providing day-to-day
operating/maintenance convenience. Some alternative software
provides some of those options, but not all. As a past owner/sysop
of a BBS/Node with 6 radio ports spread over discrete TNCs and a
Baycom USSC>4 card, two pseudo ports, various axudp links,
Netrom circuits, Rose (FPAC) circuits and telnet access to the
BBS, I believe I am qualified as a user to attest to the status
and flexibility of Linux ax25 that couldn't be equaled then, or
now.
This is a change to something that's been around for a while, and it
affects more than just my packages, so I'm bringing this to the mailing
list for discussion. I have pretty much made up my mind that this is the
right thing to do but I will listen to compelling counter-arguments.
Kernel ax25 has been in Debian since the very early days of Linux,
and although it would take a vivid imagination to expect the use
of kernel ax25 to ever again return to what it got in the hey-day
of packet radio, it's always remained in use, and it appears to be
undergoing some renewed interest thanks to the humble Raspberry Pi
drawing amateur operators back to digital modes, and some of the
projects they use rely on kernel ax25.
I know that the software has fallen into some state of disrepair
but you don't scrap a car just because it needs some repairs, you
fix it. Can not your decision to not include kernel ax25 in the
next Debian release be delayed for one more release to give the
amateur radio community a "last chance", as it were, to fix the
issues that currently plague ax25, to bring it "up to speed".
Terminating kernel ax25 without giving the community a chance to
fix it seems undemocratic, but worse than that, removing it from
the kernel will be a one way journey, with no chance of ever going
back if the decision is found to be the wrong one. If jumping is
inevitable, let's do it carefully.
If my response seems a bit emotional, it is, but it's mostly for
future generations of hams who will never get to experience a
"complete" package that can do everything.
I'm not a programmer, I don't have the skills, so I can't help fix
software related issues, so, as a long-term user of Debian (since
kernel 2.0.29) for amateur radio purposes I can only appeal to you
to review your decision.
Thanks,
Iain.
Regards
Ray vk2tv
|