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

Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)

On Thu, Jan 5, 2012 at 9:55 AM, Reinhard Tartler <siretart@gmail.com> wrote:
> On Thu, Jan 5, 2012 at 4:04 PM, Richard Shaw <hobbes1069@gmail.com> wrote:
>> I took over mantainership around 2.5.3 so I'm not the original author
>> of the spec file. Now that I think about it I probably don't need to
>> BR: ffmpeg-devel but the original maintainer may have begun an attempt
>> to un-bundle ffmpeg.
> I'm a bit confused now. Fabian noticed that Fedora's avidemux 2.5.3
> package already did unbundle ffmpeg. Is this untrue? Or did I
> misunderstand you two?

To my knowledge ffmpeg has never been un-bundled in RPM Fusion and
certainly wasn't when I took over maintainership.

>> As mentioned previously, the bundled ffmpeg is heavily patched. I
>> doubt if avidemux wasn't grandfathered in during the 3rd party repo
>> merger that it would pass a review request today since RPM Fusion has
>> the same policy against bundled libraries as Fedora. I had some luck
>> un-bundling some of the other libraries as you noticed, but ffmpeg is
>> beyond me.
> We would be happy to share the work and take your patches for using
> the system libraries for the Debian package. Besides, have you by
> chance already asked upstream to comment on your patches? If yes, what
> was the response?

avidemux was my 2nd package ever :) I'm getting pretty good at
packaging but I'm not really a programmer other than a little Python.
IIRC my patches are pretty much brute force at this point which really
are not upstreamable. I do know cmake MUCH better than when I created
those patches so I may take another look.

I did take a quick look and the cmake portion of the patch would be
pretty easy to turn into a cmake option, however I also have to patch
the "#include'(s). I'm not sure if there's an easy way around this or
if they need to be converted into a <file>.cpp.in and get configured
for one or the other or if there's a way to  #if DEFINE a way around

>> I think a lot of the patches for ffmpeg are to maintain "frame
>> accuracy", this feature has been dropped from the upcoming 2.6 release
>> (there are pro's and con's to both approaches) and it may be much
>> easier to un-bundle ffmpeg from this version.
> That's great to hear! Maybe we (i.e., in Debian) should, directly look
> at packaging the 2.6 development branch.

I still need to port my un-bundle patches over to 2.6, maybe that
would be the best time to make them more configurable.

>> I've already started building preview release packages. The building
>> is rather odd, I actually have to do a temporary install of
>> avidemux_core in the %build section so the headers are available for
>> linking by all the other sub-projects (cli, QT, GTK,  plugins, etc.).
>> I know the build systems differ quite a bit but I would think the
>> building methodology would sill be the same. Let me know if anyone
>> would like to take a look and I'll make my spec file available.
> Yes, that would probably be helpful for preparing the Debian package.
> Do you use some VCS for your packaging work? In case you are
> interested in our current packaging branch, it is at
> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/avidemux.git

Not currently for the avidemux preview release as I'd have to get
through a review request to host it at RPM Fusion.


Reply to: