[jitsi-dev] Debian package

Archive
#1

Dear Jitsi Devs,

this is Rolf Leggewie. I have an interest in using jitsi for my SIP
communication needs in the future. I have also been maintaining a
couple of packages I use as a Debian Maintainer for a few years now.

I'm very happy to see jitsi included in Debian officially now. There's
still a few rough edges and supporting jitsi in Debian will require
on-going maintenance for such a large package. I'd like to pitch in
with that and bring my experience in packaging to the table. I've
already imported the official Debian releases into an alioth git repo to
allow for better documentation and easier collaboration on the
packaging. The layout is conforming to what git-buildpackage would expect.

http://git.debian.org/?p=collab-maint/jitsi.git

The last couple of days, I worked on backporting the package to Ubuntu
precise to allow some exposure to a wider audience. The result is
available in my PPA at https://launchpad.net/~r0lf/+archive/stable While
doing that I've made a few patches to the Debian build process, closed a
bug or two, etc. I've pushed these changes that I propose for inclusion
in a new Debian -2 release to the rolf branch of abovementioned alioth
repo. Please have a look and let me know if you'd like me to keep going.

Regards

Rolf

#2

Hi Rolf,

You could also recommend people use the latest nightly repo from Jitsi:
https://jitsi.org/Main/DebianNightlyRepository

Does the Debian repo team have a way to build from source automatically, or
is everything done manually one application at a time?

Best,
Jungle

···

On 2 March 2014 20:26, Rolf Leggewie <foss@rolf.leggewie.biz> wrote:

Dear Jitsi Devs,

this is Rolf Leggewie. I have an interest in using jitsi for my SIP
communication needs in the future. I have also been maintaining a
couple of packages I use as a Debian Maintainer for a few years now.

I'm very happy to see jitsi included in Debian officially now. There's
still a few rough edges and supporting jitsi in Debian will require
on-going maintenance for such a large package. I'd like to pitch in
with that and bring my experience in packaging to the table. I've
already imported the official Debian releases into an alioth git repo to
allow for better documentation and easier collaboration on the
packaging. The layout is conforming to what git-buildpackage would expect.

http://git.debian.org/?p=collab-maint/jitsi.git

The last couple of days, I worked on backporting the package to Ubuntu
precise to allow some exposure to a wider audience. The result is
available in my PPA at https://launchpad.net/~r0lf/+archive/stable While
doing that I've made a few patches to the Debian build process, closed a
bug or two, etc. I've pushed these changes that I propose for inclusion
in a new Debian -2 release to the rolf branch of abovementioned alioth
repo. Please have a look and let me know if you'd like me to keep going.

Regards

Rolf

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si

#3

Hello jungleboogie0,

thank you for your comment.

You could also recommend people use the latest nightly repo from
Jitsi: https://jitsi.org/Main/DebianNightlyRepository

Well, other people might differ, but I did not and would not feel
comfortable to use that option on a production-level computer.

1) the source is not published (this is actually a GPL violation)
2) with 3rd party repos you always have to worry if their packaging
   quality is high enough that it won't mess up your system
3) obviously, dailies or nightlies will be less stable

That's exactly why I worked on the package as published in Debian to
make it suitable to work in the precise build-time and run-time environment.

Regards

Rolf

···

On 04.03.2014 13:12, jungleboogie0 wrote:

#4

Hi Rolf,

I tend to disagree with your points 2 and 3. I don't know enough about 1 to
speak about it.

2) The repo is that of Jitsi--the creators of the app you're discussing.
Why should someone trust Debian more than the site where the app is made?

3) Stable only seems like it's a nightly release frozen at a rather
arbitrarily time. The idea with the stable release is only to ensure things
that were previously working were not broken, otherwise your stable build
will miss out on many, many new features. I really wish Debian had a way to
build apps from source and the ability to download packages, much like
freeBSD.

Thanks for the time,
Jungle

···

On 4 March 2014 01:26, Rolf Leggewie <foss@rolf.leggewie.biz> wrote:

Hello jungleboogie0,

thank you for your comment.

On 04.03.2014 13:12, jungleboogie0 wrote:
> You could also recommend people use the latest nightly repo from
> Jitsi: https://jitsi.org/Main/DebianNightlyRepository

Well, other people might differ, but I did not and would not feel
comfortable to use that option on a production-level computer.

1) the source is not published (this is actually a GPL violation)
2) with 3rd party repos you always have to worry if their packaging
   quality is high enough that it won't mess up your system
3) obviously, dailies or nightlies will be less stable

That's exactly why I worked on the package as published in Debian to
make it suitable to work in the precise build-time and run-time
environment.

Regards

Rolf

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si

#5

You could also recommend people use the latest nightly repo from
Jitsi: https://jitsi.org/Main/DebianNightlyRepository

Well, other people might differ, but I did not and would not feel
comfortable to use that option on a production-level computer.

1) the source is not published (this is actually a GPL violation)

Could you please explain which source(s) we don't publish?

2) with 3rd party repos you always have to worry if their packaging
   quality is high enough that it won't mess up your system
3) obviously, dailies or nightlies will be less stable

That's exactly why I worked on the package as published in Debian to
make it suitable to work in the precise build-time and run-time

environment.

Regards
Rolf

Ingo

#6

Ingo and Jungle,

thank you again for your comments.

1) the source is not published (this is actually a GPL violation)

Could you please explain which source(s) we don't publish?

Alright, it looks like I have to seriously backtrack on the GPL
violation accusation. I apologize. After much closer inspection, it
seems you guys do ship all necessary sources and actually in a format
you guys work with.

