[jitsi-dev] Jitsi in Debian


#1

Hi Jitsi Team,

Some of us at the Tor Project are exploring options for voice conferences. We heard some nice things about Jitsi, but noticed that it's not quite yet in Debian:

https://packages.debian.org/sid/jitsi

The issue appears to be that libjitsi, a dependency of jitsi, has been rejected from Debian a few times:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038

When the Debian FTP masters rejected your package, they would have sent you an email on why. Could you enlighten us on the reason? A few of us (at Tor, that is) are also Debian Developers, so could help you with these issues, as well as sponsor your next upload.

Could you also publish the Debian packaging in a git repository somewhere? You can then add Vcs-Browser: and Vcs-Git: fields to debian/control, for others to find and contribute.

Thanks!

Ximin

···

--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git


#2

Hi Jitsi Team,

Any update on my previous email? The offer to help with packaging still stands.

I am emailing this address dev@jitsi.org because this is listed as the Maintainer: for the current jitsi package, in debian/control. This address is used by Debian infrastructure [1] to send out bug reports and other automatic notifications, as well as a point-of-contact for developers and users to contact you about the package.

However, I see that my previous message (written in September) wasn't delivered to the mailing list [2]. I also notice that Debian bug reports for Jitsi, e.g. [3] haven't been delivered to the mailing list [4], but some other Debian notices have [5].

Are your moderators selectively dropping messages? If so, please consider using a different email address for your Maintainers: field in debian/control, that accepts all relevant messages. It's not responsible to ignore questions from your users.

X

[1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
[2] http://lists.jitsi.org/pipermail/dev/2015-September/thread.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038
[4] http://lists.jitsi.org/pipermail/dev/2015-June/thread.html
[5] http://lists.jitsi.org/pipermail/dev/2015-June/024411.html

···

On 18/09/15 00:45, Ximin Luo wrote:

Hi Jitsi Team,

Some of us at the Tor Project are exploring options for voice conferences. We heard some nice things about Jitsi, but noticed that it's not quite yet in Debian:

https://packages.debian.org/sid/jitsi

The issue appears to be that libjitsi, a dependency of jitsi, has been rejected from Debian a few times:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038

When the Debian FTP masters rejected your package, they would have sent you an email on why. Could you enlighten us on the reason? A few of us (at Tor, that is) are also Debian Developers, so could help you with these issues, as well as sponsor your next upload.

Could you also publish the Debian packaging in a git repository somewhere? You can then add Vcs-Browser: and Vcs-Git: fields to debian/control, for others to find and contribute.

Thanks!

Ximin

--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git


#3

Any update on my previous email? The offer to help with packaging still
stands.

I don't remember any previous mail, so that might have gotten lost somewhere. As you might know (or maybe not) Bluejimp got acquired by Atlassian and the main focus now lies on Jitsi Meet. So any help with packaging would be appreciated. This mostly would be with dependent packages though. AFAIK the reason why libjitsi is/was blocked is the license for the javax.sdp/javax.sip API files. DD Daniel Pocock reimplemented them cleanly and we need to start using them and then they need to be packaged and uploaded to Debian too.

I am emailing this address dev@jitsi.org because this is listed as the
Maintainer: for the current jitsi package, in debian/control. This address is
used by Debian infrastructure [1] to send out bug reports and other automatic
notifications, as well as a point-of-contact for developers and users to
contact you about the package.

However, I see that my previous message (written in September) wasn't
delivered to the mailing list [2]. I also notice that Debian bug reports for
Jitsi, e.g. [3] haven't been delivered to the mailing list [4], but some
other Debian notices have [5].

E-Mail addresses that aren't subscribed to the list are being moderated. This is obviously bad for automated mails from the bugtracker. The ones that got through were probably manually allowed, just like this message. I'll see if I can somehow whitelist *.debian.org once I get access to mailman.

Are your moderators selectively dropping messages? If so, please consider
using a different email address for your Maintainers: field in
debian/control, that accepts all relevant messages. It's not responsible to
ignore questions from your users.

Using any other address for that field will bring even less attention to mails going there :frowning:

X

Ingo

···

[1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
[2] http://lists.jitsi.org/pipermail/dev/2015-September/thread.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038
[4] http://lists.jitsi.org/pipermail/dev/2015-June/thread.html
[5] http://lists.jitsi.org/pipermail/dev/2015-June/024411.html

On 18/09/15 00:45, Ximin Luo wrote:

Hi Jitsi Team,

Some of us at the Tor Project are exploring options for voice conferences.

We heard some nice things about Jitsi, but noticed that it's not quite yet in
Debian:

https://packages.debian.org/sid/jitsi

The issue appears to be that libjitsi, a dependency of jitsi, has been
rejected from Debian a few times:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038

When the Debian FTP masters rejected your package, they would have sent you

an email on why. Could you enlighten us on the reason? A few of us (at Tor,
that is) are also Debian Developers, so could help you with these issues, as
well as sponsor your next upload.

Could you also publish the Debian packaging in a git repository somewhere?

You can then add Vcs-Browser: and Vcs-Git: fields to debian/control, for
others to find and contribute.

Thanks!

Ximin


#4

Hi,

all the packaging is under
https://github.com/jitsi/jitsi/tree/master/resources/install/debian
We are using ant to generate the source package which can be used to
build jitsi latter for debian, cause the project has many jar and
binary dependencies and cannot be used as is, we embed some of the
sources inside the src package and modify some bundles that can make
use of the debian already installed dependencies, rather the bundled
jars. We also generate to types of debian package, one is the source
which I mention and the other one we call binary, we just use the jars
and natives that are currently committed to the repo to build a
package which our users use directly from our repo.

We have put a lot of effort in the debian packaging for some time, but
at least twice we had the packages deleted from mentors site, due to
no activity and no interest.
Maybe the work will got easier when some of the packages we used to
embed are pushed to debian or maven.
If you need some assistance for the current state and kicking out I
can help, just drop me a note.

Regards
damencho

···

On Tue, Oct 13, 2015 at 6:47 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Any update on my previous email? The offer to help with packaging still
stands.

I don't remember any previous mail, so that might have gotten lost somewhere. As you might know (or maybe not) Bluejimp got acquired by Atlassian and the main focus now lies on Jitsi Meet. So any help with packaging would be appreciated. This mostly would be with dependent packages though. AFAIK the reason why libjitsi is/was blocked is the license for the javax.sdp/javax.sip API files. DD Daniel Pocock reimplemented them cleanly and we need to start using them and then they need to be packaged and uploaded to Debian too.

I am emailing this address dev@jitsi.org because this is listed as the
Maintainer: for the current jitsi package, in debian/control. This address is
used by Debian infrastructure [1] to send out bug reports and other automatic
notifications, as well as a point-of-contact for developers and users to
contact you about the package.

However, I see that my previous message (written in September) wasn't
delivered to the mailing list [2]. I also notice that Debian bug reports for
Jitsi, e.g. [3] haven't been delivered to the mailing list [4], but some
other Debian notices have [5].

E-Mail addresses that aren't subscribed to the list are being moderated. This is obviously bad for automated mails from the bugtracker. The ones that got through were probably manually allowed, just like this message. I'll see if I can somehow whitelist *.debian.org once I get access to mailman.

Are your moderators selectively dropping messages? If so, please consider
using a different email address for your Maintainers: field in
debian/control, that accepts all relevant messages. It's not responsible to
ignore questions from your users.

Using any other address for that field will bring even less attention to mails going there :frowning:

X

Ingo

[1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
[2] http://lists.jitsi.org/pipermail/dev/2015-September/thread.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038
[4] http://lists.jitsi.org/pipermail/dev/2015-June/thread.html
[5] http://lists.jitsi.org/pipermail/dev/2015-June/024411.html

On 18/09/15 00:45, Ximin Luo wrote:

Hi Jitsi Team,

Some of us at the Tor Project are exploring options for voice conferences.

We heard some nice things about Jitsi, but noticed that it's not quite yet in
Debian:

https://packages.debian.org/sid/jitsi

The issue appears to be that libjitsi, a dependency of jitsi, has been
rejected from Debian a few times:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038

When the Debian FTP masters rejected your package, they would have sent you

an email on why. Could you enlighten us on the reason? A few of us (at Tor,
that is) are also Debian Developers, so could help you with these issues, as
well as sponsor your next upload.

Could you also publish the Debian packaging in a git repository somewhere?

You can then add Vcs-Browser: and Vcs-Git: fields to debian/control, for
others to find and contribute.

Thanks!

Ximin

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


#5

+debian-mentors for more comments/help

Hi, thanks a lot for the information and pointers! The documentation on why you're bundling various source packages is very useful. I see you also have a similar setup in https://github.com/jitsi/libjitsi/tree/master/resources/install/debian

I've played around with the build processes and have some comments:

1. You're only building a .orig.tar.gz, but Debian source packages require a .dsc (source package description file) and a .debian.tar.gz (debian packaging contents). After you create a full debian source package that includes all three files, you can then get rid of all of the "debian binary package" stuff from your build.xml scripts, and use the proper debian developer tools instead (e.g. dpkg-buildpackage, etc.

2. In both libjitsi and jitsi: you build up a tmp directory that contains all the sources for a debian package, out of which you build a .orig.tar.gz, but then clean (delete) the whole directory, without trying to create .dsc or .debian.tar.gz from the other files.

3. After applying the patches from [1] below, and running "ant deb-src -Dlabel=XXXX"[*], then moving the .orig.tar.gz to the same directory as the temporary jitsi/libjitsi source tree, I can run `debuild -S` inside the temporary source tree. This is the *correct way* to make Debian packages. However, the process fails, for both libjitsi and jitsi. See [2] and [3].

The TL;DR is that it looks like your debian/patches/ are out-of-date, and I'm not familiar enough with the code base, to spend the time right now to debug it.

So I wonder, who has been generating the .dsc/.debian.tar.gz files that you've been submitting to Debian FTP? I have been unable to create one myself from your git repos.

In fact, it is better to keep the debian packaging files (i.e. debian/*) in a separate repo, in the top-level directory of the repo. Then, one can generate .orig.tar.gz from the main jitsi/libjitsi repos every release, then import them to the Debian packaging repos. This is a very standard pattern for Debian packaging, supporting by the git-buildpackage tool, see for example [4] where it says "Imported Upstream version" etc. This would be cleaner and cheaper than effectively re-implementing (and maintaining) the Debian toolchain in build.xml.

AFAIK the reason why libjitsi is/was blocked is the license for the javax.sdp/javax.sip API files

Do you have some more details on that?

X

[4] https://anonscm.debian.org/cgit/pkg-privacy/packages/flashproxy.git/log/

···

========================
1. Patches for build.xml

Patches are on top of respective HEAD commits at 2015-10-17

jisti: only clean artefacts in "clean" targets to allow post-build inspection

diff --git a/resources/install/build.xml b/resources/install/build.xml
index 3922296..0eadfaf 100644
--- a/resources/install/build.xml
+++ b/resources/install/build.xml
@@ -2501,7 +2501,7 @@

     <!-- clean for deb-src -->
     <target name="clean-deb-src">
- <delete dir="${debian.tmp.dir}/${package.name}-${sip-communicator.version}" />
+ <delete dir="${debian.tmp.dir}"/>
     </target>

     <!-- copies jitsi source to ${target.dir},
@@ -2573,7 +2573,7 @@
             - libjitsi
      -->
     <target name="deb-src"
- depends="init,version,load-properties,clean-deb-src,dpkg-build-warning"
+ depends="init,version,load-properties,dpkg-build-warning"
             if="dpkg.build.present"
             description="Create a .deb package for Debian (needs dpkg utilities)">

@@ -2708,7 +2708,6 @@
         <tar destfile="${debian.dir}/${package.name}_${sip-communicator.version}.orig.tar.gz"
              compression="gzip"
              basedir="${debian.tmp.dir}"/>
- <delete dir="${debian.tmp.dir}"/>
     </target>

     <!-- clean for debuild -->

libjisti: only clean artefacts in "clean" targets to allow post-build inspection

diff --git a/resources/install/build-debian.xml b/resources/install/build-debian.xml
index 8c1a020..f0dc711 100644
--- a/resources/install/build-debian.xml
+++ b/resources/install/build-debian.xml
@@ -11,9 +11,6 @@
         <tar destfile="${dist}/libjitsi_${build.label}.orig.tar.gz"
              compression="gzip"
              basedir="${tmp}"/>
- <delete failonerror="false" includeemptydirs="true">
- <fileset dir="${tmp}"/>
- </delete>
     </target>

     <target name="deb-copy-libjitsi">
@@ -187,7 +184,9 @@
     </target>

     <target name="clean-debuild">
-
+ <delete failonerror="false" includeemptydirs="true">
+ <fileset dir="${tmp}"/>
+ </delete>
         <delete failonerror="false">
             <fileset dir="lib">
                 <include name="*.jar"/>

=========================
2. debuild -S on libjitsi

# after patching and running `ant deb-src -Dlabel=9999`, and moving the built .orig.tar.gz to the correct location listed below
# I don't know what label to use here

libjitsi.git/tmp/libjitsi$ ls -1 ..
libjitsi/
libjitsi_9999.orig.tar.gz

libjitsi.git/tmp/libjitsi$ debuild -S
dpkg-buildpackage -rfakeroot -d -us -uc -S
dpkg-buildpackage: source package libjitsi
dpkg-buildpackage: source version 9999
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Damian Minkov <damencho@jitsi.org>
dpkg-source --before-build libjitsi
dpkg-source: info: applying bouncycastle-1.49.patch
dpkg-source: info: applying bouncycastle-1.51.patch
dpkg-source: info: applying remove-hflip
can't find file to patch at input line 6
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------

Description: Removes hflip, filters internal api availbale in ffmpeg but not in libav
Index: libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.c

--- libjitsi.orig/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.c
+++ libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.c

--------------------------
No file to patch. Skipping patch.
8 out of 8 hunks ignored
can't find file to patch at input line 111
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------

Index: libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.h

--- libjitsi.orig/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.h
+++ libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.h

--------------------------
No file to patch. Skipping patch.
7 out of 7 hunks ignored
patching file src/org/jitsi/impl/neomedia/MediaServiceImpl.java
Hunk #1 succeeded at 1156 (offset 33 lines).
patching file src/org/jitsi/impl/neomedia/device/VideoMediaDeviceSession.java
Hunk #1 succeeded at 523 (offset 10 lines).
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'remove-hflip' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-source: info: restoring quilt backup files for remove-hflip
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/remove-hflip/ --reject-file=- < libjitsi/debian/patches/remove-hflip gave error exit status 1
dpkg-buildpackage: error: dpkg-source --before-build libjitsi gave error exit status 2
debuild: fatal error at line 1374:
dpkg-buildpackage -rfakeroot -d -us -uc -S failed
29

======================
3. debuild -S on jitsi

# after patching and running `ant deb-src -Dlabel=5478`, and moving the built .orig.tar.gz to the location listed below
# The label is the latest one here: http://bluejimp.com/jitsi/changelogs/ and `ant deb-src` downloads the relevant file from here

jitsi.git/release/debian/tmp/jitsi-2.9.5478$ ls -1 ..
jitsi-2.9.5478/
jitsi_2.9.5478-1_source.build
jitsi_2.9.5478.orig.tar.gz

jitsi.git/release/debian/tmp/jitsi-2.9.5478$ debuild -S
dpkg-buildpackage -rfakeroot -d -us -uc -S
dpkg-buildpackage: source package jitsi
dpkg-buildpackage: source version 2.9.5478-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Damian Minkov <damencho@jitsi.org>
dpkg-source --before-build jitsi-2.9.5478
dpkg-source: info: applying bcprov-upgrade-1.48
dpkg-source: info: applying removes-gdata-deps
dpkg-source: info: applying encoding.patch
dpkg-source: info: applying bouncycastle-1.51.patch
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/bouncycastle-1.51.patch/ --reject-file=- < jitsi-2.9.5478/debian/patches/bouncycastle-1.51.patch gave error exit status 1
can't find file to patch at input line 6
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------

Description: Removes import that is only available in bouncycastle 1.51.
Index: jitsi/src/net/java/sip/communicator/impl/libjitsi/libjitsi.manifest.mf

--- jitsi.orig/src/net/java/sip/communicator/impl/libjitsi/libjitsi.manifest.mf
+++ jitsi/src/net/java/sip/communicator/impl/libjitsi/libjitsi.manifest.mf

--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'bouncycastle-1.51.patch' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-buildpackage: error: dpkg-source --before-build jitsi-2.9.5478 gave error exit status 2
debuild: fatal error at line 1374:
dpkg-buildpackage -rfakeroot -d -us -uc -S failed
29

On 13/10/15 17:09, Damian Minkov wrote:

Hi,

all the packaging is under
https://github.com/jitsi/jitsi/tree/master/resources/install/debian
We are using ant to generate the source package which can be used to
build jitsi latter for debian, cause the project has many jar and
binary dependencies and cannot be used as is, we embed some of the
sources inside the src package and modify some bundles that can make
use of the debian already installed dependencies, rather the bundled
jars. We also generate to types of debian package, one is the source
which I mention and the other one we call binary, we just use the jars
and natives that are currently committed to the repo to build a
package which our users use directly from our repo.

We have put a lot of effort in the debian packaging for some time, but
at least twice we had the packages deleted from mentors site, due to
no activity and no interest.
Maybe the work will got easier when some of the packages we used to
embed are pushed to debian or maven.
If you need some assistance for the current state and kicking out I
can help, just drop me a note.

Regards
damencho

On Tue, Oct 13, 2015 at 6:47 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Any update on my previous email? The offer to help with packaging still
stands.

I don't remember any previous mail, so that might have gotten lost somewhere. As you might know (or maybe not) Bluejimp got acquired by Atlassian and the main focus now lies on Jitsi Meet. So any help with packaging would be appreciated. This mostly would be with dependent packages though. AFAIK the reason why libjitsi is/was blocked is the license for the javax.sdp/javax.sip API files. DD Daniel Pocock reimplemented them cleanly and we need to start using them and then they need to be packaged and uploaded to Debian too.

I am emailing this address dev@jitsi.org because this is listed as the
Maintainer: for the current jitsi package, in debian/control. This address is
used by Debian infrastructure [1] to send out bug reports and other automatic
notifications, as well as a point-of-contact for developers and users to
contact you about the package.

However, I see that my previous message (written in September) wasn't
delivered to the mailing list [2]. I also notice that Debian bug reports for
Jitsi, e.g. [3] haven't been delivered to the mailing list [4], but some
other Debian notices have [5].

E-Mail addresses that aren't subscribed to the list are being moderated. This is obviously bad for automated mails from the bugtracker. The ones that got through were probably manually allowed, just like this message. I'll see if I can somehow whitelist *.debian.org once I get access to mailman.

Are your moderators selectively dropping messages? If so, please consider
using a different email address for your Maintainers: field in
debian/control, that accepts all relevant messages. It's not responsible to
ignore questions from your users.

Using any other address for that field will bring even less attention to mails going there :frowning:

X

Ingo

[1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
[2] http://lists.jitsi.org/pipermail/dev/2015-September/thread.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038
[4] http://lists.jitsi.org/pipermail/dev/2015-June/thread.html
[5] http://lists.jitsi.org/pipermail/dev/2015-June/024411.html

On 18/09/15 00:45, Ximin Luo wrote:

Hi Jitsi Team,

Some of us at the Tor Project are exploring options for voice conferences.

We heard some nice things about Jitsi, but noticed that it's not quite yet in
Debian:

https://packages.debian.org/sid/jitsi

The issue appears to be that libjitsi, a dependency of jitsi, has been
rejected from Debian a few times:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038

When the Debian FTP masters rejected your package, they would have sent you

an email on why. Could you enlighten us on the reason? A few of us (at Tor,
that is) are also Debian Developers, so could help you with these issues, as
well as sponsor your next upload.

Could you also publish the Debian packaging in a git repository somewhere?

You can then add Vcs-Browser: and Vcs-Git: fields to debian/control, for
others to find and contribute.

Thanks!

Ximin

--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git


#6

Hi,

thank you for your time.

+debian-mentors for more comments/help

Hi, thanks a lot for the information and pointers! The documentation on why you're bundling various source packages is very useful. I see you also have a similar setup in https://github.com/jitsi/libjitsi/tree/master/resources/install/debian

I've played around with the build processes and have some comments:

1. You're only building a .orig.tar.gz, but Debian source packages require a .dsc (source package description file) and a .debian.tar.gz (debian packaging contents). After you create a full debian source package that includes all three files, you can then get rid of all of the "debian binary package" stuff from your build.xml scripts, and use the proper debian developer tools instead (e.g. dpkg-buildpackage, etc.

We used to create the source package and from it then create the
needed packages to upload the file to mentors (.dsc debian.tar.gz, a
debian binary and the src package itself), you mean to do this in one
step, we can definitely do that.

2. In both libjitsi and jitsi: you build up a tmp directory that contains all the sources for a debian package, out of which you build a .orig.tar.gz, but then clean (delete) the whole directory, without trying to create .dsc or .debian.tar.gz from the other files.

The same as above, create needed files on the first step?

3. After applying the patches from [1] below, and running "ant deb-src -Dlabel=XXXX"[*], then moving the .orig.tar.gz to the same directory as the temporary jitsi/libjitsi source tree, I can run `debuild -S` inside the temporary source tree. This is the *correct way* to make Debian packages. However, the process fails, for both libjitsi and jitsi. See [2] and [3].

The TL;DR is that it looks like your debian/patches/ are out-of-date, and I'm not familiar enough with the code base, to spend the time right now to debug it.

Will try that. There were a lot of modifications lately and the debian
src packaging needs some love, time we didn't have to continue
investing, as last two attempts ended with no results.

So I wonder, who has been generating the .dsc/.debian.tar.gz files that you've been submitting to Debian FTP? I have been unable to create one myself from your git repos.

I was the one doing it, if you checkout a version near the stable
release you will be able to do so, but latest version needs updating.

In fact, it is better to keep the debian packaging files (i.e. debian/*) in a separate repo, in the top-level directory of the repo. Then, one can generate .orig.tar.gz from the main jitsi/libjitsi repos every release, then import them to the Debian packaging repos. This is a very standard pattern for Debian packaging, supporting by the git-buildpackage tool, see for example [4] where it says "Imported Upstream version" etc. This would be cleaner and cheaper than effectively re-implementing (and maintaining) the Debian toolchain in build.xml.

I'm not sure that we can handle all of the custom stuff just with the
debian build tools, or at least it will be a great effort to do so and
currently I'm not familiar with anyone that can affords this. We were
using ant to do all that stuff, by reusing all the tasks we already
had.
I'm talking for all the tasks in
https://github.com/jitsi/jitsi/blob/master/resources/install/build.xml
from line 2000 to the end (4000+) that do the debian stuff.
Maybe mavenizing the whole project can help cleaning things and make
the debian package easier, but I'm not familiar so much with maven
currently and especially with maven + debian.
I think investing time in this direction if its worth it is better,
this way we can rid of most of the patches and custom work that needs
to be done.
We were also discussing internally about a branch with the debian stuff in it.

AFAIK the reason why libjitsi is/was blocked is the license for the javax.sdp/javax.sip API files

Do you have some more details on that?

Personally I don't know. But Ingo Bauersachs and Daniel Pocock have
some progress regarding ice4j and using a package which license is ok,
but need to further check it with them. Libjitis was not updated and
the problem API license hasn't changed.

I will try checking your comments when time permits and comment on them.

Regards
damencho

···

On Sat, Oct 17, 2015 at 6:48 AM, Ximin Luo <infinity0@debian.org> wrote:

X

[4] https://anonscm.debian.org/cgit/pkg-privacy/packages/flashproxy.git/log/

========================
1. Patches for build.xml

Patches are on top of respective HEAD commits at 2015-10-17

jisti: only clean artefacts in "clean" targets to allow post-build inspection

diff --git a/resources/install/build.xml b/resources/install/build.xml
index 3922296..0eadfaf 100644
--- a/resources/install/build.xml
+++ b/resources/install/build.xml
@@ -2501,7 +2501,7 @@

     <!-- clean for deb-src -->
     <target name="clean-deb-src">
- <delete dir="${debian.tmp.dir}/${package.name}-${sip-communicator.version}" />
+ <delete dir="${debian.tmp.dir}"/>
     </target>

     <!-- copies jitsi source to ${target.dir},
@@ -2573,7 +2573,7 @@
             - libjitsi
      -->
     <target name="deb-src"
- depends="init,version,load-properties,clean-deb-src,dpkg-build-warning"
+ depends="init,version,load-properties,dpkg-build-warning"
             if="dpkg.build.present"
             description="Create a .deb package for Debian (needs dpkg utilities)">

@@ -2708,7 +2708,6 @@
         <tar destfile="${debian.dir}/${package.name}_${sip-communicator.version}.orig.tar.gz"
              compression="gzip"
              basedir="${debian.tmp.dir}"/>
- <delete dir="${debian.tmp.dir}"/>
     </target>

     <!-- clean for debuild -->

libjisti: only clean artefacts in "clean" targets to allow post-build inspection

diff --git a/resources/install/build-debian.xml b/resources/install/build-debian.xml
index 8c1a020..f0dc711 100644
--- a/resources/install/build-debian.xml
+++ b/resources/install/build-debian.xml
@@ -11,9 +11,6 @@
         <tar destfile="${dist}/libjitsi_${build.label}.orig.tar.gz"
              compression="gzip"
              basedir="${tmp}"/>
- <delete failonerror="false" includeemptydirs="true">
- <fileset dir="${tmp}"/>
- </delete>
     </target>

     <target name="deb-copy-libjitsi">
@@ -187,7 +184,9 @@
     </target>

     <target name="clean-debuild">
-
+ <delete failonerror="false" includeemptydirs="true">
+ <fileset dir="${tmp}"/>
+ </delete>
         <delete failonerror="false">
             <fileset dir="lib">
                 <include name="*.jar"/>

=========================
2. debuild -S on libjitsi

# after patching and running `ant deb-src -Dlabel=9999`, and moving the built .orig.tar.gz to the correct location listed below
# I don't know what label to use here

libjitsi.git/tmp/libjitsi$ ls -1 ..
libjitsi/
libjitsi_9999.orig.tar.gz

libjitsi.git/tmp/libjitsi$ debuild -S
dpkg-buildpackage -rfakeroot -d -us -uc -S
dpkg-buildpackage: source package libjitsi
dpkg-buildpackage: source version 9999
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Damian Minkov <damencho@jitsi.org>
dpkg-source --before-build libjitsi
dpkg-source: info: applying bouncycastle-1.49.patch
dpkg-source: info: applying bouncycastle-1.51.patch
dpkg-source: info: applying remove-hflip
can't find file to patch at input line 6
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
>Description: Removes hflip, filters internal api availbale in ffmpeg but not in libav
>Index: libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.c
>===================================================================
>--- libjitsi.orig/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.c
>+++ libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.c
--------------------------
No file to patch. Skipping patch.
8 out of 8 hunks ignored
can't find file to patch at input line 111
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
>Index: libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.h
>===================================================================
>--- libjitsi.orig/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.h
>+++ libjitsi/lib/src/jitsi-lgpl-dependencies/src/native/ffmpeg/org_jitsi_impl_neomedia_codec_FFmpeg.h
--------------------------
No file to patch. Skipping patch.
7 out of 7 hunks ignored
patching file src/org/jitsi/impl/neomedia/MediaServiceImpl.java
Hunk #1 succeeded at 1156 (offset 33 lines).
patching file src/org/jitsi/impl/neomedia/device/VideoMediaDeviceSession.java
Hunk #1 succeeded at 523 (offset 10 lines).
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'remove-hflip' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-source: info: restoring quilt backup files for remove-hflip
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/remove-hflip/ --reject-file=- < libjitsi/debian/patches/remove-hflip gave error exit status 1
dpkg-buildpackage: error: dpkg-source --before-build libjitsi gave error exit status 2
debuild: fatal error at line 1374:
dpkg-buildpackage -rfakeroot -d -us -uc -S failed
29

======================
3. debuild -S on jitsi

# after patching and running `ant deb-src -Dlabel=5478`, and moving the built .orig.tar.gz to the location listed below
# The label is the latest one here: http://bluejimp.com/jitsi/changelogs/ and `ant deb-src` downloads the relevant file from here

jitsi.git/release/debian/tmp/jitsi-2.9.5478$ ls -1 ..
jitsi-2.9.5478/
jitsi_2.9.5478-1_source.build
jitsi_2.9.5478.orig.tar.gz

jitsi.git/release/debian/tmp/jitsi-2.9.5478$ debuild -S
dpkg-buildpackage -rfakeroot -d -us -uc -S
dpkg-buildpackage: source package jitsi
dpkg-buildpackage: source version 2.9.5478-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Damian Minkov <damencho@jitsi.org>
dpkg-source --before-build jitsi-2.9.5478
dpkg-source: info: applying bcprov-upgrade-1.48
dpkg-source: info: applying removes-gdata-deps
dpkg-source: info: applying encoding.patch
dpkg-source: info: applying bouncycastle-1.51.patch
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/bouncycastle-1.51.patch/ --reject-file=- < jitsi-2.9.5478/debian/patches/bouncycastle-1.51.patch gave error exit status 1
can't find file to patch at input line 6
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
>Description: Removes import that is only available in bouncycastle 1.51.
>Index: jitsi/src/net/java/sip/communicator/impl/libjitsi/libjitsi.manifest.mf
>===================================================================
>--- jitsi.orig/src/net/java/sip/communicator/impl/libjitsi/libjitsi.manifest.mf
>+++ jitsi/src/net/java/sip/communicator/impl/libjitsi/libjitsi.manifest.mf
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'bouncycastle-1.51.patch' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-buildpackage: error: dpkg-source --before-build jitsi-2.9.5478 gave error exit status 2
debuild: fatal error at line 1374:
dpkg-buildpackage -rfakeroot -d -us -uc -S failed
29

On 13/10/15 17:09, Damian Minkov wrote:

Hi,

all the packaging is under
https://github.com/jitsi/jitsi/tree/master/resources/install/debian
We are using ant to generate the source package which can be used to
build jitsi latter for debian, cause the project has many jar and
binary dependencies and cannot be used as is, we embed some of the
sources inside the src package and modify some bundles that can make
use of the debian already installed dependencies, rather the bundled
jars. We also generate to types of debian package, one is the source
which I mention and the other one we call binary, we just use the jars
and natives that are currently committed to the repo to build a
package which our users use directly from our repo.

We have put a lot of effort in the debian packaging for some time, but
at least twice we had the packages deleted from mentors site, due to
no activity and no interest.
Maybe the work will got easier when some of the packages we used to
embed are pushed to debian or maven.
If you need some assistance for the current state and kicking out I
can help, just drop me a note.

Regards
damencho

On Tue, Oct 13, 2015 at 6:47 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Any update on my previous email? The offer to help with packaging still
stands.

I don't remember any previous mail, so that might have gotten lost somewhere. As you might know (or maybe not) Bluejimp got acquired by Atlassian and the main focus now lies on Jitsi Meet. So any help with packaging would be appreciated. This mostly would be with dependent packages though. AFAIK the reason why libjitsi is/was blocked is the license for the javax.sdp/javax.sip API files. DD Daniel Pocock reimplemented them cleanly and we need to start using them and then they need to be packaged and uploaded to Debian too.

I am emailing this address dev@jitsi.org because this is listed as the
Maintainer: for the current jitsi package, in debian/control. This address is
used by Debian infrastructure [1] to send out bug reports and other automatic
notifications, as well as a point-of-contact for developers and users to
contact you about the package.

However, I see that my previous message (written in September) wasn't
delivered to the mailing list [2]. I also notice that Debian bug reports for
Jitsi, e.g. [3] haven't been delivered to the mailing list [4], but some
other Debian notices have [5].

E-Mail addresses that aren't subscribed to the list are being moderated. This is obviously bad for automated mails from the bugtracker. The ones that got through were probably manually allowed, just like this message. I'll see if I can somehow whitelist *.debian.org once I get access to mailman.

Are your moderators selectively dropping messages? If so, please consider
using a different email address for your Maintainers: field in
debian/control, that accepts all relevant messages. It's not responsible to
ignore questions from your users.

Using any other address for that field will bring even less attention to mails going there :frowning:

X

Ingo

[1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
[2] http://lists.jitsi.org/pipermail/dev/2015-September/thread.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038
[4] http://lists.jitsi.org/pipermail/dev/2015-June/thread.html
[5] http://lists.jitsi.org/pipermail/dev/2015-June/024411.html

On 18/09/15 00:45, Ximin Luo wrote:

Hi Jitsi Team,

Some of us at the Tor Project are exploring options for voice conferences.

We heard some nice things about Jitsi, but noticed that it's not quite yet in
Debian:

https://packages.debian.org/sid/jitsi

The issue appears to be that libjitsi, a dependency of jitsi, has been
rejected from Debian a few times:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789038

When the Debian FTP masters rejected your package, they would have sent you

an email on why. Could you enlighten us on the reason? A few of us (at Tor,
that is) are also Debian Developers, so could help you with these issues, as
well as sponsor your next upload.

Could you also publish the Debian packaging in a git repository somewhere?

You can then add Vcs-Browser: and Vcs-Git: fields to debian/control, for
others to find and contribute.

Thanks!

Ximin

--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git


#7

Well, Damian....

I was one of the reviewers (together with Diane) at that time but I had
the impression that out of the review no actions have followed from
your side; at least I could not find any reference in my mailbox.

One suggestion was to file a RFS bug to keep easier track of the
progress while tackling one issue after the other. The RFS bug workflow
has been established as quasi standard for sponsorship, so without RFS
its not so likely that someone will pick up.

(Also, you need tackle the embedded code libraries. At least show some
progress! And to avoid getting you on the wrong path, as you mentioned
maven on jitsi-dev -- you cannot download dependencies at build time.)

Maybe do that as the first step, then bounce the mail exchanges we had
so far to the bug. (There were in private conversation, so you need to
ask the involved people before; my mails are ok)

Maybe you could ask the java-packaging team if they are interested in
the package? You could join them and maybe someone also will help you
on packaging.

To find a sponsor, you need to bring the package in shape first;
frankly, your changes to find a sponsor are very low if the package is
in a bad shape.
I understand thats lots of work, but it needs to be done; of course
Rome isn't built in a day, but so it might be also okish "iterate" to
it (depending on the sponsor); Howerver this won't work without some
commitment from your side -- to get the best packaging quality and a
Policy compliant package. Also to maintain this quality in the future.

Tobi

···

Am Samstag, den 17.10.2015, 16:40 -0500 schrieb Damian Minkov:

Will try that. There were a lot of modifications lately and the
debian
src packaging needs some love, time we didn't have to continue
investing, as last two attempts ended with no results.


#8

Hi,

Will try that. There were a lot of modifications lately and the
debian
src packaging needs some love, time we didn't have to continue
investing, as last two attempts ended with no results.

Well, Damian....

I was one of the reviewers (together with Diane) at that time but I had
the impression that out of the review no actions have followed from
your side; at least I could not find any reference in my mailbox.

One suggestion was to file a RFS bug to keep easier track of the
progress while tackling one issue after the other. The RFS bug workflow
has been established as quasi standard for sponsorship, so without RFS
its not so likely that someone will pick up.

There was no RFS, and no progress after your review, cause we need to
find time and power to do all the updates. The 'no progress' mentioned
was on two times before your mails.

(Also, you need tackle the embedded code libraries. At least show some
progress! And to avoid getting you on the wrong path, as you mentioned
maven on jitsi-dev -- you cannot download dependencies at build time.)

If you mean to get the dependencies out of jitsi, I havn't seen any
interest of that from anybody so not sure it is worth the effort at
this point.
I'm aware of the downloading while building problem, but you mean
there is no way to reuse maven stuff while packaging, as the list of
dependencies is maybe 30-40 libraries?

Maybe do that as the first step, then bounce the mail exchanges we had
so far to the bug. (There were in private conversation, so you need to
ask the involved people before; my mails are ok)

Maybe you could ask the java-packaging team if they are interested in
the package? You could join them and maybe someone also will help you
on packaging.

To find a sponsor, you need to bring the package in shape first;
frankly, your changes to find a sponsor are very low if the package is
in a bad shape.
I understand thats lots of work, but it needs to be done; of course
Rome isn't built in a day, but so it might be also okish "iterate" to
it (depending on the sponsor); Howerver this won't work without some
commitment from your side -- to get the best packaging quality and a
Policy compliant package. Also to maintain this quality in the future.

The problem is that the packaging of such complex project, cannot keep
up with the rapid development that happens which at some point is a
big problem.

Regards
damencho

···

On Sun, Oct 18, 2015 at 12:49 PM, Tobias Frost <tobi@debian.org> wrote:

Am Samstag, den 17.10.2015, 16:40 -0500 schrieb Damian Minkov:

Tobi


#9

+++ Damian Minkov [2015-10-18 14:17 -0500]:

> (Also, you need tackle the embedded code libraries. At least show some
> progress! And to avoid getting you on the wrong path, as you mentioned
> maven on jitsi-dev -- you cannot download dependencies at build time.)

If you mean to get the dependencies out of jitsi, I havn't seen any
interest of that from anybody so not sure it is worth the effort at
this point.

Debian is very keen on packing each project as a separate package
(because it is right), not all bundled into one source, or even worse
repeatedly bundled into lots of sources. So Debian is interested, (as
are all its derivatives), and we'll do our best to help with
that. This is much easier if upstream is on-board with that, otherwise
there can be significant build-system patch maintenance. Are they? (It
can be acceptable to leave embedded copies if they are only used by
one project, but in general it's bad (for bloat and security reasons).

I'm aware of the downloading while building problem, but you mean
there is no way to reuse maven stuff while packaging, as the list of
dependencies is maybe 30-40 libraries?

Maven and Debian policy go together very badly. If the project doesn't
already use maven then _please_ don't change to it. It's terrible for
security and reproducibility. Nothing about getting the project
packaged would be helped by such a change - in fact it would be a
major hindrance.

The problem is that the packaging of such complex project, cannot keep
up with the rapid development that happens which at some point is a
big problem.

Lots of complex projects manage to get maintained in Debian. So it can
be done. It is much easier if they use sensible build systems and
upstream is interested in helping. I am interested in seeing jitsi
properly maintained in debian so may be able to help a bit (although I
can't promise much as I currently have a pile of other pending Debian
work).

This thread should really be copied to the ITP, so people can at least see
what is going on. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757768

Wookey

···

--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/


#10

Hi,

+++ Damian Minkov [2015-10-18 14:17 -0500]:

> (Also, you need tackle the embedded code libraries. At least show some
> progress! And to avoid getting you on the wrong path, as you mentioned
> maven on jitsi-dev -- you cannot download dependencies at build time.)

If you mean to get the dependencies out of jitsi, I havn't seen any
interest of that from anybody so not sure it is worth the effort at
this point.

Debian is very keen on packing each project as a separate package
(because it is right), not all bundled into one source, or even worse
repeatedly bundled into lots of sources. So Debian is interested, (as
are all its derivatives), and we'll do our best to help with
that. This is much easier if upstream is on-board with that, otherwise
there can be significant build-system patch maintenance. Are they? (It
can be acceptable to leave embedded copies if they are only used by
one project, but in general it's bad (for bloat and security reasons).

If there is interest in any of the packages we will do it. But we
haven't seen it till now and those packages are used only by us. Will
check about splitting the current work in new packages, so we can also
split and the effort.

I'm aware of the downloading while building problem, but you mean
there is no way to reuse maven stuff while packaging, as the list of
dependencies is maybe 30-40 libraries?

Maven and Debian policy go together very badly. If the project doesn't
already use maven then _please_ don't change to it. It's terrible for
security and reproducibility. Nothing about getting the project
packaged would be helped by such a change - in fact it would be a
major hindrance.

We already done that, adding maven to most of our projects. This makes
the developer life easier, especially when working with several
packages that depend on each other.

The problem is that the packaging of such complex project, cannot keep
up with the rapid development that happens which at some point is a
big problem.

Lots of complex projects manage to get maintained in Debian. So it can
be done. It is much easier if they use sensible build systems and
upstream is interested in helping. I am interested in seeing jitsi
properly maintained in debian so may be able to help a bit (although I
can't promise much as I currently have a pile of other pending Debian
work).

Thanks for the encouraging of you all, I will try to start the initial
effort these days and I hope to come up with a working solution the
following weeks.

Regards
damencho

···

On Sun, Oct 18, 2015 at 3:38 PM, Wookey <wookey@wookware.org> wrote:

This thread should really be copied to the ITP, so people can at least see
what is going on. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757768

Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/


#11

+++ Damian Minkov [2015-10-18 14:17 -0500]:

[...]

I'm aware of the downloading while building problem, but you mean
there is no way to reuse maven stuff while packaging, as the list of
dependencies is maybe 30-40 libraries?

Maven and Debian policy go together very badly. If the project doesn't
already use maven then _please_ don't change to it. It's terrible for
security and reproducibility. Nothing about getting the project
packaged would be helped by such a change - in fact it would be a
major hindrance.

Hi,

just wanted to chime in here as a member of the Debian Java team.
Actually nowadays Maven and Debian go perfectly well together as we
prevent Maven from downloading anything during the build process. Of
course this requires that all your artifacts must be packaged for Debian
already. Then Maven will just find them in /usr/share/maven-repo.

So it doesn't really matter if you prefer Ant or Maven as build system.
Both are equally well supported. What matters is that the build system
is supported upstream and all necessary dependencies are packaged for
Debian.

Please feel free to ask Java specific questions on debian-java or to
join the team. We gladly help you to solve those packaging questions.

Regards,

Markus

···

Am 18.10.2015 um 22:38 schrieb Wookey:


#12

Before trying desktop Jitsi again, we should focus on a few smaller projects that are dependencies of libjitsi. I.e. ice4j, sdes4j, bccontrib, zrtp4j. These are all small and we can count on the help of Daniel. And then do libjitsi.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 18.10.2015 à 23:33, Damian Minkov <damencho@jitsi.org> a écrit :

Hi,

On Sun, Oct 18, 2015 at 3:38 PM, Wookey <wookey@wookware.org> wrote:
+++ Damian Minkov [2015-10-18 14:17 -0500]:

(Also, you need tackle the embedded code libraries. At least show some
progress! And to avoid getting you on the wrong path, as you mentioned
maven on jitsi-dev -- you cannot download dependencies at build time.)

If you mean to get the dependencies out of jitsi, I havn't seen any
interest of that from anybody so not sure it is worth the effort at
this point.

Debian is very keen on packing each project as a separate package
(because it is right), not all bundled into one source, or even worse
repeatedly bundled into lots of sources. So Debian is interested, (as
are all its derivatives), and we'll do our best to help with
that. This is much easier if upstream is on-board with that, otherwise
there can be significant build-system patch maintenance. Are they? (It
can be acceptable to leave embedded copies if they are only used by
one project, but in general it's bad (for bloat and security reasons).

If there is interest in any of the packages we will do it. But we
haven't seen it till now and those packages are used only by us. Will
check about splitting the current work in new packages, so we can also
split and the effort.

I'm aware of the downloading while building problem, but you mean
there is no way to reuse maven stuff while packaging, as the list of
dependencies is maybe 30-40 libraries?

Maven and Debian policy go together very badly. If the project doesn't
already use maven then _please_ don't change to it. It's terrible for
security and reproducibility. Nothing about getting the project
packaged would be helped by such a change - in fact it would be a
major hindrance.

We already done that, adding maven to most of our projects. This makes
the developer life easier, especially when working with several
packages that depend on each other.

The problem is that the packaging of such complex project, cannot keep
up with the rapid development that happens which at some point is a
big problem.

Lots of complex projects manage to get maintained in Debian. So it can
be done. It is much easier if they use sensible build systems and
upstream is interested in helping. I am interested in seeing jitsi
properly maintained in debian so may be able to help a bit (although I
can't promise much as I currently have a pile of other pending Debian
work).

Thanks for the encouraging of you all, I will try to start the initial
effort these days and I hope to come up with a working solution the
following weeks.

Regards
damencho

This thread should really be copied to the ITP, so people can at least see
what is going on. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757768

Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/

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


#13

Hey,
Thanks Ingo, while thinking for debian this weekend, I was thinking the
same. And I was thinking checking ice4j and start creating a branch called
debian in which we put all that stuff. WDYT?

Cheers
damencho

···

On Oct 19, 2015 2:20 AM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Before trying desktop Jitsi again, we should focus on a few smaller
projects that are dependencies of libjitsi. I.e. ice4j, sdes4j, bccontrib,
zrtp4j. These are all small and we can count on the help of Daniel. And
then do libjitsi.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

> Le 18.10.2015 à 23:33, Damian Minkov <damencho@jitsi.org> a écrit :
>
> Hi,
>
>> On Sun, Oct 18, 2015 at 3:38 PM, Wookey <wookey@wookware.org> wrote:
>> +++ Damian Minkov [2015-10-18 14:17 -0500]:
>>>> (Also, you need tackle the embedded code libraries. At least show some
>>>> progress! And to avoid getting you on the wrong path, as you mentioned
>>>> maven on jitsi-dev -- you cannot download dependencies at build time.)
>>>
>>> If you mean to get the dependencies out of jitsi, I havn't seen any
>>> interest of that from anybody so not sure it is worth the effort at
>>> this point.
>>
>> Debian is very keen on packing each project as a separate package
>> (because it is right), not all bundled into one source, or even worse
>> repeatedly bundled into lots of sources. So Debian is interested, (as
>> are all its derivatives), and we'll do our best to help with
>> that. This is much easier if upstream is on-board with that, otherwise
>> there can be significant build-system patch maintenance. Are they? (It
>> can be acceptable to leave embedded copies if they are only used by
>> one project, but in general it's bad (for bloat and security reasons).
>
> If there is interest in any of the packages we will do it. But we
> haven't seen it till now and those packages are used only by us. Will
> check about splitting the current work in new packages, so we can also
> split and the effort.
>
>>
>>> I'm aware of the downloading while building problem, but you mean
>>> there is no way to reuse maven stuff while packaging, as the list of
>>> dependencies is maybe 30-40 libraries?
>>
>> Maven and Debian policy go together very badly. If the project doesn't
>> already use maven then _please_ don't change to it. It's terrible for
>> security and reproducibility. Nothing about getting the project
>> packaged would be helped by such a change - in fact it would be a
>> major hindrance.
>
> We already done that, adding maven to most of our projects. This makes
> the developer life easier, especially when working with several
> packages that depend on each other.
>
>>
>>> The problem is that the packaging of such complex project, cannot keep
>>> up with the rapid development that happens which at some point is a
>>> big problem.
>>
>> Lots of complex projects manage to get maintained in Debian. So it can
>> be done. It is much easier if they use sensible build systems and
>> upstream is interested in helping. I am interested in seeing jitsi
>> properly maintained in debian so may be able to help a bit (although I
>> can't promise much as I currently have a pile of other pending Debian
>> work).
>
> Thanks for the encouraging of you all, I will try to start the initial
> effort these days and I hope to come up with a working solution the
> following weeks.
>
> Regards
> damencho
>
>> This thread should really be copied to the ITP, so people can at least
see
>> what is going on.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757768
>>
>> Wookey
>> --
>> Principal hats: Linaro, Debian, Wookware, ARM
>> http://wookware.org/
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

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


#14

Thanks Ingo, while thinking for debian this weekend, I was thinking the same.
And I was thinking checking ice4j and start creating a branch called debian
in which we put all that stuff. WDYT?

I have a working package script in a local branch. We first need to get rid of the javax.sdp stuff though, and that doesn't need to be in the Debian branch. I'll try to work on that on the weekend again.

Oh and for all our libraries, we need to find a versioning scheme. Both for Maven and Debian. It'll be no good to just use the build number.

Cheers
damencho

Ingo