| Summary: | media-video/kino 1.3.3 fails to build without v4l | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James <cctsurf> |
| Component: | Current packages | Assignee: | Denis Dupeyron (RETIRED) <calchan> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bircoph, egorov_egor, gibgibon, jcwren, Martin.vGagern, media-video, pva, silvio.gerli |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 290766 | ||
| Bug Blocks: | 359595 | ||
| Attachments: |
Kino-1.3.3 build log
kino-1.3.3-v4l1.patch kino-1.3.3.ebuild.patch |
||
|
Description
James
2011-04-02 18:44:43 UTC
It appears that Ubuntu has, instead of linking to videodev.h which no longer exists, is linking to libv4l1-videodev.h, which is a part of the media-libs/libv4l package... Until such a time as there is a better patch, I would suggest that we might do this temporarily as well... It would add another dependency for kopete, but then we could build it... I don't have time right now to try this, but will attempt soon if noone else can, Created attachment 273525 [details, diff]
kino-1.3.3-v4l1.patch
Use media-libs/libv4l header as James suggested.
Created attachment 273527 [details, diff]
kino-1.3.3.ebuild.patch
Apply patch above only for kernels >= 2.6.38.
Unfortunately there is no sane way to make media-libs/libv4l dependecy present only when new kernel is used.
(In reply to comment #3) > Unfortunately there is no sane way to make media-libs/libv4l dependecy present > only when new kernel is used. It's not the kernel that matters at compile time, it's linux-headers. So you could depend on || ( <sys-kernel/linux-headers-2.6.38 media-libs/libv4l ) and have the ebuild apply the patch unless has_version '<sys-kernel/linux-headers-2.6.38' is true. I wonder whether referencing that header is really enough. We should probably link to v4l1compat.so in order to provide a v4l1 layer even if the kernel has none. In that case, the runtime setup of the package would be different, threfore we should not do any magic compile-time autodetection, but introduce a USE flag (perhaps "v4l1emu"?) instead. Cross reference: media-video/mjpegtools has similar problems. Bug #359491 disabled v4l support altogether, and the upstream bug report referenced in bug #359491 comment #10 discusses building against libv4l for compatibility. the patch works for me. Thanks! With slight tweaking (the removal of the avutil patch), I was able to make 1.3.4 build with this patch as well. (In reply to comment #5) > the patch works for me. Thanks! With slight tweaking (the removal of the > avutil patch), I was able to make 1.3.4 build with this patch as well. Is it possibile to have this patch in portage? Just filed https://sourceforge.net/tracker/?func=detail&aid=3306021&group_id=14103&atid=314103 for a patch that should in theory use libv4l in order to provide V4L1 compatibility on a V4L2-only kernel. Not sure whether you'd want that kind of patch in the portage tree before upstream accepts it, though. Thank you for report/fix guys. Fixed in 1.3.4. |