Nonetheless, to a user (like myself) who passes along wanting to try out
jitsi, the full availability of source is not immediately obvious and to
that extent my point #1 is still valid IMVHO. When I saw only the deb
packages in the publication directory I assumed (incorrectly, my
mistake) that the full source including _packaging_ information is not
available. This is not uncommon and an impression further established
in my mind after seeing that the packaging for the binary snapshots is
completely different from the ones in Debian itself. My assumption as
someone who recompiles software routinely is that you had used some
quick command-line hacks such as equivs to bake the debs. Again, not
uncommon, I even do that myself. Even if I had not given up here
already (which to my shame I have to admit I did) I would not have found
a debian directory in the top-level of the source. Your package is the
first I have ever come across that actually ships packaging information
but it comes in template form only (!) and in a third-level directory
buried deep down (!) and the packaging information needs to be
"compiled" first (!) with a tool almost entirely unknown to me to
generate source in a format ready for the "real" compilation by the
actual Debian tools.

In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.
This could be improved by putting a README or INSTALL file in the
source and up in the deb directory explaining how to (re)compile the deb
packages from the zip files (and were to find them).

I tend to disagree with your points 2 and 3. I don't know enough about 1 to speak about it.

Jungle, let me first point out that I am not trying to convince you to
change your opinion. Let's remember you had suggested that *I* should
advise others to install from the jitsi binary repo. I had already
granted that other people might differ, but personally, I am very
hesitant to install anything from outside the official Debian or Ubuntu
repos. Therefore, I would certainly not recommend others do that.

I do acknowledge that again, there are "different strokes for different
folks", I'm not trying to convince you of my position but since you
asked I'll try my best to give you an understanding of it.

2) The repo is that of Jitsi--the creators of the app you're discussing. Why should someone trust Debian more than the site where the app is made?

1) Coding and packaging are different skill sets
2) Debian has rules and processes in place that I am familiar with
   and trust.
3) Debian security audits
4) Debian packages receive a wider exposure compared to upstream debs
... (bunch of other reasons, Distros are there for a reason)

3) Stable only seems like it's a nightly release frozen at a rather arbitrarily time. The idea with the stable release is only to ensure things that were previously working were not broken, otherwise your stable build will miss out on many, many new features. I really wish Debian had a way to build apps from source and the ability to download packages, much like freeBSD.

Well, there's Gentoo for those who want the more bleeding edge, I guess.
Or even outright LFS. Constant updates and the problems associated
with it are not my cup of tea and certainly not for the use I mentioned,
a production computer.

I am MORE than happy to forego the many, many new shiny features and
value stability and productive use of my time higher. I'm happy to wait
for those shiny features until the next long-term-support release of my
distro. No rule without exception, of course. If there is a strong
need for my work to have a later package than available from the
official repos I will usually backport the source package from Debian
unstable or testing, recompile it and upload it to my PPA so that others
don't have to go to the trouble themselves. This is exactly what I did
with jitsi.

My initial mail was also a pitch to Damien and Emil to let them know
about my desire to help them out with maintaining the package in Debian.
I am an official Debian maintainer and can make uploads to the distro.

Regards

Rolf

···

On 04.03.2014 17:48, Ingo Bauersachs wrote:
On 05.03.2014 01:19, jungleboogie0 wrote:

#7

Hi,

Ingo and Jungle,

thank you again for your comments.

1) the source is not published (this is actually a GPL violation)

Could you please explain which source(s) we don't publish?

Alright, it looks like I have to seriously backtrack on the GPL
violation accusation. I apologize. After much closer inspection, it
seems you guys do ship all necessary sources and actually in a format
you guys work with.

Nonetheless, to a user (like myself) who passes along wanting to try out
jitsi, the full availability of source is not immediately obvious and to
that extent my point #1 is still valid IMVHO. When I saw only the deb
packages in the publication directory I assumed (incorrectly, my
mistake) that the full source including _packaging_ information is not
available. This is not uncommon and an impression further established
in my mind after seeing that the packaging for the binary snapshots is
completely different from the ones in Debian itself. My assumption as
someone who recompiles software routinely is that you had used some
quick command-line hacks such as equivs to bake the debs. Again, not
uncommon, I even do that myself. Even if I had not given up here
already (which to my shame I have to admit I did) I would not have found
a debian directory in the top-level of the source. Your package is the
first I have ever come across that actually ships packaging information
but it comes in template form only (!) and in a third-level directory
buried deep down (!) and the packaging information needs to be
"compiled" first (!) with a tool almost entirely unknown to me to
generate source in a format ready for the "real" compilation by the
actual Debian tools.

Yes, everything is for a reason.

In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.
This could be improved by putting a README or INSTALL file in the
source and up in the deb directory explaining how to (re)compile the deb
packages from the zip files (and were to find them).

Will do that.

I tend to disagree with your points 2 and 3. I don't know enough about 1 to speak about it.

Jungle, let me first point out that I am not trying to convince you to
change your opinion. Let's remember you had suggested that *I* should
advise others to install from the jitsi binary repo. I had already
granted that other people might differ, but personally, I am very
hesitant to install anything from outside the official Debian or Ubuntu
repos. Therefore, I would certainly not recommend others do that.

I do acknowledge that again, there are "different strokes for different
folks", I'm not trying to convince you of my position but since you
asked I'll try my best to give you an understanding of it.

2) The repo is that of Jitsi--the creators of the app you're discussing. Why should someone trust Debian more than the site where the app is made?

1) Coding and packaging are different skill sets
2) Debian has rules and processes in place that I am familiar with
   and trust.
3) Debian security audits
4) Debian packages receive a wider exposure compared to upstream debs
... (bunch of other reasons, Distros are there for a reason)

3) Stable only seems like it's a nightly release frozen at a rather arbitrarily time. The idea with the stable release is only to ensure things that were previously working were not broken, otherwise your stable build will miss out on many, many new features. I really wish Debian had a way to build apps from source and the ability to download packages, much like freeBSD.

Well, there's Gentoo for those who want the more bleeding edge, I guess.
Or even outright LFS. Constant updates and the problems associated
with it are not my cup of tea and certainly not for the use I mentioned,
a production computer.

