Arch Linux

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

@Robert Cameron Good idea, I rebuild lirc with your sed line in PKGBUILD and it works perfectly. Looking forward to see updated package soon.

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?

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?

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.

 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?

Is this ever going to be fixed? I'd like to remove that IgnorePkg line some time ;)

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!

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.

It would be nice to fix lirc package at last.

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.

Over a year and a half and not fixed? Maybe switching Linux distributions was a mistake.

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.

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?

@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?

@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

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?