Hi, Am Donnerstag, den 10.01.2008, 21:23 +0200 schrieb Axel Thimm: > Hi, > > On Thu, Jan 10, 2008 at 02:03:55AM +0100, hermann pitton wrote: > > Am Donnerstag, den 10.01.2008, 01:13 +0200 schrieb Axel Thimm: > > > On Wed, Jan 09, 2008 at 11:42:19PM +0100, hermann pitton wrote: > > > > > > video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by > > > > > > videobuf_core) > > > > > > video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by > > > > > > videobuf_core) > > > > > > > > Guess this is the root of the problem. Axel's modules might fail to > > > > eliminate it. > > > > > > > > Mauro has converted the old single videobuf.ko to different types to be > > > > more flexible. Looks like you have an upgrade to the new types without > > > > that the old videobuf.ko is removed from your /lib/modules.../media > > > > stuff. Try to remove/delete it manually and "depmod -a". > > > > > > is there a way to somehow blacklist videobuf.ko w/o having to remove > > > it? The reason is that packagewise this belongs to the kernel rpm > > > which is managed by the upstream vendor (e.g. Red Hat, Fedora) and I > > > wouldn't want to nuke it - it would return anyway with the next kernel > > > update. > > > > > > Instead maybe some dummy alias or some remapping could be made to > > > effectively remove it from module-utils' radar w/o actually removing > > > the file? That would be much cleaner from a packaging POV. > > > > > > Thanks! > > > > here it is de facto gone, if not anymore in the next kernel release. > > > > What you do in between is up to you. > > > > If you like to stay in sync as close as possible, of course v4l-dvb > > counts and not the delayed kernel stuff. > > Yes, I understand that - but I'm interested in providing recent > v4l/dvb for users of for example 2.6.18 kernels as well, as found in > RHEL5/CentOS5/SL5. This allows users or even OEMs to build multimedia > systems on stable enterprise platforms. Yes, accepted, but we also need some testers left ;) > It all works quite well as there are mechanisms to override the > kernel's modules - only when they are renamed like in this case one > needs to take special care. That was what I was asking about. :) Renaming to something out of radar is quite safe, preferably if unloaded previously. Cheers, Hermann _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