I am MORE than happy to forego the many, many new shiny features and
value stability and productive use of my time higher. I'm happy to wait
for those shiny features until the next long-term-support release of my
distro. No rule without exception, of course. If there is a strong
need for my work to have a later package than available from the
official repos I will usually backport the source package from Debian
unstable or testing, recompile it and upload it to my PPA so that others
don't have to go to the trouble themselves. This is exactly what I did
with jitsi.

My initial mail was also a pitch to Damien and Emil to let them know
about my desire to help them out with maintaining the package in Debian.
I am an official Debian maintainer and can make uploads to the distro.

Hey, thanks for that. We will definitely will need help :slight_smile: We plan
soon to start working on packages for jitmeet and jitsi-videobridge,
which means that first we need to take out libjitsi out of jitsi
package. Which will simplify a little bit the packages :slight_smile:

Thanks
damencho

···

On Wed, Mar 5, 2014 at 6:55 PM, Rolf Leggewie <foss@rolf.leggewie.biz> wrote:

On 04.03.2014 17:48, Ingo Bauersachs wrote:
On 05.03.2014 01:19, jungleboogie0 wrote:

Regards

Rolf

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#8

Hey

1) the source is not published (this is actually a GPL violation)

Could you please explain which source(s) we don't publish?

Alright, it looks like I have to seriously backtrack on the GPL
violation accusation. I apologize. After much closer inspection, it
seems you guys do ship all necessary sources and actually in a format
you guys work with.

How would we have made it into Debian if we wouldn't do that?

Nonetheless, to a user (like myself) who passes along wanting to try out
jitsi, the full availability of source is not immediately obvious and to
that extent my point #1 is still valid IMVHO. When I saw only the deb
packages in the publication directory I assumed (incorrectly, my
mistake) that the full source including _packaging_ information is not
available.

Well. I'm not familiar with how a "usual" download directory should look
like. Our download page provides pre-built packages for all supported
platforms and source code snapshots. This snapshot is probably not what you
want because it contains the dependent libraries as binaries. This is how
Java applications are usually packaged - or at least used to be.
There are two kinds of binaries in there:
- Native code (JNI), that needs a C-compiler
- and the referenced libraries.

These are included because it would be next to impossible for a bypasser to
compile 20+ referenced projects (all with their own dependencies) and the
complicated JNI stuff. All this is largely due to the fact that the main
application is Java. Not every small library is available (or even available
in Maven if we would use it).

And then there is:
https://download.jitsi.org/jitsi/nightly/debian-src/

created with the statements from
http://lists.jitsi.org/pipermail/dev/2014-January/019700.html

Having this directory linked would probably satisfy all your requirements.

This is not uncommon and an impression further established
in my mind after seeing that the packaging for the binary snapshots is
completely different from the ones in Debian itself.

The reason for this is that we ship all the dependent libraries in our .deb,
while the package in Debian references the libraries available in the
package manager. The reason we do this is that a lot of referenced libraries
are not available in Debian at all, are not packaged correctly (missing OSGi
manifest) or need to be patched.

We went through great lengths to adapt the package build process to use the
distros packages and the result that we are now in Debian. For the builds
available from our homepage however, it still works best for us and the
users to ship the necessary libraries. Those who don't want to use our repo:
fine, use that of the distro (and please excuse my sarcasm, enjoy Ubuntu bug
894302).

My assumption as
someone who recompiles software routinely is that you had used some
quick command-line hacks such as equivs to bake the debs. Again, not
uncommon, I even do that myself. Even if I had not given up here
already (which to my shame I have to admit I did) I would not have found
a debian directory in the top-level of the source. Your package is the
first I have ever come across that actually ships packaging information
but it comes in template form only (!) and in a third-level directory
buried deep down (!) and the packaging information needs to be
"compiled" first (!) with a tool almost entirely unknown to me to
generate source in a format ready for the "real" compilation by the
actual Debian tools.

The reason why the Debian files are not in the root directory is simple: we
support Windows, Mac and Linux. Placing a Debian directory (or rpm or
whatever) would clutter the directory tree.

In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.

I've seen far worse open source projects... but I might be biased.

This could be improved by putting a README or INSTALL file in the
source and up in the deb directory explaining how to (re)compile the deb
packages from the zip files (and were to find them).

Damian already agreed to do that, but you might give him a hand with the
contents.

[jungle reply ...]

I am MORE than happy to forego the many, many new shiny features and
value stability and productive use of my time higher. I'm happy to wait
for those shiny features until the next long-term-support release of my
distro. No rule without exception, of course. If there is a strong
need for my work to have a later package than available from the
official repos I will usually backport the source package from Debian
unstable or testing, recompile it and upload it to my PPA so that others
don't have to go to the trouble themselves. This is exactly what I did
with jitsi.

My initial mail was also a pitch to Damien and Emil to let them know
about my desire to help them out with maintaining the package in Debian.
I am an official Debian maintainer and can make uploads to the distro.
Regards

Sure, that went a bit under the carpet with jungleboogies suggestions and
the GPL accusation. As part of that offer I added you as being notified on
the log4j bug (thanks for changing the status!). Damian is mainly
responsible for the Debian packaging, so I guess he will reply to any
packaging stuff that comes up.

I've taken care of some other bugs and we'd happily include patches into our
master tree. To do that however, we need them be created and submitted from
someone who signed our contributor agreement (http://bluejimp.com/bca.pdf).
This is because there are private branches, but I guess as an Ubuntu
developer you already know the reasons for such a document.

This got longer than expected, hope I answered all currently open
questions...

Rolf

Ingo

···

On 04.03.2014 17:48, Ingo Bauersachs wrote:

#9

Damian,

thank you for your reply.

I would not have found
a debian directory in the top-level of the source. Your package is the
first I have ever come across that actually ships packaging information
but it comes in template form only (!) and in a third-level directory
buried deep down (!) and the packaging information needs to be
"compiled" first (!) with a tool almost entirely unknown to me to
generate source in a format ready for the "real" compilation by the
actual Debian tools.

Yes, everything is for a reason.

Well, I guess so. Can you elaborate a bit on those? I was wondering
what's preventing you guys from simply moving the debian directory to
the top-level and doing away with those templates and variables that
need replacement during the initial build?

Where can I see how the orig tarballs (the ones you ship in Debian) are
being generated?

In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.
This could be improved by putting a README or INSTALL file in the
source and up in the deb directory explaining how to (re)compile the deb
packages from the zip files (and were to find them).

Will do that.

I'll try to pitch in when I find the time.

My initial mail was also a pitch to Damien and Emil to let them know
about my desire to help them out with maintaining the package in Debian.
I am an official Debian maintainer and can make uploads to the distro.

Hey, thanks for that. We will definitely will need help :slight_smile:

Cool. Should I add myself to Uploaders in the control file? The benefit
being that I can then eventually make uploads without requiring a
sponsor as is currently the case.

Are you OK with making a -2 release with the current tarball? It would
be easier than releasing a new tarball first. By the way, this is
something your current setup does not easily support but it should
(certainly when jitsi moves to Debian stable for the first time).

soon to start working on packages for jitmeet and jitsi-videobridge,
which means that first we need to take out libjitsi out of jitsi
package. Which will simplify a little bit the packages :slight_smile:

Any work on this going on, yet? Published?

Regards

Rolf

···

On 07.03.2014 15:50, Damian Minkov wrote:

#10

Ingo,

thank you for your comment. For the most part I had the impression you
were in an aggressive, not in a contructive, results-oriented mode. At
first I thought I would skip to answer you, but then I felt I should
give you the benefit of the doubt that in the end you are interested in
improving and sharing and not in "being right" or "winning an argument"
or anything like that.

1) the source is not published (this is actually a GPL violation)

[...]

How would we have made it into Debian if we wouldn't do that?

I thought it was clear that we are talking about
https://download.jitsi.org/jitsi/debian/jitsi_2.5-latest_amd64.deb for
example and not
http://ftp.us.debian.org/debian/pool/main/j/jitsi/jitsi_2.4.4997-1_all.deb.
Availability of the source of the former is not immediately obvious as
I thought I had explained.

Well. I'm not familiar with how a "usual" download directory should look
like.

A usual download directory for a debian binary package generally has the
original tarball, the debian tarball (packaging information) and a dsc
file (and possibly others). These files are not published anywhere for
the jisti-supplied debs, but I believe you create them from the source
snapshots you do provide and throw them away after the build. That's
unusual, seems wasteful and lends itself to misunderstandings of the
kind we had but I guess it would be a slight stretch to call it a
GPL-violation, so I backtracked on that.

Our download page provides pre-built packages for all supported
platforms and source code snapshots. This snapshot is probably not what you
want because it contains the dependent libraries as binaries.

Yes, all distros will discourage embedded code copies.

Shipping all your libs might make sense to make sure things are working
but is not something you can recommend to someone who takes the proper
and secure functioning of his computer seriously. It makes sense for
jitsi as a project, I understand that. For me as a user, it wouldn't be
something I like.

These are included because it would be next to impossible for a bypasser to
compile 20+ referenced projects (all with their own dependencies)

This is the distros' job, most importantly that of the packager
supplying accurate build-time information. Building jitsi on Debian
usually requires only one command to download the source (including
packaging information) and one more to build it in a clean chroot
environment. All lib dev files, etc. are taken care of. Your setup
completely breaks this for the snapshots.

http://lists.jitsi.org/pipermail/dev/2014-January/019700.html

Yes, it would be good to have that information more prominently
available. Still, this looks awfully complicated. More than it has to
be IMVHO.

BTW, I just *did* the work of backporting jitsi to wheezy-backports.
The branch I published should compile fine in wheezy, precise is even older.

Those who don't want to use our repo:
fine, use that of the distro (and please excuse my sarcasm, enjoy Ubuntu bug
894302).

