OP25 Docker Image Created / Looking for Testing

[NebraskaCoder]

Hello all!

I decided to create an OP25 (Boatbod Version) Docker image. It is functional for the most part but still has some bugs to work out. I published the image on Docker Hub at Docker Hub and the source code/run scripts at NebraskaCoder/op25-docker. I wanted to create this as I wanted to run OP25 on Ubuntu 20.04 but didn't have the knowledge to modify it to work under Python3 as the default.

Right now, the biggest issue I notice on my machine is that the audio will stop after so long (I haven't been keeping track of how long). This is possibly because I am redirecting the /dev/snd device to the container but I'm not certain that is the actual cause.

The image is good to use alone but note that if you use the docker-compose that I made, it must be ran using the HTTP interface as the terminal won't work.

The source for the image is on the GitHub repo under the build folder. Since I have already published it to Docker Hub, there shouldn't be a need to compile it (that'll save you 10+ minutes of setup).

All of the configuration files are in the config folder when using my docker-compose. If you use the image without my docker-compose file, you'll have to map a config folder with your start up script/trunk files OR override my default start command.

I plan to also make an image with audio streaming (darkice/liquidsoap/etc...)

I'd appreciate any feedback. This is a work in progress, so updates may come rapidly until it becomes stable.

 

[NebraskaCoder]

Actually, I have decided to move the Dockerfile to the root directory instead of a build directory.

 

[eorange]

Just curious...what advantages do you anticipate by running this in a container? Or is it just to see if you can, which I totally get.

 

[NebraskaCoder]

The main one right now is running OP25 on Ubuntu 20.04+ as last time I checked it was fighting with Python3. I'm still experimenting with other benefits. One thing I do like is being able to have a clean build every time the container is restarted. Also, not having to wait 10+ minutes for OP25 to build (well, I do when I build the image but other people won't). Hopefully, this presents a stable build for people familiar with Docker but not OP25. People who modify the code may not find much benefit to this. I'm not sure if it is or is not beneficial to advanced users of OP25 (so I guess a little of to see if I can).

 

[NebraskaCoder]

Maybe 10+ minutes isn't accurate (that's how long it took Docker to build it). 5+ for me.

 

[boatbod]

Maybe 10+ minutes isn't accurate (that's how long it took Docker to build it). 5+ for me.

Build time is entirely depending on the speed of your hardware. A complete build on an RPI3 is excruciatingly slow, whereas the same build on an RPI4 is somewhat tolerable and on my i7 development machine it's quite speedy.
I assume you are aware of the reason neither I nor Max offer pre-built/packaged versions of op25?

 

[NebraskaCoder]

Build time is entirely depending on the speed of your hardware. A complete build on an RPI3 is excruciatingly slow, whereas the same build on an RPI4 is somewhat tolerable and on my i7 development machine it's quite speedy.
I assume you are aware of the reason neither I nor Max offer pre-built/packaged versions of op25?

I can't say that I am.

 

[KA1RBI]

The main one right now is running OP25 on Ubuntu 20.04+ as last time I checked it was fighting with Python3.

The ubuntu 20.04 and python3 issues have been fully sorted but not sure how much of that work has migrated to Graham's repo.

The difference is a matter of executing one extra command over and above the standard install (see the file README-gr3.8.patch in the TLD of the repo)...

Max

 

[boatbod]

The ubuntu 20.04 and python3 issues have been fully sorted but not sure how much of that work has migrated to Graham's repo.

The difference is a matter of executing one extra command over and above the standard install (see the file README-gr3.8.patch in the TLD of the repo)...

Max

My repo should already be python3 compatible. Max's gnuradio 3.8 patches are included but I have not spent any time testing the build process on 20.04. It's on my to-do list, but I haven't had the opportunity to set up a virtual environment yet. Maybe I'll get to it over Christmas.

 

[NebraskaCoder]

After learning of reasons for why things are done the way they are done today, I might remove the prebuilt image and just keep the repo that builds the Docker image manually locally. This would negate any time savings for the first build (one of my bullet points) and with Python3 support coming, that negates that bullet point. I guess this just leaves this project for people that want to keep a clean environment or any other benefits that I'm not seeing. I do, myself, like having a fresh start every time I reload the container. I guess I won't go too far with this project and just publish the source code I have out there in case someone wants to use it and build the image themselves.

 

[boatbod]

My repo should already be python3 compatible. Max's gnuradio 3.8 patches are included but I have not spent any time testing the build process on 20.04. It's on my to-do list, but I haven't had the opportunity to set up a virtual environment yet. Maybe I'll get to it over Christmas.

