I am looking for advice on running Rhasspy on Debian 11.
As of now, I can run Rhasspy on a Debain 10 VM running on Debian 11, at least well enough for basic testing. But this “feels” complicated and fragile compared to running it natively on Debian 11.
Are there basic instructions for building from source? Is it likely to be difficult to build the current version on Debian 11?
That didn’t work for me on Debian 11.
I used those instructions for installing on a Debian 10 VM. Rhasspy worked.
I used those instructions for installing on a Debian 11 VM. Rhasspy did NOT work. I noticed the rhasspy-amd64.deb package required libgfortran4, which is NOT available in Debian 10. (FORTRAN??? REALLY???) So I added the buster archives and installed the Debian 10 version. I removed the buster archives and installed rhasspy-amd64.deb. The resulting rhasspy installation did not work as it did on the Debian 10 VM. The errors reported seemed to be unresolved library references, but I did not check that carefully.
I made a first attempt to build from source by running ./bootstrap.sh but got the following error:
configure.ac:459: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
Google turns up lots of postings regarding that particular error message but none of the suggestions I found worked for me. Some referenced packages that needed to be installed on the build machine (all the packages I found referenced were installed on my build machine), some referenced errors in the autoconf script and some referenced missing definitions of configuration variables. I’m inclined to stop here until I get some info on how the rhasspy build process is supposed to work.
Maybe greg been a long time but yeah the fortran is a surprise for many but seems to get installed often with ML type frameworks.
I would stick with docker as if you get used to the premise of it being a completely isolated container from the host as that often catches me as say aplay I will think its installed then doh its a container…
docker exec -it <running_container_name_or_id> \bin\bash gives you the cli inside the container but the other gotcha is its ephemeral so on a restart all changes are lost.
docker commit creates an image off a container that will retain all changes and if you google howto with those 2 docker commands you should be past any further gotcha’s.
If its just files then you can just add those in a new volume in the docker run conf
docker run -d -p 12101:12101 \
--name rhasspy \
--restart unless-stopped \
-v "$HOME/.config/rhasspy/profiles:/profiles" \
-v "/etc/localtime:/etc/localtime:ro" \
--device /dev/snd:/dev/snd \
rhasspy/rhasspy \
--user-profiles /profiles \
--profile en
The main volume Rhasspy shares which mounts the host "$HOME/.config/rhasspy/profiles folder as /profiles in the container is usually where the conf files and stuff is.
Docker left me VERY frustrated when I tried it. And my attempt to run the rhasspy container failed on an error regarding /dev/snd.
libvirt/Kvm/qemu virtual machines are the same kind of thing as Docker, and for my current situation are preferable in every way compared to docker. Most importantly, I have rhasspy working in one.
I can indeed deploy my Debian 10 VM with a working rhasspy installation onto the target server. But that server is weak and remote, so it is managed entirely from the command line. The option of managing a rhasspy instance running natively (Debian 11) is FAR more attractive than managing a rhasspy instance running in a VM.
I finally found the basic documentation for building rhasspy:
https://rhasspy.readthedocs.io/en/latest/contributing/#setting-up-a-development-environment
That resolves this question.