[homepage.git] / blog / tags / isenkram / isenkram.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries tagged isenkram</title>
                <description>Entries tagged isenkram</description>
                <link>http://people.skolelinux.org/pere/blog/</link>

        
        <item>
                <title>Appstream just learned how to map hardware to packages too!</title>
                <link>http://people.skolelinux.org/pere/blog/Appstream_just_learned_how_to_map_hardware_to_packages_too_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Appstream_just_learned_how_to_map_hardware_to_packages_too_.html</guid>
                <pubDate>Fri, 23 Dec 2016 10:30:00 +0100</pubDate>
                <description>&lt;p&gt;I received a very nice Christmas present today.  As my regular
readers probably know, I have been working on the
&lt;a href=&quot;http://packages.qa.debian.org/isenkram&quot;&gt;the Isenkram
system&lt;/a&gt; for many years.  The goal of the Isenkram system is to make
it easier for users to figure out what to install to get a given piece
of hardware to work in Debian, and a key part of this system is a way
to map hardware to packages.  Isenkram have its own mapping database,
and also uses data provided by each package using the AppStream
metadata format.  And today,
&lt;a href=&quot;https://tracker.debian.org/pkg/appstream&quot;&gt;AppStream&lt;/a&gt; in
Debian learned to look up hardware the same way Isenkram is doing it,
ie using fnmatch():&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
% appstreamcli what-provides modalias \
  usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00
Identifier: pymissile [generic]
Name: pymissile
Summary: Control original Striker USB Missile Launcher
Package: pymissile
% appstreamcli what-provides modalias usb:v0694p0002d0000
Identifier: libnxt [generic]
Name: libnxt
Summary: utility library for talking to the LEGO Mindstorms NXT brick
Package: libnxt
---
Identifier: t2n [generic]
Name: t2n
Summary: Simple command-line tool for Lego NXT
Package: t2n
---
Identifier: python-nxt [generic]
Name: python-nxt
Summary: Python driver/interface/wrapper for the Lego Mindstorms NXT robot
Package: python-nxt
---
Identifier: nbc [generic]
Name: nbc
Summary: C compiler for LEGO Mindstorms NXT bricks
Package: nbc
%
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;A similar query can be done using the combined AppStream and
Isenkram databases using the isenkram-lookup tool:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
% isenkram-lookup usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00
pymissile
% isenkram-lookup usb:v0694p0002d0000
libnxt
nbc
python-nxt
t2n
%
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;If you want to make this system a success and help Debian users
make the most of the hardware they have, please
help&lt;a href=&quot;https://wiki.debian.org/AppStream/Guidelines&quot;&gt;add
AppStream metadata for your package following the guidelines&lt;/a&gt;
documented in the wiki.  So far only 11 packages provide such
information, among the several hundred hardware specific packages in
Debian. The Isenkram database on the other hand contain 101 packages,
mostly related to USB dongles.  Most of the packages with hardware
mapping in AppStream are LEGO Mindstorms related, because I have, as
part of my involvement in
&lt;a href=&quot;https://wiki.debian.org/LegoDesigners&quot;&gt;the Debian LEGO
team&lt;/a&gt; given priority to making sure LEGO users get proposed the
complete set of packages in Debian for that particular hardware.  The
team also got a nice Christmas present today.  The
&lt;a href=&quot;https://tracker.debian.org/pkg/nxt-firmware&quot;&gt;nxt-firmware
package&lt;/a&gt; made it into Debian.  With this package in place, it is
not possible to use the LEGO Mindstorms NXT unit with only free
software, as the nxt-firmware package contain the source and firmware
binaries for the NXT brick.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&amp;label=PetterReinholdtsenBlog&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Isenkram updated with a lot more hardware-package mappings</title>
                <link>http://people.skolelinux.org/pere/blog/Isenkram_updated_with_a_lot_more_hardware_package_mappings.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Isenkram_updated_with_a_lot_more_hardware_package_mappings.html</guid>
                <pubDate>Tue, 20 Dec 2016 11:55:00 +0100</pubDate>
                <description>&lt;p&gt;&lt;a href=&quot;http://packages.qa.debian.org/isenkram&quot;&gt;The Isenkram
system&lt;/a&gt; I wrote two years ago to make it easier in Debian to find
and install packages to get your hardware dongles to work, is still
going strong.  It is a system to look up the hardware present on or
connected to the current system, and map the hardware to Debian
packages.  It can either be done using the tools in isenkram-cli or
using the user space daemon in the isenkram package.  The latter will
notify you, when inserting new hardware, about what packages to
install to get the dongle working.  It will even provide a button to
click on to ask packagekit to install the packages.&lt;/p&gt;

&lt;p&gt;Here is an command line example from my Thinkpad laptop:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
% isenkram-lookup  
bluez
cheese
ethtool
fprintd
fprintd-demo
gkrellm-thinkbat
hdapsd
libpam-fprintd
pidgin-blinklight
thinkfan
tlp
tp-smapi-dkms
tp-smapi-source
tpb
%
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;It can also list the firware package providing firmware requested
by the load kernel modules, which in my case is an empty list because
I have all the firmware my machine need:

&lt;p&gt;&lt;pre&gt;
% /usr/sbin/isenkram-autoinstall-firmware -l
info: did not find any firmware files requested by loaded kernel modules.  exiting
%
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;The last few days I had a look at several of the around 250
packages in Debian with udev rules.  These seem like good candidates
to install when a given hardware dongle is inserted, and I found
several that should be proposed by isenkram.  I have not had time to
check all of them, but am happy to report that now there are 97
packages packages mapped to hardware by Isenkram.  11 of these
packages provide hardware mapping using AppStream, while the rest are
listed in the modaliases file provided in isenkram.&lt;/p&gt;

&lt;p&gt;These are the packages with hardware mappings at the moment.  The
&lt;strong&gt;marked packages&lt;/strong&gt; are also announcing their hardware
support using AppStream, for everyone to use:&lt;/p&gt;

&lt;p&gt;air-quality-sensor, alsa-firmware-loaders, argyll,
&lt;strong&gt;array-info&lt;/strong&gt;, avarice, avrdude, b43-fwcutter,
bit-babbler, bluez, bluez-firmware, &lt;strong&gt;brltty&lt;/strong&gt;,
&lt;strong&gt;broadcom-sta-dkms&lt;/strong&gt;, calibre, cgminer, cheese, colord,
&lt;strong&gt;colorhug-client&lt;/strong&gt;, dahdi-firmware-nonfree, dahdi-linux,
dfu-util, dolphin-emu, ekeyd, ethtool, firmware-ipw2x00, fprintd,
fprintd-demo, &lt;strong&gt;galileo&lt;/strong&gt;, gkrellm-thinkbat, gphoto2,
gpsbabel, gpsbabel-gui, gpsman, gpstrans, gqrx-sdr, gr-fcdproplus,
gr-osmosdr, gtkpod, hackrf, hdapsd, hdmi2usb-udev, hpijs-ppds, hplip,
ipw3945-source, ipw3945d, kde-config-tablet, kinect-audio-setup,
&lt;strong&gt;libnxt&lt;/strong&gt;, libpam-fprintd, &lt;strong&gt;lomoco&lt;/strong&gt;,
madwimax, minidisc-utils, mkgmap, msi-keyboard, mtkbabel,
&lt;strong&gt;nbc&lt;/strong&gt;, &lt;strong&gt;nqc&lt;/strong&gt;, nut-hal-drivers, ola,
open-vm-toolbox, open-vm-tools, openambit, pcgminer, pcmciautils,
pcscd, pidgin-blinklight, printer-driver-splix,
&lt;strong&gt;pymissile&lt;/strong&gt;, python-nxt, qlandkartegt,
qlandkartegt-garmin, rosegarden, rt2x00-source, sispmctl,
soapysdr-module-hackrf, solaar, squeak-plugins-scratch, sunxi-tools,
&lt;strong&gt;t2n&lt;/strong&gt;, thinkfan, thinkfinger-tools, tlp, tp-smapi-dkms,
tp-smapi-source, tpb, tucnak, uhd-host, usbmuxd, viking,
virtualbox-ose-guest-x11, w1retap, xawtv, xserver-xorg-input-vmmouse,
xserver-xorg-input-wacom, xserver-xorg-video-qxl,
xserver-xorg-video-vmware, yubikey-personalization and
zd1211-firmware&lt;/p&gt;

