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

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.

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).

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.

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.

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)?

Hi bill-auger, all,

[ apologies for the slow reply ]

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.

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.

jami-gnome was removed and jami-qt still has the dependency on qt6-webengine. So it seems Jami is now unusable with Parabola.

jami-gnome is no longer maintained - it could be added back, and
used for as long as it keeps working; but it is likely to stop
working someday

hopefully by then, the jami team will allow webengine to be
disabled - im not sure what it is used for; but usually it is
for nothing essential

i dont know if they will do that; but in my experience, most
projects which decide to add webengine to their software, are
soon asked for a way to disable it, and several have complied,
even in cases where it's absence limits the functionality of the
program significantly

or ... maybe someone else can figure out how to disable
webengine, before the jami team does (or does not), and add a
patch to this ticket - having such a patch in hand, may increase
the change that the upstream will adopt the changes

maybe this ticket should be re-opened now, that jami-qt is no
longer a duplicate of another existing package

As far as I understand it should be possible to rebuild qt6-webengine without non-free codecs, shouldn't it? Or are there deeper issues with it?

(I'm deducing it from the line in `/usr/share/doc/your-freedom/blacklist`).

`qt6-webengine::parabola:1167:[uses-nonfree][FIXME:package] Arch enables proprietary codecs at build time. suspect of repeating some of chromium's mistakes, see https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-04/msg00001.html`

Hi folks,

I think you'll be happy to hear that earlier this week we finally
landed the last puzzle piece for making it possible to build jami-qt
without Qt WebEngine:

https://review.jami.net/c/jami-client-qt/+/21341
https://review.jami.net/c/jami-client-qt/+/21476

The above two commits, along with various earlier commits to the
project (such as the refactoring to migrate the chatview to migrate
from a web-based one to one using regular Qt widgets) eliminate
jami-qt's hard dependency on Qt WebEngine.

Using the latest commit in the jami-daemon, jami-libclient,
and jami-client-qt repositories, you can now invoke cmake with
-DWITH_WEBENGINE=false to configure and build jami-qt without
Qt WebEngine.

Here are the hashes for the latest commit in each of the 3 repos,
which I've tested and know to build successfully:

• jami-daemon: 8750049b0ce58133b05c90330df6fd3464dadd1d
• jami-libclient: c5bca2933fb02ef7f81e8fe0772801a4f97fd1f5
• jami-client-qt: dd0dc87a0110b55f7f5ee450e13520c683e78650

I hope to see jami-qt included in Parabola (and other GNU FSDG distros
that may not have been able to package it so far) very soon. :)

best,
amin

P.S. I understand and sympathize with the feelings about the process
of building Jami and how non-straightforward it is. Of course, Jami
is a large and complex piece of software, but its build processes
could (and arguably should) be better. The team has discussed and
planned several short-term and longer-term steps to improve the
situation, including:

• I'll be updating/improving our docs and scripts for building Jami;
• we will be restructuring the jami-client-qt repo and experiment with
  folding the jami-libclient code into the jami-client-qt repo, thus
  simplifying the build steps for jami-qt, and gradually eliminating
  the artificial barrier between jami-qt and jami-libclient codebases;
  and
• experiment with other, potentially better ways of packaging Jami as
  a project as a whole, for instance by having jami-daemon directly as
  a submodule of jami-client-qt and always pointing to a commit known
  to be compatible with the rest of jami-qt, rather than having an
  auxiliary, separate jami-project repository to tie things together.

And of course I'll be happy to brainstorm and/or help answer questions
about Jami and packaging it with you all, and would also be happy and
grateful to receive feedback about these or other topics as well.

is it really necessary to build all three packages? - only jami-gnome and jami-qt were removed from the repos

i will try building only the QT client, assuming that the devel checkout point of jami-qt is compatible with jami-daemon and jami-libclient v2022-04-07

could you estimate when those changes would reach a versioned release?

to be clear, WRT packaging feedback, parabola does not need to be concerned with that - anything in arch which is already libre, we simply take the arch binary package - i would only need to fuss with the build this one time

the devel checkout point of jami-qt is compatible with jami-daemon and jami-libclient v2022-04-07

it is not - i had to compile all three, precisely in this order:

#          implied build order: jami-daemon <- jami-libclient <- jami-qt

Right; at the moment it is not. Folks in the team recently merged
support across all three repos for per-account plugin preferences,
and as a result you want all three repos to either have that or not
have it. In this case, because the commits you'll be using from
jami-qt does include those changes, you'll need them in the daemon and
libclient as well. And indeed, you would build the daemon first, then
use that to build libclient next, and use that to build jami-qt.

I see you went ahead and bumped the three packages in Parabola, and so
everything should be fine now. :) But perhaps another approach to try
could have been to cherry pick the jami-qt patches and see if they'd
apply against the version Arch had already packaged.

P.S. I'm not sure what criteria the maintainer of the Jami packages in
Arch uses for choosing when to bump Jami. But as far as Jami releases
go, our 'nightly' releases are considered stable enough to roll out to
users, and these days we do them roughly every other week or so (yeah,
the 'nightly' name is not exactly accurate at the moment). We also
have 'stable' releases, which currently we do every one or two other
months or so. But that is not to say our 'nightly' releases aren't
considered stable. There is a changelog currently at this address:
https://git.jami.net/savoirfairelinux/jami-client-qt/-/wikis/Changelog
And I hope our upcoming project/package restructuring changes I hinted
at in my last reply will help make it much easier to tell compatible
commits and our various types of releases from within one repo.

Hi bill-auger.Thanks for packaging it so quickly. Does this now mean it will end up being able to be installed via pacman or will it stay blacklisted? I am just curious as I see it in the repos again, but still conflicts with your-freedom. In fact it comes up on a system wide update but doesn't and looking in the blacklist I see its still there, so was just curious also as to what still remains (if at all), before we might see it again?

Bandali - Thanks to you and the jami devs for working on this to resolve the webengine issue. I look foward to using the qt version at some point for video conferences with the new features :)

Ry

the 'jami-qt' package is usable; but the 'your-freedom' package
will need to be rebuilt, before it will be possible to install
'jami-qt', without removing the 'your-freedom' package

Thanks for the update and clarification. I will keep an eye on the updates. :)

Hi,

[...]

Bandali - Thanks to you and the jami devs for working on this to
resolve the webengine issue. I look foward to using the qt version at
some point for video conferences with the new features :)

Ry

Cheers! Excellent; please don't hesitate to share feedback about your
experiences, and if you run into any issues please open a bug report:
https://docs.jami.net/user/bug-report-guide.html

best,
amin

--
https://bndl.org

Hi. I am still getting an error when trying to install, (type-copying this text):

# LANG=en pacman -Sy jami-qt
resolving dependencies...
warning: cannot resolve "qt6-webengine", a dependency of "jami-qt" 
:: The following package cannot be upgraded due to unresolvable dependencies:
      jami-qt

:: Do you want to skip the above package for this upgrade? [y/N]