The Isenkram
-system provide a practical and easy way to figure out which
-packages support the hardware in a given machine. The command line
-tool isenkram-lookup 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 pcscd 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 cheese if
-cheese is currently missing. This already work just fine.
-
-
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.
-
-
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.
-
-
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
-recipe on how to add such meta-information in a blog post last
-December. If you have a hardware related package in Debian, please
-announce the relevant hardware IDs using AppStream.
-
-
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.
-
-
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 /lib/udev/rules.d/70-udev-acl.rules
-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.
-
-
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
-/lib/udev/rules.d/60-nqc.rules file now look like this:
-
-
-SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0694", ATTR{idProduct}=="0001", \
- SYMLINK+="rcx-%k", TAG+="uaccess"
-
-
-
The key part is the 'TAG+="uaccess"' at the end. 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
-70-uaccess.rules). Perhaps a lintian check should be created
-to detect this?
-
-
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
-/lib/udev/rules.d/70-udev-acl.rules. If it is, I guess the
-indirect method is the preferred way. Michael
-asked for more
-documentation from the systemd project and I hope it will make
-this clearer. For now I use the generic classes when they exist and
-is already handled by 70-uaccess.rules, and add the tag
-directly if no such class exist.
-
-
To learn more about the isenkram system, please check out
-my
-blog posts tagged isenkram.
-
-
To help out making life for LEGO constructors in Debian easier,
-please join us on our IRC channel
-#debian-lego and join
-the Debian
-LEGO team in the Alioth project we created yesterday. A mailing
-list is not yet created, but we are working on it. :)
-
-
As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
-
![[foto av billettautomat]](http://people.skolelinux.org/pere/blog/images/2016-11-29-ruter-win2000pro.jpeg)