&lt;p&gt;If you know of other packages, please let me know with a wishlist
bug report against the isenkram-cli package, and ask the package
maintainer to
&lt;a href=&quot;https://wiki.debian.org/AppStream/Guidelines&quot;&gt;add AppStream
metadata according to the guidelines&lt;/a&gt; to provide the information
for everyone.  In time, I hope to get rid of the isenkram specific
hardware mapping and depend exclusively on AppStream.&lt;/p&gt;

&lt;p&gt;Note, the AppStream metadata for broadcom-sta-dkms is matching too
much hardware, and suggest that the package with with any ethernet
card.  See &lt;a href=&quot;http://bugs.debian.org/838735&quot;&gt;bug #838735&lt;/a&gt; for
the details.  I hope the maintainer find time to address it soon.  In
the mean time I provide an override in isenkram.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Isenkram, Appstream and udev make life as a LEGO builder easier</title>
                <link>http://people.skolelinux.org/pere/blog/Isenkram__Appstream_and_udev_make_life_as_a_LEGO_builder_easier.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Isenkram__Appstream_and_udev_make_life_as_a_LEGO_builder_easier.html</guid>
                <pubDate>Fri, 7 Oct 2016 09:50:00 +0200</pubDate>
                <description>&lt;p&gt;&lt;a href=&quot;http://packages.qa.debian.org/isenkram&quot;&gt;The Isenkram
system&lt;/a&gt; provide a practical and easy way to figure out which
packages support the hardware in a given machine.  The command line
tool &lt;tt&gt;isenkram-lookup&lt;/tt&gt; 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 &lt;tt&gt;pcscd&lt;/tt&gt; if
that package isn&#39;t already installed, and if you plug in a USB video
camera the system will ask if you want to install &lt;tt&gt;cheese&lt;/tt&gt; if
cheese is currently missing.  This already work just fine.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html&quot;&gt;a
recipe on how to add such meta-information&lt;/a&gt; in a blog post last
December.  If you have a hardware related package in Debian, please
announce the relevant hardware IDs using AppStream.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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 &lt;tt&gt;/lib/udev/rules.d/70-udev-acl.rules&lt;/tt&gt;
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.&lt;/p&gt;

&lt;p&gt;The new system uses a udev tag, &#39;uaccess&#39;.  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
&lt;tt&gt;/lib/udev/rules.d/60-nqc.rules&lt;/tt&gt; file now look like this:

&lt;p&gt;&lt;pre&gt;
SUBSYSTEM==&quot;usb&quot;, ACTION==&quot;add&quot;, ATTR{idVendor}==&quot;0694&quot;, ATTR{idProduct}==&quot;0001&quot;, \
    SYMLINK+=&quot;rcx-%k&quot;, TAG+=&quot;uaccess&quot;
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;The key part is the &#39;TAG+=&quot;uaccess&quot;&#39; 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
&lt;tt&gt;70-uaccess.rules&lt;/tt&gt;).  Perhaps a lintian check should be created
to detect this?&lt;/p&gt;

&lt;p&gt;I&#39;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
&lt;tt&gt;/lib/udev/rules.d/70-udev-acl.rules&lt;/tt&gt;.  If it is, I guess the
indirect method is the preferred way.  Michael
&lt;a href=&quot;https://github.com/systemd/systemd/issues/4288&quot;&gt;asked for more
documentation from the systemd project&lt;/a&gt; and I hope it will make
this clearer.  For now I use the generic classes when they exist and
is already handled by &lt;tt&gt;70-uaccess.rules&lt;/tt&gt;, and add the tag
directly if no such class exist.&lt;/p&gt;

&lt;p&gt;To learn more about the isenkram system, please check out
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/tags/isenkram/&quot;&gt;my
blog posts tagged isenkram&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;To help out making life for LEGO constructors in Debian easier,
please join us on our IRC channel
&lt;a href=&quot;irc://irc.debian.org/%23debian-lego&quot;&gt;#debian-lego&lt;/a&gt; and join
the &lt;a href=&quot;https://alioth.debian.org/projects/debian-lego/&quot;&gt;Debian
LEGO team&lt;/a&gt; in the Alioth project we created yesterday.  A mailing
list is not yet created, but we are working on it. :)&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&amp;label=PetterReinholdtsenBlog&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Isenkram with PackageKit support - new version 0.23 available in Debian unstable</title>
                <link>http://people.skolelinux.org/pere/blog/Isenkram_with_PackageKit_support___new_version_0_23_available_in_Debian_unstable.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Isenkram_with_PackageKit_support___new_version_0_23_available_in_Debian_unstable.html</guid>
                <pubDate>Wed, 25 May 2016 10:20:00 +0200</pubDate>
                <description>&lt;p&gt;&lt;a href=&quot;https://tracker.debian.org/pkg/isenkram&quot;&gt;The isenkram
system&lt;/a&gt; is a user-focused solution in Debian for handling hardware
related packages.  The idea is to have a database of mappings between
hardware and packages, and pop up a dialog suggesting for the user to
install the packages to use a given hardware dongle.  Some use cases
are when you insert a Yubikey, it proposes to install the software
needed to control it; when you insert a braille reader list it
proposes to install the packages needed to send text to the reader;
and when you insert a ColorHug screen calibrator it suggests to
install the driver for it.  The system work well, and even have a few
command line tools to install firmware packages and packages for the
hardware already in the machine (as opposed to hotpluggable hardware).&lt;/p&gt;

&lt;p&gt;The system was initially written using aptdaemon, because I found
good documentation and example code on how to use it.  But aptdaemon
is going away and is generally being replaced by
&lt;a href=&quot;http://www.freedesktop.org/software/PackageKit/&quot;&gt;PackageKit&lt;/a&gt;,
so Isenkram needed a rewrite.  And today, thanks to the great patch
from my college Sunil Mohan Adapa in the FreedomBox project, the
rewrite finally took place.  I&#39;ve just uploaded a new version of
Isenkram into Debian Unstable with the patch included, and the default
for the background daemon is now to use PackageKit.  To check it out,
install the &lt;tt&gt;isenkram&lt;/tt&gt; package and insert some hardware dongle
and see if it is recognised.&lt;/p&gt;

