|
Hello Iain, Thanks for reaching out. Regarding your question about NOT including the AX.25 kernel support and these AX.25 related packages, why would you propose that just because one platform (ARM64) might be having an issue with it? Looking at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920651 , this seems it wasn't enabled by default for some reason but it works fine on ARM32 (Raspbian distro on Raspberry Pi, etc). Is there a bug ticketing an actual failure on ARM64 here? Works fine on xx86_64. Regarding your point on long standing bugs like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605946 , Is that what you meant by these packages not being "in good shape"? Can you be more specific? Many of these issues have been fixed in the Official AX25 repos for some time. Please review the commit logs at http://git.linux-ax25.org/cgit to see all the updates. The challenge here is that many of these updates haven't been tagged with official release versions in any timely fashion which most distro packagers don't like. The most recent tagging is around 4/2/2019 and I see a new set of debs have been initiated. That is will be an big improvement but you can see that already more fixes have come in since then so maybe you can just take the Git head and use that? What then needs to happen is effort spent to validate the fixes and close these tickets. Btw, in addition to the Official AX.25 repo, there is the VE7FET repo which also tries to sync with the official AX.25 sources but also add additional fixes: https://github.com/ve7fet/linuxax25 Regarding ax25mail-utils , I own that package and I have updates in the DEV branch at https://sourceforge.net/p/ax25mail/ax25mail-utils/ci/develop/tree/ which resolves all known warnings in Buster. I'll try to get that promoted to Master and then do an official release soon. Same can be said for my Linpac package as well. I do agree some bugs have crept into the kernel AX.25 code but the stack does remain mostly functional. In addition to that, people are actively recruiting kernel talent to help address these issues. I think loosing the Linux AX25 kernel start would be a big loss and we need to rally and get it repaired. --David KI6ZHD 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. 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. 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. 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) 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. Thanks, Iain. |