For about six months I ve been using a Raspberry Pi 3 as my desktop computer at home. The overall experience is fine, but I had to do a few adjustments.
First was to use KeePass, the second to compile gcc for cross-compilation (ie use buildroot).
KeePass I m using KeePass + KeeFox to maintain my passwords on the various websites (and avoid reusing the same everywhere).
For this to work on the Raspberry Pi, one need to use mono from Xamarin:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
echo "deb http://download.mono-project.com/repo/debian wheezy main"   sudo tee /etc/apt/sources.list.d/mono-xamarin.list
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install mono-runtime

The install instruction comes from mono-project and the initial pointer was found on raspberrypi forums, stackoverflow and Benny Michielsen s blog.
And for some plugin to work I think I had to apt-get install mono-complete. Compiling gcc Using the Raspberry Pi 3, I recovered an old project based on buildroot for the raspberry pi 2. And just for building the tool-chain I had a few issues. First the compilation would stop during mnp compilation:

 /usr/bin/gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_1 -O2 -Wa,--noexecstack tmp-divrem_1.s -fPIC -DPIC -o .libs/divrem_1.o
tmp-divrem_1.s: Assembler messages:
tmp-divrem_1.s:129: Error: selected processor does not support ARM mode  mls r1,r4,r8,r11'
tmp-divrem_1.s:145: Error: selected processor does not support ARM mode  mls r1,r4,r8,r11'
tmp-divrem_1.s:158: Error: selected processor does not support ARM mode  mls r1,r4,r8,r11'
tmp-divrem_1.s:175: Error: selected processor does not support ARM mode  mls r1,r4,r3,r8'
tmp-divrem_1.s:209: Error: selected processor does not support ARM mode  mls r11,r4,r12,r3'
Makefile:768: recipe for target 'divrem_1.lo' failed
make[]: *** [divrem_1.lo] Error 1

I Googled the error and found this post on the Raspberry Pi forum not really helpful
But I finally found an explanation on Jan Hrach s page on the subject.
The raspbian distribution is still optimized for the first Raspberry Pi so basically the compiler is limited to the old raspberypi instructions. While I was compiling gcc for a Raspberry Pi 2 so needed the extra ones. The proposed solution is to basically update raspbian to debian proper. While this is a neat idea, I still wanted to get some raspbian specific packages (like the kernel) but wanted to be sure that everything else comes from debian. So I did some apt pinning. First I experienced that pinning is not sufficient so when updating source.list with plain debian Jessie, make sure to add theses lines before the raspbian lines:

# add official debian jessie (real armhf gcc)
deb http://ftp.fr.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ jessie main
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main
deb http://ftp.fr.debian.org/debian/ jessie-updates main
deb-src http://ftp.fr.debian.org/debian/ jessie-updates main

Then run the following to get the debian gpg keys, but don t yet upgrade your system:

apt update
apt install debian-archive-keyring

Now, let s add the pinning.
First if you were using APT::Default-Release "stable"; in your apt.conf (as I did) remove it. It does not mix well with fine grained pinning we will then implement. Then, fill your /etc/apt/preferences file with the following:

# Debian
Package: *
Pin: release o=Debian,a=stable,n=jessie
Pin-Priority: 700
# Raspbian
Package: *
Pin: release o=Raspbian,a=stable,n=jessie
Pin-Priority: 600
Package: *
Pin: release o=Raspberry Pi Foundation,a=stable,n=jessie
Pin-Priority: 600
# Mono
Package: *
Pin: release v=7.0,o=Xamarin,a=stable,n=wheezy,l=Xamarin-Stable,c=main
Pin-Priority: 800

Note: You can use apt-cache policy (no parameter) to debug pinning.
The pinning above is mainly based on the origin field of the repositories (o=)
Finally you can upgrade your system:

apt update 
apt-cache policy gcc 
rm /var/cache/apt/archives/* 
apt upgrade 
apt-cache policy gcc

Note: Removing the cache ensure we download the packages from debian as raspbian is using the exact same naming but we now they are not compiled with a real armhf tool-chain. Second issue with gcc The build stopped on recipe for target 's-attrtab' failed. There are many references on the web, that one was easy, it just need more memory, so I added some swap on the external SSD I was already using to work on buildroot. Conclusion That s it for today, not bad considering my last post was more that 3 years ago

The French version is available on linuxembedded.fr : Cr e un CD d installation d une debian sp cialis e The goal is to build a debian install CD suitable for the distribution of a complete system including the operating system and applications. Debian already has a tool for that purpose: simple-cdd. Simple-cdd is a set of scripts wrapping debian-cd which is the tool used to build official CDs. In our case, we will include some non-free packages (firmwares for instance) and application specific packages in the system. Using simple-cdd Simple-cdd gets some of its configuration from your host computer, so it s recommended to work on a machine similar to your target (in particular the machine should use the same architecture: i386 or amd64). All the following actions should be done in a working directory that will contain the downloads and configurations for our system. We will start by creting a configuration file my-cdd.conf stating the mirror and components to use:

debian_mirror="http://ftp2.fr.debian.org/debian/"
mirror_components="main contrib non-free"

Then we will launch the build-simple-cdd tool once. This will build a local mirror of the needed packages that we will reused later. So be patient this can be a bit long.

build-simple-cdd --conf ./my-cdd.conf

Once done, you should get a CD iso in the images subfolder. Customizing the image To customize our image we will create a profile my-profile that will define which package to install and which extra package to include on the CD (dev packages for instance). Create a profiles folder:

mkdir profiles

Selecting the packages If you ve got an already installed machine (the one you used to test your application) you can ask dpkg to list the installed packages from that machine and use that as a basis.

dpkg --get-selections >package-list

In this file only the names of packages in the install state are needed:

grep -e '\<install$' package-list   awk ' print $1 ;' >profiles/my-profile.downloads

The file my-profile.downloads is a list of packages to include on the CD-ROM. The list of program to install is my-profile.packages . The tool will resolve dependencies, so we don t need to track down all dependencies add add them to these files. Specific packages We want to add some custom packages that we built ourselves to the CD, those packages not present in the debian archive. Let s create a local_pkg folder and fill it with all of our packages. We now can update the configuration to use all those files and make the profile my-profile the default profile.

debian_mirror="http://ftp2.fr.debian.org/debian/"
mirror_components="main contrib non-free"
simple_cdd_dir=$(pwd)
profiles="my-profile"
auto_profiles="my-profile"
local_packages="$simple_cdd_dir/local_pkg/"

If you now run the tool again, you ll get a full custom install CD!

build-simple-cdd --conf ./my-cdd.conf

However you might have missed some specific packages or their dependencies, in that case they will be missing on the CD. To find this out, check the messages for a line like:

WARNING: missing optional packages from profile my-profile: libevent-2.0-5 [...]

In that case libevent from squeeze-backports was missing. Simple-cdd is not able to download packages from backports, so I just added the packages to local_pkg . Customizing the installer Simple-cdd automatically uses a default profile. This profile might not suite your needs. To override it you just have to place modified file in the profiles folder. To do so, first copy the desired file from /usr/share/simple-cdd/profiles/ and update it. For instance the default.pressed file:

cp /usr/share/simple-cdd/profiles/default.pressed profiles

Then update the wanted options in this file. For example the partitioning options. Also as we enabled contrib and non-free you should uncomment the following lines:

d-i apt-setup/non-free  boolean true
d-i apt-setup/contrib boolean true

Adding extra files to the CD Finally we want to add the documentation, sources and other files to the CD. Simple-cdd can add files to the simple-cdd folder but there is no way to add a complete directory structure. However, as we can override the profiles, we can also override some scripts, especially tools/build/debian-cd that builds the CD.

mkdir -p tools/build
cp /usr/share/simple-cdd/tools/build/debian-cd tools/build

Then add the following lines after the $extras_base_dir cleanup:

if [ -d "$cd_extras" ]; then
  mkdir -p "$extras_base_dir"
  cp -a "$cd_extras/." "$extras_base_dir"
fi

Finally let s add the cd_extras variable to our configuration file :

cd_extras="$simple_cdd_dir/local_extras/"

Be careful to not create files conflicting with the CD content, nothing would warn you about that! Conclusion We now have a way of building a debian install CD including any files we might want to deliver with our system: sources and documentation for example.

Now that I have access to the serial console on Samsung e60 reader let s build a new linux kernel for it. The e60 reader has an ARM processor, to compile the kernel we need a cross compilation toolchain.
The first option is to use the one Samsung released with the other sources. It must work, however I don t really like the idea to run binaries from unknown sources.
The second option is to build our own toolchain, we often have to do that for systems that requires patches on the compiler.
Here, Samsung s binutils look like they were taken between 2.17 and 2.18 release (they are named 2.17.50 but are still slightly different from this snapshot) but they don t seam to embed homemade patches. As for ggc I didn t take time to check.
I choose to use the emdebian cross-development toolchain lenny version. (As the article in the french open silicium magazine #1 about FriendlyARM proposes to do). Installing the cross-development toolchain on debian First the archive keys:

sudo apt-get install emdebian-archive-keyring

Then we add a /etc/apt/sources.list.d/emdebian.list file with the following content:

deb http://ftp.uk.debian.org/emdebian/toolchains lenny main
deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main

The we update the package list to install the needed packages:

sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

That s it ! We have now our cross-compilation toolchain installed from packages, so easy to update or remove. The kernel sources Samsung released it s modified 2.6.29.4 version. By cloning the kernel 2.6.29.y git branch, I could quickly see that their changes applied well to the 2.6.29.6 version (the last in the branch). In order to better sort the changes michel.s had splat them into several patches
(patchs on e60-open project). After a few trials I build a series file allowing to apply those patches with quilt or better to import them to a git branch with git quiltimport. The order I choose allows to drop easily some patches (the last ones). One particular point on those patches is that some include binary files:

• fs/rfs/*.o a proprietary journaling layer over FAT. If you want my point ov vue, we don t need that. After all we have free journaling file systems available and linux is able to mount something else than FAT over USB
• drivers/usb/gadget/file_storage.o also the corresponding .c file was removed, the BSD/GPL license from the original code allows a binary distribution (however I didn t check if Alan Stern s name appears in the doc) but I d have liked that Samsung give that source code.

U-Boot Before compiling the kernel, we need the mkimage utility from U-Boot. Here, Let s build the U-Boot released by Samsung, and let s just copy the tools/mkimage to a location in our PATH (that s the only install method I could find).

make smdkc100_config
make CROSS_COMPILE=arm-linux-gnueabi-
cp tools/mkimage ~/bin/

Building linux For the config, one of the patches includes a .config. That file is a copy of config_rfs so even without the previous patch, we can get Samsung s config. Finally we can compile!

make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage

We can then load our kernel by following The kernel testing howto from e60-open project. To load the kernel we will need the following command:

sudo dnw arch/arm/boot/uImage

That it, and it works ! Well almost, the kernel cannot find his modules. This will not be a big deal for the ones included in the sources (but the subject of a next post) but the /lib/modules/max14540.ko and lib/modules/dhd.ko modules are not included in the sources while reporting a GPL license to the kernel. Missing source code The Samsung Open Source Release Center website has a contact form, but it does not seam to work (I even booted my netbook on windows to try with IE8 without success). After browsing the french e60 forum I found their email address and mailed them, no answer so far (not even automatic). Let s wait Conclusion We can compile a kernel for the e60 reader without using the cross tools from Samsung.
There still some work to load modules as the one on the reader are copiled for 2.6.29.4 and our kernel does not want to load them. (I ve already done a few tests but that will be a next posts topic.)
But without the missing sources it will be hard for us to best use our e60 reader. Update: I got an answer from Samsung, they updated the released archive. I still have to look at it.

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).

1. Let s start with a few common bugs reported over the past few weeks:
   • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
   • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
   • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
   • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on http://pkg-xorg.alioth.debian.org/, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
   • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
   • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
   • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
   • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. libI810XvMC.so.1 in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
   • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
   • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
   • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
   • [KiBi] xterm: new upstream, to unstable.
   • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
   • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
   • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
   • [KiBi] libxp to unstable, nothing fancy, that s libxp
   • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
   • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
   • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
   • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
   • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
   • [KiBi] siliconmotion video driver: to unstable.
   • [KiBi] pixman: new upstream release candidate, to experimental
   • [Sean] last but not least: many compiz packages to experimental.

Better later than never, I restarted to triage last week, here is the report for it.

• #526095 ping & close KVM switch change makes mouse stop working.
• #495139 upstream cleanlinks: warning in find usage.
• #550308 ping x11-apps: xedit search dialog shows garbage.
• #555647 ping x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt.

In the mean time, Cyril has been triaging a lot of bugs see Debian XSF News #7.
But there are still 533 bugs to triage. Mike Hommey recently wrote about graphs for the Debian Bug Tracking System. In particular there is now a per maintainer graph, so here it the X Strike Force bug graph ! (Note: the graph does not filter out some bugs as we do on UDD. The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Time for a seventh Debian XSF News issue!

• On the documentation side, I tried to come up with a squeeze backports policy. There are some new upstream releases and xorg-server 1.10 coming up (read below), as well as X stack s migration to testing, to consider before thinking of backporting though.
• Where backports will likely help is for old intel cards (see our FAQ entry). According to Chris Wilson, current kernels/intel drivers are better for 855+, but 830/845 still need a miracle.
• Migrating the X stack to testing needs a bit of coordination, because of the always painful dependency between the nouveau driver and the Linux kernel version. As mentioned in my mail to debian-release@ that would be quite self-contained otherwise. Bottom line: we re waiting for the kernel.
• As announced on debian-x@, the plan is to wait for this migration to happen before uploading new upstream releases of libdrm, the intel driver, and mesa to unstable. Both libdrm and mesa were prepared for Ubuntu, and will be likely uploaded to experimental soon. The intel driver was prepared, but only built against xorg-server 1.10 and uploaded to experimental for now.
• On the xorg-server 1.10 side, the (very late) RandR patches were proven broken, so reverting RandR 1.4 was decided. With some minor tweaks (to the radeon driver), that went quite well, and xorg-server 1.10 got released. Unfortunately, there s still some missing fix for the build system, which explains why I didn t upload a final 1.10 to experimental yet; several patches were proposed already (I checked a bunch of them), but we re still waiting for a final patch.
• As a result of the RandR 1.4 reverts, the video ABI was broken again. Fortunately I gave it a quick try right before 1.10rc3 got released, and noticed the breakage, so the video ABI got bumped. I was therefore very happy with my decision to only upload a bunch of drivers to experimental, built against 1.10rc* (see DXN#6), since I only needed to upload the following video drivers again: ati, dummy, fbdev, intel, mach64, nouveau, r128, vesa. It might make sense to add cirrus to that list next time, for tests under kvm and the like.
• After I poked Peter Hutterer, he kindly and promptly released snapshots for the following input drivers: kbd, mouse, and synaptics, which I uploaded both to unstable (built against 1.9), and to experimental (built against 1.10).
• If you re having troubles with your synaptics device, make sure you have no configuration issues in xorg.conf; even if that used to work somehow, autoconfiguration might fail if there s a misconfigured device (for example, wrong Device option there). You might want to have a look at our how to configure input documentation.
• On the driver side, for 1.9/unstable, Tormod Volden prepared updates for the mga and savage video drivers, which I sponsored.
• Julien Viard de Galbert prepared a new xserver-xorg-video-openchrome snapshot, which I uploaded to unstable.
• He also prepared the addition of a debug package, which I also sponsored after setting the Dm-Upload-Allowed field to yes since he s doing a pretty good job already. It s currently sitting in NEW accordingly.
• A while ago, Thibaut Girka requested the addition of an udeb for the libxtst library, it s now sitting in NEW. Thibaut is working on a virtual on-screen keyboard, initially for use in the Graphical Installer for devices lacking a keyboard (but likely useful in other circumstances). Work is going on, stay tuned.
• Steve Langasek was kind enough to MultiArch-ify both libx11 and xorg; both were uploaded.
• Wayland is getting way more funnier than planned: it is now needed to get mesa built against wayland libraries (to get the wayland EGL platform), and the needed mesa bits are (last I asked) only in master for now.
• On the bugs side, I spent many hours pinging submitters and triaging bugs, mostly on the ati and intel video drivers, as well as on xorg-server again, along with the xorg meta package. (Clicking on a bug graph below leads to a cached full-year view.)

  x-x-video-ati	x-x-video-intel	xorg-server	xorg

• According to the UDD view of XSF bugs, and to Julien s TXBW1, we went down from 880 bugs in november to 540 bugs now.

This report is 2 week late It was delayed by an important event, not the release of squeeze, but the birth of my first child: C lestine is born Monday the 31th of January. My wife and C lestine are both fine now but the firsts days were not that easy. I m starting to recover from the lack of sleep, but I m still very late on my debian tasks So I guess I just drop Triaging for week 13, 14 and maybe 15 Now the bugs I triaged just before :

• #509489 ping & merge with #492783 Switching from tty to X by pressing Alt+cursorkey pass cursorkey keypress to X. OK for this user, waiting for more responses on other merged bugs
• #515546 ping & closed keys stick when switching consoles.
• #369202 ping randomly activated access keys .
• #547143 ping, it s udev now, not hal xorg/evdev/HAL versus serial mouse submitter said serial devices should be handled using inputattach. I think It s been added to some docs but didn t take time to look at it.
• #547888 ping & closed by submitter thanks! high CPU usage in X.org server after some time.
• #489996 mail error, closed problem auto-detecting / selecting some modes.
• #550124 ping & closed some modes aren t recognized.

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Time for a third Debian XSF News issue! Debian XSF News #3

• Julien Viard de Galbert keeps on triaging bugs: TXBW9+10+11.
• After having taken some advice from Sven Joachim, I uploaded mesa 7.10 to experimental. I made both dh_install and dh_makeshlibs stricter, which triggered a FTBFS on i386 and sparc respectively. The former is fixed in git already, the latter still needs to be fixed. mesa 7.9 was already failing on non-Linux ports, and that s still happening for 7.10.
• I uploaded xkeyboard-config 2.1 to experimental. It is the source package for both xkb-data and xkb-data-udeb, which contain XKB configuration data. As mentioned in the changelog that s a big jump (3 upstream releases at once). While preparing it, I noticed a significant size increase: the udeb grew from 3.1MB to 3.5MB. Since size matters in the Debian Installer, I tried compressing the files shipped in the udeb, getting rid of a bunch of extra whitespaces and comments. A few tests seem to show no regressions, and the size went down to 2.6MB. Yay!.
• I did some heavy bug triaging myself, attacking some source packages: xkeyboard-config, mesa, and xorg-server. All in all, I managed to send 80+ mails in less than 16 hours, meaning 5+ answers per hour in average. I spent some more time after that, reaching 150+ mails in less than a week. Many bugs got closed, which can be seen on Mike Hommey s BTS graphs. The most interesting graph can be seen below.
• I closed a very old bug.
• I uploaded a new release candidate for xorg-server 1.9.4 to experimental. Nothing fancy on the upstream side (mostly XQuartz fixes), but on the Debian side, an update of the bug script. As a reminder, that s the script run by reportbug to collect information about the system. That should help us spot more common issues.
• The bug script update was cherry-picked into xorg-server 2:1.7.7-12 for unstable, along with two bugfixes. If everything goes fine, we might try and get it accepted for squeeze s r1 (in other words: the first point release for squeeze).
• I finally managed to get mesa to work on my Intel board enough to let me test wayland. Having a look at the architecture (it has pictures!) and at the FAQ should help interested folks to understand what this is all about. I opened an ITP for it, as well as one for libxkbcommon. The latter is already uploaded and sitting in NEW. We ll also need GL support in cairo, so I requested it.
• I should stress a few points: wayland is really at an early stage of development; all that is going to be shipped for now is a sample compositor implementation and a few sample clients for people to play with. Maybe wayland is going to replace X some day, but it should be noted that it comes with heavy requirements, like GL/EGL support. It s nice since many features and bugfixes are going to land in mesa, but that means that it s going to be available on a restricted class of hardware only, as opposed to X s ability to run more or less anywhere. This also means that early testers might need a pretty recent mesa snapshot. I ll try to make that easier, or at least well-documented. (Many thanks to Darxus for the review.)

It s been a year On a personal note, it s been a year to the day since I first looked into X. After having hacked on the Debian Installer to make it use X.Org instead of DirectFB, I did some heavy bug triaging, resulting in a drop in the xorg-server bug count in March. The same happened past week as written above, resulting in a second drop. In the meanwhile, the bug count remained more or less stable, since we try to reply quickly to new bugs, and since Julien Viard de Galbert does bug triaging on a weekly basis: One might ask: what does maintaining X mean?

• Packaging mostly everything X-related.
• Taking care of incoming bug reports as well as older ones.
• Working with upstream (which is going to be the subject of a later blog post), as well as coordinating with Ubuntu.
• Keeping an eye on the Graphical Installer.
• Writing documentation targeted at both users and maintainers.
• Advertising XSF s work.

I ve been lasy about the reporting lately, so this is a 3 weeks update at once ! The bug count according to udd is down to 818. I guess this is due to Kibi s triaging on input related bugs, but I helped to close a few one too ! I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again !

• #451708 ping & close xserver-xorg-input-synaptics: Option GuestMouseOff true not working.
• #424743 ping & forwarded X11 pen driver doesn t work on tabletPC Fujitsu Stylistic 2300 (fix included).
• #499664 ping, try nouveau X fails to start with xserver-xorg-video-nv 1:2.1.12-1.
• #512614 confirmed & upstream xset dpms rejects reasonable values as illegal.
• #512711 ping and later closed All keypresses repeated roughly three times each, makes login impossible.
• #513128 ping X server crashes every time when gnome-screensaver starts.
• #486356 merge with #482592 numlock led is inversed (using numlockx) .
• #515737 ping & closed After upgrading from Etch to Lenny, mouse pointer is very slow and keys don t repeat.
• #515840 ping Desktop is not using full screen after upgrade from etch to lenny.
• #516860 closed after looking at the git history Xorg with -sharevts use almost 100% of the CPU.
• #362434 ping & closed, suggested to try nouveau nv has problems with xcursor-themes.
• #502131 ping & closed System gets into a state and fails to process modifier keys.
• #453296 closed (old ping unanswered) MacBook: cannot assign right mouse click to lower Enter key.
• #504537 ping X server eats CPU on sparc.
• #502313 ping Applications are getting ghost Alt keypress events, but I press no keys.
• #527118 ping autoadded input devices kill X server.
• #270887 forwarded startx and xinit do not preserve client arguments.
• #542542 closed after looking at the git history non-VGA compatible graphics devices won t run X.
• #492888 ping xorg ignores keystrokes.
• #543210 merge with #492783 Alt-F7 to return to X, passes F7 key to top focus d window.
• #524413 closed xauth fails with xorg 7.4, this was actually an xinit bug and the git log lead to #549377 being closed

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Time for a second Debian XSF News issue! I ll skip stuff related to the new katamari since I wrote about that already.

• I reassigned a big memory leak to the kernel. It happens with a Radeon HD 4200 card and the xserver-xorg-video-ati driver.
• I mentioned on debian-boot@ how to reassign bug to the xorg meta package. We regularly receive bug reports about either X-related issues in the graphical installer, or about the just-installed X stack.
• I started a xsf-docs repository to hold some documentation, trying to keep up-to-date information about the X stack. The wiki is unfortunately a bit of a mess, and contains some very old stuff like an ancient FAQ. This has historical value, but doesn t really help. ;) The new documentation lives at http://pkg-xorg.alioth.debian.org/, and it should be packaged at some point (maybe merged into an existing package).
• Julien Cristau uploaded xorg-server 2:1.7.7-10 to unstable, and it was unblocked for squeeze.
• Triage happened on the xorg meta package, which should be our frontdesk : people should report or reassign bugs against this package when they re not sure which X component is at fault.
• The intel driver was tweaked to fail properly if KMS is disabled, so that the X server autodetection code could fall back to vesa. Unfortunately, it turned out to be insufficient in some cases. That was fixed in the we wish you a working driver release. The latter migrated to squeeze.
• On a related note, we discovered (through bug reports), that the intel driver in experimental somehow needs libdrm-intel1 from experimental. Not that symbols would be missing, but some nasty bugs happen when the version from unstable is used instead. We still need to address this issue.
• Julien pushed more patches to the server-1.7-branch upstream, which I merged, uploaded as 2:1.7.7-11, and got unblocked for squeeze. A crasher was reported right after that, but it s probably going to wait for squeeze r1 (see next entry).
• Bernhard R. Link reported an issue with old XF86Config-4 configuration files. We cloned that bug report and fixed both in git. I ll probably upload xorg-server 2:1.7.7-12 to unstable soon with those fixes. Then we ll probably upload 2:1.7.7-12~squeeze1 to stable-proposed-updates once squeeze is released.
• To keep track of this kind of bugs, I ve started using the squeeze-candidate usertag. That s documented in the how to triage bugs page, added to xsf-docs.
• I updated the cirrus driver to improve support in QEMU and FAUmachine, it s been unblocked for squeeze.
• I fixed partial upgrades for the libx11-6 and libx11-data packages.
• Julien Viard de Galbert has been very active in the bug triaging area! See the reports: TXBW3, TXBW4+5, TXBW6, TXBW7, TXBW8.
• He also blogged about how easy it is to triage X bugs. Join the fun!
• I also wrote a tiny doc about configuring input, and poked a bunch of bugs for the following input drivers: evdev, kbd, mouse, and synaptics.
• I digged into the infamous gdm3 bug, which causes xkb options to be lost when one logs in. A summary is available in the upstream bug report.

There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer s job. While it s true in general, some understaffed teams are so flooded by bugs that they just can t do it.
I ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks! Then the thread evolved in lots of directions, I m not following all of it, but there was the question of the bug triaging and as I m doing it for the X packages, I want to share about my experience here. The available triaging docs The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o ! Now if all those docs don t help you, then try to improve the docs as a first step ! Talk with the maintainer(s) Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway. My current process This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!

1. List bug from UDD: XSF unstable bugs sorted by date.
2. Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
3. Read the report, don t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
4. If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it s not that often that I have something to test).
5. Decide what to do, most of the time, I will ping the submitter.
6. I m a mutt user, and to my help the bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
   So I launch bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.
   The triaging procedure suggest to ping -submitter, but using mutt it s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
7. In the message, always try to be kind and helpful, most of the time ask to test newer versions.
8. Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
9. When the submitter answers, just react accordingly, if the bug can be closed, then close it !
10. If after some time, the bug are still not answered, consider closing them (I haven t started that yet, but this will probably get the bug number down faster:) ).

Note: Sometime I don t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. To submitters, please keep the bug CCed when you answer, thanks. For the skeptics Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don t close bugs if I m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! Also this work might look boring, but it s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I ve learned on Xorg. Conclusion As long as I have time for it, I ll continue to triage bugs and I d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! Get involved !

Happy new year !

• #440495, #437255 ping Keyboard steal after stopping touchpad.
• #476143 Closed: submitter never answered Brice s request xserver-xorg-video-nv: Driver reports wrong display size.
• #468331 ping xserver-xorg-input-kbd: xorg.conf okay, no AltGr though but setxkbmap -variant nodeadkeys de works.
• #498210 ping xserver-xorg-input-kbd: ctrl:nocaps keycode 66 is on both the control and shiftlock modifier list.
• #488685 ping & close: hardware not available anymore xserver-xorg-input-kbd: Acer TravelMate 2303M : the Fn key is inverted.
• #511910 ping xserver-xorg-input-evtouch 0.8.7-3 does not work with HAL.
• #513297 close x11-xkb-utils: When I use the setxkbmap command i get the following error: Error loading new keyboard description.

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

For some reason¹ bug #607242 did not make it to the debian-x@d.o mailing list, I got aware of it only by the message shirish sent to my blog.
If he didn t write to me, this bug will have waited for what about 3 years until I got all the 800+ bugs triaged ? So please you can help triaging X bugs, first subscribe to the debian-x mailing list so you can get the feeling of what to respond to some bugs, and join the TXBW effort

• #607242 reassign & give+ask moreinfo.
• #403350 ping & try nouveau xserver-xorg-video-nv: xset dpms force off does not turn off the backlight.
• #469104 config suggestions & close xserver-xorg-video-tdfx: screen resolution too low.
• #476198 closed xserver-xorg-video-radeonhd: Cannot turn on a secondary screen without restarting X (xrandr-related problem).
• #492783 ping, unreproducible vt switch key combination leaks to clients.
• #496150 ping xserver-xorg-core: shutting off monitor messes up display.
• #504104 ping & closed xserver-xorg-input-mouse: Emulate3Buttons stops working from time to time.

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date. Note 1: The Xorg.0.log file was so huge that the mailing list did not accept the mail.

An other week, a few more bugs looked, unfortunately in the mean time the number of bug grew to 875

• #471423 ping ati driver ignore Option Enable false in monitor section, but accept the undocumented Option Disable true .
• #468561 ping & closed vesa: switching resolution with xrandr after suspend-to-ram.
• #447526 ping memory leaks.
• #475534 closed as reported said, oclock seams to work correctly
• #466044 ping xserver-xorg-core: internal screen of laptop with external screen attached not blanked when laptop closed but still in use.
• #482317 ping libxt6: scroll list overflow in gv.
• #425814 ping xserver-xorg-video-ati: Xv broken on Mach64 3D Rage LT Pro AGP-133.

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Last week I was too busy for the triaging work, so I did more this week Anyway there are still some 871 bug candidate for triaging, so again, any help would be appreciated ! Also I d like to thank again people giving me cheers and advices when they receive my pings The buglist now:

• #419986 ping & close server lockups related to dri.
• #415588 ping modelines are ignored.
• #417601 ping & close mga dri issue.
• #439357 closed 3 year old install issue Not relevant anymore
• #377847 ping nv driver: No way to set 1600 1200, apparently it works with nouveau.
• #449039 ping crash with too many remote clients.
• #440880 closed 3 year old, user never replied.
• #457440 ping ctrl-alt keyboard combinations ceased working after prompts by ratpoison.
• #413691 ping & closed arrow keys sometimes produce repeated digits.
• #451537 ping then closed by submitter Can no longer scroll up/down with edge of touchpad.
• #437254 ping touchpad issue, at first the reported tried to hack out a patch
• #444183 ping macbook xserver-xorg-input-mouse: Vertical scrolling doesn t work anymore.
• #445625 ping: try nouveau? crash with nv driver and dual head configuration.
• #428091 ping Display has wrong colours and is offset (in 16bpp only).

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

This week it has been harder for me to start on this but KiBi s post Debian XSF News #1 pushed me to continue. Thanks for the cheers!

• #331637 ping Xrandr disabled while Xorg log says the opposite.
• #321357 tagged wontfix xset behaves as intended, there is no easy way to set keyboard autorepeat for single key
• #242442 close xclock -rv looks visible to me.
• #427346 close was already tagged unreproducible, I couldn t reproduce it either so I closed it.
• #169239 ping 8 year old wish probably too late ?
• #431449 ping xmodmap errors when launched by keyboard shortcut.
• #202923 close xorg has timestamps in server log messages.
• #252214 tagged wontfix Andrew Pimlott (reporter) said This bug probable needs a NOBODYCARES tag. so wontfix will do it.

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Since people seem to like it, I ll be trying to publish some news about ongoing work on the XSF side, on a (possibly) regular basis. Let s have a look at what happened since last time I blogged about X in Debian, mostly by checking what appeared in my =debian-x mailbox. Debian XSF News #1

• mesa 7.9 was uploaded to experimental by Julien Cristau.
• Jurij Smakov uploaded a bunch of xserver-xorg-sun* drivers to experimental for us.
• I started a debian/xsf-tools.git repository to gather some tools for people wishing to work on X-related packages. For now it contains the usual tagging script, an mrconfig file to ease downloading/updating all XSF packages, thanks to the mr tool, and some bits of documentation. I also added the git URL to the upstream repositories to debian/watch* for all packages.
• Christopher James Halse Rogers started a discussion about the Ubuntu plans for Natty release. This is mostly about DRI, and unfortunately, I haven t digged into mesa yet, but thankfully we had some answers from upstream there.
• I uploaded many xfonts-* packages, prepared by Julien Cristau.
• I uploaded many x11-* bundles as well. Why are we creating bundles? Because there are many tiny applications, which (from the distribution point of view) don t deserve their own package. For example x11-apps contains toys like xclock, xeyes, or xlogo.
• I uploaded many lib* packages, plus pixman. When there were no fundamental changes (as in: no need for an shlibs bump, which could prevent some packages from migrating), those were uploaded to unstable, others went to experimental.
• Some cherry-picked patches were added to libx11, from a stable branch. The 2:1.3.3-4 version has been unblocked for squeeze, and brings support for Compose O A and for Compose \ o /.
• I also reverted the removal of the (famous?) apple:badmap and apple:goodmap options for macintosh keyboards in xkeyboard-configuration (which produces the xkb-data binary package), thanks to a bugreport from Yves-Alexis Perez; it s been unblocked for squeeze as well. If someone notices an inversion of those keys after the upgrade, that s probably because one of those options was added at some point, was ignored and unnoticed, and finally taken into account. Depending on the case, it s sufficient to switch to the other one, or to remove it entirely.
• Many bug submitters were pinged by Julien Viard de Galbert. But another report should appear soon, following TXBW1 and TXBW2.
• More drivers were updated to their latest upstream versions, and uploaded to experimental.
• Thanks to an xserver-xorg-video-mga user (Ferenc W gner), we were able to extract and apply a patch from launchpad s #292214 to fix the dual head breakage. Since we haven t seen any complains since then, we ll probably ask for an unblock for squeeze.

What are the XSF plans?

• Keep close track of upstream work, possibly contributing there. We re mostly up-to-date with the RC1 for X11R7.6 and it d be nice to keep it that way, but that requires time/work.
• Keep on answering new bug reports quickly, before bug reporters vanish or switch to another system (a broken X can trigger this kind of reaction).
• Keep on pinging older bug reports. Anyone is welcome to join and help, there s no high profile required to do so, as confirmed by Julien Viard de Galbert.
• To make it easier, it would be nice to have some documentation written down, instead of relying on everyone s own memory. There s a lot of wiki pages about X in Debian, but they might be outdated, incomplete, or inaccurate. Building up some consistent documentation should help people understand how they can contribute, and how to do so.
• It d be nice to have some documentation targeted at users as well, so refreshing the old XSF FAQ would be welcome, as well as shipping it in some package for offline use.

Hey, one more week !

• #418377 ping & closed (default X resolution for etch?! installation).
• #419960 ping & closed (submitter screen apparently does not support DPMS).
• #409337 ping (Xorg/Gdm vertical refresh config).
• #389030 closed (boot with no usb mouse now work !).
• #309226 ping (xnest crash, seams fixed now).
• #397438 ping (dual monitor on old ati driver).
• #414275 ping, user can t test it any more, so closing.

Well my UDD query report 879 bugs today not a great improvement since last week if more bugs are opened than I can close, I m not going to make it alone ! The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

I did just yesterday ! I was hacking on fluxbox and rebuilding the package to test directly on my system.
When I was happy with my changes I thought, I should write a patch for this
But guess what ! With format 3.0 (quilt) it was already there, in the debian/patch directory, just waiting to be renamed and completed with a nice DEP-3 header ! It is a lot more easy to contribute with those tools! So thank you debian folks !

Here is my report for the first week, (actualy I m a little bit late, but friday loked like a better day for such reports)

• #385803 Reported upstream.
• #391452 Wontfix, there is a nicer alternative.
• #335515 Ping & closed.
• #394529 Asked for a phrasing (any native English writer can help here).
• #252585 I m not sure the actual needed changes worth it, so I proposed to just document it, waiting for feedback
• #379480 Ping & closed.
• #290881 Today s package has changed, so reassigned and updated info.
• #251449 Added info, if someone is more easy with wiki stuff than bug triaging, then updating the FAQ is a work for you .
• #420018 Ping & closed.

That s it about 880 bugs more to go ! The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.