[jitsi-dev] Git for jitsi, native Debian package?


#1

Hi,

I've just re-tryed Jitsi and it now finally works with my old logitech
quickcam.[1][2] However I had to call it with v4l1compat preloaded:
LD_PRELOAD=/usr/lib/i386-linux-gnu/libv4l/v4l1compat.so jitsi

So I thought I should try to get jitsi into the official Debian archive.[3]

[1] http://comments.gmane.org/gmane.comp.voip.sip-communicator.user/1175
[2] http://java.net/jira/browse/JITSI-960
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627362

Are you aware of anybody already working on a native Debian package? I'll have
a look in the source and the dependencies before I announce to do it.

I've seen that somebody from RedHat already suggested whether you might switch
to Git?[4] I'm also doing a Git import right now and will push it to github
afterwards.[5] There are very good reasons and benefits in a Git switch[6] and
it makes living especially for external people like packagers much easier.

[4] http://java.net/nonav/projects/jitsi/lists/dev/archive/2011-02/message/130
[5] https://github.com/thkoch2001
[6] http://whygitisbetterthanx.com

Best regards,

Thomas Koch, http://www.koch.ro


#2

Hi,

after a first look, jitsi won't be easy at all to package. I write down my
impressions if others want to look into the packaging and maybe you could help
a bit to make it easier. I'm sorry for any mistake in the following.

Jitsi has a LOT of dependencies, all of them committed as binaries to lib/.
The first thing for a packager (either Debian or Fedora) is to identify all
these libraries, remove them from the upstream tarball and try to compile
jitsi with the versions of the libraries available in the distribution.

This would be easier, if the dependencies would be managed, e.g. by ivy or
maven. Thus each dependency would be clearly identified.

I've found the evil json.org library of Crockford in the dependencies. The
license of this library forbids inclusion in any free software distribution:
http://www.mail-archive.com/debian-legal@lists.debian.org/msg40718.html

Maybe jitsi could be breaken up in smaller parts, separating OS dependent
stuff and optional functionality. Then a debian packager could start with the
core functionality.

The project is a mixed C/Java project. Shared C libraries are also committed
to SVN without information about their origin. It would be much much easier,
if those parts interacting with C code could be seperated from the rest of the
plain java code.

The jitsi SVN contains patches for other projects e.g. ffmpeg. In a
distribution I try of course to reuse the already packaged projects.

I don't know about OSGI, but I believe that it wouldn't be necessary to have
so many repetitive blocks to create OSGI compliant jars. Could the bnd tool
help with this?

What is your opinion? Are you interested to have jitsi in Fedora, RedHat,
Debian and Ubuntu? In this case I think the best way would be if packagers
would first work together with you to do some preparation work directly in
your repository. This in turn would be much easier if you'd use Git.

Best regards and thank you for Jitsi,

Thomas Koch, http://www.koch.ro


#3

Hey Thomas,

Thanks for looking into this!

We are of course interested in having Jitsi integrated in the Debian
repos. We are also aware of the problems that are caused by the way we
store our dependencies. (They were actually already raised on this list
by Daniel Zucchetto).

Off the top of my head, the easiest way for us to fix this issue would
be to simply copy the source code zip/jar files in the Jitsi repo since
we need the libs packages in our binaries which would make their use
from within other libs quite tricky.

Would this work?

Emil

На 20.11.11 21:00, Thomas Koch написа:

···

Hi,

after a first look, jitsi won't be easy at all to package. I write down my
impressions if others want to look into the packaging and maybe you could help
a bit to make it easier. I'm sorry for any mistake in the following.

Jitsi has a LOT of dependencies, all of them committed as binaries to lib/.
The first thing for a packager (either Debian or Fedora) is to identify all
these libraries, remove them from the upstream tarball and try to compile
jitsi with the versions of the libraries available in the distribution.

This would be easier, if the dependencies would be managed, e.g. by ivy or
maven. Thus each dependency would be clearly identified.