Excuse me, but is that sarcasm really necessary? Are you absolutely
sure that your code has LESS bugs than the stuff in Ubuntu? With LOTS
more eyeballs on what is in Debian and Ubuntu? And even if it was,
would I as a user REALLY want to spend my time auditing that this is in
fact true (assuming that I would be able to, which I'm not)? And would
I REALLY want to repeat this process after every one of your releases?
And keep up-to-date with security alerts, etc.?

For me, the answer is clear. Using a distro comes at a price, but it's
WAY lower than the alternatives.

The reason why the Debian files are not in the root directory is simple: we
support Windows, Mac and Linux. Placing a Debian directory (or rpm or
whatever) would clutter the directory tree.

I strongly suggest you use separate upstream code and packaging code
branches. Then the problem simply goes away. It seems you already use
different repos, not even branches in the same repo, to compile your
bundle every time. I'd think this would be a lot cleaner, easier to
maintain and wouldn't break the build-tools in Debian and probably other
distros.

In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.

I've seen far worse open source projects... but I might be biased.

Whether jitsi is a good project or not is not the point.

I've not even looked or tried to and I don't want to - and that is the
point. Why repeat the work that somebody else is much more qualified to
do? My policy is to usually not install software that hasn't passed
Debian muster.

And once more, coding and packaging skills are not the same and there
are VERY few people who understand both well.

I've taken care of some other bugs and we'd happily include patches into our
master tree. To do that however, we need them be created and submitted from
someone who signed our contributor agreement (http://bluejimp.com/bca.pdf).

I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.

Best regards

Rolf

···

On 08.03.2014 22:06, Ingo Bauersachs wrote:

On 04.03.2014 17:48, Ingo Bauersachs wrote:

#11

thank you for your comment. For the most part I had the impression you
were in an aggressive, not in a contructive, results-oriented mode. At
first I thought I would skip to answer you, but then I felt I should
give you the benefit of the doubt that in the end you are interested in
improving and sharing and not in "being right" or "winning an argument"
or anything like that.

I'm sorry if it sounded like that. That was certainly not the intention and
I know that I sometimes should choose my wording more carefully. I
definitely don't want to win an argument, at best I'm going to ignore all
this because I mostly work on Windows anyway.

1) the source is not published (this is actually a GPL violation)

[...]

How would we have made it into Debian if we wouldn't do that?

I thought it was clear that we are talking about
https://download.jitsi.org/jitsi/debian/jitsi_2.5-latest_amd64.deb for
example and not

http://ftp.us.debian.org/debian/pool/main/j/jitsi/jitsi_2.4.4997-1_all.deb.

Availability of the source of the former is not immediately obvious as
I thought I had explained.

Well. I'm not familiar with how a "usual" download directory should look
like.

A usual download directory for a debian binary package generally has the
original tarball, the debian tarball (packaging information) and a dsc
file (and possibly others). These files are not published anywhere for
the jisti-supplied debs, but I believe you create them from the source
snapshots you do provide and throw them away after the build. That's
unusual, seems wasteful and lends itself to misunderstandings of the
kind we had but I guess it would be a slight stretch to call it a
GPL-violation, so I backtracked on that.

Okay, so: Damian, can we put those files into the debian directory?

Our download page provides pre-built packages for all supported
platforms and source code snapshots. This snapshot is probably not what

you

want because it contains the dependent libraries as binaries.

Yes, all distros will discourage embedded code copies.

Shipping all your libs might make sense to make sure things are working
but is not something you can recommend to someone who takes the proper
and secure functioning of his computer seriously. It makes sense for
jitsi as a project, I understand that. For me as a user, it wouldn't be
something I like.

Yes, of course.

These are included because it would be next to impossible for a bypasser

to

compile 20+ referenced projects (all with their own dependencies)

This is the distros' job, most importantly that of the packager
supplying accurate build-time information. Building jitsi on Debian
usually requires only one command to download the source (including
packaging information) and one more to build it in a clean chroot
environment. All lib dev files, etc. are taken care of. Your setup
completely breaks this for the snapshots.

I'm open to suggestions how we should organize our git repository to fix all
that. (And that's again not intended to sound aggressive, I really don't
know any better way currently and if you have suggestions, it could perhaps
solve other problems (source attachment in the IDEs for example).)
The main problem here is that a lot of our dependent libraries are not
available as Debian packages (a detailed list in
/resources/install/debian/README.embedded-libraries).

http://lists.jitsi.org/pipermail/dev/2014-January/019700.html

Yes, it would be good to have that information more prominently
available.

Damian, can we put that somewhere in a README, e.g. in the debian download
directory?

Still, this looks awfully complicated. More than it has to
be IMVHO.

How should it look like then?

BTW, I just *did* the work of backporting jitsi to wheezy-backports.
The branch I published should compile fine in wheezy, precise is even

older.

Those who don't want to use our repo: fine, use that of the distro (and
please excuse my sarcasm, enjoy Ubuntu bug 894302).