&lt;p&gt;If you want to know what kind of packages isenkram would propose for
the machine it is running on, you can check out the isenkram-lookup
program.  This is what it look like on a Thinkpad X230:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
% isenkram-lookup 
bluez
cheese
fprintd
fprintd-demo
gkrellm-thinkbat
hdapsd
libpam-fprintd
pidgin-blinklight
thinkfan
tleds
tp-smapi-dkms
tp-smapi-source
tpb
%p
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The hardware mappings come from several places.  The preferred way
is for packages to announce their hardware support using
&lt;a href=&quot;https://www.freedesktop.org/software/appstream/docs/&quot;&gt;the
cross distribution appstream system&lt;/a&gt;.
See
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/tags/isenkram/&quot;&gt;previous
blog posts about isenkram&lt;/a&gt; to learn how to do that.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Using appstream with isenkram to install hardware related packages in Debian</title>
                <link>http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html</guid>
                <pubDate>Sun, 20 Dec 2015 12:20:00 +0100</pubDate>
                <description>&lt;p&gt;Around three years ago, I created
&lt;a href=&quot;http://packages.qa.debian.org/isenkram&quot;&gt;the isenkram
system&lt;/a&gt; to get a more practical solution in Debian for handing
hardware related packages.  A GUI system in the isenkram package will
present a pop-up dialog when some hardware dongle supported by
relevant packages in Debian is inserted into the machine.  The same
lookup mechanism to detect packages is available as command line
tools in the isenkram-cli package.  In addition to mapping hardware,
it will also map kernel firmware files to packages and make it easy to
install needed firmware packages automatically.  The key for this
system to work is a good way to map hardware to packages, in other
words, allow packages to announce what hardware they will work
with.&lt;/p&gt;

&lt;p&gt;I started by providing data files in the isenkram source, and
adding code to download the latest version of these data files at run
time, to ensure every user had the most up to date mapping available.
I also added support for storing the mapping in the Packages file in
the apt repositories, but did not push this approach because while I
was trying to figure out how to best store hardware/package mappings,
&lt;a href=&quot;http://www.freedesktop.org/software/appstream/docs/&quot;&gt;the
appstream system&lt;/a&gt; was announced.  I got in touch and suggested to
add the hardware mapping into that data set to be able to use
appstream as a data source, and this was accepted at least for the
Debian version of appstream.&lt;/p&gt;

&lt;p&gt;A few days ago using appstream in Debian for this became possible,
and today I uploaded a new version 0.20 of isenkram adding support for
appstream as a data source for mapping hardware to packages.  The only
package so far using appstream to announce its hardware support is my
pymissile package.  I got help from Matthias Klumpp with figuring out
how do add the required
&lt;a href=&quot;https://appstream.debian.org/html/sid/main/metainfo/pymissile.html&quot;&gt;metadata
in pymissile&lt;/a&gt;.  I added a file debian/pymissile.metainfo.xml with
this content:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
&amp;lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&amp;gt;
&amp;lt;component&amp;gt;
  &amp;lt;id&amp;gt;pymissile&amp;lt;/id&amp;gt;
  &amp;lt;metadata_license&amp;gt;MIT&amp;lt;/metadata_license&amp;gt;
  &amp;lt;name&amp;gt;pymissile&amp;lt;/name&amp;gt;
  &amp;lt;summary&amp;gt;Control original Striker USB Missile Launcher&amp;lt;/summary&amp;gt;
  &amp;lt;description&amp;gt;
    &amp;lt;p&amp;gt;
      Pymissile provides a curses interface to control an original
      Marks and Spencer / Striker USB Missile Launcher, as well as a
      motion control script to allow a webcamera to control the
      launcher.
    &amp;lt;/p&amp;gt;
  &amp;lt;/description&amp;gt;
  &amp;lt;provides&amp;gt;
    &amp;lt;modalias&amp;gt;usb:v1130p0202d*&amp;lt;/modalias&amp;gt;
  &amp;lt;/provides&amp;gt;
&amp;lt;/component&amp;gt;
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;The key for isenkram is the component/provides/modalias value,
which is a glob style match rule for hardware specific strings
(modalias strings) provided by the Linux kernel.  In this case, it
will map to all USB devices with vendor code 1130 and product code
0202.&lt;/p&gt;

&lt;p&gt;Note, it is important that the license of all the metadata files
are compatible to have permissions to aggregate them into archive wide
appstream files.  Matthias suggested to use MIT or BSD licenses for
these files.  A challenge is figuring out a good id for the data, as
it is supposed to be globally unique and shared across distributions
(in other words, best to coordinate with upstream what to use).  But
it can be changed later or, so we went with the package name as
upstream for this project is dormant.&lt;/p&gt;

&lt;p&gt;To get the metadata file installed in the correct location for the
mirror update scripts to pick it up and include its content the
appstream data source, the file must be installed in the binary
package under /usr/share/appdata/.  I did this by adding the following
line to debian/pymissile.install:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
debian/pymissile.metainfo.xml usr/share/appdata
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;With that in place, the command line tool isenkram-lookup will list
all packages useful on the current computer automatically, and the GUI
pop-up handler will propose to install the package not already
installed if a hardware dongle is inserted into the machine in
question.&lt;/p&gt;

&lt;p&gt;Details of the modalias field in appstream is available from the 
&lt;a href=&quot;https://wiki.debian.org/DEP-11&quot;&gt;DEP-11&lt;/a&gt; proposal.&lt;/p&gt;

&lt;p&gt;To locate the modalias values of all hardware present in a machine,
try running this command on the command line:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
cat $(find /sys/devices/|grep modalias)
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;To learn more about the isenkram system, please check out
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/tags/isenkram/&quot;&gt;my
blog posts tagged isenkram&lt;/a&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Debian Jessie, PXE and automatic firmware installation</title>
                <link>http://people.skolelinux.org/pere/blog/Debian_Jessie__PXE_and_automatic_firmware_installation.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Debian_Jessie__PXE_and_automatic_firmware_installation.html</guid>
                <pubDate>Fri, 17 Oct 2014 14:10:00 +0200</pubDate>
                <description>&lt;p&gt;When PXE installing laptops with Debian, I often run into the
problem that the WiFi card require some firmware to work properly.
And it has been a pain to fix this using preseeding in Debian.
Normally something more is needed.  But thanks to
&lt;a href=&quot;https://packages.qa.debian.org/i/isenkram.html&quot;&gt;my isenkram
package&lt;/a&gt; and its recent tasksel extension, it has now become easy
to do this using simple preseeding.&lt;/p&gt;

&lt;p&gt;The isenkram-cli package provide tasksel tasks which will install
firmware for the hardware found in the machine (actually, requested by
the kernel modules for the hardware).  (It can also install user space
programs supporting the hardware detected, but that is not the focus
of this story.)&lt;/p&gt;

&lt;p&gt;To get this working in the default installation, two preeseding
values are needed.  First, the isenkram-cli package must be installed
into the target chroot (aka the hard drive) before tasksel is executed
in the pkgsel step of the debian-installer system.  This is done by
preseeding the base-installer/includes debconf value to include the
isenkram-cli package.  The package name is next passed to debootstrap
for installation.  With the isenkram-cli package in place, tasksel
will automatically use the isenkram tasks to detect hardware specific
packages for the machine being installed and install them, because
isenkram-cli contain tasksel tasks.&lt;/p&gt;

&lt;p&gt;Second, one need to enable the non-free APT repository, because
most firmware unfortunately is non-free.  This is done by preseeding
the apt-mirror-setup step.  This is unfortunate, but for a lot of
hardware it is the only option in Debian.&lt;/p&gt;

