Summary: | lirc-0.7.2 emerge fails, lirc_i2c.c: I2C_ALGO_BIT undeclared | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daan van den Berg <d.m.j.vandenberg> |
Component: | Current packages | Assignee: | Heinrich Wendel (RETIRED) <lanius> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | shansan |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
2.6.14 kernel config
patch to compile lirc_i2c.c against 2.6.14 failed patch output pre-patched kcompat.h file for those having issues using the previous patch patch that hopefully does apply ebuild with conditional haup patching |
Description
Daan van den Berg
2005-11-03 07:51:16 UTC
created an attachment with kernel config Created attachment 72018 [details]
2.6.14 kernel config
Created attachment 72093 [details, diff]
patch to compile lirc_i2c.c against 2.6.14
This patch works for me
but not for me... or is it a kernel patch? well, it just gets really frustrating, it even blocks an emerge -u world... eh, no it's not a kernel patch, it's a patch agains lirc-0.7.2. Of course you have to patch your lirc ebuild as well. ... src_unpack() { unpack ${A} cd ${S} epatch ${FILESDIR}/lirc-0.7.2_2.6.14.patch #epatch ${FILESDIR}/lirc-0.7.0-xbox.patch.bz2 ... I'm having the same issue as Daan seems to be in getting the patch to apply. ami# cat /usr/local/portage-homebrew/app-misc/lirc/lirc-0.7.2-r1.ebuild <snip> src_unpack() { unpack ${A} cd ${S} #epatch ${FILESDIR}/lirc-0.7.0-xbox.patch.bz2 epatch ${FILESDIR}/lirc-0.7.2_2.6.14.patch </snip> ami# cat /usr/local/portage-homebrew/app-misc/lirc/files/lirc-0.7.2_2.6.14.patch --- drivers/kcompat.h 2005-11-04 11:17:11.000000000 +0100 +++ drivers/kcompat.h 2005-11-04 11:16:06.000000000 +0100 @@ -162,6 +162,7 @@ #define MODULE_DEVICE_TABLE(x,y) #endif +#include <linux/interrupt.h> #ifndef IRQ_RETVAL typedef void irqreturn_t; #define IRQ_NONE @@ -226,4 +226,9 @@ #endif +#ifndef I2C_ALGO_BIT +# define I2C_ALGO_BIT 0 +#endif + #endif /* _KCOMPAT_H */ ami temp # emerge --info Portage 2.0.53_rc7 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo x86_64) ================================================================= System uname: 2.6.14-gentoo x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.12.0_pre9 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict unsermake" GENTOO_MIRRORS="http://prometheus.cs.wmich.edu/gentoo http://mirror.mcs.anl.gov/pub/gentoo/ http://gentoo.mirrors.pair.com/ http://mirror.datapipe.net/gentoo http://mirrors.acm.cs.rpi.edu/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage-homebrew" SYNC="rsync://10.0.0.1/gentoo-portage" USE="amd64 X alsa arts artswrappersuid avi bitmap-fonts cairo cdr clock-screen crypt divx4linux dvd dvdr dvdread emboss encode fam firefox foomaticdb fortran gif gtk gtk2 imlib insecure-savers jpeg kde kdeenablefinal key-screen lirc lzw lzw-tiff mad mouse moznocompose moznoirc moznomail mozvg mp3 mpeg ncurses nls nptl nptlonly nvidia opengl pam pdflib perl png python qt quicktime readline sdl search-screen spell sqlite ssl symlink tcpd thebes tiff transcode truetype-fonts type1-fonts udev usb userlocales xine xml2 xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS Follows will be my patch.out file Created attachment 72295 [details]
failed patch output
Created attachment 72297 [details]
pre-patched kcompat.h file for those having issues using the previous patch
I took to manually patching the drivers/kcompat.h file (edit it, copy to a safe
location, start a non-patch-applying build, wait till its finished unpacking;
hit CTRL-Z; copy the patched version over to the build dir; then fg to resume
build) and it built cleanly.
Not sure how to make a patch file; so I've just attached my kcompat.h file
Created attachment 72312 [details, diff]
patch that hopefully does apply
yeah, you're right, the original patch doesn't apply. Try this one.
(In reply to comment #9) > Created an attachment (id=72312) [edit] > patch that hopefully does apply > > yeah, you're right, the original patch doesn't apply. Try this one. Works for me on amd64; same emerge --info as before. Well, still no use... Same error message with the new patch. I'm a n00b when it comes to creating patches, so please don't expect me to do such things myself, I really can't (and besides, I don't have time for it). Thanks for all the patches and support, but I'm thinking about giving up (unless someone can convince me not to ;) ) Well, at least I found something. Scrolled through the lirc_i2c.c file (didn't understand much, to be honest) and found the following lines: static int ir_attach(struct i2c_adapter *adap, int addr, unsigned short flags, int kind) { struct IR *ir; client_template.adapter = adap; client_template.addr = addr; if (NULL == (ir = kmalloc(sizeof(struct IR),GFP_KERNEL))) return -ENOMEM; memcpy(&ir->l,&lirc_template,sizeof(struct lirc_plugin)); memcpy(&ir->c,&client_template,sizeof(struct i2c_client)); ir->c.adapter = adap; ir->c.addr = addr; i2c_set_clientdata(&ir->c, ir); ir->l.data = ir; ir->l.minor = minor; ir->l.sample_rate = 10; ir->nextkey = -1; switch(addr) { case 0x64: strcpy(ir->c.name,"Pixelview IR"); ir->l.code_length = 8; ir->l.add_to_buf=add_to_buf_pixelview; break; case 0x4b: strcpy(ir->c.name,"PV951 IR"); ir->l.code_length = 32; ir->l.add_to_buf=add_to_buf_pv951; break; case 0x71: /* The PVR150 IR receiver uses the same protocol as other Hauppauge cards, but the data flow is different, so we need to deal with it by its own. */ strcpy(ir->c.name,"Hauppauge IR (PVR150)"); ir->l.code_length = 13; ir->l.add_to_buf=add_to_buf_haup_pvr150; break; case 0x6b: strcpy(ir->c.name,"Adaptec IR"); ir->l.code_length = 32; ir->l.add_to_buf=add_to_buf_adap; break; case 0x18: case 0x1a: if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848)) { strcpy(ir->c.name,"Hauppauge IR"); ir->l.code_length = 13; ir->l.add_to_buf=add_to_buf_haup; } else { strcpy(ir->c.name,"Leadtek IR"); ir->l.code_length = 8; ir->l.add_to_buf=add_to_buf_pvr2000; } break; case 0x30: strcpy(ir->c.name,"KNC ONE IR"); ir->l.code_length = 8; ir->l.add_to_buf=add_to_buf_knc1; break; case 0x21: case 0x23: strcpy(ir->c.name,"TV-Box IR"); ir->l.code_length = 8; ir->l.add_to_buf=add_to_buf_pcf8574; ir->bits = flags & 0xff; ir->flag = (flags >> 8) & 0xff; break; default: /* shouldn't happen */ printk("lirc_i2c: Huh? unknown i2c address (0x%02x)?\n",addr); kfree(ir); return -1; } printk("lirc_i2c: chip found @ 0x%02x (%s)\n",addr,ir->c.name); /* register device */ i2c_attach_client(&ir->c); ir->l.minor = lirc_register_plugin(&ir->l); i2c_use_client(&ir->c); return 0; } As I have a Hauppauge PVR150, could it be that lirc_i2c.c tries to use the wrong device? There's seperate lines for the PVR150, but how to reach those? No, the problem is not in lirc_i2c.c . I've got a pvr500 (which is 2 pvr150's in one, with an internal pci-pci bridge) and had exactly the same error messages as you have. I resolved them by applying my patch. So I guess you either have to to figure out how to apply a patch, or wait until the lirc-ebuild gets updated. I don't know what exactly happened, or what I did, but suddenly it worked. I think it had to do by first commenting the LIRC_OPTS line in /etc/make.conf, emerging lirc and after that uncommenting the LIRC_OPTS line again and re-emerging lirc. Don't know if it could be like this but for me it worked all of a sudden... Thanks anyway and I will mark this one as solved. again, it is SOLVED (In reply to comment #15) > again, it is SOLVED Uh, solved implies that the problem won't be experianced by other users anymore; since there hasn't been a rev-bump to the portage version to either incorporate Rene's patch, or similar; others will still encounter the problem. Granted they'll find a solution but thats besides the point. Whatever. At any rate, I did a local test to see if Daan's solution did work, and it seems to. Trying to merge (an unpatched) lirc with my LIRC_OPTS line in make.conf fails as previously noted but commenting it out the build executes fine. whoops... didn't know about that. thanks for the info! Well, I think the workaround doesn't work after all... It was the --with-driver=serial option that worked somehow, but the --with-driver=hauppauge option DOES NOT. Guess that means to reopen the bug? yes, I think you should reopen it. It does compile without --with-driver=hauppauge, but then it doesn't compile the i2c driver, so your hauppauge remote doesn't work. Seems like this is a specific 2.6.14 kernel problem. I downgraded my kernel to 2.6.13-r5, and lirc compiled without problems, even with the LIRC_OPTS="--with-driver=hauppauge" option. Seems like downgrading is the only option here... (In reply to comment #20) > Seems like this is a specific 2.6.14 kernel problem. I downgraded my kernel to > 2.6.13-r5, and lirc compiled without problems, even with the > LIRC_OPTS="--with-driver=hauppauge" option. Seems like downgrading is the only > option here... > > The patch that Rene posted in comment *does* work, atleast for me. It both allows lirc to compile cleanly, and I get a positive response with my remote, testing with `irw`. You (Daan) mentioned the new patch gave you an error, what was it? Alternately, you can use the (pre patched) kcompat.h file I provided earlier. > The patch that Rene posted in comment *does* work, atleast for me. It both > allows lirc to compile cleanly, and I get a positive response with my remote, > testing with `irw`. > You (Daan) mentioned the new patch gave you an error, what was it? Alternately, > you can use the (pre patched) kcompat.h file I provided earlier. The error the new patch gave me was exactly the same as before. I really don't know how to apply the pre patched kcompat.h file, despite your explanation in your post (kinda n00b...) I have downgraded my kernel now to 2.6.13-r5, and now lirc compiles without any problem, I even get pos response with my remote with 'irw'. The only problem left is that MythTV doesn't work as expected (mythfilldatabase etc), but that's beyond the scope of this thread. Created attachment 72519 [details] ebuild with conditional haup patching (In reply to comment #22) > > The patch that Rene posted in comment *does* work, atleast for me. It both > > allows lirc to compile cleanly, and I get a positive response with my remote, > > testing with `irw`. > > You (Daan) mentioned the new patch gave you an error, what was it? > Alternately, > > you can use the (pre patched) kcompat.h file I provided earlier. > > The error the new patch gave me was exactly the same as before. I really don't > know how to apply the pre patched kcompat.h file, despite your explanation in > your post (kinda n00b...) I have downgraded my kernel now to 2.6.13-r5, and now > lirc compiles without any problem, I even get pos response with my remote > with 'irw'. The only problem left is that MythTV doesn't work as expected > (mythfilldatabase etc), but that's beyond the scope of this thread. Such is the problem when you've got too many bugs and not enough developers, the `true solution` to this is as simple as rev-bumping the ebuild to apply Rene's patch; which is why I've gone and made an updated ebuild file. The actions are quite hackish, I couldn't figure out how to read the in-ebuild copy of LIRC_OPTS so I create a var called MY_LIRC_OPTS via some grepping and sed of /etc/make.conf (which means this wont work if you set LIRC_OPTS via command line). Unfortunately I don't have the time to do this right; and even this much took me far longer than I'd planned. Daan, you'll want to take a look at Gentoo-wiki's guide to using an overlay, which'll describe how to properly use this ebuild: http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds *** This bug has been marked as a duplicate of 111820 *** |