[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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


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: