When do you plan to have debian Bullseye builds and a self install script for boards other then the pi boards ?
We have a guy for that and he knows he needs doing but he’s busy… family new job… you know the drill.
Does he want any help?
Maybe, kc1kcc is here on community.
We need updated pkgs and a updated build. I would also like to see a web gui like openrepeater . So that if used in repeater mode its easier for the end user.
I want to be able to install on a radxa zero or other board with a install script… I prefere more open boards then the raspi . and with current cost of pi boards other boards are cheaper.’
I tried, but it depends on libsnmp30, which is no longer available on 11…
root@repeater:/tmp# apt install asl-asterisk
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:The following packages have unmet dependencies:
asl-asterisk : Depends: libsnmp30 (>= 5.7.3+dfsg) but it is not installable
E: Unable to correct problems, you have held broken packages.
root@repeater:/tmp#
I’m looking into a INOVATO Quadra… it’s $29.95 comes with a case, HDMI cable and power pack…IT runs Debian Bulleye 64-bit. Shipping is less than a week US- Canada only. It has the horsepower of a RPI3 which has been made of unobtainum for the last year…
I tried the wiki instructions to load on a Debian machine but they failed… I see I am not alone…
This little guy is real easy to SSH into… and has 2.0 and 3.0 USB ports… and a SD card slot. Debian IS FLASHED IN 16Gb MEMORY…
I’d send KC1KCC one if it would speed things up with development
Larry W8LM
The Inovato Quadra is ARM64 and there is no arch in the current ASL repo. I’m twisting a couple of arms to get a build but don’t hold your breath. The number of people that can do this task are few.
1 Like
1 Like
I was able to install AllStarLinux on Debian 11 (Bullseye) on an x86-64 VM. I used the ASL repository and installed from packages. There were two different errors I needed to overcome:
-
Certain dependencies of the asl-asterisk package are not available on Bullseye. To get around this, I added the Buster repository. Here’s a generic reference that can help you to do that: (Grr! As a new user, I can’t add links. unix dot stackexchange dot com slash questions slash 60555 )
-
The asl-dahdi-dkms package would not compile on my kernel (5.10.0-20-amd64) using the package currently in the repository as of 20230116. So I had to modify the source code and re-package the .deb. Here’s a generic reference on how to extract a .deb, repackage it and manually install it: How to manually modify a .deb package | Alexandra Zaharia
There were two problems with the source code. First, .ioctl has been removed from the file_operations struct, so you need to use either Unlocked IOCTL or Compatible IOCTL. I am not sure which should be used here, so I used Unlocked IOCTL. There are two files that need modification in the /usr/src/asl-dahdi-3.0.1.20200801-0.1/drivers/dahdi path: dahdi-base.c and dahdi_transcode.c . For each of these, I added the following to the top of the file:
#define HAVE_UNLOCKED_IOCTL
The second error is a missing symbol for vpmadtreg_register and vpmadtreg_unregister. These are for a specific model of hardware echo-cancelling boards, which I do not have. So I simpy remmed out the calls for those two functions in usr/src/asl-dahdi-3.0.1.20200801-0.1/drivers/dahdi/vpmadt032_loader/dahdi_vpmadt032_loader.c (which were lines 134 and 140 for me).
Remember to update the md5sums for those three files when you rebuild the deb…
To install, I simply followed the same instructions in the Beginner’s Guide for repository: start with the Install_from_ASL_Repository section and go from there, with the following changes:
Before I began, I added the Buster repo. Before I installed the asl-dahdi-linux package, I downloaded the asl-linux-dkms package (apt download asl-linux-dkms), extracted it, modified the files (including the md5sums), and re-packaged the deb. I then installed its deps manually (apt install dkms gawk), then manually installed the rebuilt package (dpkg -i ). You can then continue with the guide, including installing the asl-dahdi-linux package as normal.
I am a very new ASL user, so I may have missed something: my quick and dirty hack may have broken something and I just haven’t found out what yet. But I was able to connect my node to a local repeater and I have used outputstreamcmd to hear the audio. Hopefully this will continue to work, and if there are other problems maybe someone else will be able to get us all a little farther was well!
1 Like
After doing this on Debian 11 (Bullseye) x86-64, I wanted to do it on ARM, too. Unfortunately, ASL does not yet have a repository for AArch64 (arm64), and all of my ARM VM infrastructure is AArch64, so no testing there. At this point, support for armhf is actively shrinking and I’m really not interested in moving in that direction. So, no ARM testing from me at all.
However, during the process I gave it a try on Ubuntu 22.04 (Jammy) x86-64. This uses kernel 5.15 and GCC 11. I used a very similar process to what I documented above. There were two additional changes needed in dkms/extras-data/usr/src/asl-dahdi-3.0.1.20200801-0.1/drivers/dahdi/Kbuild to address changes in GCC 11 over GCC 10 (used in Bullseye):
-
Add " -Wno-implicit-fallthrough -Wno-misleading-indentation" to the end of the CFLAGS_MODULE line
-
Find the “hostprogs-y := makefw” line and change it to be “hostprogs-always-y := makefw”.
With those changes and the ones in my post above, I was able to complete the installation of ASL on Ubuntu 22.04. The only testing I have done is to create a loopback ALSA device, use outstreamcmd to push the audio out via aplay, and then use sox and netcat to pipe the audio to my workstation. I was able to connect to a node on a local repeater and hear my audio!
There’s a link above that says ASL won’t compile on any kernel newer than 5.15. I don’t have enough desire to try a newer kernel; with Bullseye and Jammy we’ve got more than 3 years before EOL, so that’s enough for now.
1 Like
@ad8jl I’m glad you go this working on x86. It seems there is some desire in the community to get ASL working on more recent versions of Debian. I have had this running on Raspberry Pi OS, 64bit (aarch64) Debian 11.6, kernel 5.15.32 for some time now, with my own source code modifications. Maybe I’ll message you to see if you want to collaborate on getting the ASL project up to speed with Bullseye. Below I’ll just put a couple of notes about things you ran into that I also ran into.
ke5gdb already did a patch to the Dahdi source for it to work on kernels 5.9 and above. See this pull request:Fixed compilation issues on 5.9+ kernel versions by ke5gdb · Pull Request #1 · AllStarLink/ASL-DAHDI · GitHub
I tried getting the admins to merge the pull request, but for some reason they were not convinced yet. If you could test the patch, mabye you want to add a comment or bump to that pull request, you can let them know that the patch works and would have helped you.
The approach I took here was to just do the research to see what the packages had been renamed to. I think this would be preferable to adding packages from a previous release. Here is what works for me on the Bullseye repo for installing build dependencies:
apt -y install quilt libreadline-dev libgsm1-dev libssl-dev libasound2-dev libpq-dev \
unixodbc-dev libpri-dev libvpb-dev libnewt-dev libsqlite3-dev libspeex-dev \
libspeexdsp-dev libcurl4-openssl-dev libpopt-dev libiksemel-dev freetds-dev libvorbis-dev \
libsnmp-dev libcap-dev libi2c-dev libjansson-dev build-essential libtonezone-dev \
git cmake g++ libboost-all-dev libgmp-dev swig python3-numpy libusb-dev
You can let me know if this works for you.
If you want to try it, here is my branch that I build for my own aarch64 device: GitHub - encbar5/ASL-Asterisk at mydevelop
Looks like Artemia76 also attempted changes for this in the following pull request: Aarch64 portage by Artemia76 · Pull Request #35 · AllStarLink/ASL-Asterisk · GitHub
I ran into this problem as well, and have it in this commit on my repo: Kbuild change hostprogs-y to hostprogs · encbar5/ASL-DAHDI@4158740 · GitHub
I didn’t create a pull request, because as you note this syntax is compiler version dependent, so it only makes sense to merge this for a repo that’s dedicated to Debian 11 compatibility.
This just adds warnings to the compiler output but doesn’t modify code, right? I definitely didn’t add this to my build, so I’m just curious what prompted you to make this change, in case I’m missing something.
Again, nice work and thanks for sharing all your effort!
1 Like
I’m not familiar with this forum, and I don’t see an easy way to quote a previous message, so I apologize for the top-posting…
Anyway: To give you some perspective from me: I’m not interested in depending on non-project repositories, third-party-modified or -compiled material, etc. I’m perfectly fine with my own randomly-modified nonsense… 
I’m also very happy to hear about other people’s random modifications (and to share my own), but if I’m going to go in that direction, I want to make those same modifications on my own, starting from official project-supplied material. However, this project seems to be a challenge, in that the main code is still being worked on, but very slowly – so not attractive for a simple fork, but not nearly fast enough to keep up with the changes in the rest of the ecosystem. So we’ll see how well I’ll be able to do that.
ioctl changes
It seems that the patches you point out add both UNLOCKED_IOCTL and COMPAT_IOCTL (which are not mutually exclusive, and aren’t even overly related to each other). So my change, while clearly a hack, is not far from the proposed solution. Thank you for pointing me in that direction. From my research, it seems that one or the other of those have been expected for a long time (sometime in the 2.6 days), and that this recent change is simply removing the backward-compatibility cruft; seeing as the ASL DAHDI code clearly is aware of the new way of doing it, I don’t see why this should be a problem. Given that it’s very unlikely that anyone is going to want to run this on something as old as a 2.6 kernel, I think the proper solution is to simply drop the pre-2.6 backward-compatible code and simply adopt the UNLOCKED_IOCTL and COMPAT_IOCTL code full-time. If nothing else, it’s an even cleaner patch…
When I get a chance, I will try the patch. I expect zero difference, but there’s a reason why you test… It won’t likely be until after Winter Field Day, though: too much work to do before then.
Renamed dependencies
The big dependencies that were an issue were SNMP3 and SQLite0: these are essentially obsolete packages, replaced by (possibly not fully backward-compatible) newer versions, with intentionally-different names (likely because of that not-quite-backward-compatible thing). Given that I have zero experience with ASL, I did not know if this would be an issue, hence the using the properly-named packages – and, sadly, all the downlevel junk that they are dependent on as well. Adding the Buster repository was merely expedient, certainly not a good idea. But if there’s a way to do this without changing the ASL packages and using all Bullseye packages, I’m all for it. I will try this when I try the above patch.
Out-of-project repositories/third-party-compiled code
I addressed that in the intro; if I had to, I would rather compile everything myself. But my need for ASL does not justify that – I much prefer project-supported packages and repositories to custom-compiling – and I don’t want to run on an entire architecture that the project does not support. If the project won’t support it, I’m not going that far on a limb, especially as a brand-new user. My issue is I would prefer to run ASL on an external VM than on hardware, and my Arm VM infrastructure is all AArch64. So if it has to stay on x86, so be it.
Compiler warnings
This doesn’t add warnings; it turns off warnings. This was on Ubuntu Jammy, based on GCC11. Debian Bullseye is still using GCC10. These warnings are new for GCC11 (afaik), which is why they only have to be added on GCC11. I think both of these warnings are valuable, and worth addressing so they could be left on; but not only is it not my codebase, it’s not really ASL’s either, so ultimately it’s up to Digium/Sangoma to address. But if you want it to compile with -Werror, you’ll have to turn them off for now. So I did.
Next steps for me
Right now, my immediate obstacle is finding a low-latency method of getting the audio from a VM-based ASL to a different workstation across the public Internet. I can successfully get audio out of ASL via outstreamcmd and then push it around to wherever (via ALSA, PulseAudio, lame, ffmpeg, etc.), but the results have been poor. I haven’t had much time to see what other options are available yet. (Next step might be to investigate using IAX to push the audio to an actual Asterisk box and deal with it from there, but I haven’t even Googled to see if that’s a viable plan yet.)
I also don’t own any radio hardware that I can use with ASL yet. I do have a CM108 USB dongle that I’m very willing to modify, but I don’t have a radio with COS available. I’ve only been a ham for less than 4 months, so I don’t have a lot of spare radio equipment. I do have several different types of 2m/70cm radios, but I don’t have a lot of experience (or at this moment, desire) to modify them.
Finally, I’m much more focused on improving my current understanding about the project itself: if I understand it correctly, we’re using code from a repository that hasn’t been updated in two years, and seems to depend on downlevel dependencies? I’m also unclear on how safe and up-to-date the underlying Asterisk code is: it at least says it’s based on Asterisk 1.4.23, which was released literally 14 years ago. I’m not at all certain my understanding is correct, so I’m still trying to dig into this. But this is why I’m only using this on VM’s outside of my network.
All of this is a long-winded way of saying that my biggest hurdles at the moment are not about getting it deployed, even on the newest OS or CPU architecture. I’ve proven that I can make that work well enough. My biggest obstacles are fundamental worries about the project in general, my current lack of ASL-optimized radio equipment, and the fact that my worries about the project make it harder for me to implement (e.g. keeping it off my local network), and do not encourage me to invest in my lack of equipment.
But hey, just because I’m a picky snob doesn’t mean others can’t use it, which is why I wanted to document how I found to make it work and share it with others! And thank you very much for sharing your results. I will test what I can and let you know how things turn out on my side.
Here’s a followup with the testing I said I would perform. This time I’ve included details of exactly what I did. I intentionally did not include these details last time: they work fine today, but could break at any time. In order to do this properly, you likely need a decent amount of Linux experience, even with these extra details. Of course, if you’re choosing to install via packages, it’s probably because you have that experience. So here are my details. Use at your own risk.
Renamed dependencies
I looked more carefully at the provided list of dependencies. It seems that those are dependencies for when you’re compiling ASL from source. This thread seems centered on using the pre-compiled packages, and that is also my specific target. In any case, your list of dependencies did not allow me to use the ASL-provided packages on Bullseye.
Playing with it did motivate me to not be lazy and figure out the dependencies by hand. As previously mentioned, there are two libraries we need from Buster: libsnmp3 and libsqlite0. Here are the commands needed to install the latest oldstable (Buster) versions of the missing libraries. NOTE You really should make sure that you’re getting the latest versions of these libraries: use http://packages.debian.org to search for “libsnmp3” and “libsqlite0” and get the download URL’s from there! (But seeing ASL is using a years-old fork of Asterisk, what’s a couple more libraries, right? 
)
First, there are a few dependencies that these libraries themselves need that are provided by Bullseye. Seeing as apt can’t install local packages and dpkg can’t install dependencies (where’s yum/dnf when you need it?), we have to install these dependencies by hand. And because dpkg won’t install from URL’s (my kingdom for dnf!), we have to manually download them. This is where you should be updating the URL’s to use latest libraries after a package search! Finally, there’s one more dependency to deal with: libsnmp3 wants libperl5.28. However, we already have libperl5.32 installed (you can confirm with: apt list --installed | grep "libperl"), and this should work just fine instead of the requested 5.28. We will use equivs to create an empty libperl5.28.0 package that will make everyone happy:
apt install libmariadb3 libsensors5 libsnmp-base
wget http://security.debian.org/debian-security/pool/updates/main/n/net-snmp/libsnmp30_5.7.3+dfsg-5+deb10u4_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/s/sqlite/libsqlite0_2.8.17-15_amd64.deb
apt -y install equivs
equivs-control libperl5.28.control
sed -i 's/<package name; defaults to equivs-dummy>/libperl5.28/g' libperl5.28.control
sed -i 's/# Version: <enter version here; defaults to 1.0>/Version: 5.28.0/g' libperl5.28.control
equivs-build libperl5.28.control
dpkg -i libperl5.28_5.28.0_all.deb libsnmp30_5.7.3+dfsg-5+deb10u4_amd64.deb libsqlite0_2.8.17-15_amd64.deb
Here’s an overview of how I got to those commands. Start with a throwaway installation. Follow the installation instructions until you get to a point where a needed package isn’t available. Add the Buster repository (details of doing this are an exercise left for the reader: see my previous post for links that may help guide you). Now redo the apt install that failed, and it should work for you by pulling down the proper packages from Buster. Finally, get the list of packages currently installed: apt list --installed > busterpackages. Look in that file for packages that only came from Buster (hint: look for “/oldstable”). In my case, 4 packages were needed: libsqlite0, libsnmp3, and two different perl 5.28 packages. To resolve this, I scrapped that install and created another throwaway install. This time, before I installed the package that would fail, I downloaded and installed (via dpkg) the missing packages. Of course, they very likely won’t install directly, either: you’re going to need to figure out what dependencies they have, and then determine if you can meet those from packages found in Bullseye. If not, you have to figure out if you need more packages from Buster, or if you can create empty packages to bypass those dependencies completely. Once you get all of that worked out and documented, you’ll probably want to trash that install and use your new process on a clean install. That will confirm that your process is correct. Otherwise, you get to figure out what mistakes you made, update your process, trash your install (again!) and redo it until you get it right! (Yeah, I wish I could have gotten it done in 2 installs; I think it was more like 4…)
Hopefully, the ASL people will simply update their packages for Bullseye in the future and save a lot of people a lot of work!
ioctl changes
When I get a chance, I will try the patch. I expect zero difference, but there’s a reason why you test…
I tested this: I used the link you included to download a diff (by adding “.diff” to the URL for the pull request above) and apply it to the extracted package, then package everything back up and install it, working around the same limitations of apt/dpkg as were described above:
apt download asl-dahdi-dkms
mkdir dkms && cd "$_"
ar x ../asl-dahdi-dkms*.deb
mkdir extras-control extras-data
tar -C extras-control/ -xf control.tar.xz
tar -C extras-data/ -xf data.tar.xz
wget https://patch-diff.githubusercontent.com/raw/AllStarLink/ASL-DAHDI/pull/1.diff
cd extras-data/usr/src/asl-dahdi-3.0.1.20200801-0.1/
patch -p2 < ../../../../1.diff
cd ../../../..
rm 1.diff
nano extras-data/usr/src/asl-dahdi-3.0.1.20200801-0.1/drivers/dahdi/vpmadt032_loader/dahdi_vpmadt032_loader.c
No one has made a patch for this, and I’m not going to put something this ugly out on GitHub – and I’m too lazy to resolve this for hardware I will never use. So, we hack: Find “vpmadtreg_register” (line 134) and add “//” to the beginning of the line. Find “vpmadtreg_unregister” (line 140) and add “//” to the beginning of the line. Save and exit.
cd extras-data
find usr -type f -exec md5sum '{}' \; > ../extras-control/md5sums
rm ../data.tar.xz
tar cfJ ../data.tar.xz *
cd ../extras-control
rm ../control.tar.xz
tar cfJ ../control.tar.xz *
cd ..
rm ../asl-dahdi-dkms_1%3a3.0.1.20200801-0.1_all.deb
ar r ../asl-dahdi-dkms_1%3a3.0.1.20200801-0.1_all.deb debian-binary control.tar.xz data.tar.xz
cd ..
apt -y install dkms gawk
dpkg -i asl-dahdi-dkms_1%3a3.0.1.20200801-0.1_all.deb
Continue with the rest of the ASL by package instructions.
Low-latency audio
On a VM, using outstreamcmd to push the audio out to Linux audio infrastructure works for a quick test, but the latency is very poor. In the end, I ended up abandoning it and just attached a SIP phone to it. That gave me low-latency audio to monitor a repeater, but I ran into other rough edges: audio levels, DTMF PTT issues, etc. I ended up going farther into the world of questionable security of decade-old binaries and set up IAXrpt, which worked more smoothly. My next step is to try to use IAX to connect ASL to a generic (and up to date!) Asterisk system and see if it might resolve some of my issues on the VoIP side, and allow me to separate VoIP (where I have a lot more experience) and ASL (where I’m very new). Eventually I will work on radio interface items, but this will likely push me into having to run ASL on local physical hardware and I’m not sure it’s worth the hassle and security risk at this point. None of that is really relevant to this thread anyway…
So that’s a bit of a recipe on how to intsall ASL via packages on Debian 11 (Bullseye). I hope it is useful for others, until the ASL team catches up with the latest changes.
1 Like
I am able to compile, make and make install with no errors on Deb 11 on an amd64 netbook but something seems to be missing from the make install because it is not setting up asterisk as a service, and not putting asl-menu in an accessible location. For those above who got it working on 11 did you have to do anything special to get asterisk running as a service? ie. ‘sudo service asterisk status’ shows there is no such service defined. If I run asterisk from the command line to start it and then run asterisk -vvvr it gives some errors saying can’t find a /dev/dahdi subfolder. But the make was all fine with no errors so it would appear some steps of the make install are not being done yet no error gets displayed.
I was doing this for an ARM device, not x86, and it’s been so long since I did it, but based on your comments I’m vaguely remember that yes there were several things I had to manually fix after the install. The programs in sbin aren’t copied over, so I just did it manually. I may have even created my own service unit file in /etc/systemd/system to run asterisk.
The missing dahdi device is because you probably need to install the dahdi kernel module, which on x86 can be as easy as sudo apt install dahdi-dkms
ASL is now working on my ($50) netbook with Debian 11! Everything is working great, installed Supermon and AllScan, now monitoring a net on the Keller Peak repeater, with an ANR100 Radio-less node plugged into the netbook.
As alluded to above this was not easy to do but for anyone else who wants to do it, this is basically what I did:
- Install Debian 11
- Follow steps on ASL github page to compile latest ASL from source
- There is an error during ./configure but if you google the error message there’s an easy fix
- Do the make and make install. They complete fine but don’t actually install ASL.
- Review all the posts above, and run the commands in AD8JL’s most recent post above. You may also need to run
sudo apt install dahdi-dkmsagain as suggested in above post. - Run commands in N5UD’s solution in Beta2rel6 multiple problems WYSE 3040 - #6 by kk6rq
You can now run asl-menu and everything went smoothly for me from there.
Thanks for everyone’s input on this.
2 Likes
Thanks, David; I’ll keep this bookmarked for later; finally got a working Buster install that I’ll hang onto until I work out my hardware problems (backwards 5v reading, despite triple-checking my wiring!); I bought multiples of all the boards so should be easy enough to troubleshoot. Thanks for putting in the work on that.
-Bob
KK6RQ