| Summary: | media-video/ffmpeg2theora-9999 won't build because of wrong paths to headers | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Armando Di Cianno <armando> |
| Component: | New packages | Assignee: | 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 | ||
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.
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. 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. >> 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. 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. (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. |
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: