Description of problem:
lircd segfaults. Snippet from journalctl
systemd: Starting LIRC Infrared Signal Decoder...
systemd: Started LIRC Infrared Signal Decoder.
lircd: Cannot open /sys/class/rc
kernel: lircd: segfault at 0 ip 00007f821daa645a sp 00007fff1f5c0ae8
error 4 in libc-2.19.so[7f82
systemd: lircd.service: main process exited, code=killed, status=11/SEGV
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. urpmi lirc
2. systemctl start lircd
Steps to Reproduce:
I opened a ticket at http://sourceforge.net/p/lirc/tickets/39/
Suggested fix found at http://sourceforge.net/p/lirc/tickets/39/#cc0b
change "output = /var/run/lirc/lircd"
to "lircdfile = /var/run/lirc/lircd"
Hi, I'm the upstream maintainer.
Note that patches are available in the release_0.9.1b branch, should you want to release this before next upstream point release. The solution in comment #2 is not really the proper one although it kinda works.
PATCH, Triaged, UPSTREAMAssignee:
This bug was not fixed.
We have a patch from upstream (see comment #3), would be nice to integrate it.
5a2: lircd segfaults =>
lircd segfaults (upstream patch available)Whiteboard:
There is no 0.9.1b release still, and I see no such branch in the sourceforge git interface.
Indeed, upstream went directly to 0.9.2a. I had a look whether I could find the patches to backport, but my motivation was not high enough and I quickly gave up.
Other distros have patches though, so we might want to look there (I'm just not so interested as I don't have any infrared device to test the results).
*** Bug 16446 has been marked as a duplicate of this bug. ***
*** Bug 16541 has been marked as a duplicate of this bug. ***
Anssi, this bug seems to hit various users. Do you intend to fix it or must we look for another volunteer?
BTW, lirc-0.9.3 is out, fixing this.
And now 0.9.3a...
lircd segfaults (upstream patch available) =>
6_s1: lircd segfaults (upstream patch available)
Better yet, http://www.lirc.org/ [22-May-2016] lirc-0.9.4 released.
Actually, 0.9.4a as of 2016-06-28:
Assigning to all packagers collectively since Anssi isn't responding.
To packagers: this is a bug that requires updating lirc to a newer version.
6_s1: lircd segfaults (upstream patch available) =>
6_s1: lircd segfaults (upstream release is 0.9.4c-0.4)
6_s1: lircd segfaults (upstream release is 0.9.4c-0.4) =>
lircd segfaults (upstream release is 0.9.4d)Status comment:
Next upcoming release is 0.10.0. There are preview packages built for cauldron and mageia 6t at https://copr.fedorainfracloud.org/coprs/leamas/lirc-0.10-preview/ (no actual testing).
The preview packages work fine (without any manual configuration !) with the IR kernel module from TBS (v170330).
There was a little problem using the RPMs as an update for lirc 0.9.1a because lirc-libs-0.10.0 is not recognized as an upgrade for lib64lirc0-0.9.1a, but as a conflicting RPM.
Also the lirc-setup utility needed a couple of changes before it would start.
Forgot to mention that I also tried downloading and building the source RPM on my mga6 RC installation without problems
(In reply to Arne Spiegelhauer from comment #16)
> There was a little problem using the RPMs as an update for lirc 0.9.1a
> because lirc-libs-0.10.0 is not recognized as an upgrade for
> lib64lirc0-0.9.1a, but as a conflicting RPM.
This should be fixable using a spec file Obsoletes: or Provides: I'll happily accept a patch for this, but it needs testing I cannot do.
Patches goes to http://sf.net/p/lirc, as an issue or a message to the mailing list.
There is now a rc2, with untested fixes to the two issues above.
Note that although package more or less works, it does not comply to the Mageia packaging guidelines. In particular, the library name is wrong and does not allow multilib parallel installations.
lirc 0.10.0 is out, with mageia 6 rpm available at https://copr.fedorainfracloud.org/coprs/leamas/lirc-0.10-preview. The cauldron builds are broken on the COPR site due to COPR errors - until fixed rebuild the srpm which should be fine on cauldron.
See comment #19 about mageia packaging guidelines compliance