[SCM] FFmpeg packaging branch, master.unstripped, updated. upstream/0.svn20090128-73-gc28891f

[Reinhard Tartler]

Christian Marillat <marillat at debian.org> writes:

> Reinhard Tartler <siretart at tauware.de> writes:
>
> [...]
>
>> Ok, how do you feel about me updating ffmpeg to an current svn snapshot,
>> and uploading both the stripped 'ffmpeg-debian' and the unstripped
>> 'ffmpeg' package at debian-multimedia.org? this would make sure that the
>> packages in debian-multimedia.org are compatible to the debian ffmpeg
>> version.
>
> We can do a try. 

Okay, I'll prepare the upload and publish them somewhere where you can
download via http until you give me an dput snippet for your incoming
queue.

>> I suspect that the 'master.unstripped' branch needs some further tweaks,
>> like building against x264 or amr.
>
> Yes, Could you add these dependencies in debian/control.ffmpeg ?

oh, indeed. it seems that libavcodec has 3 object files that can make
use of yasm. I will add it to the packaging branch.

> ,----
> | libmp3lame-dev, libfaac-dev, libxvidcore4-dev, libx264-dev (>=
> | 1:0.svn20090222), ccache, libamrnb-dev, libamrwb-dev, libdirac-dev,
> | nvidia-glx-dev (>= 180.29) [amd64 i386]
> `----
>
> I see tha yasm is missing in Build-Depends.
>
> It is possible to add ccache and multicpu build with NCPUS ?

multicpu build is already there, but the variable is named NJOBS, not
NCPUS. Is there reference document that describes how it should be done
properly.

ccache is something that should IMO be controlled in the build
environment by setting PATH. the package does preserve PATH from the
environment.

We could perhaps add some magic by checking DEB_BUILD_OPTIONS, but I
suppose that wouldn't help you too much, right?

Fabian Greffrath <greffrath at leat.rub.de> writes:

> Reinhard Tartler schrieb:
>> I suspect that the 'master.unstripped' branch needs some further tweaks,
>> like building against x264 or amr.
>
> Please note that building against amr{n,w}b will make the resulting
> binary packages unredistributable -- at least according to ffmpeg
> upstream.

that is my understanding as well. However it seems that Christian does
not see a problem with this. Christian, could you perhaps elaborate here
a bit why you don't see a license problem?

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