← Back to team overview

mythbuntu-bugs team mailing list archive

[Bug 698007] Re: lirc init script can create circular symlinks

 

The second patch included here is compatible with the patch in bug
69799, if the other patch is applied first.  I can combine them into a
single patch if that is preferred.

It will take me some time to re-test against natty.  Is this likely to
be included in natty if I do this soon?  If so, I'll raise the priority
of this on my todo list.

I have not been in communication with the Debian developers, as I've
only tested Ubuntu packages.  I can file upstream with Debian as well,
but I'd like to take the time to test against Debian first, and adjust
patches if necessary.

Do you have any comments regarding the magic symlinking, and if it would
be safe to only do so if the socket matches /var/run/lirc/lircd\d+  and
then symlink from /dev/$(basename $REMOTE_SOCKET)

-- 
You received this bug notification because you are a member of Mythbuntu
Bug Team, which is subscribed to lirc in Ubuntu.
https://bugs.launchpad.net/bugs/698007

Title:
  lirc init script can create circular symlinks

Status in “lirc” package in Ubuntu:
  New

Bug description:
  Binary package hint: lirc

  This is related to bug 697999 and specifically my need to work around
  that bug.

  If, in /etc/lirc/hardware.conf, you set REMOTE_SOCKET to /dev/lircd1
  and transmitter_socket to /dev/lircd, then the lirc init script will
  create a circular symlink loop between /dev/lircd and /dev/lircd1.
  The script tests if OLD_SOCKET != REMOTE_SOCKET, but it should also
  make sure that OLD_SOCKET != TRANSMITTER_SOCKET  Additionally, before
  removing ${OLD_SOCKET}1 the script should do the same checks, which it
  currently does none.

  A patch for this solution is attached.

  My preference would actually to be to use the new socket locations in
  /var/run/lircd, however, then the the order I create those sockets is
  irrelevant, as the magical symlinking always symlinks /dev/lircd to
  the remote and /dev/lircd1 to the transmitter, which is backwards from
  how I need it to be.  I'm not actually sure what the best fix is here.
  Perhaps it could just test if the socket is /var/run/lirc/lircd\d+ and
  if it is, then just symlink to /dev/$(basename $REMOTE_SOCKET)  If
  this is an acceptable solution, I can probably write up a patch for
  this behavior if necessary.  However, there may be other cases the
  current behavior is designed to correct for.  If bug 697999 gets
  fixed, then this problem will no longer affect me.



References