Hi, On 27/07/2019 01:22, David Ranch wrote: > 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. This was just an example. We have had issues on x86 and x86_64 where packets would be emitted twice for no good reason, clogging up channels with duplicates. The programs in the ax25-apps package often have segfaults during normal operation. > 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? Yes, there have been other issues too. These are not small packages, they are complex with many code paths and many features. The lack of a test suite makes it difficult to have confidence that updates are not going to break things, especially as we increase compat levels and automatically introduce new hardening options to the compiler in doing so. I manually test these packages (although the coverage of those manual tests is probably 10% of the code paths at best) on amd64 but not other platforms, and other platforms are historically where I've seen the hardening-related bugs pop up. > 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. The issues that have been fixed there are mostly to satisfy modern compilers. They have not fixed functional bugs. Yes, I've uploaded new debs to experimental to avoid breaking unstable with a messed-up libax25. These are compiled with the latest hardening options from compat level 12. > 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 Have these changes been pushed upstream at all? When we have tried to ask upstream for comment on bugs we've not had a response, which is another challenge in this packaging. > 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. Do these packages require kernel AX.25 support or are they able to use KISS/AGWPE? We have KISS/AGWPE soundmodems in Debian and so this would not preclude the continued packaging of ax25mail-utils if the support is still there for it to be used. > In addition to that, people are actively > recruiting kernel talent to help address these issues. Do you have a reference for this? Has anyone started work? > I think loosing > the Linux AX25 kernel start would be a big loss and we need to rally and > get it repaired. If I had more time to spend on this, I wouldn't be fixing kernel AX.25 but writing a userspace daemon to attach to a KISS/AGWPE TNC and then put IP out on a tap interface. Thanks, Iain.
Attachment:
signature.asc
Description: OpenPGP digital signature