[jitsi-dev] RFS: jitsi/1.1.4365-1 [ITP]


#1

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  We are looking for a sponsor for our package "jitsi"

* Package name : jitsi
   Version : 1.1.4365-1
   Upstream Author : Jitsi Community <dev@jitsi.java.net>
* URL : https://jitsi.org/
* License : LGPL v2
   Section : net

  It builds those binary packages:

    jitsi - Java VoIP and Instant Messaging client
jitsi-jni - Jitsi JNI library

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/jitsi

  Alternatively, one can download the package with dget using this command:

    dget -x http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

  More information about Jitsi can be obtained from https://jitsi.org
and the developers mailinglist: dev@jitsi.java.net.

  Regards,
   Damian Minkov


#2

Hello Damian,

I'm glad to see a package of jitsi. I've taken a look at the packaging
on mentors.d.o and I think there is some additional work to do before
the package can be included in Debian.

The first thing I would suggest is that the orig.tar.gz be repacked to:

a) not include binary JARs or .class files
- For example, there are 3 separate copies of junit alone.

b) exclude copies source libraries that are already packaged for Debian
- For example, libavcodec

c) exclude copies of distinct libraries that should be packaged separately.
- For example, ice4j (even though you're also upstream for that), jsip

I recognize that these may represent significant effort - particularly
(b) and (c) - given that the library versions in the source tarball
appear to be newer than the versions in Debian and that the libraries in
(c) will each become a separate package.

The reason behind (b) and (c) is the section Debian Policy concerning
"convenience copies of code" [1]. The reason for (a) is that the binary
artifacts needlessly bloat the archive.

This is the right list to help with (c), and (b) as possible for Java
packages.

Cheers,
tony

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

···

On 12/10/2012 05:13 AM, Damian Minkov wrote:

  We are looking for a sponsor for our package "jitsi"

* Package name : jitsi
   Version : 1.1.4365-1
   Upstream Author : Jitsi Community <dev@jitsi.java.net <mailto:dev@jitsi.java.net>>
* URL : https://jitsi.org/
* License : LGPL v2
   Section : net

  http://mentors.debian.net/package/jitsi
  dget -x http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc


#3

Hi Tony,

thanks for the quick comments on our package, we have some questions:

> We are looking for a sponsor for our package "jitsi"
>
> * Package name : jitsi
> Version : 1.1.4365-1
> Upstream Author : Jitsi Community <dev@jitsi.java.net <mailto:
dev@jitsi.java.net>>
> * URL : https://jitsi.org/
> * License : LGPL v2
> Section : net

> http://mentors.debian.net/package/jitsi
> dget -x
http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

Hello Damian,

I'm glad to see a package of jitsi. I've taken a look at the packaging
on mentors.d.o and I think there is some additional work to do before
the package can be included in Debian.

The first thing I would suggest is that the orig.tar.gz be repacked to:

a) not include binary JARs or .class files
- For example, there are 3 separate copies of junit alone.

Oh OK. They must have slipped in accidentally. We'll remove them in the
next submission

b) exclude copies source libraries that are already packaged for Debian
- For example, libavcodec

We had a quick test with libav and we seemed to be missing some headers (as
opposed to when using ffmpeg 1.0). We can give it another try and look some
more. I am wondering however if we could somehow CC the corresponding
maintainers and maybe have some feedback from them as well.

c) exclude copies of distinct libraries that should be packaged separately.
- For example, ice4j (even though you're also upstream for that), jsip

We completely understand the advantages of committing things into separate
packages. The thing is that we started work on the Jitsi source deb package
around the beginning of August and it has taken us that long to get here.
We were hence hoping that we could work on getting the first version in its
current form. We were planning on ultimately spinning off libs such as
ice4j and libjitsi but given that no other projects are currently depending
on them we were hoping that it could wait.

Is this unreasonable?

Thanks
Damian

···

On Tue, Dec 11, 2012 at 7:14 AM, tony mancill <tmancill@debian.org> wrote:

On 12/10/2012 05:13 AM, Damian Minkov wrote:

I recognize that these may represent significant effort - particularly
(b) and (c) - given that the library versions in the source tarball
appear to be newer than the versions in Debian and that the libraries in
(c) will each become a separate package.

The reason behind (b) and (c) is the section Debian Policy concerning
"convenience copies of code" [1]. The reason for (a) is that the binary
artifacts needlessly bloat the archive.

This is the right list to help with (c), and (b) as possible for Java
packages.

Cheers,
tony

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles


#4

Hi,

the package have been updated, removed any binaries or class files from it.

Thanks
Damian

···

On Tue, Dec 11, 2012 at 1:31 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi Tony,

thanks for the quick comments on our package, we have some questions:

On Tue, Dec 11, 2012 at 7:14 AM, tony mancill <tmancill@debian.org> wrote:

On 12/10/2012 05:13 AM, Damian Minkov wrote:

> We are looking for a sponsor for our package "jitsi"
>
> * Package name : jitsi
> Version : 1.1.4365-1
> Upstream Author : Jitsi Community <dev@jitsi.java.net
> <mailto:dev@jitsi.java.net>>
> * URL : https://jitsi.org/
> * License : LGPL v2
> Section : net

> http://mentors.debian.net/package/jitsi
> dget -x
> http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

Hello Damian,

I'm glad to see a package of jitsi. I've taken a look at the packaging
on mentors.d.o and I think there is some additional work to do before
the package can be included in Debian.

The first thing I would suggest is that the orig.tar.gz be repacked to:

a) not include binary JARs or .class files
- For example, there are 3 separate copies of junit alone.

