On Thu, Jan 5, 2012 at 9:55 AM, Reinhard Tartler <siret...@gmail.com> wrote: > On Thu, Jan 5, 2012 at 4:04 PM, Richard Shaw <hobbes1...@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 it. >> 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. Richard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
