Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#58238 - [lirc] Devinput driver missing

Attached to Project: Arch Linux
Opened by Stefan Rehm (srehm) - Sunday, 15 April 2018, 14:51 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 16 April 2018, 04:31 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 23
Private No


The lirc package does no longer ship the devinput driver. According to the upstream NEWS file (, the parameters to the configure script have changed in 0.10.0rc1. Apparently, it is now required to add --enable-devinput to the configure call. Also, uinput has been dropped, so the HAVE_UINPUT environment variable currently used in the PKGBUILD has no longer any effect.
Please update the call to 'configure' accordingly.

Additional info:
* package version: 1:0.10.1-1
This task depends upon

Comment by Robert Cameron (rpcameron) - Wednesday, 25 April 2018, 20:04 GMT
If uinput support is still desired for the package, it can be enabled with "--enable-uinput" in the configure line.

Also, certain packaged tools require 'python-setuptools' and 'python-yaml' to be present when building, otherwise lirc-setup and some affiliated files/tools won't be installed.

Also, the patch isn't terribly necessary, as it can be replaced by a single sed before the call to configure:

sed -i -e 's/GETGROUPS_T,\[int/GETGROUPS_T,\[gid_t/g'
Comment by YP (knedlyk) - Friday, 27 April 2018, 09:56 GMT
@Robert Cameron Good idea, I rebuild lirc with your sed line in PKGBUILD and it works perfectly. Looking forward to see updated package soon.
Comment by loqs (loqs) - Friday, 27 April 2018, 12:44 GMT
Also, the patch isn't terribly necessary, as it can be replaced by a single sed before the call to configure:

sed -i -e 's/GETGROUPS_T,\[int/GETGROUPS_T,\[gid_t/g'

so the test becomes
dnl AC_TYPE_GETGROUPS seems broken on recent MacOS, so:
AC_MSG_CHECKING([Figure out if getgrouplist() needs gid_t or int])
export CFLAGS=-Werror
#include <unistd.h>
#include <grp.h>
]], [[
gid_t groups[32]; int ngroups; const char* user = "root";
getgrouplist(user, 1, groups, &ngroups);
export CFLAGS="$oldcflags"

You have hardcoded the result to be gid_t when the configure test fails as the test is still broken.
What if it is built on a system where getgrouplist returns type int?
Comment by Robert Cameron (rpcameron) - Friday, 27 April 2018, 13:10 GMT
IIRC, when I first investigated the build error a couple of months ago, I remember reading that was particular to FreeBSD/OS X ... are there Arch packages being built for either of those OSes?

Pulling up `man 3 getgrouplist` returns:
int getgrouplist(const char *user, gid_t group,
gid_t *groups, int *ngroups);

So apparently with glibc, getgrouplist() will always take gid_t. Are there non-glibc targets that Arch packages target?
Comment by loqs (loqs) - Friday, 27 April 2018, 14:14 GMT
For the package targeting the repositories it would be glibc but then if you insist on using sed
you could just sed out from dnl AC_TYPE_GETGROUPS to export CFLAGS="$oldcflags" and replace with AC_TYPE_GETGROUPS.
That would avoid the configure script reporting a result of int but using gid_t and generate the correct result for systems which do not have a broken autoconf check.
Comment by Eli Schwartz (eschwartz) - Monday, 30 April 2018, 15:34 GMT
 FS#57792  When there's a pending upstream patch, I see no reason to use something fundamentally gross like sed in preference over an elegant patch. Your sed line isn't terribly necessary, :p fails to be easily readable, lacks technical correctness, and has the additional issue of not having smart autodetection when it no longer applies.

Can we not discuss irrelevant, offtopic bikeshedding about the *method* used to fix something totally unrelated to this bugreport?
Comment by Robin (lazlev) - Friday, 31 August 2018, 18:20 GMT
Is this ever going to be fixed? I'd like to remove that IgnorePkg line some time ;)
Comment by Andrew Whatson (flatwhatson) - Wednesday, 21 November 2018, 06:24 GMT
The priority of this bug (Low) is incorrect, the package is quite broken without the devinput driver. The ArchWiki LIRC QuickStart guide cannot be followed, even the LIRC documentation itself expects the devinput driver to be present.  FS#59505  has cropped up as a duplicate of this bug, because the devinput driver couldn't be loaded because it's not present in the package.

The solution is trivial: add "--enable-devinput" to the configure flags, confirmed in the ticket above.

This issue has sat unacknowledged for 6+ months. Please, for the love of dog, somebody fix this package!
Comment by Nick (DerHomp) - Wednesday, 21 November 2018, 07:37 GMT
I have to agree with Andrew.
Lirc is not usable for me without devinput and the solution is really simple.
Currently I build the package myself but it would be better if the fix could be implemented.
Comment by Darek (blablo) - Monday, 31 December 2018, 12:22 GMT
It would be nice to fix lirc package at last.
Comment by Bharath Ramesh (krosswindz) - Friday, 10 May 2019, 10:13 GMT
Any update on devinput its been over a year and there has been no fix for this. LIRC is unusable without devinput in my setup.
Comment by Robert Wiegand (bob_w) - Thursday, 02 January 2020, 21:57 GMT
Over a year and a half and not fixed? Maybe switching Linux distributions was a mistake.
Comment by Lubosz Sarnecki (lubosz) - Friday, 21 August 2020, 12:58 GMT
While there is a solution for this in the AUR ( it's a shame this package did not receive it's one line fix for 2+ years.

It gets more relevance these days since it's related to IoT.
Comment by Eli Schwartz (eschwartz) - Monday, 14 September 2020, 01:22 GMT
pacman -U

Does this fix things for you?

should fix all 3 issues mentioned here.


The yaml and gobject dependencies are explicitly documented upstream and I'm fairly confident they need to be added....

lukas, can you please look at this change?