This is an update request for lirc on mga1. Updated oackages in mga1 core/updates_testing: lirc-0.9.0-1.1.mga1 lib64lirc0-0.9.0-1.1.mga1 lib64lirc-devel-0.9.0-1.1.mga1 dkms-lirc-0.9.0-1.1.mga1 Advisory: ============= LIRC package shipped with Mageia 1 is incompatible with the LIRC kernel drivers on 64-bit systems. This update upgrades lirc to version 0.9.0, fixing the compatibility. Additionally, the dkms-lirc package didn't work with the Mageia kernel version. This has now been fixed as well, and drivers that already exist in the Mageia main kernel have been removed from the package. Note that the dkms-lirc is only needed by the users of the following LIRC drivers on Mageia 1: - lirc_atiusb - lirc_i2c - lirc_wpc8769l. Other drivers area already included in the main kernel package. ============= Testing information: ============== The old dkms-lirc package doesn't work with the Mageia kernel (a build failure). The new one should build fine. This is easily testable. The 64-bit incompatibility means that devices using LIRC kernel modules do not work with the old 'lirc' package, and button presses are simply not seen. Testing this therefore requires a 64-bit system with an IR receiver handled by a LIRC kernel module (e.g. lirc_serial).
Thankyou Anssi, I will test
CC: (none) => eeeemail
It is not available in updates_testing yet Anssi, could you check on it please. Thanks.
Builds got rejected by: Submission errors, aborting: - lirc-0.9.0-1.1.mga1.x86_64: - missing-lsb-keyword Required-Start in /etc/rc.d/init.d/lircd - missing-lsb-keyword Required-Stop in /etc/rc.d/init.d/lircd - missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/lircd - missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/lircmd - lirc-0.9.0-1.1.mga1.i586: - missing-lsb-keyword Required-Start in /etc/rc.d/init.d/lircd - missing-lsb-keyword Required-Stop in /etc/rc.d/init.d/lircd - missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/lircd - missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/lircmd
CC: (none) => tmb
missing-lsb-keyword check was lifted, I resubmitted lirc and it is now in core/updates_testing.
So far testing i586. I plugged in the usb receiver and trying to test, no luck so far but I noticed this in syslog when its plugged in.. udevd-work[16103]: kernel-provided name 'lirc0' and NAME= 'lirc/0' disagree, please use SYMLINK+= or change the kernel to provide the proper name There are two devices in /dev one lirc0 and one lirc/0 cat /dev/lirc0 or lirc/0 says Device or resource busy and irw shows no output. It could be that I need to reboot after upgrading lirc so I will try that (I need to anyway) and report back with anything else I find.
Did it work before with the same /etc/sysconfig/lircd and /etc/lirc/lircd.conf? i.e. is a configuration issue ruled out?
lirc has never worked in MGA1. lirc-remotes appears to be missing, no /etc/lirc/lircd.conf is being created x86_64: Sep 10 12:04:24 mega kernel: usb 5-1: new full speed USB device using uhci_hcd and address 4 Sep 10 12:04:24 mega kernel: usb 5-1: New USB device found, idVendor=1784, idProduct=0001 Sep 10 12:04:24 mega kernel: usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Sep 10 12:04:24 mega kernel: usb 5-1: Product: eHome Infrared Transceiver Sep 10 12:04:24 mega kernel: usb 5-1: Manufacturer: Topseed Sep 10 12:04:24 mega kernel: usb 5-1: SerialNumber: TS000C3h Sep 10 12:04:24 mega kernel: Registered IR keymap rc-rc6-mce Sep 10 12:04:24 mega kernel: input: Media Center Ed. eHome Infrared Remote Transceiver (1784:0001) as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.0/rc/rc1/input8 Sep 10 12:04:24 mega kernel: rc1: Media Center Ed. eHome Infrared Remote Transceiver (1784:0001) as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.0/rc/rc1 Sep 10 12:04:24 mega kernel: rc rc1: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 Sep 10 12:04:24 mega kernel: mceusb 5-1:1.0: Registered Topseed eHome Infrared Transceiver on usb5:4 Sep 10 12:04:24 mega mtp-probe: checking bus 5, device 4: "/sys/devices/pci0000:00/0000:00:1a.2/usb5/5-1" Sep 10 12:04:24 mega mtp-probe: bus: 5, device: 4 was not an MTP device Sep 10 12:04:24 mega udevd-work[22973]: kernel-provided name 'lirc0' and NAME= 'lirc/0' disagree, please use SYMLINK+= or change the kernel to provide the proper name ps aux | grep lirc root 27195 0.0 0.0 36264 548 ? Ss 12:26 0:00 lircd --device=/dev/lirc/0 Some buttons appear to work with the desktop, such as power button and arrow buttons and volume buttons. Also enter and clear do enter and ^[[3~ in a terminal and irw. Copied /etc/lirc/lircd.conf from http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=blob_plain;f=remotes/mceusb/lircd.conf.mceusb;h=8fd5536e6f97175e70579d49a6f57e7076ccddf1;hb=HEAD restarted lircd It doesn't seem to be linking the button presses to their values in lircd.conf I have a hauppage mce RC6 remote. Not sure what other info I can find. Let me know if theres something else I can check.
I can test this on x86_64 I have a mythtv system currently running with my own lircd package. Unfortunately I will not get the chance to test it until Sunday or Monday
CC: (none) => derekjenn
claire, I'm not familiar with mceusb usage with LIRC, but you might need to create a lircd.conf yourself with irrecord. BTW, an x86_64 mga1 user has privately confirmed to me that the updated package made lirc_serial work again.
I'll try that later Anssi, the lircd.conf I used was from lirc.org git repository though for that remote.
$ irrecord -d /dev/lirc/0 .lircd.conf irrecord - application for recording IR-codes for usage with lirc Copyright (C) 1998,1999 Christoph Bartelmus(lirc@bartelmus.de) irrecord: could not get file information for /dev/lirc/0 irrecord: default_init(): No such file or directory irrecord: could not init hardware (lircd running ? --> close it, check permissions) $ su -c "service lircd stop" - Password: Stopping Linux Infrared Remote Control daemon: [ OK ] $ irrecord -d /dev/lirc/0 .lircd.conf irrecord - application for recording IR-codes for usage with lirc Copyright (C) 1998,1999 Christoph Bartelmus(lirc@bartelmus.de) irrecord: could not get file information for /dev/lirc/0 irrecord: default_init(): No such file or directory irrecord: could not init hardware (lircd running ? --> close it, check permissions) $ ll /dev/lirc/0 crw------- 1 root root 251, 0 Sep 10 16:44 /dev/lirc/0
$ su -c "service lircd start" - Password: Starting Linux Infrared Remote Control daemon: [ OK ] $ ll /dev/lirc/0 crw------- 1 root root 251, 0 Sep 10 16:44 /dev/lirc/0 uname -r 2.6.38.8-desktop-5.mga Could it be a problem with using the new kernel in updates_testing?
Doing a bit of reading it seems lirc has changed the way it works recently. Testing i586: irw - gives nothing # ir-keytable -t -s rc1 Testing events. Please, press CTRL-C to abort. 1315766533.749990: event MSC: scancode = 800f0401 1315766533.868990: event MSC: scancode = 800f0401 1315766534.453035: event MSC: scancode = 800f0402 1315766534.572039: event MSC: scancode = 800f0402 1315766535.067049: event MSC: scancode = 800f0403 1315766536.128105: event MSC: scancode = 800f0404 1315766536.477126: event MSC: scancode = 800f0405 1315766536.584121: event MSC: scancode = 800f0405 1315766536.978143: event MSC: scancode = 800f0406 ..etc It seems I'm having the same problem as colinjones in comment #13 here: http://forum.xbmc.org/showthread.php?s=4ef224a0103013a5612819e4634dd61a&t=101151&page=2 ir-keytable -v -p RC6 -w /etc/rc_keymaps/rc6_mce -s rc1 gives the result pasted to: http://pastebin.com/gn8UJTax If its the same thing then it appears there is a bug in ir-keytable (Source RPM: v4l-utils-0.8.3-1.mga1.src.rpm)
I have not started testing functionality of lirc yet, but I am seeing something that does not look right when installing the package. On using urpmi or rpmdrake to install lirc-0.9.0-1.1.mga1.x86_64 it does not update lib64lirc0 which remains lib64lirc0-0.8.7-1.mga1. I have to manually select lib64lirc0-0.9.0-1.1.mga1.x86_64 for updating. Shouldn't lib64lirc0 be at the same release level as lirc?
Yes it's true. I had updated mine through MageiaUpdate and lirc hadn't required liblirc0 which was still at 0.8.7, which might explain some of the problems. Retesting with it installed but it really ought to require its own lib's didn't it?
It doesn't appear to be any better. irw gives nothing cat /dev/input/event8 �â�mN�f�mNh* "��mN'��mN�� �mN� ��mN^�#��mNâ�#��mN�!��mN���"�mN��%�mN|D�(�mN�$�)�mN�`$�)�mNI$�*�mNÕ$�*�mN�7$�+�mN��$�,�mN��$�,�mN$�,�mN-� $�,�mN!$�-�mN��$�-�mNy$�-�mN.$�-�mNF�$�-�mN:W$�-�mN�$�-�mNh� ..etc As normal user $ ir-keytable Found /sys/class/rc/rc2/ (/dev/input/event8) with: Driver mceusb, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: RC-6 Extra capabilities: <access denied> As root # ir-keytable Found /sys/class/rc/rc2/ (/dev/input/event8) with: Driver mceusb, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: RC-6 Repeat delay = 500 ms, repeat period = 33 ms # ir-keytable -t -v -s rc2 Found device /sys/class/rc/rc2/ Input sysfs node is /sys/class/rc/rc2/input10/ Event sysfs node is /sys/class/rc/rc2/input10/event8/ Parsing uevent /sys/class/rc/rc2/input10/event8/uevent /sys/class/rc/rc2/input10/event8/uevent uevent MAJOR=13 /sys/class/rc/rc2/input10/event8/uevent uevent MINOR=72 /sys/class/rc/rc2/input10/event8/uevent uevent DEVNAME=input/event8 Parsing uevent /sys/class/rc/rc2/uevent /sys/class/rc/rc2/uevent uevent NAME=rc-rc6-mce /sys/class/rc/rc2/uevent uevent DRV_NAME=mceusb input device is /dev/input/event8 /sys/class/rc/rc2/protocols protocol rc-5 (disabled) /sys/class/rc/rc2/protocols protocol nec (disabled) /sys/class/rc/rc2/protocols protocol rc-6 (enabled) /sys/class/rc/rc2/protocols protocol jvc (disabled) /sys/class/rc/rc2/protocols protocol sony (disabled) /sys/class/rc/rc2/protocols protocol lirc (disabled) Opening /dev/input/event8 Input Protocol version: 0x00010001 Testing events. Please, press CTRL-C to abort. 1315815264.286634: event MSC: scancode = 800f0422 1315815264.392640: event MSC: scancode = 800f0422 1315815265.899713: event MSC: scancode = 800f041f 1315815266.654754: event MSC: scancode = 800f040d 1315815266.762275: event MSC: scancode = 800f040d 1315815267.887811: event MSC: scancode = 800f0402 ..etc
Finally managed to get a chance to test lirc lirc-0.9.0-1.1.mga1 tested on x86_64 All works OK Test rig was running mythtv which was previously running with my own compiled version of lirc-0.9.0 kernel is 2.6.38.8-desktop-5.mga lirc module is lirc_serial with a home brew receiver
Claire, Are you using the correct keytable? You wrote "$ ir-keytable Found /sys/class/rc/rc2/ (/dev/input/event8) with: Driver mceusb, table rc-rc6-mce" From what I read at http://www.mythtv.org/wiki/LIRC#Set_up the driver and the keytable should match. There is an mceusb keytable in /usr/share/lirc-remotes. Have you tried that one?
These are the modules automatically loaded Derek. Also: [root@linux ~]# ls /usr/share/lirc-remotes ls: cannot access /usr/share/lirc-remotes: No such file or directory Mageia does not appear to have an lirc-remotes package but the lircd.conf was taken from the git repository ir-keytable uses keymap files stored in /etc/rc_keymaps/ - which one it uses is determined in /etc/rc_maps.cfg. It has driver/table/file pairings. One of which is * rc-rc6-mce rc6_mce # ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event8) with: Driver mceusb, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: RC-6 Repeat delay = 500 ms, repeat period = 33 ms ]# lsmod | grep ir ir_lirc_codec 12770 3 lirc_dev 19346 1 ir_lirc_codec ir_sony_decoder 12493 0 ir_jvc_decoder 12490 0 ir_rc6_decoder 12490 0 ir_rc5_decoder 12490 0 ir_nec_decoder 12490 0 rc_core 25697 9 ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,rc_rc6_mce,ir_nec_decoder,mceusb # lsmod | grep mce rc_rc6_mce 12454 0 mceusb 18254 0 rc_core 25697 9 ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,rc_rc6_mce,ir_nec_decoder,mceusb usbcore 167270 7 mceusb,btusb,uhci_hcd,ohci_hcd,ehci_hcd,usbhid The driver is chosen by the kernel as mceusb, using the rc-rc6-mce table for the remote which uses the rc6_mce keymap file in /etc/rc_keymaps. If I understand this correctly, lirc is an extra layer which should then translate the standard keymappings (0x800f0416 KEY_PLAY etc) to the standard Play, Right, OK etc most applications still require. irw though which shows the output of /var/run/lirc/lircd socket shows nothing I think this is because the keymap table is not being properly loaded so no translation from the raw gobbledegook is being made. I'm not sure if that makes it a problem for lirc or whether it should be filed against v4l-utils. Lirc requires ir-keytable to work correctly, which it doesn't appear to be doing by not loading key mappings above 0x7fffffff. What do you think Anssi?
# ir-keytable -r scancode 0x7fffffff = KEY_PLAYPAUSE (0xa4) Enabled protocols: RC-6
Theres also this .. udevd-work[8033]: kernel-provided name 'lirc0' and NAME= 'lirc/0' disagree, please use SYMLINK+= or change the kernel to provide the proper name
Testing this on x86_64.. # ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event6) with: Driver mceusb, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: RC-6 Repeat delay = 500 ms, repeat period = 33 ms # ir-keytable -r scancode 0x800f0400 = KEY_NUMERIC_0 (0x200) scancode 0x800f0401 = KEY_NUMERIC_1 (0x201) scancode 0x800f0402 = KEY_NUMERIC_2 (0x202) scancode 0x800f0403 = KEY_NUMERIC_3 (0x203) scancode 0x800f0404 = KEY_NUMERIC_4 (0x204) scancode 0x800f0405 = KEY_NUMERIC_5 (0x205) scancode 0x800f0406 = KEY_NUMERIC_6 (0x206) scancode 0x800f0407 = KEY_NUMERIC_7 (0x207) scancode 0x800f0408 = KEY_NUMERIC_8 (0x208) scancode 0x800f0409 = KEY_NUMERIC_9 (0x209) scancode 0x800f040a = KEY_DELETE (0x6f) scancode 0x800f040b = KEY_ENTER (0x1c) scancode 0x800f040c = KEY_POWER (0x74) scancode 0x800f040d = KEY_LEFTMETA (0x7d) scancode 0x800f040e = KEY_MUTE (0x71) scancode 0x800f040f = KEY_INFO (0x166) scancode 0x800f0410 = KEY_VOLUMEUP (0x73) scancode 0x800f0411 = KEY_VOLUMEDOWN (0x72) scancode 0x800f0412 = KEY_CHANNELUP (0x192) scancode 0x800f0413 = KEY_CHANNELDOWN (0x193) scancode 0x800f0414 = KEY_FASTFORWARD (0xd0) scancode 0x800f0415 = KEY_REWIND (0xa8) scancode 0x800f0416 = KEY_PLAY (0xcf) scancode 0x800f0417 = KEY_RECORD (0xa7) scancode 0x800f0418 = KEY_PAUSE (0x77) scancode 0x800f0419 = KEY_STOP (0x80) scancode 0x800f041a = KEY_NEXT (0x197) scancode 0x800f041b = KEY_PREVIOUS (0x19c) scancode 0x800f041c = KEY_NUMERIC_POUND (0x20b) scancode 0x800f041d = KEY_NUMERIC_STAR (0x20a) scancode 0x800f041e = KEY_UP (0x67) scancode 0x800f041f = KEY_DOWN (0x6c) scancode 0x800f0420 = KEY_LEFT (0x69) scancode 0x800f0421 = KEY_RIGHT (0x6a) scancode 0x800f0422 = KEY_OK (0x160) scancode 0x800f0423 = KEY_EXIT (0xae) scancode 0x800f0424 = KEY_DVD (0x185) scancode 0x800f0425 = KEY_TUNER (0x182) scancode 0x800f0426 = KEY_EPG (0x16d) scancode 0x800f0427 = KEY_ZOOM (0x174) scancode 0x800f043a = KEY_BRIGHTNESSUP (0xe1) scancode 0x800f0446 = KEY_TV (0x179) scancode 0x800f0447 = KEY_AUDIO (0x188) scancode 0x800f0448 = KEY_PVR (0x16e) scancode 0x800f0449 = KEY_CAMERA (0xd4) scancode 0x800f044a = KEY_VIDEO (0x189) scancode 0x800f044c = KEY_LANGUAGE (0x170) scancode 0x800f044d = KEY_TITLE (0x171) scancode 0x800f044e = KEY_PRINT (0xd2) scancode 0x800f0450 = KEY_RADIO (0x181) scancode 0x800f045a = KEY_SUBTITLE (0x172) scancode 0x800f045b = KEY_RED (0x18e) scancode 0x800f045c = KEY_GREEN (0x18f) scancode 0x800f045d = KEY_YELLOW (0x190) scancode 0x800f045e = KEY_BLUE (0x191) scancode 0x800f0465 = KEY_POWER2 (0x164) scancode 0x800f046e = KEY_PLAYPAUSE (0xa4) scancode 0x800f046f = KEY_MEDIA (0xe2) scancode 0x800f0480 = KEY_BRIGHTNESSDOWN (0xe0) scancode 0x800f0481 = KEY_PLAYPAUSE (0xa4) Enabled protocols: RC-6 So may be able to get a bit further.
(In reply to comment #19) > Mageia does not appear to have an lirc-remotes package but the lircd.conf was > taken from the git repository > Good point. I had lirc-remotes-0.8.3-0.20080704.4mdv2010.0 installed from my previous mandriva. Should we raise another bug for lirc-remotes?
IMHO lirc-remotes should be part of lirc, a require or suggest, if not part of the lirc package. lirc doesn't seem to be working i586 but it seems to be down to ir-keytable. I suppose it will depend which remote you use as for some the codes are below 0x7fffffff. irw still shows nothing on my x86_64 which, given that ir-keytable has properly loaded points at a possible misconfiguration or bug. I will keep trying with it. Perhaps Anssi wouldn't mind having another look at this? I'll reassign back to Anssi. Please assign to QA again when you've had a look Anssi and let us know what you think.
Assignee: qa-bugs => anssi.hannula
Forgot to add QA to CC.
CC: (none) => qa-bugs
(In reply to comment #14) > Shouldn't lib64lirc0 be at the same release level as lirc? Well, I'm not sure if a requirement should be added. They are not incompatible with one another so there are no adverse effects. (In reply to comment #21) > Theres also this .. > udevd-work[8033]: kernel-provided name 'lirc0' and NAME= 'lirc/0' disagree, > please use SYMLINK+= or change the kernel to provide the proper name This is indeed a bug, probably should open another report for this. I don't think thie update should be delayed for a fix to this, as it is not a regression and apparently doesn't cause issues. (In reply to comment #22) > # ir-keytable > Found /sys/class/rc/rc0/ (/dev/input/event6) with: > Driver mceusb, table rc-rc6-mce > Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC > Enabled protocols: RC-6 > Repeat delay = 500 ms, repeat period = 33 ms I guess this is somewhat offtopic, but here goes: Your problem is the above. The RC-6 protocol in-kernel decoder is selected, causing the kernel to decode the keypresses according to the v4l-utils rc-keytable file. The kernel then creates an event device (/dev/input/event6 as per above) which receives the events (and can be tested using "evtest /dev/input/event6"). They are automatically used by X server, however the X protocol has a limited amount of key codes and therefore applications do not see all the buttons. To use the device with LIRC, you need to either a) Use an mceusb-specific lircd.conf, and switch from the kernel RC6 decoder to the LIRC passthrough protocol with "ir-keytable --protocol=LIRC" so that the lircd can receive the events through /dev/lirc0, instead of them being passed to the eventX device. Not sure if something should do this automatically somehow, maybe open a bugreport if you think so. (I wonder if both LIRC and RC-6/whatever could be enabled by default, dunno why it is not already like that). or b) Use the "devinput" LIRC driver which takes the pre-decoded /dev/input/eventX as input instead of /dev/lirc0 (needs a devinput-specific lircd.conf). There might be differences in behavior between a) and b) (especially the repeat handling behaviour might be better with option a). (In reply to comment #23) > Should we raise another bug for lirc-remotes? Feel free to open one and assign it to me. I'll take a look on whether we should provide one then. (In reply to comment #24) > IMHO lirc-remotes should be part of lirc, a require or suggest, if not part of > the lirc package. Well, as lirc-remotes is not required for operation, it is simply a collection of sample config files, I don't think it belongs as a requirement. What could probably be done is what Fedora does, i.e. add a notification on top of default lircd.conf: # Populated config files can be found in the lirc-remotes sub-package # or at http://lirc.sourceforge.net/remotes/ > I'll reassign back to Anssi. Please assign to QA again when you've had a look > Anssi and let us know what you think. I think the update should be OK'd as is as it introduces no regressions and fixes a severe bug on 64-bit systems. For any other issues separate bug reports should be opened (it is very difficult to follow them here), and another update can be made if the issues are deemed real and fixes are needed for mga1. I'd also be OK with it if you think we should delay the update until everything has been investigated (even though I might not agree with it).
Assignee: anssi.hannula => qa-bugs
Bug 2758 has been raised for lirc-remotes. I am happy for the lirc update to be validated.
I haven't forgotten this, I'll have another go at it today :)
I am unable to test this i586. It just isn't working for me. I have tried both a and b above and still get nothing from irw. evtest is not packaged for mageia but cat /dev/input/event8 does show something is going on. It could easily be some configuration problem even tho the picture of the remote is on SF along with the conf, albeit mine has an extra row of buttons at the bottom (red, green, yellow, blue and teletext). http://lirc.sourceforge.net/remotes/mceusb/PVR_500_MCE.jpg I'm not sure where to go from here. Derek are you able to test i586? I will ask on the mageia-discuss mailing list for i586 testers also.
(In reply to comment #29) > > I'm not sure where to go from here. Derek are you able to test i586? > > I will ask on the mageia-discuss mailing list for i586 testers also. Sorry no. The only computer I have with a serial port for my IR receiver is running 64 bit
This still needs i586 testing.
I'm going to validate this one, we are short of people with supported hardware to check it i586. Sorry it has taken so long, Anssi thankyou for your assistance. At least we have been thorough, if not completely successful! Advisory: ============= LIRC package shipped with Mageia 1 is incompatible with the LIRC kernel drivers on 64-bit systems. This update upgrades lirc to version 0.9.0, fixing the compatibility. Additionally, the dkms-lirc package didn't work with the Mageia kernel version. This has now been fixed as well, and drivers that already exist in the Mageia main kernel have been removed from the package. Note that the dkms-lirc is only needed by the users of the following LIRC drivers on Mageia 1: - lirc_atiusb - lirc_i2c - lirc_wpc8769l. Other drivers area already included in the main kernel package. ============= SRPM: lirc-0.9.0-1.1.mga1.src.rpm Could sysadmin please push from core/updates_testing to core/updates. Thankyou!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Spelling correction: "Other drivers are" in last line of advisory.
update pushed.
Status: NEW => RESOLVEDCC: (none) => dmorganecResolution: (none) => FIXED