Project

General

Profile

Packaging Request #3313

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

ryry - 23 days ago - . Updated 20 days ago.

Status:
open
Priority:
wish
Assignee:
-
% Done:

0%


Description

Hi
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
Ryan


Related issues

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

Actions

History

#1

Updated by bill-auger 23 days 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

#2

Updated by ryry 23 days 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 https://labs.parabola.nu/issues/3051 and might have been preventing parabola from following the nightly like arch does.
Anyhows thank you anyway

Ryan

#3

Updated by bill-auger 23 days 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 ftp.gnu.org 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

#4

Updated by bill-auger 22 days ago

#5

Updated by ryry 22 days 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?

#6

Updated by bill-auger 21 days 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

#7

Updated by ryry 21 days 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.

#8

Updated by bill-auger 21 days 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

#9

Updated by bill-auger 20 days 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

#10

Updated by bill-auger 20 days 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