ETA: the gr-3.8 patch does not run against my repo without editing. I'll see what I can do to expedite the needed changes.

 

[eorange]

After learning of reasons for why things are done the way they are done today, I might remove the prebuilt image and just keep the repo that builds the Docker image manually locally. This would negate any time savings for the first build (one of my bullet points) and with Python3 support coming, that negates that bullet point. I guess this just leaves this project for people that want to keep a clean environment or any other benefits that I'm not seeing. I do, myself, like having a fresh start every time I reload the container. I guess I won't go too far with this project and just publish the source code I have out there in case someone wants to use it and build the image themselves.

Are you saying you will be able to build the Docker image from source every time, as needed?

 

[NebraskaCoder]

Are you saying you will be able to build the Docker image from source every time, as needed?

So, I just tested things, and yes. It will build it and then cache it so that you don't have to build it every time you run it. I will make a separate script to force a rebuild for when boatbod updates his repo. Otherwise, my start script will build the image the first time and reuse the built image other times. If I find the time, maybe I'll make a Python script so that it can be more interactive and also check for new boatbod commits and ask to rebuild the image.

 

[boatbod]

I've been working on Ubuntu 20.04 / Python3 / gr3.8 support today and it's reached the point where I think it is mostly working in my 'dev' branch. There's still some work to do but it should be good for P25 using either rx.py or multi_rx.py.

 

[NebraskaCoder]

I've been working on Ubuntu 20.04 / Python3 / gr3.8 support today and it's reached the point where I think it is mostly working in my 'dev' branch. There's still some work to do but it should be good for P25 using either rx.py or multi_rx.py.

I'll pull down a copy and test.

 

[boatbod]

I'll pull down a copy and test.

Right now my only known deficiency is the TRBO trunking module, but that probably isn't being used by anyone. I'm sure other glitches will show up though... there are some really weird differences between python3 and python2 string handling that don't make themselves know until you hit an error at runtime.

 

[NebraskaCoder]

Right now my only known deficiency is the TRBO trunking module, but that probably isn't being used by anyone. I'm sure other glitches will show up though... there are some really weird differences between python3 and python2 string handling that don't make themselves know until you hit an error at runtime.

I don't. We only have Capacity Plus and Connect Plus around here. I know what you mean by thr string handling as well. I started Python about a year and a half ago to two years ago, and Python3 was mainstream, so I started on Python3.

 

[NebraskaCoder]

Right now my only known deficiency is the TRBO trunking module, but that probably isn't being used by anyone. I'm sure other glitches will show up though... there are some really weird differences between python3 and python2 string handling that don't make themselves know until you hit an error at runtime.

So, it wasn't obvious to me at first that I needed to patch before running install but I got through it (after reverting a VM snapshot I made before running install). After, it looks like io isn't being imported? I have created pull request (Add missing io import by NebraskaCoder · Pull Request #86 · boatbod/op25) to fix this.

user@DESKTOP:~/op25/op25/gr-op25_repeater/apps$ ./rx.py
Traceback (most recent call last):
  File "./rx.py", line 1026, in <module>
    sys.stderr = io.TextIOWrapper(sys.stderr.detach().detach(), write_through=True) # disable stderr buffering
NameError: name 'io' is not defined
user@DESKTOP:~/op25/op25/gr-op25_repeater/apps$ ./op25.sh
user@DESKTOP:~/op25/op25/gr-op25_repeater/apps$

 

[boatbod]

So, it wasn't obvious to me at first that I needed to patch before running install but I got through it (after reverting a VM snapshot I made before running install). After, it looks like io isn't being imported? I have created pull request (Add missing io import by NebraskaCoder · Pull Request #86 · boatbod/op25) to fix this.

user@DESKTOP:~/op25/op25/gr-op25_repeater/apps$ ./rx.py
Traceback (most recent call last):
  File "./rx.py", line 1026, in <module>
    sys.stderr = io.TextIOWrapper(sys.stderr.detach().detach(), write_through=True) # disable stderr buffering
NameError: name 'io' is not defined
user@DESKTOP:~/op25/op25/gr-op25_repeater/apps$ ./op25.sh
user@DESKTOP:~/op25/op25/gr-op25_repeater/apps$

Thanks for catching that; late yesterday evening I added a magic incantation to force stderr to be unbuffered and tested it on multi_rx, but then when I placed the same code in rx.py I forgot the required import io. Doh!

 

[NebraskaCoder]

Thanks for catching that; late yesterday evening I added a magic incantation to force stderr to be unbuffered and tested it on multi_rx, but then when I placed the same code in rx.py I forgot the required import io. Doh!

It was the home stretch and as soon as I saw it I knew that one would be easy to fix.