&lt;p&gt;The end result is two lines needed in your preseeding file to get
firmware installed automatically by the installer:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
base-installer base-installer/includes string isenkram-cli
apt-mirror-setup apt-setup/non-free boolean true
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The current version of isenkram-cli in testing/jessie will install
both firmware and user space packages when using this method.  It also
do not work well, so use version 0.15 or later.  Installing both
firmware and user space packages might give you a bit more than you
want, so I decided to split the tasksel task in two, one for firmware
and one for user space programs.  The firmware task is enabled by
default, while the one for user space programs is not.  This split is
implemented in the package currently in unstable.&lt;/p&gt;

&lt;p&gt;If you decide to give this a go, please let me know (via email) how
this recipe work for you. :)&lt;/p&gt;

&lt;p&gt;So, I bet you are wondering, how can this work.  First and
foremost, it work because tasksel is modular, and driven by whatever
files it find in /usr/lib/tasksel/ and /usr/share/tasksel/.  So the
isenkram-cli package place two files for tasksel to find.  First there
is the task description file (/usr/share/tasksel/descs/isenkram.desc):&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
Task: isenkram-packages
Section: hardware
Description: Hardware specific packages (autodetected by isenkram)
 Based on the detected hardware various hardware specific packages are
 proposed.
Test-new-install: show show
Relevance: 8
Packages: for-current-hardware

Task: isenkram-firmware
Section: hardware
Description: Hardware specific firmware packages (autodetected by isenkram)
 Based on the detected hardware various hardware specific firmware
 packages are proposed.
Test-new-install: mark show
Relevance: 8
Packages: for-current-hardware-firmware
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The key parts are Test-new-install which indicate how the task
should be handled and the Packages line referencing to a script in
/usr/lib/tasksel/packages/.  The scripts use other scripts to get a
list of packages to install.  The for-current-hardware-firmware script
look like this to list relevant firmware for the machine:

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
#!/bin/sh
#
PATH=/usr/sbin:$PATH
export PATH
isenkram-autoinstall-firmware -l
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;With those two pieces in place, the firmware is installed by
tasksel during the normal d-i run. :)&lt;/p&gt;

&lt;p&gt;If you want to test what tasksel will install when isenkram-cli is
installed, run &lt;tt&gt;DEBIAN_PRIORITY=critical tasksel --test
--new-install&lt;/tt&gt; to get the list of packages that tasksel would
install.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://wiki.debian.org/DebianEdu/&quot;&gt;Debian Edu&lt;/a&gt; will be
pilots in testing this feature, as isenkram is used there now to
install firmware, replacing the earlier scripts.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Install hardware dependent packages using tasksel (Isenkram 0.7)</title>
                <link>http://people.skolelinux.org/pere/blog/Install_hardware_dependent_packages_using_tasksel__Isenkram_0_7_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Install_hardware_dependent_packages_using_tasksel__Isenkram_0_7_.html</guid>
                <pubDate>Wed, 23 Apr 2014 14:50:00 +0200</pubDate>
                <description>&lt;p&gt;It would be nice if it was easier in Debian to get all the hardware
related packages relevant for the computer installed automatically.
So I implemented one, using
&lt;a href=&quot;http://packages.qa.debian.org/isenkram&quot;&gt;my Isenkram
package&lt;/a&gt;.  To use it, install the tasksel and isenkram packages and
run tasksel as user root.  You should be presented with a new option,
&quot;Hardware specific packages (autodetected by isenkram)&quot;.  When you
select it, tasksel will install the packages isenkram claim is fit for
the current hardware, hot pluggable or not.&lt;p&gt;

&lt;p&gt;The implementation is in two files, one is the tasksel menu entry
description, and the other is the script used to extract the list of
packages to install.  The first part is in
&lt;tt&gt;/usr/share/tasksel/descs/isenkram.desc&lt;/tt&gt; and look like
this:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
Task: isenkram
Section: hardware
Description: Hardware specific packages (autodetected by isenkram)
 Based on the detected hardware various hardware specific packages are
 proposed.
Test-new-install: mark show
Relevance: 8
Packages: for-current-hardware
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The second part is in
&lt;tt&gt;/usr/lib/tasksel/packages/for-current-hardware&lt;/tt&gt; and look like
this:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
#!/bin/sh
#
(
    isenkram-lookup
    isenkram-autoinstall-firmware -l
) | sort -u
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;All in all, a very short and simple implementation making it
trivial to install the hardware dependent package we all may want to
have installed on our machines.  I&#39;ve not been able to find a way to
get tasksel to tell you exactly which packages it plan to install
before doing the installation.  So if you are curious or careful,
check the output from the isenkram-* command line tools first.&lt;/p&gt;