I've found the evil json.org library of Crockford in the dependencies. The
license of this library forbids inclusion in any free software distribution:
http://www.mail-archive.com/debian-legal@lists.debian.org/msg40718.html

Maybe jitsi could be breaken up in smaller parts, separating OS dependent
stuff and optional functionality. Then a debian packager could start with the
core functionality.

The project is a mixed C/Java project. Shared C libraries are also committed
to SVN without information about their origin. It would be much much easier,
if those parts interacting with C code could be seperated from the rest of the
plain java code.

The jitsi SVN contains patches for other projects e.g. ffmpeg. In a
distribution I try of course to reuse the already packaged projects.

I don't know about OSGI, but I believe that it wouldn't be necessary to have
so many repetitive blocks to create OSGI compliant jars. Could the bnd tool
help with this?

What is your opinion? Are you interested to have jitsi in Fedora, RedHat,
Debian and Ubuntu? In this case I think the best way would be if packagers
would first work together with you to do some preparation work directly in
your repository. This in turn would be much easier if you'd use Git.

Best regards and thank you for Jitsi,

Thomas Koch, http://www.koch.ro

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#4

Emil Ivov:

Hey Thomas,

Thanks for looking into this!

We are of course interested in having Jitsi integrated in the Debian
repos. We are also aware of the problems that are caused by the way we
store our dependencies. (They were actually already raised on this list
by Daniel Zucchetto).

Off the top of my head, the easiest way for us to fix this issue would
be to simply copy the source code zip/jar files in the Jitsi repo since
we need the libs packages in our binaries which would make their use
from within other libs quite tricky.

Would this work?

Emil

Hi Emil,

thank you for your interest. However I'm afraid I don't understand your last
paragraph at all. Anyways, I won't be able to package jitsi alone, since I
only have some experience with java packages but don't know to package C
stuff.

In any case, there are some things that Jitsi should/could/must do itself to
make a native package for Debian/Fedora/OpenSuse doable. I've opened jira
issues for those and linked them from an umbrella issue:

http://java.net/jira/browse/JITSI-996

We can continue to discuss the items separately in those issues.

Regards,

Thomas Koch, http://www.koch.ro


#5

Hey Thomas,

Emil Ivov:

Hey Thomas,

Thanks for looking into this!

We are of course interested in having Jitsi integrated in the Debian
repos. We are also aware of the problems that are caused by the way we
store our dependencies. (They were actually already raised on this list
by Daniel Zucchetto).

Off the top of my head, the easiest way for us to fix this issue would
be to simply copy the source code zip/jar files in the Jitsi repo since
we need the libs packages in our binaries which would make their use
from within other libs quite tricky.

Would this work?

Emil

Hi Emil,

thank you for your interest. However I'm afraid I don't understand your last
paragraph at all. Anyways, I won't be able to package jitsi alone, since I
only have some experience with java packages but don't know to package C
stuff.

Sure. I am not sure if you have already noticed but we do already
maintain fucntional debian packages that should be a good basis.

In any case, there are some things that Jitsi should/could/must do itself to
make a native package for Debian/Fedora/OpenSuse doable. I've opened jira
issues for those and linked them from an umbrella issue:

http://java.net/jira/browse/JITSI-996

Ouch ... that's something that we like to avoid [0].

We only enter issues once we've determined exactly what they are and
decided that we'll be fixing them at some point. I've closed the
issues and we'll reopen those that we agree on, if and when we do.
Right now we are still in the discussion stages of the debian
packaging. We'd first need to decide exactly what needs to be resolved
here and how we can do that.

As for the svn-to-git switch: as much as I appreciate git's
versatility, I am afraid a switch would require too much effort so
it's not in our foreseeable roadmap. Besides, I am not convinced all
developers would feel more comfortable with it than with SVN.

Cheers,
Emil

[0] http://www.jitsi.org/index.php/Development/BugsAndIssues

···

On Tue, Nov 22, 2011 at 4:09 PM, Thomas Koch <thomas@koch.ro> wrote:

