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 -my isenkram -package and its recent tasksel extension, it has now become easy -to do this using simple preseeding.
- -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.)
- -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.
- -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.
- -The end result is two lines needed in your preseeding file to get -firmware installed automatically by the installer:
- -- --base-installer base-installer/includes string isenkram-cli -apt-mirror-setup apt-setup/non-free boolean true -
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.
- -If you decide to give this a go, please let me know (via email) how -this recipe work for you. :)
- -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):
- -- --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 -
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: - -
- --#!/bin/sh -# -PATH=/usr/sbin:$PATH -export PATH -isenkram-autoinstall-firmware -l -
With those two pieces in place, the firmware is installed by -tasksel during the normal d-i run. :)
- -If you want to test what tasksel will install when isenkram-cli is -installed, run DEBIAN_PRIORITY=critical tasksel --test ---new-install to get the list of packages that tasksel would -install.
- -Debian Edu will be -pilots in testing this feature, as isenkram is used there now to -install firmware, replacing the earlier scripts.
+ +Making packages for Debian requires quite a lot of attention to +details. And one of the details is the content of the +debian/copyright file, which should list all relevant licenses used by +the code in the package in question, preferably in +machine +readable DEP5 format.
+ +For large packages with lots of contributors it is hard to write +and update this file manually, and if you get some detail wrong, the +package is normally rejected by the ftpmasters. So getting it right +the first time around get the package into Debian faster, and save +both you and the ftpmasters some work.. Today, while trying to figure +out what was wrong with +the +zfsonlinux copyright file, I decided to spend some time on +figuring out the options for doing this job automatically, or at least +semi-automatically.
+ +Lucikly, there are at least two tools available for generating the +file based on the code in the source package, +debmake +and cme. I'm +not sure which one of them came first, but both seem to be able to +create a sensible draft file. As far as I can tell, none of them can +be trusted to get the result just right, so the content need to be +polished a bit before the file is OK to upload. I found the debmake +option in +a +blog posts from 2014. + +
To generate using debmake, use the -cc option: + +
+debmake -cc > debian/copyright ++ +
Note there are some problems with python and non-ASCII names, so +this might not be the best option.
+ +The cme option is based on a config parsing library, and I found +this approach in +a +blog post from 2015. To generate using cme, use the 'update +dpkg-copyright' option: + +
+cme update dpkg-copyright ++ +
This will create or update debian/copyright. The cme tool seem to +handle UTF-8 names better than debmake.
+ +When the copyright file is created, I would also like some help to +check if the file is correct. For this I found two good options, +debmake -k and license-reconcile. The former seem +to focus on license types and file matching, and is able to detect +ineffective blocks in the copyright file. The latter reports missing +copyright holders and years, but was confused by inconsistent license +names (like CDDL vs. CDDL-1.0). I suspect it is good to use both and +fix all issues reported by them before uploading. But I do not know +if the tools and the ftpmasters agree on what is important to fix in a +copyright file, so the package might still be rejected.
+ +The devscripts tool licensecheck deserve mentioning. It +will read through the source and try to find all copyright statements. +It is not comparing the result to the content of debian/copyright, but +can be useful when verifying the content of the copyright file.
+ +Are you aware of better tools in Debian to create and update +debian/copyright file. Please let me know, or blog about it on +planet.debian.org.
+ +As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
+ +Update 2016-02-20: I got a tip from Mike Gabriel +on how to use licensecheck and cdbs to create a draft copyright file + +
+licensecheck --copyright -r `find * -type f` | \ + /usr/lib/cdbs/licensecheck2dep5 > debian/copyright.auto ++ +
He mentioned that he normally check the generated file into the +version control system to make it easier to discover license and +copyright changes in the upstream source. I will try to do the same +with my packages in the future.
+ +Update 2016-02-21: The cme author recommended +against using -quiet for new users, so I removed it from the proposed +command line.
Today I came across an unexpected Ubuntu boot screen. Above the -bread shelf on the ICA shop at Storo in Oslo, the grub menu of Ubuntu -with Linux kernel 3.2.0-23 (ie probably version 12.04 LTS) was stuck -on a screen normally showing the bread types and prizes:
- -If it had booted as it was supposed to, I would never had known -about this hidden Linux installation. It is interesting what -errors can reveal.
+ +The appstream system +is taking shape in Debian, and one provided feature is a very +convenient way to tell you which package to install to make a given +firmware file available when the kernel is looking for it. This can +be done using apt-file too, but that is for someone else to blog +about. :)
+ +Here is a small recipe to find the package with a given firmware +file, in this example I am looking for ctfw-3.2.3.0.bin, randomly +picked from the set of firmware announced using appstream in Debian +unstable. In general you would be looking for the firmware requested +by the kernel during kernel module loading. To find the package +providing the example file, do like this:
+ ++ ++% apt install appstream +[...] +% apt update +[...] +% appstreamcli what-provides firmware:runtime ctfw-3.2.3.0.bin | \ + awk '/Package:/ {print $2}' +firmware-qlogic +% +
See the +appstream wiki page to learn how to embed the package metadata in +a way appstream can use.
+ +This same approach can be used to find any package supporting a +given MIME type. This is very useful when you get a file you do not +know how to handle. First find the mime type using file +--mime-type, and next look up the package providing support for +it. Lets say you got an SVG file. Its MIME type is image/svg+xml, +and you can find all packages handling this type like this:
+ ++ ++% apt install appstream +[...] +% apt update +[...] +% appstreamcli what-provides mimetype image/svg+xml | \ + awk '/Package:/ {print $2}' +bkchem +phototonic +inkscape +shutter +tetzle +geeqie +xia +pinta +gthumb +karbon +comix +mirage +viewnior +postr +ristretto +kolourpaint4 +eog +eom +gimagereader +midori +% +
I believe the MIME types are fetched from the desktop file for +packages providing appstream metadata.