Red Hat Bugzilla – Bug 442248
Add patches necessary for gnome-lirc-properties
Last modified: 2008-06-10 17:37:43 EDT
contains two patches which are necessary to get gnome-lirc-properties working
The patches have been submitted upstream:
but without much feedback.
Both patches seem sane to me, and the resume switch for irrecord is another
option, so shouldn't cause problems with existing applications.
And an additional patch for include support in lirc.conf, used by
gnome-lirc-properties as well:
Created attachment 302325 [details]
Patch against CVS.
0001-* needed updating.
Regarding the "include" patch - wouldn't a lirc.conf.d directory from where all
*.conf would be loaded in alphabetical order (in the C locale) be a better
option than the include directive? That way new config snippets could be just
dropped there and the main config file could stay unmodified or wouldn't even
have to exist. Of course if the include directive supported wildcards,
lircd.conf.d could be implemented with it (eg. httpd.conf, ld.so.conf style).
Apart from that detail, the patches sound sane to me. A clear upstream buy-in
would be very much welcome though, I'd rather not maintain non-upstream patches
myself in the long term. Of course, more lirc co-maintainers are welcome in
case you're willing to maintain these patches if needed (or lirc otherwise) in
I talked to Mario, the Ubuntu lirc maintainer, about the include patch. It was
I'll rework the patch to fix the problems Christoph mentioned.
Updated patch posted. It changes the syntax for include as well, for which
gnome-lirc-properties would need to be updated.
(In reply to comment #3)
> Regarding the "include" patch - wouldn't a lirc.conf.d directory from where all
> *.conf would be loaded in alphabetical order (in the C locale) be a better
> option than the include directive? That way new config snippets could be just
> dropped there and the main config file could stay unmodified or wouldn't even
> have to exist. Of course if the include directive supported wildcards,
> lircd.conf.d could be implemented with it (eg. httpd.conf, ld.so.conf style).
The patch has been accepted upstream. I snatched it from the upstream CVS, and
updated the patch in the patch.
> Apart from that detail, the patches sound sane to me. A clear upstream buy-in
> would be very much welcome though, I'd rather not maintain non-upstream patches
> myself in the long term. Of course, more lirc co-maintainers are welcome in
> case you're willing to maintain these patches if needed (or lirc otherwise) in
> the future.
I'm not that hot on maintaining lirc, but I'd be happy to look at any problems
with the patches I'm providing.
Created attachment 305060 [details]
Updated patch with upstream include support.
Created attachment 305125 [details]
Minus init files changes from bug 442341
Personally, I prefer patch attachments as patches, not patches that generate
patches, those are too hard to review without actually applying them, and
whether or not to apply them is one of the things to be considered when
reviewing them... :)
Anyhow, I've gone ahead and patched in the upstream include support, but not the
other bits that aren't upstream, as I've not looked at them all that closely
The other 2 patches are similar to what was posted upstream. The first one
needed a shoehorn to get in, but that's about it.
Created attachment 305285 [details]
Updated for current sources.
Created attachment 305286 [details]
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Any news on those patches?
Just committed to the lirc devel branch. Would definitely like to see them get
merged upstream, so please do ping Christoph. I'll chime in upstream too, if
The patches aren't needed anymore, so we have all the patches we need for
gnome-lirc-properties, just need the init/sysconfig changes in now.