Oh OK. They must have slipped in accidentally. We'll remove them in the next
submission

b) exclude copies source libraries that are already packaged for Debian
- For example, libavcodec

We had a quick test with libav and we seemed to be missing some headers (as
opposed to when using ffmpeg 1.0). We can give it another try and look some
more. I am wondering however if we could somehow CC the corresponding
maintainers and maybe have some feedback from them as well.

c) exclude copies of distinct libraries that should be packaged
separately.
- For example, ice4j (even though you're also upstream for that), jsip

We completely understand the advantages of committing things into separate
packages. The thing is that we started work on the Jitsi source deb package
around the beginning of August and it has taken us that long to get here. We
were hence hoping that we could work on getting the first version in its
current form. We were planning on ultimately spinning off libs such as ice4j
and libjitsi but given that no other projects are currently depending on
them we were hoping that it could wait.

Is this unreasonable?

Thanks
Damian

I recognize that these may represent significant effort - particularly
(b) and (c) - given that the library versions in the source tarball
appear to be newer than the versions in Debian and that the libraries in
(c) will each become a separate package.

The reason behind (b) and (c) is the section Debian Policy concerning
"convenience copies of code" [1]. The reason for (a) is that the binary
artifacts needlessly bloat the archive.

This is the right list to help with (c), and (b) as possible for Java
packages.

Cheers,
tony

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles


#5

Hi Damian:

Responses are interspersed below:

Hi Tony,

thanks for the quick comments on our package, we have some questions:

    > We are looking for a sponsor for our package "jitsi"
    >
    > * Package name : jitsi
    > Version : 1.1.4365-1
    > Upstream Author : Jitsi Community <dev@jitsi.java.net
    <mailto:dev@jitsi.java.net> <mailto:dev@jitsi.java.net
    <mailto:dev@jitsi.java.net>>>
    > * URL : https://jitsi.org/
    > * License : LGPL v2
    > Section : net

    > http://mentors.debian.net/package/jitsi
    > dget -x
    http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

    Hello Damian,

    I'm glad to see a package of jitsi. I've taken a look at the packaging
    on mentors.d.o and I think there is some additional work to do before
    the package can be included in Debian.

    The first thing I would suggest is that the orig.tar.gz be repacked to:

    a) not include binary JARs or .class files
     - For example, there are 3 separate copies of junit alone.

Oh OK. They must have slipped in accidentally. We'll remove them in the
next submission

I pulled the new version, thank you for pulling those out. (That saves
8MB on the orig.tar.gz.)

    b) exclude copies source libraries that are already packaged for Debian
     - For example, libavcodec

We had a quick test with libav and we seemed to be missing some headers
(as opposed to when using ffmpeg 1.0). We can give it another try and
look some more. I am wondering however if we could somehow CC the
corresponding maintainers and maybe have some feedback from them as well.

Within Debian, I think the best course of action for libraries that need
updates is to file severity wishlist bugs against those library
packages. Sometimes maintainers will upload newer versions of libraries
to experimental, which will allow you continue development (although it
means that your package would also go into experimental, at least for
the time being). If you wanted to, you could even block your ITP bug
with update requests.

libavcodec was one example (that might problematic), but there are
others that I think can be resolved.

lcrypto appears to be bouncycastle 1.43, and Debian already has 1.46 in
unstable [1]. Is there something about the embedded copy that differs
from the upstream bouncycastle?

portaudio is also packaged for Debian [2].

I haven't had a chance to check all of the others yet.

    c) exclude copies of distinct libraries that should be packaged
    separately.
     - For example, ice4j (even though you're also upstream for that), jsip

We completely understand the advantages of committing things into
separate packages. The thing is that we started work on the Jitsi source
deb package around the beginning of August and it has taken us that long
to get here. We were hence hoping that we could work on getting the
first version in its current form. We were planning on ultimately
spinning off libs such as ice4j and libjitsi but given that no other
projects are currently depending on them we were hoping that it could wait.

Is this unreasonable?

I don't think it's unreasonable for libraries that are currently
specific to jitsi and have the same upstream (others may disagree). But
for libraries that have distinct upstreams, I think it's important that
they be separate packages (again, if others disagree, please chime in),
even if they're not currently part of Debian. Without that, it becomes
difficult to determine what package needs to be updated when there are
security issues with a particular library. Second, it helps the
community at large to have useful libraries packaged. (That's with my
Debian hat on - I recognize that it can be a lot of work.) Also, it
helps establish the provenance of those libraries. For example, I'm not
sure looking at the debian/copyright for jitsi where to look for the
upstream of macwidgets.

The fact that you have all of the project dependencies building from
source means that much of the work for these dependency libraries has
been done, and it's impressive too!

I think some of these libraries - for example gdata-java-client -
could/should be maintained by the Debian Java team. I'll continue to
take a look to see which of these might already be or should be packaged
separately in Debian.

Cheers,
tony

[1] http://packages.qa.debian.org/b/bouncycastle.html
[2] http://packages.qa.debian.org/p/portaudio19.html

···

On 12/11/2012 03:31 AM, Damian Minkov wrote:

On Tue, Dec 11, 2012 at 7:14 AM, tony mancill <tmancill@debian.org > <mailto:tmancill@debian.org>> wrote:
    On 12/10/2012 05:13 AM, Damian Minkov wrote:


#6

Hi,

Hi Damian:

Responses are interspersed below:

Hi Tony,

thanks for the quick comments on our package, we have some questions:

    > We are looking for a sponsor for our package "jitsi"
    >
    > * Package name : jitsi
    > Version : 1.1.4365-1
    > Upstream Author : Jitsi Community <dev@jitsi.java.net
    <mailto:dev@jitsi.java.net> <mailto:dev@jitsi.java.net
    <mailto:dev@jitsi.java.net>>>
    > * URL : https://jitsi.org/
    > * License : LGPL v2
    > Section : net

    > http://mentors.debian.net/package/jitsi
    > dget -x
    http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

    Hello Damian,

    I'm glad to see a package of jitsi. I've taken a look at the packaging
    on mentors.d.o and I think there is some additional work to do before
    the package can be included in Debian.

    The first thing I would suggest is that the orig.tar.gz be repacked to:

    a) not include binary JARs or .class files
     - For example, there are 3 separate copies of junit alone.

Oh OK. They must have slipped in accidentally. We'll remove them in the
next submission

I pulled the new version, thank you for pulling those out. (That saves
8MB on the orig.tar.gz.)

    b) exclude copies source libraries that are already packaged for Debian
     - For example, libavcodec

We had a quick test with libav and we seemed to be missing some headers
(as opposed to when using ffmpeg 1.0). We can give it another try and
look some more. I am wondering however if we could somehow CC the
corresponding maintainers and maybe have some feedback from them as well.

Within Debian, I think the best course of action for libraries that need
updates is to file severity wishlist bugs against those library
packages. Sometimes maintainers will upload newer versions of libraries
to experimental, which will allow you continue development (although it
means that your package would also go into experimental, at least for
the time being). If you wanted to, you could even block your ITP bug
with update requests.

libavcodec was one example (that might problematic), but there are
others that I think can be resolved.

lcrypto appears to be bouncycastle 1.43, and Debian already has 1.46 in
unstable [1]. Is there something about the embedded copy that differs
from the upstream bouncycastle?

Yes it is a different from the standard one. Discussion about it can
be found here:
http://java.net/projects/jitsi/lists/dev/archive/2012-07/message/192
There are a number of changes there needed for SSL Certificate
validation, Skein and also a modified Big Number module that
is better suited for security functions.

portaudio is also packaged for Debian [2].

We are using a patched version of one of the branches of the portaudio
project. It is the hotplug branch. The patches have been contributed
to portaudio, they were discussed on their mailing list but never
found a way even in the branch.
In the near future we will probably remove the portaudio dependency so
there is really no point in waiting for an updated version.

I haven't had a chance to check all of the others yet.

    c) exclude copies of distinct libraries that should be packaged
    separately.
     - For example, ice4j (even though you're also upstream for that), jsip

We completely understand the advantages of committing things into
separate packages. The thing is that we started work on the Jitsi source
deb package around the beginning of August and it has taken us that long
to get here. We were hence hoping that we could work on getting the
first version in its current form. We were planning on ultimately
spinning off libs such as ice4j and libjitsi but given that no other
projects are currently depending on them we were hoping that it could wait.

Is this unreasonable?

I don't think it's unreasonable for libraries that are currently
specific to jitsi and have the same upstream (others may disagree). But
for libraries that have distinct upstreams, I think it's important that
they be separate packages (again, if others disagree, please chime in),
even if they're not currently part of Debian. Without that, it becomes
difficult to determine what package needs to be updated when there are
security issues with a particular library. Second, it helps the
community at large to have useful libraries packaged. (That's with my
Debian hat on - I recognize that it can be a lot of work.) Also, it
helps establish the provenance of those libraries. For example, I'm not
sure looking at the debian/copyright for jitsi where to look for the
upstream of macwidgets.

The fact that you have all of the project dependencies building from
source means that much of the work for these dependency libraries has
been done, and it's impressive too!

I think some of these libraries - for example gdata-java-client -
could/should be maintained by the Debian Java team. I'll continue to
take a look to see which of these might already be or should be packaged
separately in Debian.

We are using newer version of gdata than the one that is in the
repository. We are using version 1.43 of the library which is from Feb
2011, where in debian the version is 1.30 from Feb 2009.
That is also and the situation for dnsjava-java using 2.1.3 where we
can find in debian version 2.0.8.

We found and updated several lib sources/dependencies - jmdns,
mac-widgets, apache felix and apache felix-main and we updated again
the package.

Regards
Damian

···

On Fri, Dec 14, 2012 at 6:21 AM, tony mancill <tmancill@debian.org> wrote:

On 12/11/2012 03:31 AM, Damian Minkov wrote:

On Tue, Dec 11, 2012 at 7:14 AM, tony mancill <tmancill@debian.org >> <mailto:tmancill@debian.org>> wrote:
    On 12/10/2012 05:13 AM, Damian Minkov wrote:

Cheers,
tony

[1] http://packages.qa.debian.org/b/bouncycastle.html
[2] http://packages.qa.debian.org/p/portaudio19.html


#7

Hi,

once again we have updated the package, removed the ffmpeg sources and
added the libav dependencies.

Thanks
Damian

···

On Sat, Dec 15, 2012 at 1:48 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

On Fri, Dec 14, 2012 at 6:21 AM, tony mancill <tmancill@debian.org> wrote:

Hi Damian:

Responses are interspersed below:

On 12/11/2012 03:31 AM, Damian Minkov wrote:

Hi Tony,

thanks for the quick comments on our package, we have some questions:

On Tue, Dec 11, 2012 at 7:14 AM, tony mancill <tmancill@debian.org >>> <mailto:tmancill@debian.org>> wrote:

    On 12/10/2012 05:13 AM, Damian Minkov wrote:

    > We are looking for a sponsor for our package "jitsi"
    >
    > * Package name : jitsi
    > Version : 1.1.4365-1
    > Upstream Author : Jitsi Community <dev@jitsi.java.net
    <mailto:dev@jitsi.java.net> <mailto:dev@jitsi.java.net
    <mailto:dev@jitsi.java.net>>>
    > * URL : https://jitsi.org/
    > * License : LGPL v2
    > Section : net

    > http://mentors.debian.net/package/jitsi
    > dget -x
    http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

    Hello Damian,

    I'm glad to see a package of jitsi. I've taken a look at the packaging
    on mentors.d.o and I think there is some additional work to do before
    the package can be included in Debian.

    The first thing I would suggest is that the orig.tar.gz be repacked to:

    a) not include binary JARs or .class files
     - For example, there are 3 separate copies of junit alone.

Oh OK. They must have slipped in accidentally. We'll remove them in the
next submission

I pulled the new version, thank you for pulling those out. (That saves
8MB on the orig.tar.gz.)

    b) exclude copies source libraries that are already packaged for Debian
     - For example, libavcodec

We had a quick test with libav and we seemed to be missing some headers
(as opposed to when using ffmpeg 1.0). We can give it another try and
look some more. I am wondering however if we could somehow CC the
corresponding maintainers and maybe have some feedback from them as well.

