+Title: Isenkram, Appstream and udev make life as a LEGO builder easier
+Tags: english, debian, isenkram
+Date: 2016-10-07 09:50
+
+<p><a href="http://packages.qa.debian.org/isenkram">The Isenkram
+system</a> provide a practical and easy way to figure out which
+packages support the hardware in a given machine. The command line
+tool <tt>isenkram-lookup</tt> and the tasksel options provide a
+convenient way to list and install packages relevant for the current
+hardware during system installation, both user space packages and
+firmware packages. The GUI background daemon on the other hand provide
+a pop-up proposing to install packages when a new dongle is inserted
+while using the computer. For example, if you plug in a smart card
+reader, the system will ask if you want to install <tt>pcscd</tt> if
+that package isn't already installed, and if you plug in a USB video
+camera the system will ask if you want to install <tt>cheese</tt> if
+cheese is currently missing. This already work just fine.</p>
+
+<p>But Isenkram depend on a database mapping from hardware IDs to
+package names. When I started no such database existed in Debian, so
+I made my own data set and included it with the isenkram package and
+made isenkram fetch the latest version of this database from git using
+http. This way the isenkram users would get updated package proposals
+as soon as I learned more about hardware related packages.</p>
+
+<p>The hardware is identified using modalias strings. The modalias
+design is from the Linux kernel where most hardware descriptors are
+made available as a strings that can be matched using filename style
+globbing. It handle USB, PCI, DMI and a lot of other hardware related
+identifiers.</p>
+
+<p>The downside to the Isenkram specific database is that there is no
+information about relevant distribution / Debian version, making
+isenkram propose obsolete packages too. But along came AppStream, a
+cross distribution mechanism to store and collect metadata about
+software packages. When I heard about the proposal, I contacted the
+people involved and suggested to add a hardware matching rule using
+modalias strings in the specification, to be able to use AppStream for
+mapping hardware to packages. This idea was accepted and AppStream is
+now a great way for a package to announce the hardware it support in a
+distribution neutral way. I wrote
+<a href="http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html">a
+recipe on how to add such meta-information</a> in a blog post last
+December. If you have a hardware related package in Debian, please
+announce the relevant hardware IDs using AppStream.</p>
+
+<p>In Debian, almost all packages that can talk to a LEGO Mindestorms
+RCX or NXT unit, announce this support using AppStream. The effect is
+that when you insert such LEGO robot controller into your Debian
+machine, Isenkram will propose to install the packages needed to get
+it working. The intention is that this should allow the local user to
+start programming his robot controller right away without having to
+guess what packages to use or which permissions to fix.</p>
+
+<p>But when I sat down with my son the other day to program our NXT
+unit using his Debian Stretch computer, I discovered something
+annoying. The local console user (ie my son) did not get access to
+the USB device for programming the unit. This used to work, but no
+longer in Jessie and Stretch. After some investigation and asking
+around on #debian-devel, I discovered that this was because udev had
+changed the mechanism used to grant access to local devices. The
+ConsoleKit mechanism from <tt>/lib/udev/rules.d/70-udev-acl.rules</tt>
+no longer applied, because LDAP users no longer was added to the
+plugdev group during login. Michael Biebl told me that this method
+was obsolete and the new method used ACLs instead. This was good
+news, as the plugdev mechanism is a mess when using a remote user
+directory like LDAP. Using ACLs would make sure a user lost device
+access when she logged out, even if the user left behind a background
+process which would retain the plugdev membership with the ConsoleKit
+setup. Armed with this knowledge I moved on to fix the access problem
+for the LEGO Mindstorms related packages.</p>
+
+<p>The new system uses a udev tag, 'uaccess'. It can either be
+applied directly for a device, or is applied in
+/lib/udev/rules.d/70-uaccess.rules for classes of devices. As the
+LEGO Mindstorms udev rules did not have a class, I decided to add the
+tag directly in the udev rules files included in the packages. Here
+is one example. For the nqc C compiler for the RCX, the
+<tt>/lib/udev/rules.d/60-nqc.rules</tt> file now look like this:
+
+<p><pre>
+SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0694", ATTR{idProduct}=="0001", \
+ SYMLINK+="rcx-%k", TAG+="uaccess"
+</pre></p>
+
+<p>I suspect all packages using plugdev in their /lib/udev/rules.d/
+files should be changed to use this tag (either directly or indirectly
+via <tt>70-uaccess.rules</tt>). Perhaps a lintian check should be
+created to detect this?</p>
+
+<p>I've been unable to find good documentation on the uaccess feature.
+It is unclear to me if the uaccess tag is an internal implementation
+detail like the udev-acl tag used by
+<tt>/lib/udev/rules.d/70-udev-acl.rules</tt>. If it is, I guess the
+indirect method is the preferred way. Michael
+<a href="https://github.com/systemd/systemd/issues/4288">asked for more
+documentation from the systemd project</a> and I hope it will make
+this clearer. For now I use the generic classes when they exist and
+is already handled by <tt>70-uaccess.rules</tt>, and add the tag
+directly if no such class exist.</p>
+
+<p>To learn more about the isenkram system, please check out
+<a href="http://people.skolelinux.org/pere/blog/tags/isenkram/">my
+blog posts tagged isenkram</a>.</p>
+
+<p>To help out making life for LEGO constructors in Debian easier,
+please join us on our IRC channel
+<a href="irc://irc.debian.org/%23debian-lego">#debian-lego</a> and join
+the <a href="https://alioth.debian.org/projects/debian-lego/">Debian
+LEGO team</a> in the Alioth project we created yesterday. A mailing
+list is not yet created, but we are working on it. :)</p>
+
+<p>As usual, if you use Bitcoin and want to show your support of my
+activities, please send Bitcoin donations to my address
+<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&label=PetterReinholdtsenBlog">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
projects / homepage.git / commitdiff