Packaging for Debian

[Hibby]

Hi there,

I'm Hibby MM0RFN, a Debian Developer responsible for a lot of packet radio software appearing in apt on debian/ubuntu/raspi etc.

I'd love to package ardopcf and include it in Debian - we already ship pat, and I think a modem that isn't vara and is in line with our ethos would complement that offering nicely.

It shouldn't need any work on your side - I would maintain a [https://salsa.debian.org/debian-hamradio-team/pat](mirror of the code similar to this) and I'll patch it if I run into build/usability issues, feeding patches/etc back to you. After acceptance it becomes available to users to simply apt install ardopcf (or a graphical version instead!) and over time that will filter down to raspi, ubuntu and other systems too as they pull in our updates.

I already maintain some of John's software in my private repo so that users of the UK packet network here have easy access to bpq/qtsoundmodem/etc across bullseye/bookworm/testing and we're beginning to play with ardop, so that would provide a more general availability to users on older systems who don't want to upgrade their OS right away.

Cheers!

[pflarue]

@Hibby,

I think that it would be great to have ardopcf packaged for easy installation by users of Debian and its derivatives. However, I'm not sure whether now is the right time for this. Ardopcf still has a lot of bugs and opportunities for improvement. I'm busy with other things for another month or so, but then I have a long todo list of issues that I think need attention. I have also found that most every time I dig into the code to work on one issue I discover a few more to add to the list. There are still significant portions of code written by John Wiseman that I haven't yet taken the time to fully understand.

My concern is that if a package isn't updated when new releases become available, people who have installed it via apt are less likely to take advantage of improvements available through newer releases available on GitHub. This would be especially bad if a release that gets packaged is found to have introduced a significant new bug, and the package doesn't get updated in a timely manner to fix that bug. We have just started to implement testing that will help to avoid serious regressions. Until that testing is greatly expanded, I depend mostly on my own personal ad-hoc testing, which can easily miss a serious issue.

I'm curious what sort of timeline you imagine, and I'd like to hear your response to my concern.

I'd also like to hear what Colin, @cbs228, who has made some significant recent contributions, thinks of your proposal.

Of course, a wonderful feature of Open Source software is that you don't need my permission to do most anything you want with this program. If you haven't done so already, I'd encourage you to read through the recently expanded documentation, and through some of the comments I've written relating to recent pull requests. This may help you to better understand my goals relating to future development of this project.

[cbs228]

I'd also like to hear what Colin, @cbs228, who has made some significant recent contributions, thinks of your proposal.

I would be very excited to see this software packaged for Debian! pat should have a modem to go with it. I feel that ardopcf would be straightforward to package since:

• It has minimal dependencies
• OS dependencies are already dynamic
• The host interface socket API is very stable

Packaging will give this project greater exposure. It will also give users a source of "trusted" binaries that are known to correspond to the source code. This is something that's very important to many people, including me.

I have never packaged for Debian, or anywhere else, but I understand that one of the greatest considerations is not breaking APIs and CLIs. Version numbering should reflect these changes. Breaking changes are only accepted at certain points in time. Because of this, packagers often need to backport bugfixes to maintain an old version. The less breakage we introduce, the easier their job is.

• We should probably finalize any planned CLI changes before we try and package.

• Reliability has improved a great deal from the early days of this project. If we're happy with our reliability—and are ready to absorb core dumps from any bugs that still lurk—we should proceed.

@Hibby, do you think we should ship a systemd service (vendor disabled) which will help allow unattended operation? I'm not sure if you can do sound in the root session, so it would probably need to be a user unit. We don't have syslog integration yet, but that's something I could prioritize if desired.

[Hibby]

Hi both, thanks for your comments and thoughts!

@pflarue You've hit upon both the joy and the pain of the Debian release model! Stability vs age. We release roughly every 2 years (there'll be a new one next year, Freezes will probably start January-February).

We have a few approaches to mitigate this - the unstable and testing distributions are generally kept up to date by developers like me, and major changes can be put into the stable-backports repo so that there is still an official channel for big changes to filter through - it does require user opt-in, however. Ubuntu do a new release every 6 months, but they tend to follow a similar no-updates-unless-it's-security policy.

The biggest vulnerable party to this are Raspi users - RasPi foundation update RasPi OS a few months after a Debian Stable release. The 64bit OS uses the debian official repositories but the 32bit OS is a selective rebuild of our packages and I don't think they get backports. This is why I maintain my own repos, where I'm backporting the latest official packages to bullseye & bookworm alongside my separate packaging of QtSoundModem, linbpq and QtTermTCP.

