I downloaded jami-20250321.0.tar.gz tarball. 
Crossbuilding is hard for me, so I decided to build with qemu. It may take a long time.
Looks like some modifications of “rules.mak” is necessary.
After inserting LIBRESSL_CONF += -DENABLE_ASM=Off into daemon/contrib/src/libressl/rules.mak, jamid was built, but I found vaapi was linked… So I should pass --disable-accel to daemon/configure and rebuild?
Edited:
I see, I forgot to disable vaapi when building ffmpeg.
Just an update on progress. I can’t get the arm64 daemon that Rubus_chiliadenus kindly built to run, and it looks like the problem is 32 bit libraries, because of course the Pi started out as 32 bit. So I think I’m just going to have to start from scratch with 64 bit Raspberry OS. From what I’ve read this is largely Debian but with a few modifications for the Pi, so it uses the Debian repositories. It’s probably for the best, but it will take me a few days to get there.
I rebuilt the Pi with 64 bit Raspberry OS, but Rubus_chiliadenus’ daemon still didn’t run, grumbling about libupnp. So I decided to run the build on the Pi itself, which as you can imagine took a long time. I followed these instructions for autotools, but this revealed the long apt-get statement for building the daemon is not quite complete; I also needed libpipewire-0.3-dev and libsystemd-dev. The long apt-get command also broke a dependency:
dpkg: libjack-jackd2-0:arm64: dependency problems, but removing anyway as you requested:
libfluidsynth3:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
libavdevice59:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
libasound2-plugins:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
gstreamer1.0-plugins-good:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
libfluidsynth3:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
libavdevice59:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
libasound2-plugins:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
gstreamer1.0-plugins-good:arm64 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however:
Package libjack-jackd2-0:arm64 is to be removed.
Package libjack-0.125 is not installed.
Package libjack-jackd2-0:arm64 which provides libjack-0.125 is to be removed.
Despite building and installing the whole thing, still it did not work, still grumbling about libupnp. After trying a few things, Rubus_chiliadenus suggested I install the packages from sid repo. Of these, only libixml would install. However, it looks like this was the key to the whole thing, as that got the daemon running.
However, there is a flaw in the instructions for creating a jamiserver account, because profile.vcf is a symlink that points to a file in a subdirectory off /home/foobar/.local/share/jami/, so when that directory is rsynced to user jamiserver on the Jami server, it continues to point to the file in foobar’s home directory, which of course doesn’t exist, requiring some fiddling around. That done, the Jami server springs to life and appears to work as intended (though I’m still playing with it).
I plan to revisit a few of the problem areas, when I have the time, including trying Rubus_chiliadenus’ daemon again.
If my memory serves, I used export DISABLE_PIPEWIRE=true to disable pipewire when building on debian 11.
Can you please advise how the Jami on servers page should be improved? Thank you
I’m trying to figure out a simple workaround for profile.vcf being an absolute symlink. Can it be safely changed to a relative symlink, either by changing the Jami code that creates it, or with a third-party tool?
I’ve come back to this having been busy with other things, but I have been monitoring what I set up. One thing I noticed is that sometimes messages were not getting through, but if I restarted Jami on the Pi it would clear the log-jam. I put in place a temporary cron job to restart the daemon on a regular basis, but there have been many improvements to Jami since then, so yesterday I finally rebuilt and installed the daemon from source. I’ve noticed that the server does not appear in the list of linked devices on other devices. Digging deeper I found that config.yml contained the name of the device from which I copied the configuration (“Copy the Jami configuration files” in the Jami for servers documentation). However, editing that and restarting the daemon did not cause the server to appear in the list of linked devices. I also recall sblin saying that copying the config across would cause problems since a new device key would not be created. I think my next move will be to attempt to build and install the qt client on the Raspberry Pi (shouldn’t take more than a few eons), and use that to set up the server configuration (thankfully this Pi does have a fully operational graphical desktop), but does anyone have any better ideas?
Edit: Looks like building the client is not an option, at least not with the Qt packages in the Raspberry OS repo:
CMake Error at CMakeLists.txt:191 (message):
Qt 6.6 or higher is required. Found 6.4.2
Theoretically, there will be no problem if the copied profile is not continued to be used on the old device.