Excuse me, but is that sarcasm really necessary? Are you absolutely
sure that your code has LESS bugs than the stuff in Ubuntu? With LOTS
more eyeballs on what is in Debian and Ubuntu? And even if it was,
would I as a user REALLY want to spend my time auditing that this is in
fact true (assuming that I would be able to, which I'm not)? And would
I REALLY want to repeat this process after every one of your releases?
And keep up-to-date with security alerts, etc.?

For me, the answer is clear. Using a distro comes at a price, but it's
WAY lower than the alternatives.

No, it isn't. Sorry.
But I hope we can agree that actions such as "Remove dependency on bnd and
don't add OSGi headers to jar file." fall into the same category as the
famous random number bug.

The reason why the Debian files are not in the root directory is simple:

we

support Windows, Mac and Linux. Placing a Debian directory (or rpm or
whatever) would clutter the directory tree.

I strongly suggest you use separate upstream code and packaging code
branches. Then the problem simply goes away. It seems you already use
different repos, not even branches in the same repo, to compile your
bundle every time. I'd think this would be a lot cleaner, easier to
maintain and wouldn't break the build-tools in Debian and probably other
distros.

I guess you mean the libjitsi, otr4j and the libsrc repos. The first two are
dependencies (but independent projects) but also maintained by us. The last
is a repository that contains the source code snapshots of all dependencies
we use.

The branch approach sounds useful. Given how loved git is by some members, I
doubt though that we switch to that. But this is not my decision to make.

In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.

I've seen far worse open source projects... but I might be biased.

Whether jitsi is a good project or not is not the point.

I've not even looked or tried to and I don't want to - and that is the
point. Why repeat the work that somebody else is much more qualified to
do? My policy is to usually not install software that hasn't passed
Debian muster.

And once more, coding and packaging skills are not the same and there
are VERY few people who understand both well.

See, that's why we did it so bad :slight_smile:

I've taken care of some other bugs and we'd happily include patches
into our master tree. To do that however, we need them be created and
submitted from someone who signed our contributor agreement
(http://bluejimp.com/bca.pdf).

I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.

The code itself is LGPL and needs to stay that way. Emil would have to
decide if there can be an exception for packaging files regarding the
contributor agreement.

Best regards
Rolf

Ingo

···

On 08.03.2014 22:06, Ingo Bauersachs wrote:

On 04.03.2014 17:48, Ingo Bauersachs wrote:

#12

Hi,

thank you for your comment. For the most part I had the impression you
were in an aggressive, not in a contructive, results-oriented mode. At
first I thought I would skip to answer you, but then I felt I should
give you the benefit of the doubt that in the end you are interested in
improving and sharing and not in "being right" or "winning an argument"
or anything like that.

I'm sorry if it sounded like that. That was certainly not the intention and
I know that I sometimes should choose my wording more carefully. I
definitely don't want to win an argument, at best I'm going to ignore all
this because I mostly work on Windows anyway.

1) the source is not published (this is actually a GPL violation)

[...]

How would we have made it into Debian if we wouldn't do that?

I thought it was clear that we are talking about
https://download.jitsi.org/jitsi/debian/jitsi_2.5-latest_amd64.deb for
example and not

http://ftp.us.debian.org/debian/pool/main/j/jitsi/jitsi_2.4.4997-1_all.deb.

Availability of the source of the former is not immediately obvious as
I thought I had explained.

Well. I'm not familiar with how a "usual" download directory should look
like.

A usual download directory for a debian binary package generally has the
original tarball, the debian tarball (packaging information) and a dsc
file (and possibly others). These files are not published anywhere for
the jisti-supplied debs, but I believe you create them from the source
snapshots you do provide and throw them away after the build. That's
unusual, seems wasteful and lends itself to misunderstandings of the
kind we had but I guess it would be a slight stretch to call it a
GPL-violation, so I backtracked on that.

Okay, so: Damian, can we put those files into the debian directory?

No, they are not created. The deb package on our site is not created
entirely from source as it reuses jars and native binaries.
These are the files for example from latest nightly build:
jitsi_2.5.5134-1_amd64.changes
jitsi_2.5.5134-1_amd64.deb.asc
jitsi_2.5.5134-1_i386.deb
jitsi_2.5.5134_amd64.changelog
jitsi_2.5.5134.orig.tar.gz
jitsi_2.5.5134-1_amd64.deb
jitsi_2.5.5134-1_i386.changes
jitsi_2.5.5134-1_i386.deb.asc
jitsi_2.5.5134_i386.changelog

We upload everything without *.asc and *.orig.tar.gz and everything is
there in the download folder, some files are hidden cause they mean
nothing to the normal user.

Our download page provides pre-built packages for all supported
platforms and source code snapshots. This snapshot is probably not what

you

want because it contains the dependent libraries as binaries.

Yes, all distros will discourage embedded code copies.

Shipping all your libs might make sense to make sure things are working
but is not something you can recommend to someone who takes the proper
and secure functioning of his computer seriously. It makes sense for
jitsi as a project, I understand that. For me as a user, it wouldn't be
something I like.

Yes, of course.

These are included because it would be next to impossible for a bypasser

to

compile 20+ referenced projects (all with their own dependencies)

This is the distros' job, most importantly that of the packager
supplying accurate build-time information. Building jitsi on Debian
usually requires only one command to download the source (including
packaging information) and one more to build it in a clean chroot
environment. All lib dev files, etc. are taken care of. Your setup
completely breaks this for the snapshots.

I'm open to suggestions how we should organize our git repository to fix all
that. (And that's again not intended to sound aggressive, I really don't
know any better way currently and if you have suggestions, it could perhaps
solve other problems (source attachment in the IDEs for example).)
The main problem here is that a lot of our dependent libraries are not
available as Debian packages (a detailed list in
/resources/install/debian/README.embedded-libraries).

http://lists.jitsi.org/pipermail/dev/2014-January/019700.html

Yes, it would be good to have that information more prominently
available.

Damian, can we put that somewhere in a README, e.g. in the debian download
directory?

Will do, when I start looking at the debian package for libjitsi.

Regards
damencho

···

On Sat, Mar 8, 2014 at 6:35 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

On 08.03.2014 22:06, Ingo Bauersachs wrote:

On 04.03.2014 17:48, Ingo Bauersachs wrote:

Still, this looks awfully complicated. More than it has to
be IMVHO.

How should it look like then?

BTW, I just *did* the work of backporting jitsi to wheezy-backports.
The branch I published should compile fine in wheezy, precise is even

older.

Those who don't want to use our repo: fine, use that of the distro (and
please excuse my sarcasm, enjoy Ubuntu bug 894302).

