Add initial debian files and debian build script

[encbar5]

This is an example of how to build the debian packages. I tested this on a fresh install of Debian 11. Just run the debian_build.sh script from anywhere and it should do an unattended build of the debian packages for you. For installing on the target system, you need to make sure you also have the rpt sounds package available in the repo you are installing from. A release of that deb can be gotten here: https://github.com/encbar5/app_rpt_sounds/releases/tag/1.0.0 The target system will also need the phreaknet dahdi installed, due to dependency of app_rpt on chan_dahdi. Most definitely there is still a list of TODOs

• we need to decide on a package naming and versioning convention
• the build script right now is for local execution by a developer and still needs to be integrated into an automated build system
• need to test on other architectures and Debian major versions

[encbar5]

If you want to test installing the packages using apt-get, then you can use the private packagecloud repo that I set up for testing. (I still don't have keys to the aptly). Just run curl -s https://0caa91cfef0f84d201cb9ca144c81d23449633327087e0a4:@packagecloud.io/install/repositories/ki5kqb/asl3-testing/script.deb.sh | sudo bash to install the repo. Then run sudo apt install asterisk. Note you will also have to run phreaknet dahdi to get the correct dahdi. Then edit config files, sudo systemctl restart asterisk, and you should be online.

[encbar5]

I think it would make more sense to put this in its own ASL repo, so it can be managed more effectively. This is a big PR and this repo is really just for Asterisk source files. I think there is already a repo for this but I'm not sure. @tsawyer might have a suggestion.

I have tried various configurations of this. We are already managing a lot of inputs to this system, any one of which could break the build (phreaknet script, asterisk source, dahdi source, app_rpt). If anything this pull request is meant to generate discussion about the pros and cons.

The ASL2 way of doing this was to store the entire asterisk source, with the app_rpt source and debian source all in one repo. Already in ASL3 we are separating the asterisk source from the app_rpt source. Arguments could probably be made either way. But imagine if our goal is to do continuous builds, it complicates things to have to detect changes in two different repos (changes to a debian repo and changes to an app_rpt repo).

[InterLinked1]

The main consideration is the stuff in this repo is slated to be upstreamed to Asterisk, and that is the scope of what I'm involved in. The packaging stuff isn't related to Asterisk work so in an ideal world, this repo might eventually disappear whereas the packaging would continue on, if that makes sense.

[encbar5]

Excellent point about upstream. If we are thinking about upstreaming, however, why are we not building on vanilla asterisk? Doesn't it seem unlikely that the dozens of patches applied by phreaknet would all be accepted upstream? So we aren't really building or testing in a way that promotes integrating upstream. For all intents and purposes the phreaknet asterisk is a fork of asterisk, just with the changes stored in a script instead of in a repo.

[InterLinked1]

Excellent point about upstream. If we are thinking about upstreaming, however, why are we not building on vanilla asterisk? Doesn't it seem unlikely that the dozens of patches applied by phreaknet would all be accepted upstream?

Most of my patches are accepted upstream and I do work to get as many merged there as possible. However, we're talking about dozens to close to a hundred patches per year, which is a slow process and takes time. There are a few in particular that have not been merged that are currently needed, which Tim brought up earlier. Hopefully we'll work something out on those soon but I can't guarantee what upstream will do.

So we aren't really building or testing in a way that promotes integrating upstream.

The idea is to upstream as much as possible, so that the least amount of stuff is outside the tree as possible. This is the approach I take with Asterisk and PhreakScript. Patches also tend to be fragile, particularly for things like chan_dahdi. The long term goal is to upstream all of the patches there, but they have to be prioritized in the appropriate order.

For all intents and purposes the phreaknet asterisk is a fork of asterisk, just with the changes stored in a script instead of in a repo.

I disagree, a fork is different. A fork needs to be actively maintained to keep up with an upstream, a problem that apply patches inherently does not have. Additionally, the primary focus of PhreakScript is a wrapper around compiling to make installation easier. The patches are supplementary to address holes or missing features upstream, as an enhancement. The original goal was not simply to apply patches on top of Asterisk. Ideally, all those patches are upstreamed and the patches can be removed there. It's just a temporary stopgap.

It's a different story for DAHDI, since DAHDI is currently in a semipermanent state of disrepair and neglect.

There are a few patches there that likely will never be upstreamed, but those aren't ones that that are pertinent to app_rpt.

[encbar5]

Thank you for the good explanation. I have a lot to learn about how the upstreaming works for asterisk in particular. It does seem like a separate repo is the way to go. I can work on that. But at the same time there is some tension between the way the phreaknet script handles patches and the preferred "Debian" way of doing it using the quilt tool. Obviously phreaknet needs to handle multiple distributions whereas .Deb files not so much. It also doesn't make sense for use to develop and test using one method and then package using a completely different method. This part might need some discussion.

[InterLinked1]

Thank you for the good explanation. I have a lot to learn about how the upstreaming works for asterisk in particular.

It's maybe a bit simpler conceptually now than it used to be prior to April; at this point, it's just GitHub PRs (although with a process still). But due to the sheer volume of patches they handle, and that I alone submit, it's hard to get things merged in a timely manner. Most recently a lot of my patches from December are just now getting merged.

It does seem like a separate repo is the way to go. I can work on that. But at the same time there is some tension between the way the phreaknet script handles patches and the preferred "Debian" way of doing it using the quilt tool. Obviously phreaknet needs to handle multiple distributions whereas .Deb files not so much.

Yeah, you hit the nail on the head there. Debian is better supported in practice, but it's supposed to mostly agnostic, and even work on non-Linux Unices like BSD. Asterisk itself is supposed to be highly portable like that as well.

It also doesn't make sense for use to develop and test using one method and then package using a completely different method. This part might need some discussion.

Yes, I think this is a bigger discussion for the ASL team. Again, I only focus on the Asterisk stuff so I have my own biases here and lack of familiarity with the packaging. My main thing here is I think there should be a permanent home for what you're doing in the ASL organization.

[tsawyer]

At some point we need to meet about this. Discussion of how to go forward with packaging and the possibility of a public beta is needed. What do you guys think?

[encbar5]

At some point we need to meet about this. Discussion of how to go forward with packaging and the possibility of a public beta is needed. What do you guys think?

I'm away for one more week, but maybe ahead of the meeting we can go ahead and put together an agenda of discussion items and possible opinions. I would like to see a roadmap for ASL3 so we can understand stand how our efforts are flowing together and what to focus on. Maybe best to organize on Slack

[tsawyer]

maybe ahead of the meeting we can go ahead and put together an agenda of discussion items and possible opinions.

Would you mind starting a list of items for the meeting?

[encbar5]

I haven't looked at this in a while, but I'm not so sure about the argument for not putting the debian directory in this repo. The rpt_install.sh script doesn't look to be something that needs to be upstreamed, yet it is in this repo, and could easily be removed. The same would go for the debian directory.

[InterLinked1]

I haven't looked at this in a while, but I'm not so sure about the argument for not putting the debian directory in this repo. The rpt_install.sh script doesn't look to be something that needs to be upstreamed, yet it is in this repo, and could easily be removed. The same would go for the debian directory.

rpt_install.sh is a helper script to manipulate the Asterisk source and config files. The Debian files are neither, which is why I said they could be separated out.

Ultimately, this repo will not exist at some point in the future, it will either be merged into Asterisk or move to ASL, so that's why I figure you may as well make this as ASL repo now, because that stuff will never be merged into Asterisk. It helps keeps things separated out cleanly a bit more. That way all the packaging stuff can go in one repo, and it doesn't really have anything to do with the stuff in this repo.

[encbar5]

This has been open long enough. Closing the pull request.