Recently I got stuck with the problem of using an old kernel (now in jessie) on a new machine running unstable. Since the kernel in question is still available and supported this is not a problem per se, but if you try to recompile the dkms modules for virtualbox then the kernel headers are nowhere to be found. To solve this problem we need to first add these two line in apt/sources.list

deb http://ftp.fr.debian.org/debian jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main

and then nicely asking apt-get to install the needed gcc version from jessie’s archive. This is the less distractive way of doing this.

After this simple operation I can now recompile the virtualbox kernel modules.

$sudo apt install linux-headers-3.16.0-4-amd64 gcc-4.8/jessie
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Selected version '4.8.4-1' (Debian:8.9/oldstable [amd64]) for 'gcc-4.8'
The following packages were automatically installed and are no longer required:
  libgsoap-2.8.49 libvncserver1
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  cpp-4.8 gcc-4.8-base libasan0 libgcc-4.8-dev libisl10 linux-compiler-gcc-4.8-x86 linux-headers-3.16.0-4-common
  linux-kbuild-3.16
Suggested packages:
  gcc-4.8-locales gcc-4.8-multilib gcc-4.8-doc libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg libasan0-dbg libtsan0-dbg
  libquadmath0-dbg
The following NEW packages will be installed:
  cpp-4.8 gcc-4.8 libasan0 libgcc-4.8-dev libisl10 linux-compiler-gcc-4.8-x86 linux-headers-3.16.0-4-amd64
  linux-headers-3.16.0-4-common linux-kbuild-3.16
The following packages will be DOWNGRADED:
  gcc-4.8-base
0 upgraded, 9 newly installed, 1 downgraded, 0 to remove and 44 not upgraded.
Need to get 17.3 MB of archives.
After this operation, 63.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
[...]

I just finished to address the awesome debian crowd at the Mini Deb conf in paris. My presentation was about a few challenges we have ahead to bootstrap debian on a new architecture. Johannes Schauer and Wookey did a lot of work in the last few months particularly focusing on Linaro/Ubuntu. After Wheezy I think it is important to catch up with their work and integrate it in debian.

The two main take away messages from my presentation :

• ”’Add Multi Arch annotations”’ to your packages. This is essential to cross compile packages automatically. We are still not able to cross compile a minimal debian system in debian because we still miss many multi-arch annotations. Experiments show that with these annotations, these packages will cross compile just fine. A lot of work has been done in this direction by Wookey.

• Debian should ”’consider adding build profiles”’ to build dependencies. Build Profiles are global build dependencies filters to create packages with a different set of functionalities. Build profiles are of the form Build-Depends: foo (>=0.1) [amd64] <!stage1 bootstrap> | bar.

This week we just reached an important milestone toward a fully automatic bootstrap procedure. Hopefully we are going to tell you more about this work during fosdem 2013

My slides are attached.

• Attachment 0

This entry is not really about computers, technology, or other work-related topics, but more about a hard-hack that I wanted to try for a while. How to make a kilt !!!

After a bit of duck-ducking, I decided to follow this excellent tutorial. At first sight the entire process seems a bit long, but you will realize that after the first read, that everything boils down to 3 steps: measure, fold and pin, sew.

For the measure part, I’ve the impression that the formula that is given in the instructable (waist/3*8+1) is a bit short for my comfort and taste. This is the size for the internal apron, the folded part that goes all around your left hip, back, and right hip, and the front apron. My suggestion would be to make the inner apron a bit longer then the front apron. This way the kilt will feel in my opinion more comfortable and it will envelop you body completely.

For the fold and pin part, you just need a bit of patience and a ruler. Put the pins parallel to the folding as in the instructable and not perpendicular. This will help you later when sewing everything.

The sewing … If you know how to use a sewing machine, this is going to be a piece of cake. Otherwise, well, I spent more time troubleshooting the machine then sewing the kilt. I broke a few needles in the process and learned how to thread the machine with my eyes blindfolded. Not to mention that you have to learn how to disassemble this machines in a thousand parts to understand how the thread got stuck. It was fun. A lesson that I’ve learned is that a sewing machine works much better in the morning than late at night when you are tired and sleepy. Really !

Other then that, it was a fun experience. Maybe I’ll make another one to commit this skill to mind. Maybe I’ll run a kilt making workshop at the next debconf :)

• Attachment 0
• Attachment 1

So, what happens if your root partition is full and you reboot your machine ? If it is really full, and in particular there is no space to write anywhere, you might be stuck with a no space on device.

To avoid this problem, there exists a script /etc/init.d/mountoverflowtmp that runs a check to see if there is a minimum acceptable space on /tmp and if there is not, it mounts it overflow. It also checks for unneeded overflow tmpfs for /tmp and removes them if that is appropriate.(src).

But if you do not reboot again, you might get stuck with a mini /tmp directory of 1Mb . This is a neat trick, but you need to know about it to avoid unpleasant and unexpected surprises.

The new release of dose, apart from a few bug fixes, ships a new and improved version of dose-builddebcheck (man page). All the improvements done to dose-builddebcheck are from a set of patches submitted by Johannes Schauer in the context of the Bootstrap GSoC. We are still actively working on this. I invite you to read josh’s recent blog post on the topic. For more background and discussion, you can have a look at the archives of this mailing list.

Dose-builddebcheck (or buildcheck for short) is similar in intent to dose-debcheck but for source packages. Buildcheck allows you to check, just by looking at the Source and Packages files, if all the dependencies can be satisfied and installed, all this in a matter of seconds (less then 30 secs to test all the source packages in sid on my laptop).

A simple example :

deb-buildcheck.native \
  --deb-native-arch=amd64 \
  tests/DebianPackages/Sid-amd64-Packages-050812.bz2 
  tests/DebianPackages/Sid-Sources-050812.bz2

native-architecture: amd64
background-packages: 55945
foreground-packages: 18175
broken-packages: 64

real    0m22.223s
user    0m21.937s
sys 0m0.204s

This will check for all source packages in the Source file if their build dependencies can satisfied on amd64 given the Packages binary file. This is nice but nothing new. A script based on the old edos tools has been around for quite a long time. We want more !

The new exciting feature brought by Johannes is the capability of checking source packages for cross-compilation :

dose-builddebcheck -f -e -s --checkonly picolisp \
  --deb-native-arch=amd64 \
  --deb-foreign-archs=armel \
  --deb-host-arch=armel \
  tests/DebianPackages/Sid-amd64-Packages-050812.bz2 \
  tests/DebianPackages/Sid-armel-Packages-050812.bz2 \
  tests/DebianPackages/Sid-Sources-050812.bz2 

(I)Sources: Parsing Sources file tests/DebianPackages/Sid-Sources-single-version-050812.bz2...
(I)Format822: total packages 17723
(I)Format822: Merging repositories
(I)Packages: Parsing Packages file tests/DebianPackages/Sid-armel-Packages-050812.bz2...
(I)Packages: Parsing Packages file tests/DebianPackages/Sid-amd64-Packages-050812.bz2...
(I)Format822: total packages 58095

native-architecture: amd64
foreign-architecture: armel
host-architecture: armel
report:
 -
  package: src:apicolisp
  version: 3.1.0.7-1
  architecture: kopensolaris-amd64,solaris-amd64,amd64,any-i386,any-armel,any-armeb,any-arm,any-avr32,any-hppa,any-m32r,any-m68k,any-mips,any-mipsel,any-powerpc,any-s390,any-sh3,any-sh3eb,any-sh4,any-sh4eb,any-sparc,any-armhf
  source: picolisp (= 3.1.0.7-1)
  status: ok

background-packages: 75818
foreground-packages: 17723
broken-packages: 0

This will check, if the source package ‘picolisp’ in the Sources file can be cross compiled for ‘armel’ on the native architecture ‘amd64’ given the list of binary packages in the Packages file. The generated report is, as for dose-debcheck, encoded in yaml and it can be simply parsed using an off-the-shelf library.

Apt is the canonical tool that can be used to check if a package can be cross compiled. Josh found a few discrepancies between dose and apt results. This was a very good test for both tools: Bug #683786 is a very interesting read…

Dose 3.1.1 (the latest release) should land soon in experimental. Otherwise you can get it from our (new) project homepage.