Once the freeze schedule is announced, we can take a view to see if you think development will be complete to a level that you're comfortable with for inclusion - While I could go ahead and do things, it'll make life better for us all if I at least do things in party with yourselves!

@cbs228 We're a little more relaxed than that when it comes to applications - for libraries with lots of dependencies we'll usually need to manage an ABI/API change (see: Hamlib as a prime example!) but it would but unfair if we dictated too heavily on how you develop an application! I'll have to backport security changes (CVE level) into stable, but functional stuff is generally frozen for the whole OS support cycle with optional backports as I mention.

For systemd, I ship this for direwolf as part of the debian packaging - direwolf is started as a specific user and granted a couple of groups on start. That definitely feels like an 'OS-level' thing to ship, as we can control user/group creation on install quietly for users. That's not to say you can't copy that and ship a version with some documentation on how!

In terms of packaging, I'll maintain a /debian folder which contains everyhing related to our requirements and whenever there's a new release at your end import it and upload it to the unstable archive. You won't need to worry about that bit.

I'm quite happy to do the work on packaging and maintain it in my own fast moving repo so at least there's some feedback about multiarch, different OSes and any challenges we'll have in build, and then further down the line once you're comfortable with how stable the program is etc are we can look at migrating the packaging overall to the full Debian family proper!

[pflarue]

@Hibby, getting ardopcf into your "fast moving repo" sounds reasonable at this time. If I understand correctly, you are more likely to update that repo as ardopcf is changed. If Debian is on a 2-year cycle with freezes in January/February (2-3 months away), then I think it would be better to wait another two years before doing that.

Any feedback you can provide about challenges associated with packaging ardopcf would be welcome so that we can work to address them.

@cbs228, as seen in Issue #48, I expressed some concerns about major changes to the command line. However, my recent work to expand the ardopcf documentation reminded me of the current annoying requirement to specify the host port (which can almost always keep the default value) to set the audio devices. Also, I feel less concerned about making changes to the command line options now that there exists documentation specific to ardopcf that provides a definitive reference. I'd also like to see some further discussion of the pros/cons of allowing options to be set via a configuration file as mentioned by @spudmusket in that Issue since it might make sense to coordinate such changes.

@cbs228, you mention usage with systemd. This is another area that I don't have a good understanding of, but I am reluctant to recommend using ardopcf as a long running program until it has the ability to pause and restart trying to decode incoming audio. This is important because ardopcf uses a significant amount of CPU time trying to decode incoming signals while "idle". I believe that this was the intent of the CODEC host command that is currently not functional. Fixing the CAPTURE/CAPTUREDEVICES and PLAYBACK/PLAYBACKDEVICES would also allow ardopcf to be at least partially reconfigured without restarting.

[cbs228]

ardopcf uses a significant amount of CPU time trying to decode incoming signals while "idle"

My intent behind a systemd integration is more for nodes that operate as infrastructure (WL2K, BBS) and less for "sometimes stations" that aren't always on. We would ship the unit file as "disabled by default" so as not to interfere with how most people use ardopcf today.

We could design for socket unit activation on the host interface, but that would be harder and would probably not fit cleanly into our two-socket host interface.

For applications where power consumption is critical, such as off-grid solar stations, it might be better to sleep/suspend the entire computing device rather than worry about pausing the ardopcf process or codec individually.

[pflarue]

@cbs228, I've created a new Issue #123 documenting my desire to enable the CODEC host command, and describing a use case that would be improved by having this command available.

[Dinsmoor]

I'm working on getting the packaging files filled out. Only completed the control and copyright so far. Even if we don't release to stable this year, the actual content of these files shouldn't change much for when we are ready. I'll submit a PR when I'm done with whatever I want to do. I'll leave all of the required parts I'm not sure what to fill out with FIXMEs or TODOs or something.

[Dinsmoor]

Wow WEE it has been a year already. Man. Okay, Peter, I merged your changes and updated what I had already drafted a year ago. Time flies. See PR #171

[corvus-ch]

Musing about packing ardop for Debian, I had a look at this repository. Looks like I am not the first one.

While I have no experience with Debian packaging, I am willing to learn, and I am offering my help. Is there anything, somebody with a fresh pair of eyes and some time available can help get this done?

Having this available as a package, would allow simplifying quite some installation instructions.