Thank you bandali!
I really don’t like snaps since I learned how ubuntu intends to use them (replacing the standard apt package that gets silently deleted, leading straight to a walled garden à la Google/Apple). I understand this costs you a lot of work anyhow, and that with this you touch a lot of people in Ubuntu!
I think I’ll try to get the Debian/stable version, or else I’ll wait unstable enters testing
Thank you again for both your work and your reactivity here!
Thank you bandali!
I just come back to this unsolved discussion : I see that on my debian-testing I just cannot use the .debs associated to stable versions (or at least, the ones given on the download page for Debian… So it’s not just a matter of trying too recent…
 BUT! @bandali : I see that if on my Deian testing I download the Ubuntu .deb (not the Debian one), playing the following simulation with apt-get install -s seems to announce it is going to run fine (in French on my system):
Les paquets supplémentaires suivants seront installés :
Paquets suggérés :
Les NOUVEAUX paquets suivants seront installés :
jami-all libnatpmp1 libyaml-cpp0.6
0 mis à jour, 3 nouvellement installés, 0 à enlever et 0 non mis à jour.
Inst libnatpmp1 (20150609-7+b2 Debian:testing [amd64])
Inst libyaml-cpp0.6 (0.6.3-9 Debian:testing [amd64])
Inst jami-all (20201127.1.409973e~dfsg1-0 local-deb [amd64])
Conf libnatpmp1 (20150609-7+b2 Debian:testing [amd64])
Conf libyaml-cpp0.6 (0.6.3-9 Debian:testing [amd64])
Conf jami-all (20201127.1.409973e~dfsg1-0 local-deb [amd64])
I didn’t dare to actually try but do you think this would solve my problem and allow me to run the (Ubuntu) latest version on Debian testing?
replying to myself : doing the above works, but it created lots of conflicts afterwards with the ordinary updates in Testing, so… I had to remove it…
 @bandali I add this AFTER you answered me below, because sillily being a new user here I’m prevented to post a fourth time in the same conversation (!)
But this actualy is a reply, to thank you -I’ll track you carefully from now on!
I’ll have a look at Guix too, that I heard many positive things about, but I don’t master for now.
Indeed, I would discourage using deb packages meant for one distro and/or version on another distro and/or version. Even if all the dependencies line up by sheer luck, it is bound to break when either of the distros move on to differing package versions, and/or result in conflicts like the one you experienced.
The current situation with Debian testing is indeed unfortunate, since Jami is neither in Debian’s official testing repos nor do we provide a version for Debian testing on dl.jami.net. That said, as I mentioned before, I have been working for several weeks/months on alleviating this situation and getting Jami updated in Debian unstable and then Debian testing. Some great progress has been made, and I’ll hopefully be able to share more updates about it in the near future.
In the meantime, if you prefer to not use the Snap package of Jami, another option would be to try installing Guix on your Debian testing and install Jami using Guix’s package manager.
For this to be considered a security communications package all operating systems that jami run on should have the O.S. and current version number posted
This is just to say I continue tracking the Debian testing version, to be first in line in case anything happens
Also, I sincerely wish you the best of end-of year holiday break if any, and some rest in the environment you prefer. You deserve it, would it be just because you work for such an indispensable device as Jami!
Thanks for the feedback. I will ask the team to look into setting up such a page on jami.net.
Many thanks for the kind words, and I wish you the same.
To share some good news: after a very long time, the jami package in Debian unstable (https://packages.debian.org/unstable/jami) is now on the latest release of Jami as of last night! The migration of this version from unstable to testing is currently blocked due to a regression in the gnutls28 package (a transient dependency of jami), but will hopefully happen once that is taken care of by the gnutls28 package maintainers.
I’m hoping to continue sharing good news about this as things unfold.
And now, the latest release of Jami is also available on Debian Testing https://packages.debian.org/bullseye/jami.
Very good job.
Just wanted to let everyone know that as of recently, in addition to providing Jami packages for current/older stable versions of Debian, we now also provide packages for Debian Testing and Debian Unstable under the Debian section of the download page.
Hope this helps
But am I correct that the arm64 builds are missing for debian testing?
Yes indeed. Actually, we currently only provide builds for x86 32- and 64-bits on dl.jami.net. So for now for arm64 and other arches you’d have to refer to the Jami package from your distribution’s repositories (which may be out of date) or build Jami from source.
Thank you for your quick reply.
Building Jami on Mobian appears to be problematic, so I will have to be patient
Cheers I will be resuming my work on the Jami package in Debian’s repositories soon, which may or may not indirectly help the situation for Mobian. Regardless, if you do have a specific bug report about issues building Jami on arm64 I’d appreciate it if you could let me know, so I could try and have a look some time.
It has been a while, but I am reattempting to build Jami on the Pinephone (mobian bookworm). The other options (arm64 package for debian and the snap package) provide me with a very old version of jami-gtk without swarm.
So I am trying to build the qt-client because I want to use swarm of course.
The only problem I encounter so far is the qt version of mobian, which is lagging behind (5.17 vs 6.2).
So I guess I have to build Qt6.2 first…
Indeed. Note that the Taranis release (its tarball is https://dl.jami.net/release/tarballs/jami_20211223.2.37be4c3.tar.gz) was still based on Qt 5, so you can build that with Qt 5 and use it for a while, but sooner or later you’d indeed want to get Qt 6 since the Qt 6 migration patches have already partially been merged into Jami and future releases will use Qt 6.
Thanks, I will use this previous version for a while
To be honest, building al this stuff is still quite complicated for me.
Cheers and I can certainly understand and relate to that; Jami is a complex piece of software and not the easiest to build.
For what it’s worth, to give an update, my patch for updating Jami to latest version at least in Debian’s repos –
unstable, to be specific – has been pending review for a while: https://salsa.debian.org/pkg-voip-team/ring/-/merge_requests/7. It’s still jami-gnome and not jami-qt, but new versions of jami-gnome do have some support for swarms. So that might be promising for getting new Jami with support for swarms on Debian (
unstable) based distros. And I will start work on preparing patches for Debian for packaging jami-qt in the near future as well.
Thank you, that sounds great!
I tried different builds, and finally one worked! A brief summary:
First attempt; Cloning https://git.jami.net/savoirfairelinux/jami-project and trying to build qt version. Did not work because of the Qt version of my OS.
Second attempt; Installing Snap. It works (gtk version), but the version lags behind a lot. And I want to use swarm of course.
Third attempt; Using a tarball from https://dl.jami.net/release/tarballs/?C=M;O=D and trying to build the Qt version. Building was successful, and the daemon also started. But jami-qt itself only showed a white screen. Perhaps a problem with Qt again on mobian. I have had this in the past with other Qt programs. So that remains a mystery I still have to solve
Fourth attempt; Using a tarball (most recent one) to build a jami-gnome version. This one works fine (also with swarm). There is a small bug where I can´t get the program “in focus”, so I can´t type anything in the chat. Most of the times that this happens it can be solved using “tab”. So it is good enough to use