Packaging Request #3313

[jami-qt] jami-libclient and jami-qt now merged

ryry - 7 months ago - . Updated 7 months ago.

% Done:



It appears Jami-daemon and jami-libclient now merged there are only two packages required Jami-qt and jami-daemon. I believe the only one we can not now get from arch is the jami-qt package which bill-auger built for parabola when the developers added the no webengine build flag. I wasn't sure if anyone was aware of the merge changes? Would it be possible to have the newest version of the jami-qt package/pull the arch jami-daemon package as the current one no longer works (hasn't for a few months now), due to updates to some other dependency.

Many Thanks

Related issues

Related to Packages - Packaging Request #3051: [jami-qt]: requires blacklisted 'qt6-webengine''fixed




Updated by bill-auger 7 months ago

  • Priority changed from bug to wish
  • Tracker changed from Housekeeping to Packaging Request

jami-qt was the only problematic package - all jami packages are built together from the same PKGBUILD, so this is really only asking for an upgrade - all jami package will still be in [libre], except for i686 and armv7h which still have the GTK client


Updated by ryry 7 months ago

Hi bill-auger
My apologies, I didn't know if it was a housekeeping issue moreso than a packaging request, so sorry for the miss-title, Given that the jami-libclient package is now redundant in future builds. I thought this might have been what was discussed by yourself and bandali in and might have been preventing parabola from following the nightly like arch does.
Anyhows thank you anyway



Updated by bill-auger 7 months ago

I didn't know if it was a housekeeping issue moreso than a packaging request,

really, it is neither - it is simply an out-of-date package; but there is no category for that on the bug tracker - those should be flagged on the packages website; and are not not important enough to deserve a ticket, unless the out-of-date package is broken or un-installable

if "follow the nightly" means un-versioned VCS builds, we always try to avoid that as a matter of policy - arch normally does also - VCS builds should be reserved for emergency situations - jami makes proper releases; but much less often than the arch packages are upgraded - the last sourceball on was november 2021; so AFAIAC, the parabola version is still further ahead than it should be - rather than "outdated", it is actually "pre-dated"

i was hoping that the parabola package would be a one time release; but now it looks that the arch package strictly depends on webengine (and is still built from VCS), so it may need to remain on the blacklist indefinitely

i will need to look into this more - bundling the client libs with the daemon, but keeping the client separate (especially that it is the only compatible client), that does not smell quite right to me - i think we should wait until there is a new stable release to sort this out


Updated by bill-auger 7 months ago


Updated by ryry 7 months ago

I believe that they keep the daemon part separate so that the other clients such as android, ios and windows are able to use the same dameon/libs but have different clients, so that may be why it might seem a little odd?


Updated by bill-auger 7 months ago

it makes sense to package the client libs separately
to allow for a variety of multiple clients - it is odd to
package the server with the client libs, unless some client is
also in the package - quassel is an example

quassel-common    # the client libs
quassel-core      # the daemon
quassel-client    # a client
quassel-client-qt # another client

quassel-monolithic    # quassel-core + quassel-common + quassel-client
quassel-monolithic-qt # quassel-core + quassel-common + quassel-client-qt

$ pacman -Sii quassel-core | grep Required
Required By     : None

in that way, no clients depend on the daemon being installed
locally - the daemon may be running on a separate machine,
on a router or home-server for example, so that multiple clients
can be the interface of the same real session - AFAIK, jami is
also designed to be used that way


Updated by ryry 7 months ago

I think that because Jami doesn't use a client-server model and being p2p and distributed using the DHT, it means each instance of JAMI on a desktop or mobile device runs those functions, which is probably why this is so?. I think this is the way tox operates aswell, by having toxcore to do the backend stuff and having the clients of which there are a variety which all use toxcore.


Updated by bill-auger 7 months ago

but it is a client-server model - the daemon is the server - the difference is that there is not a single centralized server, which every client connects to; but each user runs a server

with typical p2p software, the client and server are the same application - your client does not connect to your server (itself); but to other people's servers, and other people's clients connect to your server - with jami, the client and server are separate programs - both your client and other people's clients connect to your server; and your server does not need to be running on the same computer as your client(s)

i have not looked into it, but maybe arch is compiling it, such that the daemon needs to be running on the same computer as the client - if that is the case, then it is effectively disabling a feature - but if that is the case, the client and daemon could be one single package, like a typical p2p application; because each is useless without the other, and no alternative clients exist - if there is only one possible client, and if there were to be exactly two packages; the logical split is with the daemon in one package and the client libs and GUI in the other package

there was an alternative client (the GTK client); but the upstream is not maintaining it anymore - if the GTK client was going to remain viable, then we would probably not be discussing this now - parabola would simply replace the QT client in arch with the GTK client


Updated by bill-auger 7 months ago

i just discussed this with the jami devs - there was a stable release today; which effectively obsoletes the GTK client

the client libs were absorbed by the QT client upstream - they are not in the daemon package, which makes much more sense; though that change makes it more difficult now, for any alternative clients to be written


Updated by bill-auger 7 months ago

  • Subject changed from [jami-qt] Jami-daemon and jami-libclient now merged to [jami-qt] jami-libclient and jami-qt now merged

Also available in: Atom PDF