Project

General

Profile

Packaging Request #3051

jami-qt suggestion

Anonymous - 5 months ago - . Updated 3 months ago.

Status:
wont-fix
Priority:
bug
Assignee:
-
% Done:

0%


Description

Following the recent announcement by the GNU Jami team, the standard and maintained Jami client on desktop is the Qt-based client. See their GitLab repository for more information.

Jami is a valuable piece of software for real-time voice and video communication, that does not require any server to run. Having it packaged in Parabola (since Arch only package the GNOME client and does not appear to be updated too often) would be a useful addition in my opinion.

Also, the client relies on both libjamiclient and jami-daemon to run. So, packaging the client would mean packaging these two others as well.

History

#1

Updated by bill-auger 5 months ago

the jami client and both of those custom dependencies are
already in the repos - arch packages them, so this would not be
a good reason to blacklist the existing package(s) - if the QT
client is indeed the only one supported by the upstream, arch
will package it, and retire the gnome client - parabola would
then get it automatically

#2

Updated by freemor 5 months ago

The gnome client isn't currently depricated. It'll is being phased out.

And with regards to the update cycle. Jami doesn't "update often" at least not by the crazy pace that most people expect to see these days.
They have a new release about once every 4-6 month. The there is the fact that it is hell to build. There was a period where Arch could not build the current Jami due to Libs being out of sync (Arch versions of the Libs were ahead of what Jami would build with).

Hopefully the QT client will tame the code base a bit, but I doubt it. It seems to be a function of how the Jami devs work. I use Jami regularly but I still prefer Tox as it has a much saner code base. Sadly Tox clients on non GNU/Linux systems are in need of some love. So in that way Jami wins out.

#3

Updated by Anonymous 5 months ago

Thank you for your insights.

So let’s hope they package jami-qt soon in their repos (the GNOME client is far from ideal IMHO when not using a DE).

#4

Updated by bill-auger 5 months ago

  • Status changed from open to wont-fix
#5

Updated by freemor 4 months ago

I've been keeping an eye on the AUR PKGBUILD. As expected it's breaking often. But the latest breakage is concerning.

as400 commented on [53]2021-08-04 13:49
There are missing deps: libnotify, qt5-quickcontrols2, qt5-svg, qt5-webengine.

Our old friend qt5-webengine may be about to claim another package. Someone should have a chat with the Jami Project if that is the case. They are a GNU project I believe an thus one would think they'd want to steer wide of the qt5-webengine/Chromium mess.

Haven't dug deep yet. but will if I can fine the time in a day or 3.

PKGBUILD is at https://aur.archlinux.org/pkgbase/jami-client-qt-git/ to save those interested the time to look it up.

#6

Updated by freemor 4 months ago

Did some more digging and YEP, Huston, we've got a problem:

Straight from build.py on the jami git (build.py is their script yo pull in all depends)

DNF_CLIENT_QT_DEPENDENCIES = [ 'qt5-qtsvg-devel', 'qt5-qtwebengine-devel', 'qt5-qtmultimedia-devel', 'qt5-qtdeclarative-devel', 'qt5-qtquickcontrols2-devel', 'qt5-qtquickcontrols' ]

and

PACMAN_CLIENT_QT_DEPENDENCIES = [ 'qt5-declarative', 'qt5-graphicaleffects', 'qt5-multimedia', 'qt5-quickcontrols', 'qt5-quickcontrols2', 'qt5-svg', 'qt5-tools', 'qt5-webengine' ]

https://git.jami.net/savoirfairelinux/ring-project/-/blob/master/build.py if people want to check it out.

I'll not move this to a BR yet as it isn't officially packaged in Arch yet. We may have to blacklist when it is.

Perhaps someone with a bit more Libre community clout than I could file A BR or start a dialogue with the Jami folks about why qt5-webengine is a bad idea.

#7

Updated by bill-auger 4 months ago

bandali are you getting this by email? - we have a few questions about the jami QT port

the situation now seems to be that the jami QT port is unfit for the FSDG, and may need to be blacklisted, due to the chromium/webengine requirement - that is peculiar for a GNU project, but is not necessarily an upstream freedom issue - in this case, it is still up for debate, and has been debated for years; but is currently unacceptable by consensus of the FSDG work-group

