When the lircd 0.8.6 is started, it writes lircd: could not assign address to socket lircd: No such file or directory I've searched the internet and it is caused by the new infrastructure of lircd creating the socket file in /var/run/lirc. The daemon also wants to use the /var/run/lirc/lircd.pid as default (overriden by init.d script). The workaround is to create /var/run/lirc, but I think better would be to use the default - /var/run/lirc/.
Created attachment 205234 [details] lirc-0.8.6-r1 ebuild Fixed missing /var/run/lirc problem. Added lirc.m4 to /usr/share/aclocal.
Created attachment 205236 [details] files/lircd-0.8.6: new init.d file
Anyway, the lirc-0.8.6 brings incompatibility with older applications - it moves /dev/lircd to /var/run/lirc/lircd. I don't know how to workaround this...
Created attachment 205238 [details] files/lircd-0.8.6: updated init.d file It was rather easy, the lircd `-o /dev/lircd` parameter is now used for backwards compatibility
Created attachment 205239 [details] files/lircd-0.8.6: updated init.d file Use /dev/${SVCNAME} as lircd's output file (same trick as for PIDFILE).
(In reply to comment #5) > Created an attachment (id=205239) [edit] > files/lircd-0.8.6: updated init.d file > > Use /dev/${SVCNAME} as lircd's output file (same trick as for PIDFILE). > Works fine, tested with "lirc-0.8.6-r1 ebuild" for device hauppauge Thank you!
*** Bug 286217 has been marked as a duplicate of this bug. ***
/dev is really not the place for a socket. Shouldn't the "older applications" be updated to find the socket at /var/run/lirc/lircd rather than Gentoo overriding a decision by the LIRC developers to correct a mistake?
(In reply to comment #8) > /dev is really not the place for a socket. Shouldn't the "older applications" > be updated to find the socket at /var/run/lirc/lircd rather than Gentoo > overriding a decision by the LIRC developers to correct a mistake? No problem for new applications, but what about the old ones? kdelirc in kde-3.5.10 for example...
(In reply to comment #9) > (In reply to comment #8) > > /dev is really not the place for a socket. Shouldn't the "older applications" > > be updated to find the socket at /var/run/lirc/lircd rather than Gentoo > > overriding a decision by the LIRC developers to correct a mistake? > > No problem for new applications, but what about the old ones? kdelirc in > kde-3.5.10 for example... For each unstable (~arch) ebuild for each application that depends on lirc: 1. Make the ebuild depend on >=app-misc/lirc-0.8.6. 2a. If the application hard-codes the path, add some processing to update the hard-coded path in the source code: sed -e 's|/dev/lircd|/var/run/lirc/lircd|g' 2b. If the application uses a configuration file to specify the location of the socket, update the config file similarly. 3. Revbump the ebuild to ensure users get the fix. For each stable ebuild for each application that depends on lirc: 1. Make the ebuild depend on <app-misc/lirc-0.8.6. When lirc-0.8.6 gets stabilized, then all ebuilds for applications depending on lirc, stable or not, should be of the first case.
(In reply to comment #10) That is a good idea. Actually there are applications that use liblirc_client from the lirc package; those assume the default socket path (pulseaudio, mplayer and vlc for example) - my ebuild (the init.d script) will break them. Only the applications with hardcoded/configurable paths (kdelirc) need to be changed. I've counted 33 apps in the portage tree that depend on app-misc/lirc so each have to be checked separately.
For a first fix I will move the socket location...in the long run we should change it but I do not have the time to do that.
(In reply to comment #12) > For a first fix I will move the socket location...in the long run we should > change it but I do not have the time to do that. Using the lirc's default socket location is the first step. Keeping it on the old place breaks apps using liblirc_client, keeping it on the new place breaks apps using hard-coded path. Second step is to fix all applications not using liblirc_client to at least make them depending on "<app-misc/lirc-0.8.6". This needs to be coordinated with the other package maintainers I think - I'm not a Gentoo dev to do so, but I can help creating patches (`sed` lines) and ebuilds for some apps at least.
As a shortcut, perhaps we could patch lircd to create a symbolic link at /dev/lircd to wherever it creates its socket (/var/run/lirc/lircd by default). That would "fix" both liblirc_client programs and hard-coded-path programs easily.
Created attachment 205692 [details] Updated lirc-0.8.6-r1 ebuild Applies patch to support (optional) symbolic link file.
Created attachment 205693 [details] files/lircd-0.8.6: updated init.d file Passes option to lirc to create symbolic link file
Created attachment 205694 [details, diff] files/lirc-0.8.6-symlink.patch: symbolic link support Patch that adds support for automatic symbolic link
(In reply to comment #14) > As a shortcut, perhaps we could patch lircd to create a symbolic link at > /dev/lircd to wherever it creates its socket (/var/run/lirc/lircd by default). > That would "fix" both liblirc_client programs and hard-coded-path programs > easily. Something like the attached patch? ;-)
(In reply to comment #18) > Something like the attached patch? ;-) Or even less intrusive would be to have the init.d script create the symlink. After I made my suggestion, I realized there's really no reason the symlink needs to be created by lircd.
Created attachment 205863 [details] Updated lirc-0.8.6-r1 ebuild 1. Without the patching 2. Keeps /var/run/lirc dir 3. No installation of lirc.m4 (back to the original ebuild; it was useless anyway - better is to use the liblirc_client library)
Created attachment 205864 [details] files/lircd-0.8.6: updated init.d file The symbolic link (/dev/lircd) is now created/deleted from the init.d script
Comment on attachment 205694 [details, diff] files/lirc-0.8.6-symlink.patch: symbolic link support No patching needed, init.d script will do the job
I guess I've presented a lot of implemented _working_ options, so now it is Gentoo devs turn - please do whatever you want to do :-)
Sorry for all the caused trouble, it should be fixed now. Thanks for all the valuable input.
*** Bug 287440 has been marked as a duplicate of this bug. ***
