MOTU Application for Guillaume Martres (smarter)

[Reinhard Tartler]

Guillaume Martres <smarter3 at gmail.com> writes:

>> As an example, did you notice the shlibs change in the ffmpeg package?
>> Do you have plans to make actual use of it?
> I didn't notice it, but I'm not the principal maintainer of ffmpeg in 
> Medibuntu. After talking with mr_pouit, it appears that you're referring to 
> the dependencies on the *-unstripped-* packages. We didn't use that since 
> there was a possibility that Ubuntu would use it, but we're open to any 
> suggestion.

Even if ubuntu would use it, it wouldn't hurt if you provided these
packages until ubuntu or debian would use it.

The idea of these packages is that some 'ffmpeg' source package (instead
of ffmpeg-something) would provide the '-unstripped-' variants that
would not cause grief with upgrades.

>> Did you have consider talking/working together with the ~motumedia
>> and/or the pkg-multimedia team on alioth? If not, why?
> We would be happy to work with ~motumedia, and we've already shared
> some patches with debian-multimedia, but there doesn't seem an easy
> way to get in touch with you.  Do you have an IRC channel and/or a
> mailing-list? 

The irc channel is #ubuntu-motu. There wasn't the need of a dedicated
irc channel for ~motumeda yet.

As for mailing list, try pkg-multimedia-maintainers at lists.alioth.debian.org

> As for pkg- multimedia, I don't think there's a lot of things we could
> share.

Well, all work in the ffmpeg package happens there, so I'm pretty
surprised by that answer. I'd like to mention some changes that I could
imagine to include in the package I was provided a patch. AFAIUI the
medibuntu ffmpeg packages does the following changes to the ffmpeg
package:

  - use an unstripped ffmpeg tarball
  - link against a52
  - link against faad
  - link against libamr

The first point is already discussed in this email (the -unstripeed-
variants). I have been even thinking of adding some mechanism that
copies around debian/control.in.* files to make this even more easy.  As
for a52 and faad, if you look in the source, libavcodec already
supports loading these two packages via dlopen(). This means if we just
copy the header into a quilt patch, we could enable support for a52 and
faad in the ubuntu package without build depending on packages in
multiverse.

I haven't checked the libamr situation, but I imagine it should be
doable to implement this with libamr as well.


You see, I instantly see various points where we could collaborate.
Collaboration and communication skills is one of the key points I'd like
to see from prospective MOTUs.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4