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