Re: RFS: jitsi/1.1.4365-1 [ITP]
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
>
Reply to: