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 Antonio Rojas (arojas) - Sunday, 13 February 2022, 07:18 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 27
Private No

Details

Description:
The lirc package does no longer ship the devinput driver. According to the upstream NEWS file (http://lirc.sourceforge.net/lirc.org/html/NEWS.txt), 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

Closed by  Antonio Rojas (arojas)
Sunday, 13 February 2022, 07:18 GMT
Reason for closing:  Fixed
Additional comments about closing:  lirc 0.10.1-11
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' configure.ac
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' configure.ac

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])
oldcflags="$CFLAGS"
export CFLAGS=-Werror
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#include <unistd.h>
#include <grp.h>
]], [[
gid_t groups[32]; int ngroups; const char* user = "root";
getgrouplist(user, 1, groups, &ngroups);
]])],[
AC_MSG_RESULT(gid_t)
AC_DEFINE(GETGROUPS_T,[gid_t])
],[
AC_MSG_RESULT(int)
AC_DEFINE(GETGROUPS_T,[gid_t])
]
)
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 (https://aur.archlinux.org/packages/lirc-devinput/) 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 https://pkgbuild.com/~eschwartz/repo/x86_64/lirc-1%3A0.10.1-6.1-x86_64.pkg.tar.zst

Does this fix things for you?

should fix all 3 issues mentioned here.

PKGBUILD used: https://paste.xinu.at/MQKCjDh/

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?
Comment by S (sierratango) - Saturday, 11 September 2021, 21:50 GMT
@Eli Schwartz, can you please assign the bug report to another developer who is more active to get the fix packaged in the Arch repo?
Comment by John (graysky) - Saturday, 12 February 2022, 13:32 GMT
@Eli Schwartz - I tried your PKGBUILD posted on 13-Sep-2020 but found that it failed to build. Can you give a whirl? Python 3.10 related?

EDIT: I had a look at how fedora is building[1], it seems they have a patch for this (0007-database.py-Handle-new-PyYAML-interface.patch) as well as a few others that apply cleanly:
0001-Replace-the-obsolete-get_event_loop-with-get_running.patch
0002-lirc-setup-Fix-crash-on-start-on-missing-lirc.config.patch
0006-python-pkg-Don-t-use-deprecated-time.clock-RHBZ-1718.patch

1. https://koji.fedoraproject.org/koji/buildinfo?buildID=1896237
Comment by John (graysky) - Saturday, 12 February 2022, 14:12 GMT
I got it working using Fedora's patches and Eli's PKGBUILD from 13-Sep-2021. Please see: https://github.com/graysky2/lirc

Any comments on suitability to replace current one?

Loading...