Excuse me, but is that sarcasm really necessary? Are you absolutely
sure that your code has LESS bugs than the stuff in Ubuntu? With LOTS
more eyeballs on what is in Debian and Ubuntu? And even if it was,
would I as a user REALLY want to spend my time auditing that this is in
fact true (assuming that I would be able to, which I'm not)? And would
I REALLY want to repeat this process after every one of your releases?
And keep up-to-date with security alerts, etc.?

For me, the answer is clear. Using a distro comes at a price, but it's
WAY lower than the alternatives.

No, it isn't. Sorry.
But I hope we can agree that actions such as "Remove dependency on bnd and
don't add OSGi headers to jar file." fall into the same category as the
famous random number bug.

The reason why the Debian files are not in the root directory is simple:

we

support Windows, Mac and Linux. Placing a Debian directory (or rpm or
whatever) would clutter the directory tree.

I strongly suggest you use separate upstream code and packaging code
branches. Then the problem simply goes away. It seems you already use
different repos, not even branches in the same repo, to compile your
bundle every time. I'd think this would be a lot cleaner, easier to
maintain and wouldn't break the build-tools in Debian and probably other
distros.

I guess you mean the libjitsi, otr4j and the libsrc repos. The first two are
dependencies (but independent projects) but also maintained by us. The last
is a repository that contains the source code snapshots of all dependencies
we use.

The branch approach sounds useful. Given how loved git is by some members, I
doubt though that we switch to that. But this is not my decision to make.

In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.

I've seen far worse open source projects... but I might be biased.

Whether jitsi is a good project or not is not the point.

I've not even looked or tried to and I don't want to - and that is the
point. Why repeat the work that somebody else is much more qualified to
do? My policy is to usually not install software that hasn't passed
Debian muster.

And once more, coding and packaging skills are not the same and there
are VERY few people who understand both well.

See, that's why we did it so bad :slight_smile:

I've taken care of some other bugs and we'd happily include patches
into our master tree. To do that however, we need them be created and
submitted from someone who signed our contributor agreement
(http://bluejimp.com/bca.pdf).

I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.

The code itself is LGPL and needs to stay that way. Emil would have to
decide if there can be an exception for packaging files regarding the
contributor agreement.

Best regards
Rolf

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#13

I'm sorry if it sounded like that.

Schwamm dr�ber :wink:

I'm open to suggestions how we should organize our git repository to fix all
that.

While I do not think that I fully understand the position of Jitsi as a
project, I would assume that separating the program code branch from
several packaging code branches might be an idea. The code branch is
then merged into the packaging branch from which the release can easily
be made. Added benefit is that you can easily have more restrictive
contributors' requirements for the code branch when compared to the
packaging branch. I wonder if this approach would create a problem for
the Jitsi project?

solve other problems (source attachment in the IDEs for example).)

I do not use an IDE. Can you try to explain the problem here? The
easier, the better :wink:

The main problem here is that a lot of our dependent libraries are not
available as Debian packages (a detailed list in
/resources/install/debian/README.embedded-libraries).

That's certainly something to work on over time, but I do not think this
affects what we are discussing too much.

Packaging for Debian should eventually rely less and less on embedded
copies. It's one of the TODO items for the Debian packager to work with
other packagers on this. If you still prefer to have your nightly/daily
snapshot binaries to be built with embedded copies, that's fine of
course. One way to achieve that is with two separate build specs which
I believe is what is currently happening.

For me, the answer is clear. Using a distro comes at a price, but it's
WAY lower than the alternatives.

No, it isn't. Sorry.

OK. I think it's self-evident by the fact that Distros are popular.
But we can certainly agree to disagree (or fail to understand each
other's position)

But I hope we can agree that actions such as "Remove dependency on bnd and
don't add OSGi headers to jar file." fall into the same category as the
famous random number bug.

I know nothing about that "famous" bug and I know very little about the
bnd bug except that trying to solve one problem introduced a regression
elsewhere and that it's now finally being dealt with.

(http://bluejimp.com/bca.pdf).

I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.

The code itself is LGPL and needs to stay that way. Emil would have to
decide if there can be an exception for packaging files regarding the
contributor agreement.

Emil has remained remarkably silent on this topic, I hope he will
eventually find the time to pitch in with his thoughts. Especially the
question if he would welcome another official Debian uploader.

I will probably not do much - if any - upstream coding so the license
might not be as much of a problem. I will do packaging work and I would
not be happy to see my work go closed source. But my work would not
affect any Windows or iOS or Android binaries and these are I guess the
OSs targetted with any private branches out there.

···

On 09.03.2014 00:35, Ingo Bauersachs wrote:

#14

Rolf Leggewie:

I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.

The Jitsi-community has been using the LGPL for a long time and Debian
does not prefer GPL over LGPL.

It is not obvious what the GPL would legally imply for packaging work
(if anything at all). So the only certain implication is that
considering to use the GPL for that limited purpose takes time.

For those reasons I suggest to withdraw that GPL-requirement and just
adopt a license which is compatible with both Debian and the
Jistsi-community.

(I am not seeking for the Jitsi team but am a member of the FOSS community)

Cheers,
Andreas

#15

Hello!

A usual download directory for a debian binary package generally has the
original tarball, the debian tarball (packaging information) and a dsc
file (and possibly others). These files are not published anywhere for
the jisti-supplied debs, but I believe you create them from the source
snapshots you do provide and throw them away after the build. That's
unusual, seems wasteful and lends itself to misunderstandings of the
kind we had but I guess it would be a slight stretch to call it a
GPL-violation, so I backtracked on that.

Okay, so: Damian, can we put those files into the debian directory?

No, they are not created. The deb package on our site is not created
entirely from source

Then that sounds indeed like a GPL-violation to me. You have to supply
full source that allows to recreate the binaries you publish. And it
has to be published "alongside" the binaries.

I am not very familiar with the ant build process, certainly not
familiar enough to dissect what is going on. So, please tell us how the
binaries are being "compiled"? Am I correct to assume that no real
compilation is taking place, but it's just a bunch of files being copied
around and possibly compressed as zip/jar files, etc.? What is the
command used by the ant build process to actually create the deb packages?

These are the files for example from latest nightly build:
jitsi_2.5.5134-1_amd64.changes

Do these files reference the dsc files? Maybe you can pastebin an
example file?

Regards

Rolf

···

On 10.03.2014 15:43, Damian Minkov wrote:

#16

Hello Andreas,

thank you for your comments.

Rolf Leggewie:

I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.

The Jitsi-community has been using the LGPL for a long time and Debian
does not prefer GPL over LGPL.

Jitsi code is licensed under LGPL, that much is true. But contributions
themselves are not accepted under LGPL, instead you need to sign an
agreement that reads to me more like an MIT license. I do not want to
contribute under such a license, I think you misunderstood that point.
It is too permissisive, I do not want my contributions to be included in
closed-source projects. I am aware that this might mean that I cannot
help the Jitsi community. In that case, I'd try to help Jitsi in
Debian. And lastly, I can contribute to Jitsi in Ubuntu in case Jitsi
Debian turned out to be impossible as well (Jitsi Devs are the Jitsi
Debian maintainers and currently no additional third party).

It is not obvious what the GPL would legally imply for packaging work
(if anything at all).

Are you sure you understand the differences between the different licenses?

I believe the packaging and the code core can be separated and
contributions for the packaging accepted under a different, more
restrictive license if Emil so chooses. An answer to that possibility
is what we are still waiting for.

For those reasons I suggest to withdraw that GPL-requirement and just
adopt a license which is compatible with both Debian and the
Jistsi-community.

You misunderstood where the "problem" lies. MIT for example would
certainly be fine by Debian, but I'm not willing to put any Jitsi
packaging work I might do under MIT or similar.

Regards

Rolf

···

On 11.03.2014 16:39, Andreas Kuckartz wrote:

#17

Hi,

Hello!

A usual download directory for a debian binary package generally has the
original tarball, the debian tarball (packaging information) and a dsc
file (and possibly others). These files are not published anywhere for
the jisti-supplied debs, but I believe you create them from the source
snapshots you do provide and throw them away after the build. That's
unusual, seems wasteful and lends itself to misunderstandings of the
kind we had but I guess it would be a slight stretch to call it a
GPL-violation, so I backtracked on that.

Okay, so: Damian, can we put those files into the debian directory?

No, they are not created. The deb package on our site is not created
entirely from source

Then that sounds indeed like a GPL-violation to me. You have to supply
full source that allows to recreate the binaries you publish. And it
has to be published "alongside" the binaries.

The sources are published with every build next to the binaries:
https://download.jitsi.org/jitsi/nightly/debian/
https://download.jitsi.org/jitsi/nightly/src/

I am not very familiar with the ant build process, certainly not
familiar enough to dissect what is going on. So, please tell us how the
binaries are being "compiled"? Am I correct to assume that no real
compilation is taking place, but it's just a bunch of files being copied
around and possibly compressed as zip/jar files, etc.? What is the
command used by the ant build process to actually create the deb packages?

To generate a deb file which is uploaded to our repository you just
need to do: ant deb -Dlabel=1234. Which uses the jar files as they are
and native binaries that are in lib/native. Binaries build script is
in src/native/build.xml.
To generate a debian source package you need to execute: ant deb-src
-Dlabel... and then that package can be build with debian package
tools.
This is the information I'm planning to put in the readme files.

These are the files for example from latest nightly build:
jitsi_2.5.5134-1_amd64.changes

Do these files reference the dsc files? Maybe you can pastebin an
example file?

Here it is:
https://download.jitsi.org/jitsi/nightly/debian/jitsi_2.5.5134-1_i386.changes
And the asc files actually are publicly accessible:
https://download.jitsi.org/jitsi/nightly/debian/signatures/

Regards
damencho

···

On Mon, Mar 10, 2014 at 10:24 AM, Rolf Leggewie <foss@rolf.leggewie.biz> wrote:

On 10.03.2014 15:43, Damian Minkov wrote:

Regards

Rolf

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#18

Damian,

thank you for the quick reply.

No, they are not created. The deb package on our site is not created
entirely from source

Then that sounds indeed like a GPL-violation to me. You have to supply
full source that allows to recreate the binaries you publish. And it
has to be published "alongside" the binaries.

The sources are published with every build next to the binaries:
https://download.jitsi.org/jitsi/nightly/debian/
https://download.jitsi.org/jitsi/nightly/src/

I see. Let's see if I got it correct now.

- Jitsi source is fully published
- You are shipping some lib binaries and use them to compile jitsi but
  you are not including the source for the libraries

Correct?

Depending on the license of the library, then it's still a GPL-violation
to provide full source, even if you don't compile the binaries from
source yourself.

That's a bit different from my original concern, though, which was to be
able to recreate the debs the same way you create them which I believe
is possible, albeit in a non-standard way.

To generate a debian source package you need to execute: ant deb-src
-Dlabel... and then that package can be build with debian package
tools.

So it is indeed the two-stage process I had previously thought it was.

What command do you actually use for the second stage, what debian
package tools? pbuilder? debuild?

This is the information I'm planning to put in the readme files.

Great.

Regards

Rolf

···

On 10.03.2014 17:09, Damian Minkov wrote:

#19

Rolf Leggewie:

I do not want my contributions to be included in
closed-source projects.

I see. So you insist on the GPL because the LGPL would not satisfy that
requirement.

It is not obvious what the GPL would legally imply for packaging work
(if anything at all).

Are you sure you understand the differences between the different
licenses?

I think so, yes. But I consider the likely practical difference for your
work to be marginal. It might even be questionable if the usual scripts
included in packages are protected by copyright law but I do not want to
spend more time thinking about such questions now.

It is my opinion that Debian packagers as a general rule should not try
to enforce their preferred FOSS license on FOSS software they are
packaging. But what you are doing certainly is your decision. I wonder
what would happen if there were _two_ separate Jitsi packages where the
main essential difference is the license of the packaging scripts.

Cheers,
Andreas

#20

Hey Rolf,

(I very much apologise for the delay here)

Hello Andreas,

thank you for your comments.

Rolf Leggewie:

I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.

The Jitsi-community has been using the LGPL for a long time and Debian
does not prefer GPL over LGPL.

Jitsi code is licensed under LGPL, that much is true. But contributions
themselves are not accepted under LGPL, instead you need to sign an
agreement that reads to me more like an MIT license.

Correct.

I do not want to
contribute under such a license, I think you misunderstood that point.
It is too permissisive, I do not want my contributions to be included in
closed-source projects. I am aware that this might mean that I cannot
help the Jitsi community.

Unfortunately this might be the case. Jitsi development is funded in large part by BlueJimp's business activity that relies on companies adopting Jitsi for their deployments. Sometimes such deployments are conditioned on the possibility to add proprietary modules to the project. Sacrificing that option with GPL content could have a significant negative impact on Jitsi enterprise adoption and hence on the development of Jitsi itself.

We also need to have the option of changing FLOSS licenses in the future. Maybe we'd like to move to LGPL3 or MIT or Apache or AGPL. Who knows. We can't do this unless you have signed a contributor agreement.

Note that this agreement does say your work will always also be provided as open source.

In that case, I'd try to help Jitsi in
Debian. And lastly, I can contribute to Jitsi in Ubuntu in case Jitsi
Debian turned out to be impossible as well (Jitsi Devs are the Jitsi
Debian maintainers and currently no additional third party).

Anyway you choose to help would be greatly appreciated.

It is not obvious what the GPL would legally imply for packaging work
(if anything at all).

Are you sure you understand the differences between the different licenses?

I believe the packaging and the code core can be separated and
contributions for the packaging accepted under a different, more
restrictive license if Emil so chooses. An answer to that possibility
is what we are still waiting for.

You are free to do that. You can easily create your scripts separately then apply any number of scripts that you distribute as you see fit.

If however, we are to maintain those scripts in the Jitsi repo than I'd rather avoid an augmented licensing complexity and special rules for a non-critical piece of the project.

Hope this makes sense to you.

Cheer,
Emil

···

On 11.03.14, 12:15, Rolf Leggewie wrote:

On 11.03.2014 16:39, Andreas Kuckartz wrote:

--
https://jitsi.org