&lt;p&gt;The information about which packages are handling which hardware is
fetched either from the isenkram package itself in
/usr/share/isenkram/, from git.debian.org or from the APT package
database (using the Modaliases header).  The APT package database
parsing have caused a nasty resource leak in the isenkram daemon (bugs
&lt;a href=&quot;http://bugs.debian.org/719837&quot;&gt;#719837&lt;/a&gt; and
&lt;a href=&quot;http://bugs.debian.org/730704&quot;&gt;#730704&lt;/a&gt;).  The cause is in
the python-apt code (bug
&lt;a href=&quot;http://bugs.debian.org/745487&quot;&gt;#745487&lt;/a&gt;), but using a
workaround I was able to get rid of the file descriptor leak and
reduce the memory leak from ~30 MiB per hardware detection down to
around 2 MiB per hardware detection.  It should make the desktop
daemon a lot more useful.  The fix is in version 0.7 uploaded to
unstable today.&lt;/p&gt;

&lt;p&gt;I believe the current way of mapping hardware to packages in
Isenkram is is a good draft, but in the future I expect isenkram to
use the AppStream data source for this.  A proposal for getting proper
AppStream support into Debian is floating around as
&lt;a href=&quot;https://wiki.debian.org/DEP-11&quot;&gt;DEP-11&lt;/a&gt;, and
&lt;a href=&quot;https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014.2FProjects.2FAppStreamDEP11Implementation.AppStream.2FDEP-11_for_the_Debian_Archive&quot;&gt;GSoC
project&lt;/a&gt; will take place this summer to improve the situation.  I
look forward to seeing the result, and welcome patches for isenkram to
start using the information when it is ready.&lt;/p&gt;

&lt;p&gt;If you want your package to map to some specific hardware, either
add a &quot;Xb-Modaliases&quot; header to your control file like I did in
&lt;a href=&quot;http://packages.qa.debian.org/pymissile&quot;&gt;the pymissile
package&lt;/a&gt; or submit a bug report with the details to the isenkram
package.  See also
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/tags/isenkram/&quot;&gt;all my
blog posts tagged isenkram&lt;/a&gt; for details on the notation.  I expect
the information will be migrated to AppStream eventually, but for the
moment I got no better place to store it.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Automatically locate and install required firmware packages on Debian (Isenkram 0.4)</title>
                <link>http://people.skolelinux.org/pere/blog/Automatically_locate_and_install_required_firmware_packages_on_Debian__Isenkram_0_4_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Automatically_locate_and_install_required_firmware_packages_on_Debian__Isenkram_0_4_.html</guid>
                <pubDate>Tue, 25 Jun 2013 11:50:00 +0200</pubDate>
                <description>&lt;p&gt;It annoys me when the computer fail to do automatically what it is
perfectly capable of, and I have to do it manually to get things
working.  One such task is to find out what firmware packages are
needed to get the hardware on my computer working.  Most often this
affect the wifi card, but some times it even affect the RAID
controller or the ethernet card.  Today I pushed version 0.4 of the
&lt;a href=&quot;http://packages.qa.debian.org/isenkram&quot;&gt;Isenkram package&lt;/a&gt;
including a new script isenkram-autoinstall-firmware handling the
process of asking all the loaded kernel modules what firmware files
they want, find debian packages providing these files and install the
debian packages.  Here is a test run on my laptop:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
# isenkram-autoinstall-firmware 
info: kernel drivers requested extra firmware: ipw2200-bss.fw ipw2200-ibss.fw ipw2200-sniffer.fw
info: fetching http://http.debian.net/debian/dists/squeeze/Contents-i386.gz
info: locating packages with the requested firmware files
info: Updating APT sources after adding non-free APT source
info: trying to install firmware-ipw2x00
firmware-ipw2x00
firmware-ipw2x00
Preconfiguring packages ...
Selecting previously deselected package firmware-ipw2x00.
(Reading database ... 259727 files and directories currently installed.)
Unpacking firmware-ipw2x00 (from .../firmware-ipw2x00_0.28+squeeze1_all.deb) ...
Setting up firmware-ipw2x00 (0.28+squeeze1) ...
# 
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;When all the requested firmware is present, a simple message is
printed instead:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
# isenkram-autoinstall-firmware 
info: did not find any firmware files requested by loaded kernel modules.  exiting
# 
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;It could use some polish, but it is already working well and saving
me some time when setting up new machines. :)&lt;/p&gt;

&lt;p&gt;So, how does it work?  It look at the set of currently loaded
kernel modules, and look up each one of them using modinfo, to find
the firmware files listed in the module meta-information.  Next, it
download the Contents file from a nearby APT mirror, and search for
the firmware files in this file to locate the package with the
requested firmware file.  If the package is in the non-free section, a
non-free APT source is added and the package is installed using
&lt;tt&gt;apt-get install&lt;/tt&gt;.  The end result is a slightly better working
machine.&lt;/p&gt;

&lt;p&gt;I hope someone find time to implement a more polished version of
this script as part of the hw-detect debian-installer module, to
finally fix &lt;a href=&quot;http://bugs.debian.org/655507&quot;&gt;BTS report
#655507&lt;/a&gt;.  There really is no need to insert USB sticks with
firmware during a PXE install when the packages already are available
from the nearby Debian mirror.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Isenkram 0.2 finally in the Debian archive</title>
                <link>http://people.skolelinux.org/pere/blog/Isenkram_0_2_finally_in_the_Debian_archive.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Isenkram_0_2_finally_in_the_Debian_archive.html</guid>
                <pubDate>Wed, 3 Apr 2013 23:40:00 +0200</pubDate>
                <description>&lt;p&gt;Today the &lt;a href=&quot;http://packages.qa.debian.org/isenkram&quot;&gt;Isenkram
package&lt;/a&gt; finally made it into the archive, after lingering in NEW
for many months.  I uploaded it to the Debian experimental suite
2013-01-27, and today it was accepted into the archive.&lt;/p&gt;

&lt;p&gt;Isenkram is a system for suggesting to users what packages to
install to work with a pluggable hardware device.  The suggestion pop
up when the device is plugged in.  For example if a Lego Mindstorm NXT
is inserted, it will suggest to install the program needed to program
the NXT controller.  Give it a go, and report bugs and suggestions to
BTS. :)&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Welcome to the world, Isenkram!</title>
                <link>http://people.skolelinux.org/pere/blog/Welcome_to_the_world__Isenkram_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Welcome_to_the_world__Isenkram_.html</guid>
                <pubDate>Tue, 22 Jan 2013 22:00:00 +0100</pubDate>
                <description>&lt;p&gt;Yesterday, I
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/First_prototype_ready_making_hardware_easier_to_use_in_Debian.html&quot;&gt;asked
for testers&lt;/a&gt; for my prototype for making Debian better at handling
pluggable hardware devices, which I
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Lets_make_hardware_dongles_easier_to_use_in_Debian.html&quot;&gt;set
out to create&lt;/a&gt; earlier this month.  Several valuable testers showed
up, and caused me to really want to to open up the development to more
people.  But before I did this, I want to come up with a sensible name
for this project.  Today I finally decided on a new name, and I have
renamed the project from hw-support-handler to this new name.  In the
process, I moved the source to git and made it available as a
&lt;a href=&quot;http://anonscm.debian.org/gitweb/?p=collab-maint/isenkram.git&quot;&gt;collab-maint&lt;/a&gt;
repository in Debian.  The new name?  It is &lt;strong&gt;Isenkram&lt;/strong&gt;.
To fetch and build the latest version of the source, use&lt;/p&gt;

&lt;pre&gt;
git clone http://anonscm.debian.org/git/collab-maint/isenkram.git
cd isenkram &amp;&amp; git-buildpackage -us -uc
&lt;/pre&gt;

&lt;p&gt;I have not yet adjusted all files to use the new name yet.  If you
want to hack on the source or improve the package, please go ahead.
But please talk to me first on IRC or via email before you do major
changes, to make sure we do not step on each others toes. :)&lt;/p&gt;

&lt;p&gt;If you wonder what &#39;isenkram&#39; is, it is a Norwegian word for iron
stuff, typically meaning tools, nails, screws, etc.  Typical hardware
stuff, in other words.  I&#39;ve been told it is the Norwegian variant of
the German word eisenkram, for those that are familiar with that
word.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2013-01-26&lt;/strong&gt;: Added -us -us to build
instructions, to avoid confusing people with an error from the signing
process.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2013-01-27&lt;/strong&gt;: Switch to HTTP URL for the git
clone argument to avoid the need for authentication.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>First prototype ready making hardware easier to use in Debian</title>
                <link>http://people.skolelinux.org/pere/blog/First_prototype_ready_making_hardware_easier_to_use_in_Debian.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/First_prototype_ready_making_hardware_easier_to_use_in_Debian.html</guid>
                <pubDate>Mon, 21 Jan 2013 12:00:00 +0100</pubDate>
                <description>&lt;p&gt;Early this month I set out to try to
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Lets_make_hardware_dongles_easier_to_use_in_Debian.html&quot;&gt;improve
the Debian support for pluggable hardware devices&lt;/a&gt;.  Now my
prototype is working, and it is ready for a larger audience.  To test
it, fetch the
&lt;a href=&quot;http://anonscm.debian.org/viewvc/debian-edu/trunk/src/hw-support-handler/&quot;&gt;source
from the Debian Edu subversion repository&lt;/a&gt;, build and install the
package.  You might have to log out and in again activate the
autostart script.&lt;/p&gt;

&lt;p&gt;The design is simple:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Add desktop entry in /usr/share/autostart/ causing a program
hw-support-handlerd to start when the user log in.&lt;/li&gt;

&lt;li&gt;This program listen for kernel events about new hardware (directly
from the kernel like udev does), not using HAL dbus events as I
initially did.&lt;/li&gt;

&lt;li&gt;When new hardware is inserted, look up the hardware modalias in
the APT database, a database
&lt;a href=&quot;http://anonscm.debian.org/viewvc/debian-edu/trunk/src/hw-support-handler/modaliases?view=markup&quot;&gt;available
via HTTP&lt;/a&gt; and a database available as part of the package.&lt;/li&gt;

&lt;li&gt;If a package is mapped to the hardware in question, the package
isn&#39;t installed yet and this is the first time the hardware was
plugged in, show a desktop notification suggesting to install the
package or packages.&lt;/li&gt;

&lt;li&gt;If the user click on the &#39;install package now&#39; button, ask
aptdaemon via the PackageKit API to install the requrired package.&lt;/li&gt;

&lt;li&gt;aptdaemon ask for root password or sudo password, and install the
package while showing progress information in a window.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;I still need to come up with a better name for the system.  Here
are some screen shots showing the prototype in action.  First the
notification, then the password request, and finally the request to
approve all the dependencies.  Sorry for the Norwegian Bokmål GUI.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2013-01-21-hw-support-1-notification.png&quot;&gt;
&lt;br&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2013-01-21-hw-support-2-password.png&quot;&gt;
&lt;br&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2013-01-21-hw-support-3-dependencies.png&quot;&gt;
&lt;br&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2013-01-21-hw-support-4-installing.png&quot;&gt;
&lt;br&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2013-01-21-hw-support-5-installing-details.png&quot; width=&quot;70%&quot;&gt;&lt;/p&gt;

&lt;p&gt;The prototype still need to be improved with longer timeouts, but
is already useful.  The database of hardware to package mappings also
need more work.  It is currently compatible with the Ubuntu way of
storing such information in the package control file, but could be
changed to use other formats instead or in addition to the current
method.  I&#39;ve dropped the use of discover for this mapping, as the
modalias approach is more flexible and easier to use on Linux as long
as the Linux kernel expose its modalias strings directly.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2013-01-21 16:50&lt;/strong&gt;: Due to popular demand,
here is the command required to check out and build the source: Use
&#39;&lt;tt&gt;svn checkout
svn://svn.debian.org/debian-edu/trunk/src/hw-support-handler/; cd
hw-support-handler; debuild&lt;/tt&gt;&#39;.  If you lack debuild, install the
devscripts package.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2013-01-23 12:00&lt;/strong&gt;: The project is now
renamed to Isenkram and the source moved from the Debian Edu
subversion repository to a Debian collab-maint git repository.  See
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Welcome_to_the_world__Isenkram_.html&quot;&gt;build
instructions&lt;/a&gt; for details.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Using modalias info to find packages handling my hardware</title>
                <link>http://people.skolelinux.org/pere/blog/Using_modalias_info_to_find_packages_handling_my_hardware.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Using_modalias_info_to_find_packages_handling_my_hardware.html</guid>
                <pubDate>Tue, 15 Jan 2013 08:00:00 +0100</pubDate>
                <description>&lt;p&gt;Yesterday, I wrote about the
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html&quot;&gt;modalias
values provided by the Linux kernel&lt;/a&gt; following my hope for
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Lets_make_hardware_dongles_easier_to_use_in_Debian.html&quot;&gt;better
dongle support in Debian&lt;/a&gt;.  Using this knowledge, I have tested how
modalias values attached to package names can be used to map packages
to hardware.  This allow the system to look up and suggest relevant
packages when I plug in some new hardware into my machine, and replace
discover and discover-data as the database used to map hardware to
packages.&lt;/p&gt;

&lt;p&gt;I create a modaliases file with entries like the following,
containing package name, kernel module name (if relevant, otherwise
the package name) and globs matching the relevant hardware
modalias.&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
Package: package-name
&lt;br&gt;Modaliases: module(modaliasglob, modaliasglob, modaliasglob)&lt;/p&gt;
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;It is fairly trivial to write code to find the relevant packages
for a given modalias value using this file.&lt;/p&gt;

&lt;p&gt;An entry like this would suggest the video and picture application
cheese for many USB web cameras (interface bus class 0E01):&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
Package: cheese
&lt;br&gt;Modaliases: cheese(usb:v*p*d*dc*dsc*dp*ic0Eisc01ip*)&lt;/p&gt;
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;An entry like this would suggest the pcmciautils package when a
CardBus bridge (bus class 0607) PCI device is present:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
Package: pcmciautils
&lt;br&gt;Modaliases: pcmciautils(pci:v*d*sv*sd*bc06sc07i*)
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;An entry like this would suggest the package colorhug-client when
plugging in a ColorHug with USB IDs 04D8:F8DA:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
Package: colorhug-client
&lt;br&gt;Modaliases: colorhug-client(usb:v04D8pF8DAd*)&lt;/p&gt;
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;I believe the format is compatible with the format of the Packages
file in the Debian archive.  Ubuntu already uses their Packages file
to store their mappings from packages to hardware.&lt;/p&gt;

&lt;p&gt;By adding a XB-Modaliases: header in debian/control, any .deb can
announce the hardware it support in a way my prototype understand.
This allow those publishing packages in an APT source outside the
Debian archive as well as those backporting packages to make sure the
hardware mapping are included in the package meta information.  I&#39;ve
tested such header in the pymissile package, and its modalias mapping
is working as it should with my prototype.  It even made it to Ubuntu
Raring.&lt;/p&gt;

&lt;p&gt;To test if it was possible to look up supported hardware using only
the shell tools available in the Debian installer, I wrote a shell
implementation of the lookup code.  The idea is to create files for
each modalias and let the shell do the matching.  Please check out and
try the
&lt;a href=&quot;http://anonscm.debian.org/viewvc/debian-edu/trunk/src/hw-support-handler/hw-support-lookup?view=co&quot;&gt;hw-support-lookup&lt;/a&gt;
shell script.  It run without any extra dependencies and fetch the
hardware mappings from the Debian archive and the subversion
repository where I currently work on my prototype.&lt;/p&gt;

&lt;p&gt;When I use it on a machine with a yubikey inserted, it suggest to
install yubikey-personalization:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
% ./hw-support-lookup
&lt;br&gt;yubikey-personalization
&lt;br&gt;%
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;When I run it on my Thinkpad X40 with a PCMCIA/CardBus slot, it
propose to install the pcmciautils package:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
% ./hw-support-lookup 
&lt;br&gt;pcmciautils
&lt;br&gt;%
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;If you know of any hardware-package mapping that should be added to
&lt;a href=&quot;http://anonscm.debian.org/viewvc/debian-edu/trunk/src/hw-support-handler/modaliases?view=co&quot;&gt;my
database&lt;/a&gt;, please tell me about it.&lt;/p&gt;

&lt;p&gt;It could be possible to generate several of the mappings between
packages and hardware.  One source would be to look at packages with
kernel modules, ie packages with *.ko files in /lib/modules/, and
extract their modalias information.  Another would be to look at
packages with udev rules, ie packages with files in
/lib/udev/rules.d/, and extract their vendor/model information to
generate a modalias matching rule.  I have not tested any of these to
see if it work.&lt;/p&gt;

&lt;p&gt;If you want to help implementing a system to let us propose what
packages to install when new hardware is plugged into a Debian
machine, please send me an email or talk to me on
&lt;a href=&quot;irc://irc.debian.org/%23debian-devel&quot;&gt;#debian-devel&lt;/a&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Modalias strings - a practical way to map &quot;stuff&quot; to hardware</title>
                <link>http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html</guid>
                <pubDate>Mon, 14 Jan 2013 11:20:00 +0100</pubDate>
                <description>&lt;p&gt;While looking into how to look up Debian packages based on hardware
information, to find the packages that support a given piece of
hardware, I refreshed my memory regarding modalias values, and decided
to document the details.  Here are my findings so far, also available
in
&lt;a href=&quot;http://anonscm.debian.org/viewvc/debian-edu/trunk/src/hw-support-handler/&quot;&gt;the
Debian Edu subversion repository&lt;/a&gt;:

&lt;p&gt;&lt;strong&gt;Modalias decoded&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;This document try to explain what the different types of modalias
values stands for.  It is in part based on information from
&amp;lt;URL: &lt;a href=&quot;https://wiki.archlinux.org/index.php/Modalias&quot;&gt;https://wiki.archlinux.org/index.php/Modalias&lt;/a&gt; &amp;gt;,
&amp;lt;URL: &lt;a href=&quot;http://unix.stackexchange.com/questions/26132/how-to-assign-usb-driver-to-device&quot;&gt;http://unix.stackexchange.com/questions/26132/how-to-assign-usb-driver-to-device&lt;/a&gt; &amp;gt;,
&amp;lt;URL: &lt;a href=&quot;http://code.metager.de/source/history/linux/stable/scripts/mod/file2alias.c&quot;&gt;http://code.metager.de/source/history/linux/stable/scripts/mod/file2alias.c&lt;/a&gt; &amp;gt; and
&amp;lt;URL: &lt;a href=&quot;http://cvs.savannah.gnu.org/viewvc/dmidecode/dmidecode.c?root=dmidecode&amp;view=markup&quot;&gt;http://cvs.savannah.gnu.org/viewvc/dmidecode/dmidecode.c?root=dmidecode&amp;view=markup&lt;/a&gt; &amp;gt;.

&lt;p&gt;The modalias entries for a given Linux machine can be found using
this shell script:&lt;/p&gt;

&lt;pre&gt;
find /sys -name modalias -print0 | xargs -0 cat | sort -u
&lt;/pre&gt;

&lt;p&gt;The supported modalias globs for a given kernel module can be found
using modinfo:&lt;/p&gt;

&lt;pre&gt;
% /sbin/modinfo psmouse | grep alias:
alias:          serio:ty05pr*id*ex*
alias:          serio:ty01pr*id*ex*
%
&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;PCI subtype&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;A typical PCI entry can look like this.  This is an Intel Host
Bridge memory controller:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
pci:v00008086d00002770sv00001028sd000001ADbc06sc00i00
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;This represent these values:&lt;/p&gt;

&lt;pre&gt;
 v   00008086  (vendor)
 d   00002770  (device)
 sv  00001028  (subvendor)
 sd  000001AD  (subdevice)
 bc  06        (bus class)
 sc  00        (bus subclass)
 i   00        (interface)
&lt;/pre&gt;

&lt;p&gt;The vendor/device values are the same values outputted from &#39;lspci
-n&#39; as 8086:2770.  The bus class/subclass is also shown by lspci as
0600.  The 0600 class is a host bridge.  Other useful bus values are
0300 (VGA compatible card) and 0200 (Ethernet controller).&lt;/p&gt;

&lt;p&gt;Not sure how to figure out the interface value, nor what it
means.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;USB subtype&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Some typical USB entries can look like this.  This is an internal
USB hub in a laptop:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Here is the values included in this alias:&lt;/p&gt;

&lt;pre&gt;
 v    1D6B  (device vendor)
 p    0001  (device product)
 d    0206  (bcddevice)
 dc     09  (device class)
 dsc    00  (device subclass)
 dp     00  (device protocol)
 ic     09  (interface class)
 isc    00  (interface subclass)
 ip     00  (interface protocol)
&lt;/pre&gt;

&lt;p&gt;The 0900 device class/subclass means hub.  Some times the relevant
class is in the interface class section.  For a simple USB web camera,
these alias entries show up:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
usb:v0AC8p3420d5000dcEFdsc02dp01ic01isc01ip00
&lt;br&gt;usb:v0AC8p3420d5000dcEFdsc02dp01ic01isc02ip00
&lt;br&gt;usb:v0AC8p3420d5000dcEFdsc02dp01ic0Eisc01ip00
&lt;br&gt;usb:v0AC8p3420d5000dcEFdsc02dp01ic0Eisc02ip00
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Interface class 0E01 is video control, 0E02 is video streaming (aka
camera), 0101 is audio control device and 0102 is audio streaming (aka
microphone).  Thus this is a camera with microphone included.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;ACPI subtype&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The ACPI type is used for several non-PCI/USB stuff.  This is an IR
receiver in a Thinkpad X40:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
acpi:IBM0071:PNP0511:
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The values between the colons are IDs.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;DMI subtype&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The DMI table contain lots of information about the computer case
and model.  This is an entry for a IBM Thinkpad X40, fetched from
/sys/devices/virtual/dmi/id/modalias:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
dmi:bvnIBM:bvr1UETB6WW(1.66):bd06/15/2005:svnIBM:pn2371H4G:pvrThinkPadX40:rvnIBM:rn2371H4G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The values present are&lt;/p&gt;

&lt;pre&gt;
 bvn  IBM            (BIOS vendor)
 bvr  1UETB6WW(1.66) (BIOS version)
 bd   06/15/2005     (BIOS date)
 svn  IBM            (system vendor)
 pn   2371H4G        (product name)
 pvr  ThinkPadX40    (product version)
 rvn  IBM            (board vendor)
 rn   2371H4G        (board name)
 rvr  NotAvailable   (board version)
 cvn  IBM            (chassis vendor)
 ct   10             (chassis type)
 cvr  NotAvailable   (chassis version)
&lt;/pre&gt;

&lt;p&gt;The chassis type 10 is Notebook.  Other interesting values can be
found in the dmidecode source:&lt;/p&gt;

&lt;pre&gt;
  3 Desktop
  4 Low Profile Desktop
  5 Pizza Box
  6 Mini Tower
  7 Tower
  8 Portable
  9 Laptop
 10 Notebook
 11 Hand Held
 12 Docking Station
 13 All In One
 14 Sub Notebook
 15 Space-saving
 16 Lunch Box
 17 Main Server Chassis
 18 Expansion Chassis
 19 Sub Chassis
 20 Bus Expansion Chassis
 21 Peripheral Chassis
 22 RAID Chassis
 23 Rack Mount Chassis
 24 Sealed-case PC
 25 Multi-system
 26 CompactPCI
 27 AdvancedTCA
 28 Blade
 29 Blade Enclosing
&lt;/pre&gt;

&lt;p&gt;The chassis type values are not always accurately set in the DMI
table.  For example my home server is a tower, but the DMI modalias
claim it is a desktop.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;SerIO subtype&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;This type is used for PS/2 mouse plugs.  One example is from my
test machine:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
serio:ty01pr00id00ex00
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The values present are&lt;/p&gt;

&lt;pre&gt;
  ty  01  (type)
  pr  00  (prototype)
  id  00  (id)
  ex  00  (extra)
&lt;/pre&gt;

&lt;p&gt;This type is supported by the psmouse driver.  I am not sure what
the valid values are.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Other subtypes&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;There are heaps of other modalias subtypes according to
file2alias.c.  There is the rest of the list from that source: amba,
ap, bcma, ccw, css, eisa, hid, i2c, ieee1394, input, ipack, isapnp,
mdio, of, parisc, pcmcia, platform, scsi, sdio, spi, ssb, vio, virtio,
vmbus, x86cpu and zorro.  I did not spend time documenting all of
these, as they do not seem relevant for my intended use with mapping
hardware to packages when new stuff is inserted during run time.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Looking up kernel modules using modalias values&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;To check which kernel modules provide support for a given modalias,
one can use the following shell script:&lt;/p&gt;

&lt;pre&gt;
  for id in $(find /sys -name modalias -print0 | xargs -0 cat | sort -u); do \
    echo &quot;$id&quot; ; \
    /sbin/modprobe --show-depends &quot;$id&quot;|sed &#39;s/^/  /&#39; ; \
  done
&lt;/pre&gt;

&lt;p&gt;The output can look like this (only the first few entries as the
list is very long on my test machine):&lt;/p&gt;

