As part of creating the custom wspr spot server and building WSJTX from source I created a docker container that contained WSJTX build from source such that I could keep the version of WSJTX that I was build separate from the one that I had on my local machine, it also meant that once build I could use that version of WSJTX anywhere I had docker and not worry about missing dependencies.
Building the container
For the contianer I wanted the latest version of WSJTX, so I opted to download the latest version of WSJTX directly from their git repositiory. As for building the container I largely translated the instructions here. This resulted in the following docker file:
ENV TZ 'Australia/Melbourne'
RUN echo $TZ > /etc/timezone && \
apt-get update && apt-get upgrade -y && \
apt-get install -y tzdata && \
rm /etc/localtime && \
ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && \
dpkg-reconfigure -f noninteractive tzdata && \
apt-get install -y autoconf automake libtool cmake git && \
RUN apt-get install -y build-essential gfortran asciidoctor libfftw3-dev qtdeclarative5-dev texinfo libqt5multimedia5 libqt5multimedia5-plugins qtmultimedia5-dev libusb-1.0.0-dev libqt5serialport5-dev asciidoc libudev-dev
RUN mkdir /hamlib
RUN git clone git://git.code.sf.net/u/bsomervi/hamlib src
RUN cd src && git checkout integration && ./bootstrap && mkdir ../build && cd ../build && \
../src/configure --prefix=$HOME/hamlib-prefix --disable-shared --enable-static --without-cxx-binding --disable-winradio CFLAGS="-g -O2 -fdata-sections -ffunction-sections" LDFLAGS="-Wl,--gc-sections" && \
make -j4 && make install-strip && cd ../../
RUN mkdir /wsjtx
RUN git clone https://git.code.sf.net/p/wsjt/wsjtx wsjt-wsjtx
RUN apt-get install -y qttools5-dev
RUN mkdir build && mkdir output && cd build && cmake -D CMAKE_PREFIX_PATH=~/hamlib-prefix -D CMAKE_INSTALL_PREFIX=/wsjtx/output ../wsjt-wsjtx/ && cmake --build . -- -j2 && cmake --build . --target install
This can be built using the following docker command:
docker build -t wsjtx .
The entrypoint for the container could be changed from “/bin/bash” to “/wsjt/output/bin/wsjtx” if you want to automatically run WSJTX when the container starts. But having bash as the default allows for easier access to the other tools that come with WSJTX.
Running the container on Linux
In order to run the container on Linux, we need to solve 2 problems. Firstly we need the container to be able to access the Xserver running on the host machine and secondly, we need the container to be able to access the audio devices on the host machine. Thankfully jessie frazelle has a blog post on doing just that where they run spotify in a container. So for our use case this becomes:
docker -it --device /dev/snd:/dev/snd -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY wsjtx
This can also be extended to pass through UART ports required for rig control, although I haven’t explicitly tested this as I was interested in the receiving and decoding.
Running the container on Windows
Running the container on windows is a little tricker as by default there is no X Server we can pass through and audio devices are handled differently.
Thankfully it can still be achieved we just need to get an Xserver and the Windows port of PulseAudio to make this work. For the Xserver I followed the advice of Robin Kretzschmar who used
vcxsrv installed via the
chocolatey package manager for windows. For PulseAudio searching the web turned up this stackoverflow outlining this exact problem.
Once I had followed both sets of instructions, and started both PulseAudio and my local Xserver I was able to run wsjtx using the following command:
docker run -it -e PULSE_SERVER=tcp:192.168.8.160 -e DISPLAY=192.168.8.160:0.0 wsjtx /wsjtx/output/bin/wsjtx