use correct path for tbtacl in udev rules

Bug #1761757 reported by Colin Ian King
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
thunderbolt-tools (Ubuntu)
Fix Released
High
Colin Ian King

Bug Description

./thunderbolt-tools_0.9.3-1_amd64/lib/udev/rules.d/tbtacl.rules:
# Thunderbolt udev rules for ACL (device auto approval)
SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="add" ATTR{authorized}=="0" RUN+="@UDEV_BIN_DIR@/tbtacl add $devpath"
SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="change" ATTR{authorized}!="0" RUN+="@UDEV_BIN_DIR@/tbtacl change $devpath"

should changed to fix up @UDEV_BIN_DIR@ to be:

SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="add" ATTR{authorized}=="0" RUN+="/lib/udev/tbtacl add $devpath"
SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="change" ATTR{authorized}!="0" RUN+="/lib/udev/tbtacl change $devpath"

Changed in thunderbolt-tools (Ubuntu):
status: New → In Progress
importance: Undecided → High
assignee: nobody → Colin Ian King (colin-king)
Changed in thunderbolt-tools (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunderbolt-tools - 0.9.3-2

---------------
thunderbolt-tools (0.9.3-2) unstable; urgency=medium

  * Set UDEV_BIN_DIR to /lib/udev (LP: #1761757)

 -- Colin King <email address hidden> Fri, 6 Apr 2018 14:52:11 +0100

Changed in thunderbolt-tools (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Seth Arnold (seth-arnold) wrote :

I think the real fix is easier... This still has two copies of the file:

sarnold@hunt:/tmp/bolt$ ar x thunderbolt-tools_0.9.3-2_amd64.deb
sarnold@hunt:/tmp/bolt$ tar tf data.tar.xz
./
./lib/
./lib/udev/
./lib/udev/rules.d/
./lib/udev/rules.d/60-tbtacl.rules
./lib/udev/rules.d/60-tbtxdomain.rules
./lib/udev/rules.d/tbtacl.rules
./lib/udev/tbtacl
./lib/udev/tbtacl-write
./lib/udev/tbtxdomain
./usr/
./usr/bin/
./usr/bin/tbtadm
./usr/share/
./usr/share/bash-completion/
./usr/share/bash-completion/completions/
./usr/share/bash-completion/completions/tbtadm
./usr/share/doc/
./usr/share/doc/thunderbolt-tools/
./usr/share/doc/thunderbolt-tools/changelog.Debian.gz
./usr/share/doc/thunderbolt-tools/copyright
./usr/share/doc/thunderbolt-user-space/
./usr/share/doc/thunderbolt-user-space/copyright
./usr/share/man/
./usr/share/man/man1/
./usr/share/man/man1/tbtadm.1.gz
sarnold@hunt:/tmp/bolt$ tar xf data.tar.xz
sarnold@hunt:/tmp/bolt$ cat lib/udev/rules.d/*tbtacl*
# Thunderbolt udev rules for ACL (device auto approval)
SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="add" ATTR{authorized}=="0" RUN+="/lib/udev/tbtacl add $devpath"
SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="change" ATTR{authorized}!="0" RUN+="/lib/udev/tbtacl change $devpath"
# Thunderbolt udev rules for ACL (device auto approval)
SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="add" ATTR{authorized}=="0" RUN+="/lib/udev/tbtacl add $devpath"
SUBSYSTEM=="thunderbolt" ENV{DEVTYPE}=="thunderbolt_device" ACTION=="change" ATTR{authorized}!="0" RUN+="/lib/udev/tbtacl change $devpath"

I think the better solution is to delete this line from debian/rules:

        cp tbtacl/tbtacl.rules.in tbtacl/tbtacl.rules

Thanks

Revision history for this message
Yehezkel Bernat (yehezkelshb) wrote :

I'm not sure I understand what's going on here, so I'll take the risk that I'm describing the obvious:

@UDEV_BIN_DIR@ is a cmake parameter that is replaced by cmake with the path it reads from pkgconfig. See here:
https://github.com/intel/thunderbolt-software-user-space/blob/master/CMakeLists.txt#L10
If this is the wrong location:
1. UDEV_BIN_DIR can be set manually while running cmake (or using ccmake/cmake-gui).
2. If there is a better way to detect the distro-specific correct location for udev dirs, I'd like to fix it upstream.

Anyway, copy of the original .rules.in files instead of using the resulted .rules file seems strange to me.

Revision history for this message
Colin Ian King (colin-king) wrote :

No need to worry about this, it was a mistake I made in the debian packaging, it is now resolved.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.