cutecom was worked around to use the compability headers from libv4l package. this does make it compile, but it doesn't run if you use kernel 2.6.38 or higher we are stabilizing udev-197 and arch's are in CC list, that means you can't run 2.6.37 anymore on default systems so you'd have to add !<sys-fs/udev-197 to the dependencies, to make it force install eudev instead from the virtual eudev has compability down to 2.6.31
to clarify, udev-197 needs at least 2.6.39 which no longer ships v4l1
Do you mean cutecom or qutecom? qutecom runs fine, it just will not have any v4l1 functionality on recent kernels.
(In reply to comment #2) > Do you mean cutecom or qutecom? qutecom, sorry > qutecom runs fine, it just will not have any v4l1 functionality on recent > kernels. And it's somehow useful without v4l capabilities?
How about a IUSE="v4l" v4l? ( !>=sys-fs/udev-197 ) Or does it sanely report at runtime about missing capabilities?
Close the bug as WORKSFORME then; I'll take your word anyway as the maintainer.
(In reply to comment #4) > How about a > > IUSE="v4l" > > v4l? ( !>=sys-fs/udev-197 ) > > Or does it sanely report at runtime about missing capabilities? Will it cause downgrade of udev? In that case I think it's undesired. If I don't misremember wee now have only "v4l" USE flag for v4l2 support and, then, if people have v4l enabled systemd-wide, they will get this block when trying to merge qutecom Probably could be moved to libv4l: https://bugs.gentoo.org/show_bug.cgi?id=362543#c4 See this debian patch: http://patch-tracker.debian.org/patch/series/view/qutecom/2.2.1+dfsg1-3/new-videodev.patch It looks it could help
(In reply to comment #6) > (In reply to comment #4) > > How about a > > > > IUSE="v4l" > > > > v4l? ( !>=sys-fs/udev-197 ) > > > > Or does it sanely report at runtime about missing capabilities? > > Will it cause downgrade of udev? In that case I think it's undesired. If I > don't misremember wee now have only "v4l" USE flag for v4l2 support and, > then, if people have v4l enabled systemd-wide, they will get this block when > trying to merge qutecom It would force eudev or older udev to be emerged, those that still support older kernels with support for v4l1. It's clear v4l in qutecom cannot work on a system with new udev, like 197, since it forces at least kernel >=2.6.39 and the v4l1 support was dropped in 2.6.38. > Probably could be moved to libv4l: > https://bugs.gentoo.org/show_bug.cgi?id=362543#c4 > > See this debian patch: > http://patch-tracker.debian.org/patch/series/view/qutecom/2.2.1+dfsg1-3/new- > videodev.patch > > It looks it could help Nope. All it does is allow building the libv4l1 support using the libv4l compability headers. It doesn't use the library. It's only a hack to allow building. I'm pretty sure that's what is being already used in Portage. Useless patch, pretty much.
Patch that would completely disable building the v4l1 support would work, but I'm not sure if the app is still useful or not. That's why I asked. Maybe it's useful with sound only. The only clean solution seems to be creating an upstream snapshot and getting rid of this ancient version like now.
Well, I would prefer to prevent downgrades that could cause other problems as much as possible. I thought v4l1 support was killed in the past for most of the stuff and "v4l" USE flag was meant to be used for v4l2 support (once "v4l2" USE flag died). If v4l1 support for this package is so important, I would move it (with its block to current stable udev) to a "v4l1" USE flag to see it disabled in most systems and people seeing clearly that what they are trying to enable is deprecated (that could also be another USE flag to control it ;)) Will try to google a bit to see if some v4l2 support for this has rised somewhere
Couldn't find anything apart of that debian patch and a similar one applied in AltLinux. I have also seen: http://lists.qutecom.org/pipermail/qutecom-commits/2011-April/000010.html Then, maybe a much newer snapshot could help like Samuli suggested
(In reply to comment #9) > Well, I would prefer to prevent downgrades that could cause other problems > as much as possible. I thought v4l1 support was killed in the past for most > of the stuff and "v4l" USE flag was meant to be used for v4l2 support (once > "v4l2" USE flag died). If v4l1 support for this package is so important, I > would move it (with its block to current stable udev) to a "v4l1" USE flag > to see it disabled in most systems and people seeing clearly that what they > are trying to enable is deprecated (that could also be another USE flag to > control it ;)) We lastrited everything that didn't either link against the libv4l1 compat libraries on libv4l or use v4l2 directly. So yes, USE="v4l" mostly means just those. We also tried to lastrite qutecom back then, but the reason for not doing so was that users could still use older kernels that had the v4l1 support, but now that udev-197-r3 is stable, and only allows kernels equal or higher than 2.6.39, it's no longer possible to run such kernel on default systems. So with the old rationale gone, I've opened this bug to finally get rid of this. So yeah, new snapshot from the qutecom 3.x branch is the only possibility
dropped