1. is it possible to build jami-qt without qt5-webengine?
2. can it be configured to use qt5-webkit instead?
3. is it possible to build jami-qt with neither webengine nor webkit?
4. how long will the jami-gnome be supported?
5. how long will the jami-daemon remain backward-compatible with jami-gnome?
6. where to open bug report or send patches (email,gitlab)?

#8

Updated by bandali 3 months ago

Hi bill-auger, all,

[ apologies for the slow reply ]

writes:

Issue #3051 has been updated by bill-auger.

bandali are you getting this by email? - we have a few questions
about the jami QT port

I did get this indeed, and I'm sending this reply via email as well.

the situation now seems to be that the jami QT port is unfit for the
FSDG, and may need to be blacklisted, due to the chromium/webengine
requirement - that is peculiar for a GNU project, but is not
necessarily an upstream freedom issue - in this case, it is still up
for debate, and has been debated for years; but is currently
unacceptable by consensus of the FSDG work-group

1. is it possible to build jami-qt without qt5-webengine?

Unfortunately not at the moment; qt5-webengine is currently a
hard dependency of jami-qt.

2. can it be configured to use qt5-webkit instead?

Not at the moment; though I did open an issue about it a few months
ago: https://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/275

3. is it possible to build jami-qt with neither webengine nor webkit?

Not at the moment; however, after a recent discussion with a few other
Jami core developers, to me this seems like the most straightforward
option going into the future, for several reasons:

First, adding and maintaining compatibility with qt5-webkit in
addition to qt5-webengine seems like a somewhat challenging and
time-consuming task. Though I'd imagine the team would be open to
considering that option if contributor(s) from the community would be
willing to help with implementing and maintaining it going into the
future.

Second, I think we may now (or soon) be well-positioned to make the
webengine an optional dependency: the webengine is mainly used in the
chat view, for rendering the messages and link previews; however, over
the recent weeks several team members have worked on refactoring the
chat view to use native Qt widgets instead of a whole browser engine
for rendering/displaying messages, and we would most likely be able to
implement link previews without the use of a browser engine as well.
So, once the change(s) for moving to native widgets for jami-qt's chat
view lands, it could be a great time to look into making the webengine
dependency optional.

This is something I'd like to look into myself, but considering the
many other tasks I'm normally working on at work, it would be great
if folks from the community would contribute patches for this.

4. how long will the jami-gnome be supported?

For now, I plan on continuing its maintenance until the end of 2021.

5. how long will the jami-daemon remain backward-compatible with
jami-gnome?

This is tougher to say, since the daemon (and also lrc) is under
constant development and receives patches/changes from several people,
sometimes very large ones. Obviously, the team coordinates merging of
these patches so as to avoid breaking the main client applications,
which I believe currently consist of jami-qt, jami-android, and
jami-macos. For jami-gnome, I'm currently the only developer at SFL
who actively works on and maintains it, and so far I've been able to
keep it up-to-date with the lrc and daemon changes for the most part,
except for a few weeks back when jami-gnome lacked swarm-compatibility
and so wasn't compatible with latest lrc + daemon for a while.

So, as much as I would like to say "until the end of 2021" like my
previous answer, being a single developer working on jami-gnome,
I may not be able to keep up with all of the daemon and lrc changes.
For instance, I've been anxious about one or two more breaking changes
coming up in lrc and daemon which I have not had any time to work on
in order to make jami-gnome compatible with them. Depending on how
long it would take to catch up, we might have to start pinning lrc and
daemon for jami-gnome to a fixed version so as to avoid broken builds.

6. where to open bug report or send patches (email,gitlab)?

Bug reports can be sent to the issue tracker for the specific project
on git.jami.net. For instance, for jami-qt, that would be
https://git.jami.net/savoirfairelinux/jami-client-qt/-/issues,
for jami-gnome it would be
https://git.jami.net/savoirfairelinux/ring-client-gnome/-/issues,
for the daemon it would be
https://git.jami.net/savoirfairelinux/ring-daemon/-/issues, and so on.
If not sure which tracker to report the issue to, you can open the
issue in the tracker for the main 'project' repo, and one of the team
members will take care of moving it to the more specific repo:
https://git.jami.net/savoirfairelinux/ring-project/-/issues

Patches are welcome at https://review.jami.net, our Gerrit code review
instance, under the relevant project. You can see the list of all
projects at https://review.jami.net/admin/repos.

Hope this helps.

Also available in: Atom PDF