For kernels > 2.6.22, the ivtv drivers are integrated into the kernel, however, there are still utilities, as well as ivtv-fb and the saa717x driver which are not yet included. Please add ivtv-1.0.0 as the default ivtv install, and suggest for kernel versions < 2.6.22 (checking the kernel version) that it be masked so that 0.10.5 is installed instead. http://ivtvdriver.org/index.php/Main_Page
*** Bug 186230 has been marked as a duplicate of this bug. ***
*** Bug 186231 has been marked as a duplicate of this bug. ***
Created attachment 126204 [details, diff] ebuild patch to 1.0.x Patch to the ebuild which changes: *removed many CONFIG checks, only 2 now *Removed check on kernel version before 2.6.22 *Removed ivtv module name *Now only check if we have a non 2.6.22 kernel and then error Greets Sander
I just had a thought.. Maybe the ebuild should only build the modules on request via a use flag? Many people will not need the saa717x and/or ivtv-fb module. But all will want the userland tools installed! Create a use flag for the saa717x module?
Created attachment 126218 [details, diff] ebuild patch to 1.0.x version 2 (In reply to comment #4) For this patch all of the changes before plus: * add use flag for saa717x module * move the build of the 2 modules into their own if use .. * add checks if a module build was requested if not only install userland * Some cleanup of the text in the ebuild
Wouldn't just be simpler to post the ebuild? :)
(In reply to comment #6) > Wouldn't just be simpler to post the ebuild? :) Simpler yes, but many times smaller than the complete ebuild ;-)
(In reply to comment #4) > I just had a thought.. Maybe the ebuild should only build the modules on > request via a use flag? Many people will not need the saa717x and/or ivtv-fb > module. But all will want the userland tools installed! Create a use flag for > the saa717x module? > As for Lirc (and many other apps depending on kernel drivers like HAL), this will lead emerge to stop emerging in this case: when an update (esync) include an update fo both kernel and ivtv, if kernel is emerged before ivtv, when ivtv is emerged the kernel is not build, and this will lead to failure in configure step (or worse, during pre-install() ). This problem have been discussed in bug #172458 and already happen in many other cases that have been closed "CANTFIX" in most cases ... I think adding one more possible case for this to happen is not a good idea. ATM, I am having troubles with: root@moon_gen_2:~# USE="ivtv" emerge -DaNuv world These are the packages that would be merged, in order: Calculating world dependencies / !!! Multiple versions within a single package slot have been !!! pulled into the dependency graph: ('ebuild', '/', 'sys-kernel/linux-headers-2.6.19.2-r2', 'merge') pulled in by ('ebuild', '/', 'media-video/mplayer-1.0.20070814', 'merge') ('installed', '/', 'sys-kernel/linux-headers-2.6.22-r2', 'nomerge') pulled in by ('ebuild', '/', 'sys-apps/sysvinit-2.86-r9', 'merge') ('installed', '/', 'sys-apps/hal-0.5.9.1-r1', 'nomerge') ('ebuild', '/', 'sys-libs/glibc-2.6.1', 'merge') Mplayer wants to downgrade Linux, but since my 'actual' 2.6.22-gentoo-r2 is deprecated, sys-kernel/gentoo-sources-2.6.22-r3 forces merge of newer kernel during actual merge. How long before 2.6.22 get stable ? Esynced this morning, I wonder how you can tell this bug is fixed as I encontour it more than 2 weeks after close ...
Created attachment 128161 [details] /tmp/ivtv.txt I call a bug fixed when the working ebuild is in portage, and replicated on ALL mirrors.
Created attachment 128162 [details] /tmp/emerge--info Please re-open. Good luck.
Open a new bug next time, since this one is closed. Also, don't use the IVTV use flag on MPlayer. It will try to forcibly downgrade your linux-headers.
A new bug that will be marked dup of bugs #186230 and #186230 that are dup of this one for good reaons ? No way; I am having bug #186230; and since it has been marked dup of this, I comment here, in "the main branch". I have been reproached too many time by Jakub to create dups, and here, it IS the case. I shall not create a new bug, but eventually ask 186230 to be reopened and unmarked dup. But if I do so, Jakub will tell me once more that they are dups, and I would agree.
(In reply to comment #12) > A new bug that will be marked dup of bugs #186230 and #186230 that are dup of > this one for good reaons ? > > No way; I am having bug #186230; and since it has been marked dup of this, I > comment here, in "the main branch". I have been reproached too many time by > Jakub to create dups, and here, it IS the case. I shall not create a new bug, > but eventually ask 186230 to be reopened and unmarked dup. But if I do so, > Jakub will tell me once more that they are dups, and I would agree. > Personal issues with Jakub aside, bug 186230 is invalid. IVTV works on on the kernels in the tree up to and including 2.6.22. MythTV pulls in IVTV, because *some* combination of IVTV plus kernel is a stable path. The IVTV ebuild does a proper job of checking to see which kernel you are using, and that's not the task of MythTV. So, I don't see what the problem is, though I might be misunderstanding what you are asking for.
I am asking REOPEN because the ebuild that was in Porrtage this morning does not satisfy me: activating the ivtv USE flag prevents emerge to work properly.
(In reply to comment #14) > I am asking REOPEN because the ebuild that was in Porrtage this morning does > not satisfy me: activating the ivtv USE flag prevents emerge to work properly. > See comment #11.