We can continue to discuss the items separately in those issues.

Regards,

Thomas Koch, http://www.koch.ro

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#6

Hi Emil,

by looking for free software alternatives for Skype available on Debian, I got
aware of jitsi, which seems to have an awesome feature set. As it is not
available in the official Debian archive, I looked around and found out about
the recent efforts to package it for Debian (namely Debian bug #627362).

···

On Tue, Nov 22, 2011 at 04:58:34PM +0100, Emil Ivov wrote:

On Tue, Nov 22, 2011 at 4:09 PM, Thomas Koch <thomas@koch.ro> wrote:
> In any case, there are some things that Jitsi should/could/must do itself to
> make a native package for Debian/Fedora/OpenSuse doable. I've opened jira
> issues for those and linked them from an umbrella issue:
>
> http://java.net/jira/browse/JITSI-996

Ouch ... that's something that we like to avoid [0].

We only enter issues once we've determined exactly what they are and
decided that we'll be fixing them at some point. I've closed the
issues and we'll reopen those that we agree on, if and when we do.
Right now we are still in the discussion stages of the debian
packaging. We'd first need to decide exactly what needs to be resolved
here and how we can do that.
[...]

> We can continue to discuss the items separately in those issues.

Okay, so, let's list all the issues that Thomas reported already, here again.
For one to make them more visible, and also to get a consensus about the status
of these issues. Not using an issue tracker will of course make it harder to
keep track of the actual conclusions. But as you wanted to have it this way,
of course I expect that you will then give your opinion on them one by one,
more with regards to content than with regards the way we report issues.

-----------------------------------------------------------------------------

JITSI-995 document (or manage) native dependencies (by Thomas Koch)

  There's no central location where one can see which C libraries of what
  version, origin and license Jitsi uses, which of them are patched, in what way
  and for what reason.

  I'm not a C developer so I don't know if there's something like Maven/Ivy for
  C that manages dependencies?

-----------------------------------------------------------------------------

JITSI-994 Use Ivy or Maven to manage java dependencies (by Thomas Koch)

  It is hard for a distro (Debian/Fedora/Suse) packager to find out which java
  dependencies Jitsi has. A pom.xml or ivy.xml would make things much easier
  and then the dependencies could also be removed from SVN.

-----------------------------------------------------------------------------

JITSI-993 get rid of json.org java dependency (by Thomas Koch)

  The json.org java library is non-free according to Debian and maybe also
  other distros. As long as jitsi depends on json.org it can not enter the
  Debian archive.

  http://www.mail-archive.com/debian-legal@lists.debian.org/msg40718.html

-----------------------------------------------------------------------------

JITSI-997 Provide a source only tarball (by Thomas Koch)

  Linux distributions want to build their packages and all dependencies of
  those themselves. So it must be possible to download a source distribution of
  jitsi (prefarable as .tar.gz or .tar.bz2) that does not contain any
  third-party binaries and build jitsi from this source distribution with the
  help of the dependencies existing in the distro.

-----------------------------------------------------------------------------

JITSI-998 review and document licenses and origins of images in jitsi
          (by Thomas Koch)

  A distro packager needs to be sure that the images coming with Jitsi can be
  distributed under a free license. If the images are taken from common sets
  like Tango it would even be preferable for a packager to not ship the images
  in the jitsi package but to depend on the tango package of the distribution.

-----------------------------------------------------------------------------

I am looking forward to read your comments on these issues.

Regards,
Micha
.


#7

Hey Micha,

Hi Emil,

by looking for free software alternatives for Skype available on Debian, I got
aware of jitsi, which seems to have an awesome feature set. As it is not
available in the official Debian archive, I looked around and found out about
the recent efforts to package it for Debian (namely Debian bug #627362).

> In any case, there are some things that Jitsi should/could/must do itself to
> make a native package for Debian/Fedora/OpenSuse doable. I've opened jira
> issues for those and linked them from an umbrella issue:
>
> http://java.net/jira/browse/JITSI-996

Ouch ... that's something that we like to avoid [0].

We only enter issues once we've determined exactly what they are and
decided that we'll be fixing them at some point. I've closed the
issues and we'll reopen those that we agree on, if and when we do.
Right now we are still in the discussion stages of the debian
packaging. We'd first need to decide exactly what needs to be resolved
here and how we can do that.
[...]

> We can continue to discuss the items separately in those issues.

Okay, so, let's list all the issues that Thomas reported already, here again.
For one to make them more visible, and also to get a consensus about the status
of these issues.

Thanks for bringing them up!

Not using an issue tracker will of course make it harder to
keep track of the actual conclusions. But as you wanted to have it this way,
of course I expect that you will then give your opinion on them one by one,
more with regards to content than with regards the way we report issues.

We will of course open issues for those that we accept as such but
that can't happen until we've discussed them. We realize this is
frustrating but the alternative of simply dumping them in our tracker
would lead to ... well ... nothing. We may change our issue tracking
policy in the future, but right now, this is the only one we can
afford. Again, apologies for any inconvenience this may have caused,
and many thanks for bringing them here!

Now before, I continue, I've already mentioned in a couple of threads
that we are currently working on a debian tarball. This does imply a
lot of work since we need to come up with the generating scripts,
determine what libraries we can use as debian dependencies, implement
support for such dependencies (they won't work out of the box for
OSGi), retrieve the source code for the rest of the libs we use,
upload them to our libsrc, and make sure that they are properly build
by the Jitsi build process.

Hopefully, we would have all this by the end of the summer, early
autumn. Again, it is a lot of effort, but we realize how important it
would be for the project to get into Debian.

Another debian developer, Raphael Hertzog (CCed), will be guiding us
through the process and helping us where necessary.

Of course we'd be more than happy to also have you on board.

-----------------------------------------------------------------------------

JITSI-995 document (or manage) native dependencies (by Thomas Koch)

  There's no central location where one can see which C libraries of what
  version, origin and license Jitsi uses, which of them are patched, in what way
  and for what reason.

This is exactly what the libsrc directory is for. We are still working
on filling it up and we should be done by the time we finish our
debian source tarball. Also note that all the patches we have used to
patch native libs are currently in src/native

  I'm not a C developer so I don't know if there's something like Maven/Ivy for
  C that manages dependencies?

-----------------------------------------------------------------------------

JITSI-994 Use Ivy or Maven to manage java dependencies (by Thomas Koch)

  It is hard for a distro (Debian/Fedora/Suse) packager to find out which java
  dependencies Jitsi has. A pom.xml or ivy.xml would make things much easier
  and then the dependencies could also be removed from SVN.

Same as above: our libsrc should resolve this.

-----------------------------------------------------------------------------

JITSI-993 get rid of json.org java dependency (by Thomas Koch)

  The json.org java library is non-free according to Debian and maybe also
  other distros.

It kind of appears so indeed. Although the thread below does also show
rough consensus on the fact that it is unlikely for the statement to
be a problem in a court of law.

Still we do understand precautionary measures.

As long as jitsi depends on json.org it can not enter the
  Debian archive.

Right. Luckily, json.org is used for a particularly non-centric
feature in Jitsi (creating ippi.com accounts). We'll have a quick look
for alternatives and use one if it's not too much trouble. If it is,
we'll just remove the feature from the debian version.

  http://www.mail-archive.com/debian-legal@lists.debian.org/msg40718.html

-----------------------------------------------------------------------------

JITSI-997 Provide a source only tarball (by Thomas Koch)

  Linux distributions want to build their packages and all dependencies of
  those themselves. So it must be possible to download a source distribution of
  jitsi (prefarable as .tar.gz or .tar.bz2) that does not contain any
  third-party binaries and build jitsi from this source distribution with the
  help of the dependencies existing in the distro.

That's what we are currently working on. I have just reopened the
issue so that whoever's interested would be able to track progress.

http://java.net/jira/browse/JITSI-997

Thank you for creating it.

-----------------------------------------------------------------------------

JITSI-998 review and document licenses and origins of images in jitsi
          (by Thomas Koch)

  A distro packager needs to be sure that the images coming with Jitsi can be
  distributed under a free license. If the images are taken from common sets
  like Tango it would even be preferable for a packager to not ship the images
  in the jitsi package but to depend on the tango package of the distribution.

All Jitsi image have been designed by Jitsi developers. Besides we are
currently working on integrating new set of icons and labels that
BlueJimp's Joro Gomes has created for us, so there shouldn't be any
issues there.

-----------------------------------------------------------------------------

I am looking forward to read your comments on these issues.

Thanks again for taking the issues here and please let us know if you
have any other questions

Cheers,
Emil

···

On Sun, Aug 5, 2012 at 12:27 PM, Micha Lenk <micha@debian.org> wrote:

On Tue, Nov 22, 2011 at 04:58:34PM +0100, Emil Ivov wrote:

On Tue, Nov 22, 2011 at 4:09 PM, Thomas Koch <thomas@koch.ro> wrote:


#8
···

---------------------------------------------------------------------------

JITSI-993 get rid of json.org java dependency (by Thomas Koch)

  The json.org java library is non-free according to Debian and maybe

also

  other distros.

It kind of appears so indeed. Although the thread below does also show
rough consensus on the fact that it is unlikely for the statement to
be a problem in a court of law.

Still we do understand precautionary measures.

As long as jitsi depends on json.org it can not enter the Debian archive.

Right. Luckily, json.org is used for a particularly non-centric
feature in Jitsi (creating ippi.com accounts). We'll have a quick look
for alternatives and use one if it's not too much trouble. If it is,
we'll just remove the feature from the debian version.

Ahm, are you sure about that? I already looked shortly into removing the
dependency when Thomas first brought up this issue. It is used by
- ServerStoredContactListXivoImpl
- various net.java.sip.communicator.impl.replacement.*
- net.java.sip.communicator.plugin.ippiaccregwizz
- net.java.sip.communicator.plugin.sip2sipaccregwizz

Still not a big thing, but nonetheless more than only ippi. Sadly none of
the alternatives had a similar enough API to just drop in another jar and
rename some methods.

In general, it might be a good time to consider dropping some libraries that
are no longer needed (e.g. hexdump.jar, concurrent.jar).

Regards,
Ingo


#9

---------------------------------------------------------------------------

JITSI-993 get rid of json.org java dependency (by Thomas Koch)

  The json.org java library is non-free according to Debian and maybe

also

  other distros.

It kind of appears so indeed. Although the thread below does also show
rough consensus on the fact that it is unlikely for the statement to
be a problem in a court of law.

Still we do understand precautionary measures.

As long as jitsi depends on json.org it can not enter the Debian archive.

Right. Luckily, json.org is used for a particularly non-centric
feature in Jitsi (creating ippi.com accounts). We'll have a quick look
for alternatives and use one if it's not too much trouble. If it is,
we'll just remove the feature from the debian version.

Ahm, are you sure about that? I already looked shortly into removing the
dependency when Thomas first brought up this issue. It is used by
- ServerStoredContactListXivoImpl

Oh right! Had forgotten about this one. Same reasoning applies though.
Not a critical feature so we'll try to remove it if we don't have the
time to implement over an alternative lib.

- various net.java.sip.communicator.impl.replacement.*
- net.java.sip.communicator.plugin.ippiaccregwizz
- net.java.sip.communicator.plugin.sip2sipaccregwizz

Still not a big thing, but nonetheless more than only ippi. Sadly none of
the alternatives had a similar enough API to just drop in another jar and
rename some methods.

In general, it might be a good time to consider dropping some libraries that
are no longer needed (e.g. hexdump.jar, concurrent.jar).

Yup. Definitely.

Emil

···

On Tue, Aug 7, 2012 at 12:35 AM, Ingo Bauersachs <ingo@jitsi.org> wrote: