Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 218338

Summary: media-video/ffmpeg2theora-9999 won't build because of wrong paths to headers
Product: Gentoo Linux Reporter: Armando Di Cianno <armando>
Component: New packagesAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Status: VERIFIED FIXED    
Severity: normal CC: media-video, n-roeser
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Patch for the ffmpeg2theora-9999 ebuild that is currently in the tree

Description Armando Di Cianno 2008-04-18 22:14:15 UTC
Yes, I'm using and unstable ffmpeg (0.4.9_p20080206).  I need to test some things with ffmpeg2theora, and there's a convenient -9999 live source ebuild in the tree.  Unforunately, this ebuild doesn't work -- not for complex reasons, just wrong paths to headers.

I will include patch to the ebuild to fix this problem.

I would like to suggest to the video herd to clean up where ffmpeg installs it's headers -- /usr/include/ffmpeg is okay, as opposed to the /usr/include{libavformat,libavdevice,libpostproc,etceteras} breakdown that other distros use, but postprocess.h is found in /usr/include/postproc.  Definitely strange, and not very intuitive.



Reproducible: Always

Steps to Reproduce:
Comment 1 Armando Di Cianno 2008-04-18 22:15:14 UTC
Created attachment 150239 [details, diff]
Patch for the ffmpeg2theora-9999 ebuild that is currently in the tree

The patch include a fix that uses sed to fix the include paths.
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2008-04-19 04:01:41 UTC
It's not an ebuild fixed to a specific version - 9999 ebuilds are usually "live" ebuilds that download the latest files from a repository. You cannot expect those to just work. Bugfixes should go straight to upstream.
Comment 3 Armando Di Cianno 2008-04-19 21:35:54 UTC
Please excuse the reopening of this bug, but I would like to clarify some stuff.  

The issue is /not/ resolved upstream AFAICT, since it is a Gentoo specific bug (again AFAICT).  Gentoo puts headers from ffmpeg (that's media-video/ffmpeg) in non-standard places -- at least different from some/most other distros.  There are headers in /usr/include/ffmpeg and /usr/include/postproc.  Other distros use incredibly specific paths for each header, for e.g. /usr/include/libavcodec for just avcodec.h.

$ emerge  -1 ffmpeg -p
[ebuild   R   ] media-video/ffmpeg-0.4.9_p20080206

$ equery f ffmpeg|grep "/usr/include"
/usr/include
/usr/include/ffmpeg
/usr/include/ffmpeg/adler32.h
/usr/include/ffmpeg/avcodec.h
/usr/include/ffmpeg/avdevice.h
/usr/include/ffmpeg/avformat.h
/usr/include/ffmpeg/avio.h
/usr/include/ffmpeg/avstring.h
/usr/include/ffmpeg/avutil.h
/usr/include/ffmpeg/base64.h
/usr/include/ffmpeg/common.h
/usr/include/ffmpeg/crc.h
/usr/include/ffmpeg/fifo.h
/usr/include/ffmpeg/intfloat_readwrite.h
/usr/include/ffmpeg/log.h
/usr/include/ffmpeg/lzo.h
/usr/include/ffmpeg/mathematics.h
/usr/include/ffmpeg/md5.h
/usr/include/ffmpeg/mem.h
/usr/include/ffmpeg/opt.h
/usr/include/ffmpeg/random.h
/usr/include/ffmpeg/rational.h
/usr/include/ffmpeg/rgb2rgb.h
/usr/include/ffmpeg/rtsp.h
/usr/include/ffmpeg/rtspcodes.h
/usr/include/ffmpeg/sha1.h
/usr/include/ffmpeg/swscale.h
/usr/include/postproc
/usr/include/postproc/postprocess.h

So, while I'm clearly not using a /stable/ version of media-video/ffmpeg, I am using an official unstable ffmpeg ebuild.

Now, the only people that media-video/ffmpeg2theora-9999 is going to be useful for is people who are knowingly using unstable ebuilds.  So why have ffmpeg2theora-9999 in the tree at all, if it's *never going to work* with newer ffmpeg's?  Do you catch my drift here?

My patch to the ebuild uses sed, and therefore is only fixing what is known to be broken -- you are definitely correct there, as stuff might change.  Another option would be to remove the paths from the #include statements, and add Gentoo's specific locations for ffmpeg headers to the include path at compile time.  Also, you could add a specific revision SVN checkout (say the revision on the date I reported this bug) that always will compile, work, and run with these fixes.

Regardless of anything else, this is either a bug to be fixed in newer ffmpeg ebuilds or a bug in the ffmpeg2theora-9999 ebuild.  The choice of which one to fix is yours.  I would appreciate acknowledgment of this fact, or an explanation as to why I am incorrect in this case.  Thanks.
Comment 4 Ben de Groot (RETIRED) gentoo-dev 2008-04-19 23:27:44 UTC
>> Now, the only people that media-video/ffmpeg2theora-9999 is going to be useful for is people who are knowingly using unstable ebuilds.  So why have ffmpeg2theora-9999 in the tree at all, if it's *never going to work* with newer ffmpeg's? <<

The patch makes it work with the latest ffmpeg snapshot in the tree, which is 0.4.9_p20080326, and also with ffmpeg-20089999 in berkano overlay. Gentoo is _not_ doing anything non-standard w.r.t. where ffmpeg installs its headers. 

We probably should keep media-video/ffmpeg-0.4.9_p20080206 masked. The candidate for unmasking to ~arch is 0.4.9_p20080326. See also bug 214740.
Comment 5 Armando Di Cianno 2008-04-20 14:59:54 UTC
Thanks for the response.

I will bump my own testing to 0.4.9_p20080326 as well, as try to be helpful along those lines.
Comment 6 Samuli Suominen gentoo-dev 2008-05-04 07:57:34 UTC
(In reply to comment #5)
> Thanks for the response.
> 
> I will bump my own testing to 0.4.9_p20080326 as well, as try to be helpful
> along those lines.
> 

I believe the bug has been fixed in ffmpeg2theora's trunk, and -9999 should work without problems with our recent package.masked ffmpeg versions.