&lt;pre&gt;
  acpi:ACPI0003:
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/acpi/ac.ko 
  acpi:device:
  FATAL: Module acpi:device: not found.
  acpi:IBM0068:
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/char/nvram.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/leds/led-class.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/net/rfkill/rfkill.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/platform/x86/thinkpad_acpi.ko 
  acpi:IBM0071:PNP0511:
    insmod /lib/modules/2.6.32-5-686/kernel/lib/crc-ccitt.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/net/irda/irda.ko 
    insmod /lib/modules/2.6.32-5-686/kernel/drivers/net/irda/nsc-ircc.ko 
  [...]
&lt;/pre&gt;

&lt;p&gt;If you want to help implementing a system to let us propose what
packages to install when new hardware is plugged into a Debian
machine, please send me an email or talk to me on
&lt;a href=&quot;irc://irc.debian.org/%23debian-devel&quot;&gt;#debian-devel&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update 2013-01-15:&lt;/strong&gt; Rewrite &quot;cat $(find ...)&quot; to
&quot;find ... -print0 | xargs -0 cat&quot; to make sure it handle directories
in /sys/ with space in them.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Moved the pymissile Debian packaging to collab-maint</title>
                <link>http://people.skolelinux.org/pere/blog/Moved_the_pymissile_Debian_packaging_to_collab_maint.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Moved_the_pymissile_Debian_packaging_to_collab_maint.html</guid>
                <pubDate>Thu, 10 Jan 2013 20:40:00 +0100</pubDate>
                <description>&lt;p&gt;As part of my investigation on how to improve the support in Debian
for hardware dongles, I dug up my old Mark and Spencer USB Rocket
Launcher and updated the Debian package
&lt;a href=&quot;http://packages.qa.debian.org/pymissile&quot;&gt;pymissile&lt;/a&gt; to make
sure udev will fix the device permissions when it is plugged in.  I
also added a &quot;Modaliases&quot; header to test it in the Debian archive and
hopefully make the package be proposed by jockey in Ubuntu when a user
plug in his rocket launcher.  In the process I moved the source to a
git repository under collab-maint, to make it easier for any DD to
contribute.  &lt;a href=&quot;http://code.google.com/p/pymissile/&quot;&gt;Upstream&lt;/a&gt;
is not very active, but the software still work for me even after five
years of relative silence.  The new git repository is not listed in
the uploaded package yet, because I want to test the other changes a
bit more before I upload the new version.  If you want to check out
the new version with a .desktop file included, visit the
&lt;a href=&quot;http://anonscm.debian.org/gitweb/?p=collab-maint/pymissile.git&quot;&gt;gitweb
view&lt;/a&gt; or use &quot;&lt;tt&gt;git clone
git://anonscm.debian.org/collab-maint/pymissile.git&lt;/tt&gt;&quot;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Lets make hardware dongles easier to use in Debian</title>
                <link>http://people.skolelinux.org/pere/blog/Lets_make_hardware_dongles_easier_to_use_in_Debian.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Lets_make_hardware_dongles_easier_to_use_in_Debian.html</guid>
                <pubDate>Wed, 9 Jan 2013 15:40:00 +0100</pubDate>
                <description>&lt;p&gt;One thing that annoys me with Debian and Linux distributions in
general, is that there is a great package management system with the
ability to automatically install software packages by downloading them
from the distribution mirrors, but no way to get it to automatically
install the packages I need to use the hardware I plug into my
machine.  Even if the package to use it is easily available from the
Linux distribution.  When I plug in a LEGO Mindstorms NXT, it could
suggest to automatically install the python-nxt, nbc and t2n packages
I need to talk to it.  When I plug in a Yubikey, it could propose the
yubikey-personalization package.  The information required to do this
is available, but no-one have pulled all the pieces together.&lt;/p&gt;

&lt;p&gt;Some years ago, I proposed to
&lt;a href=&quot;http://lists.debian.org/debian-devel/2010/05/msg01206.html&quot;&gt;use
the discover subsystem to implement this&lt;/a&gt;.  The idea is fairly
simple:

&lt;ul&gt;

&lt;li&gt;Add a desktop entry in /usr/share/autostart/ pointing to a program
  starting when a user log in.&lt;/li&gt;

&lt;li&gt;Set this program up to listen for kernel events emitted when new
  hardware is inserted into the computer.&lt;/li&gt;

&lt;li&gt;When new hardware is inserted, look up the hardware ID in a
  database mapping to packages, and take note of any non-installed
  packages.&lt;/li&gt;

&lt;li&gt;Show a message to the user proposing to install the discovered
  package, and make it easy to install it.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;I am not sure what the best way to implement this is, but my
initial idea was to use dbus events to discover new hardware, the
discover database to find packages and
&lt;a href=&quot;http://www.packagekit.org/&quot;&gt;PackageKit&lt;/a&gt; to install
packages.&lt;/p&gt;

&lt;p&gt;Yesterday, I found time to try to implement this idea, and the
draft package is now checked into
&lt;a href=&quot;http://anonscm.debian.org/viewvc/debian-edu/trunk/src/hw-support-handler/&quot;&gt;the
Debian Edu subversion repository&lt;/a&gt;.  In the process, I updated the
&lt;a href=&quot;http://packages.qa.debian.org/d/discover-data.html&quot;&gt;discover-data&lt;/a&gt;
package to map the USB ids of LEGO Mindstorms and Yubikey devices to
the relevant packages in Debian, and uploaded a new version
2.2013.01.09 to unstable.  I also discovered that the current 
&lt;a href=&quot;http://packages.qa.debian.org/d/discover.html&quot;&gt;discover&lt;/a&gt;
package in Debian no longer discovered any USB devices, because
/proc/bus/usb/devices is no longer present.  I ported it to use
libusb as a fall back option to get it working.  The fixed package
version 2.1.2-6 is now in experimental (didn&#39;t upload it to unstable
because of the freeze).&lt;/p&gt;

&lt;p&gt;With this prototype in place, I can insert my Yubikey, and get this
desktop notification to show up (only once, the first time it is
inserted):&lt;/p&gt;

&lt;p align=&quot;center&quot;&gt;&lt;img src=&quot;http://people.skolelinux.org/pere/blog/images/2013-01-09-hw-autoinstall.png&quot;&gt;&lt;/p&gt;

&lt;p&gt;For this prototype to be really useful, some way to automatically
install the proposed packages by pressing the &quot;Please install
program(s)&quot; button should to be implemented.&lt;/p&gt;

&lt;p&gt;If this idea seem useful to you, and you want to help make it
happen, please help me update the discover-data database with mappings
from hardware to Debian packages.  Check if &#39;discover-pkginstall -l&#39;
list the package you would like to have installed when a given
hardware device is inserted into your computer, and report bugs using
reportbug if it isn&#39;t.  Or, if you know of a better way to provide
such mapping, please let me know.&lt;/p&gt;

&lt;p&gt;This prototype need more work, and there are several questions that
should be considered before it is ready for production use.  Is dbus
the correct way to detect new hardware?  At the moment I look for HAL
dbus events on the system bus, because that is the events I could see
on my Debian Squeeze KDE desktop.  Are there better events to use?
How should the user be notified?  Is the desktop notification
mechanism the best option, or should the background daemon raise a
popup instead?  How should packages be installed?  When should they
not be installed?&lt;/p&gt;

&lt;p&gt;If you want to help getting such feature implemented in Debian,
please send me an email. :)&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>