Hi,
On 30/07/2019 02:50, vk2tv wrote:
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.
This is all useful information. We should do a survey of which kernels
currently have AX.25 support enabled and which do not, and whether the
various bugs affect all of them.
The kernel team have indicated that it is not a burden for them to keep
kernel support enabled on amd64 at least, but support is disabled on at
least arm64. It would be good to have a clearer picture of what is going
on here.
You're talking here about compiling things yourself, which means that
whatever is currently in Debian wasn't good enough? To be clear, this
discussion is about removing packages from Debian that are not useful,
not making any changes to the upstream projects. They would continue to
exist and you would continue to be able to compile from source.
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
I think that there is a lack of developer resources, and also a lack of
communication between projects. I'm hoping this conversation will go
some way to improving the latter.
What kernel ax25 offers is configuration
flexibility to run multiple applications and have them cooperating
seamlessly.
As the Debian kernel team have indicated that they are happy to keep the
modules enabled, I'm no longer proposing we would disable the modules.
It is still the case though that the modules are disabled on some
architectures, requiring that users compile from source anyway.
Anything you compile from source is unaffected by this, this is only
about Debian packages you install with apt.
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.
Debian is not a democracy (at least for day-to-day package maintenance
issues). Debian has policy on what is and is not sufficient quality, and
one of the criteria is that it must be up to Debian standards in the
opinion of the maintainer.
https://release.debian.org/testing/rc_policy.txt
Saying this, we are still roughly 3 years from the next release. If this
is not enough time to fix this, then I suggest we scrap it.
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.
If amateur radio is intended to provide emergency communications in the
event of some disaster, I would want future generations to not have to
worry that their communication system will crash because they've resized
a window or that it will only perform at <50% efficiency because a bug
is causing all the packets to be sent twice. Amateur radio should be
leading innovation and yet we are stuck with broken software based on
30-40 year old designs.
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.
You don't need to be a programmer to help. I've had some positive
communications from the upstream maintainers of the userspace tools and
I'm working on updating the Debian packages. What would be really cool
is to get some reports on how these updates are working and any issues
you run into. I will hopefully, in the next few weeks, put out a call
for testing of these new packages and ask for any bugs to be reported.
If you can try on as many SBCs as you can, and talk to as many other
stations as you can (to catch interoperability issues), and report
anything you find then that is just as helpful in contributing to the
programming.
Thanks,
Iain.