bring jitsi to debian

[calestyo]

Hey.

Some time ago jitsi was packaged for Debian, but apparently it has been abandoned shortly after and is completely dysfunctional since more than a year.

Would be nice if this could be brought back into the official Debian archive and kept being well maintained.

Cheers,
Chris.

[ibauersachs]

It would be nice if we'd get help with that (specifically the required dependencies) instead of complaints.

[hasufell]

To properly package jitsi there are a few things that are problematic:

• prepackaged .jar's are suboptimal, jitsi should be buildable without any pre-packaged ones... I wasn't able to do that
• pre-built shared libraries are just bad/wrong for non-proprietary software and lead to linking problems and platform incompatibilities... it's not even clear when/how these are built, where they come from, what distro was used to build them (one practical problem you already have here is that you are libressl-incompatible)

The latter is a pretty strong no-go for a lot of distros that have basic QA I'd say.

[ibauersachs]

@hasufell The things you pointed out are not the issue. These have already been solved, see README.Debian.

What needs to/should be done:

• Update the build instructions to create the source tarball
• Package the embedded libraries (so that creating the source tarball gets easier), i.e.
  • sdes4j (easy, a Maven project, depends only on libraries already in Debian)
  • dnssecjava
  • jmork (very easy, a Maven project, no dependencies)
  • bccontrib (easy, a Maven project, depends only on libraries already in Debian)
  • zrtp4j (easy by itself, but depends on fmj, needs Use stock BouncyCastle, remove embedded libs, convert to Maven wernerd/ZRTP4J#7 or our fork)
  • fmj (unknown, no dependencies in Maven project created for Jitsi)
  • ice4j (medium, needs other dependencies packaged first)
    • weupnp (easy, already in Debian, needs an NMU)
    • java-sdp-nist-bridge (medium)
    • opentelecoms-org/java-sdp-api (easy)
    • opentelecoms-org/java-sip-api (easy)
    • jain-sip (or rather jain-sip-ri-ossonly, hard)
  • libjitsi (hard, native code, depends on ice4j)
  • dhcp4java (unknown)
  • jnsapi (unknown)
  • Smack (unknown, depends on Update Smack to 4.2 #306)
  • jmyspell (unknown)
  • joscar (unknown)
  • irc-api (unknown, @cobratbq)
  • jsocks (unknown)
  • otr4j (unknown, likely easy, which repo?)
  • jmyspell (unknown)
  • swingworker (unknown, ITP 494018)
  • ... ?
• Update outdated dependencies in Jitsi which are already in Debian (e.g. libphonenumber7-java)

The pre-built shared libraries are for our own Windows/Linux/Mac packages. As these are hard to build and need the corresponding OS, they are committed as binaries along with the Java code. But as mentioned, the Debian source tarball all creates them from source.

[calestyo]

IIRC, last time libjitsi was in Debian's NEW queue the ftp master continuously rejected it for license reasons... have these been sorted out?

[ibauersachs]

@calestyo Yes, the licensing problem were the javax.sdp and javax.sip packages. These have been replaced with an Apache 2.0 licensed version from @dpocock (see the list of libraries above). What hasn't been done though is the inclusion of them into the (lib)jitsi deb-source-tarball, and I don't want to go down that road again. I'd rather have proper Debian packages and then depend on them.

[ibauersachs]

I've been working on packaging dependencies. See the updated list above (jmork needs a sponsor, and note that the list is incomplete).

[alexmyczko]

@ibauersachs What is the state 4 years later? Could I help somehow? Regards from Brugg to Brugg

[hex-m]

One of the core developers (@damencho) commented on this effort in the Debian issue tracker in 2020-09:

There are a few concerns I have,
first is that we do not have the resources to maintain this.

The second one is that the project sometimes follows the pace of the
browsers to do new releases. Which means a new version every 6 weeks. We
had two or three occasions in the last few years where everyone needs to
update due to a breaking change in the browsers, like a mandatory field
being added in SDP, or the old bridge not supporting the new DTLS version.
And because of the pace of how things evolve, we do not support old release
doing backports. This means that if a package goes in stable it may happen
to soon be unusable.

And if someone chooses the path of doing the job we are talking about
150-200 dependent libraries, I'm not sure how many of those are already in
Debian

For the web components you find the list of dependencies here.

The dependencies for jitsi-videobridge and jicofo were posted too.

So the next step would be packaging/maintaining those dependencies.

[saghul]

That Debian issue is about Jitsi Meet, the WebRTC compatible video conferencing project, not Jitsi desktop, the multi-protocol chat client.

[hex-m]

My bad, sorry. It still confuses me regularly because Jitsi Meet is often abbreviated as Jitsi.

[calestyo]

Just for the records, the Jitsi desktop application (which I was asking for here) actually used to be in Debian. See e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038 ... and there are still some related RFPs open, e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757768 .

[ibauersachs]

@alexmyczko I haven't spent any time packaging dependencies for Debian. I'm (sometimes) working on getting the application itself running again and building Debian/Ubuntu packages, although requiring online access to Maven Central. Since I'm working alone on this, the effort of packing all dependencies for an offline build is simply too much (if it's possible at all given the state of Gradle and Kotlin in Debian).

Ping me on my e-mail if you want to grab a beer at Katarakt at some point :-)