Project

General

Profile

Packaging Request #3313

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

ryry - over 1 year ago - . Updated 24 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


Files

PKGBUILD (2.74 KB) PKGBUILD for jami-daemon Avron, 2024-03-04 10:45 AM
PKGBUILD (5.14 KB) PKGBUILD for jami-qt Avron, 2024-03-04 10:45 AM

Related issues

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

Actions
Related to Packages - Bug #3592: [jami]: rebuild against latest qt5-base (x86_64)confirmed

Actions

History

#1

Updated by bill-auger over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

#5

Updated by ryry over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

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

Updated by bill-auger 26 days ago

  • Related to Bug #3592: [jami]: rebuild against latest qt5-base (x86_64) added
#12

Updated by Avron 25 days ago

In case this is of any use, here are the PKGBUILD with which I successfully generated jami-daemon and jami-qt with libremakepkg in a chroot I just created, and then I installed them and they seem to work.

I used the parabola PKGBUILDs and changed the source versions to the ones in arch. I tried building jami-deamon without adding dhtnet as in the arch PKGBUILD, but it failed, so I added it. As it comes from jami repositories, I assumed the license is ok.

I tried building jami-qt without adding the 3rd party repositories but it failed, so I checked that there was a free license on them (it is MIT for all of them, I guess expat is the proper name, but I am not sure how to be sure it won't get any dependency), and took the small patches in the arch source, then it worked.

I only built and installed on x86. I tried following guidelines from the parabola wiki but since I never did such things before, it is likely I did not do things in the best way.

#13

Updated by bill-auger 25 days ago

i re-worked the PKGBUILDs yesterday too - the ones from arch build from VCS - we prefer to avoid that - not only it is built from VCS, but from relatively old version - jami had a new release in january - so i made the PKGBUILD use the source-ball from the GNU repo - its README suggests that it includes the daemon and client; so there may only need to be one PKGBUILD - jami-{daemon,libclient,qt} versions are all tightly coupled (ie: they always need rebuild together); and jami-qt (the only client) strictly requires jami-daemon, which AFAIK is useless alone.

the trouble so far, `make install` did not install the daemon - i suspect that it did build it though - also, i installed the existing daemon package; but the daemon does not start - i think it may require dbus which could be a problem for nonsystemd

it took a lot of guessing to get this far; and i suppose will need some more - the build documentation is nearly non-existent; but a lot can be inferred by reading the python installer - it suggests that the client and daemon can all be statically linked; which does not require dbus, so that would be another bonus

so it is not quite ready; but IMHO i would be admitting defeat if i used the arch PKGBUILD - there appears to be several reasons why the unified approach is preferable - i will attach the PKGBUILD if youre interested to help push it forward

#14

Updated by bill-auger 25 days ago

  • File qt-6.6.patch added
  • File PKGBUILD added
#15

Updated by bill-auger 24 days ago

ok, i discovered why it did not build the daemon - however, i also discovered that it is not possible to build this from the GNU source-ball - the source-ball is incomplete - it requires two other code-bases which are only available from jami as un-versioned VCS

the work-load of this package outweighs its usefulness, frankly - getting it to compile is always an all-day project - this time, i am on day 2 (so far) - as it needs to be pinned to qt6-base to avoid breakage, it will require rebuild or upgrade frequently - if i can not get it to build today; i may just drop this package - maybe guix packages it, and parabola users can get it that way - i really dont appreciate dealing with such brittle software - i can not justify spending two days every month to keep a single program working

#16

Updated by bill-auger 24 days ago

ok i think im done with this adventure :(

the currrent error i am stuck on:

../src/jamidht/archive_account_manager.cpp:660:29:
error: ‘aesGetKey’ is not a member of ‘dht::crypto’

that is from one of the external dependencies - i tried it with the both of the unversioned external dependencies at the revisions the arch PKGBUILD uses, and also the revisions which were apparently current when the jami source-ball was made, and also the current revisions today - all of those fail with same error

although bandali has been very helpful in the past, i would not expect the on-going help from the upstream that this requires - for example, the arch PKGBUILD applies a patch, commented with link to a bug report upstream, because it fails to compile with the latest QT - that bug report was closed 'wont-fix', which is baffling b- they will need to address that bug inevitably, whenever when QT gets upgraded in whichever distros they do want to support

i will push the latest WIP to abslibre if anyone is interested

#17

Updated by bill-auger 24 days ago

  • File deleted (qt-6.6.patch)
#18

Updated by bill-auger 24 days ago

  • File deleted (PKGBUILD)

Also available in: Atom PDF