Within Debian, I think the best course of action for libraries that need
updates is to file severity wishlist bugs against those library
packages. Sometimes maintainers will upload newer versions of libraries
to experimental, which will allow you continue development (although it
means that your package would also go into experimental, at least for
the time being). If you wanted to, you could even block your ITP bug
with update requests.

libavcodec was one example (that might problematic), but there are
others that I think can be resolved.

lcrypto appears to be bouncycastle 1.43, and Debian already has 1.46 in
unstable [1]. Is there something about the embedded copy that differs
from the upstream bouncycastle?

Yes it is a different from the standard one. Discussion about it can
be found here:
http://java.net/projects/jitsi/lists/dev/archive/2012-07/message/192
There are a number of changes there needed for SSL Certificate
validation, Skein and also a modified Big Number module that
is better suited for security functions.

portaudio is also packaged for Debian [2].

We are using a patched version of one of the branches of the portaudio
project. It is the hotplug branch. The patches have been contributed
to portaudio, they were discussed on their mailing list but never
found a way even in the branch.
In the near future we will probably remove the portaudio dependency so
there is really no point in waiting for an updated version.

I haven't had a chance to check all of the others yet.

    c) exclude copies of distinct libraries that should be packaged
    separately.
     - For example, ice4j (even though you're also upstream for that), jsip

We completely understand the advantages of committing things into
separate packages. The thing is that we started work on the Jitsi source
deb package around the beginning of August and it has taken us that long
to get here. We were hence hoping that we could work on getting the
first version in its current form. We were planning on ultimately
spinning off libs such as ice4j and libjitsi but given that no other
projects are currently depending on them we were hoping that it could wait.

Is this unreasonable?

I don't think it's unreasonable for libraries that are currently
specific to jitsi and have the same upstream (others may disagree). But
for libraries that have distinct upstreams, I think it's important that
they be separate packages (again, if others disagree, please chime in),
even if they're not currently part of Debian. Without that, it becomes
difficult to determine what package needs to be updated when there are
security issues with a particular library. Second, it helps the
community at large to have useful libraries packaged. (That's with my
Debian hat on - I recognize that it can be a lot of work.) Also, it
helps establish the provenance of those libraries. For example, I'm not
sure looking at the debian/copyright for jitsi where to look for the
upstream of macwidgets.

The fact that you have all of the project dependencies building from
source means that much of the work for these dependency libraries has
been done, and it's impressive too!

I think some of these libraries - for example gdata-java-client -
could/should be maintained by the Debian Java team. I'll continue to
take a look to see which of these might already be or should be packaged
separately in Debian.

We are using newer version of gdata than the one that is in the
repository. We are using version 1.43 of the library which is from Feb
2011, where in debian the version is 1.30 from Feb 2009.
That is also and the situation for dnsjava-java using 2.1.3 where we
can find in debian version 2.0.8.

We found and updated several lib sources/dependencies - jmdns,
mac-widgets, apache felix and apache felix-main and we updated again
the package.

Regards
Damian

Cheers,
tony

[1] http://packages.qa.debian.org/b/bouncycastle.html
[2] http://packages.qa.debian.org/p/portaudio19.html


#8

Hi,

we've just updated the package on mentors.debian.net following the
comments we recieved:
The dsc file can be found at:
http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_2.0.4506.10553-1.dsc

Regards
Damian

···

On Mon, Dec 10, 2012 at 3:13 PM, Damian Minkov <damencho@jitsi.org> wrote:

  Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  We are looking for a sponsor for our package "jitsi"

* Package name : jitsi
   Version : 1.1.4365-1
   Upstream Author : Jitsi Community <dev@jitsi.java.net>
* URL : https://jitsi.org/
* License : LGPL v2
   Section : net

  It builds those binary packages:

    jitsi - Java VoIP and Instant Messaging client
jitsi-jni - Jitsi JNI library

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/jitsi

  Alternatively, one can download the package with dget using this command:

    dget -x
http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

  More information about Jitsi can be obtained from https://jitsi.org and
the developers mailinglist: dev@jitsi.java.net.

  Regards,
   Damian Minkov


#9

Hello Damian,

If you haven't heard from other potential sponsors, I will take a look
at the latest packaging.

Cheers,
tony

···

On 03/15/2013 03:42 AM, Damian Minkov wrote:

Hi,

we've just updated the package on mentors.debian.net following the
comments we recieved:
The dsc file can be found at:
http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_2.0.4506.10553-1.dsc

Regards
Damian