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.
Attachment:
signature.asc
Description: OpenPGP digital signature