[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>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 if you decide to give it a go. :)&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;ahref=&quot;https://wiki.debian.org/DebianEdu/&quot;&gt;Debian Edu&lt;/a&gt; will be
pilots in testing this feature, as isenkram is used to install
firmware now.&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>