Debian Live After Debian Live

Get involved

After this happened, my next step was to get re-involved in Debian Live to help it carry on after the loss of Daniel. Here’s a quick update on some team progress, notes that could help people building Stretch images right now, and what to expect next.

Team progress

  • Iain uploaded live-config, incorporating an important fix, #bc8914bc, that prevented images from booting.
  • I want to get live-images ready for an upload, including #8f234605 to fix wrong config/bootloaders that prevented images from building.

Test build notes

  • As always, build Stretch images with latest live-build from Sid (i.e. 5.x).
  • Build Stretch images, not Sid, as there’s less of a chance of dependency issues spoiling the build, and that’s the default anyway.
  • To make build iterations faster, make sure the config is modified to not build source & not include installer (edit auto/config before ‘lb config’) and use an apt caching proxy.
  • Don’t forget to inject fixed packages (e.g. live-config) into each config. Use apt pinning as per live-manual, or drop the debs into config/packages.chroot.

Test boot notes

  • Use kvm, giving it enough ram (-m 1024 works for me).
  • For gnome-desktop and kde-desktop, use -vga qxl, or else the desktop will crash and restart repeatedly.
  • When using qxl, edit boot params to add qxl.modeset=1 (workaround for #779515, which will be fixed in kernel >= 4.3).
  • My gnome image test was spoiled by #802929. The mouse doesn’t work (pointer moves, but no buttons work). Waiting on a new kernel to fix this. This is a test environment related bug only, i.e. should work fine on hardware. (Test pending.)
  • The Stretch standard, lxde-desktop, cinnamon-desktop, xfce-desktop, and gnome-desktop images all built and booted fine (except for the gnome issue noted above).
  • The Stretch kde-desktop and mate-desktop images are next on my list to test, along with Jessie images.
  • I’ve only tested on the standard and lxde-desktop images that if the installer is included, booting from the Install boot menu option starts the installer (i.e. didn’t do an actual install).

Coming soon

See the TODO in the wiki. We’re knocking these off steadily. It will be faster with more people helping (hint, hint).


Xautomation: visually grepping for gui elements

In my first article about testing tuxpaint with xautomation, I mentioned that I wasn’t happy with hardwiring button positions. But before I could proceed, I discovered a bug in xautomation that prevented me from using visgrep to search for the “Yes” button in tuxpaint screenshots. Fortunately, the fix was straightforward enough after reading the libpng man page.

At the same time, I also decided to borrow an idea from the example scripts in the xmacro package. Running the test script on the tester’s own display may be fine for developing the script, but it is nice to be able to run it on a virtual display after the kinks are worked out. For one thing, the test doesn’t get in the way of other things when you’re waiting for it to finish. For another, it is much easier to control the test environment. Xvfb is perfect for this.

The resulting script requires tuxpaint, Xvfb, xautomation with the above patch applied, xbase-clients and Imagemagick.


Tuxpaint GUI testing with xautomation

Tuxpaint could be a poster child for l10n. It has translations now for 68 different locales. The large number of locales poses somewhat of a problem for testing1.

Tuxpaint 0.9.16 just released. During the release preparation, the manual testing of all of these locales drove me nearly insane. So to help out next time, I created the following bash script using xautomation2, imagemagick and xprop (from xbase-clients):

root_geometry=`xprop -root _NET_DESKTOP_GEOMETRY |cut -d= -f2`
root_x=`echo $root_geometry |cut -d, -f1`
root_y=`echo $root_geometry |cut -d, -f2`

capture_tuxpaint () {
   tuxpaint --startblank --nolockfile --lang $1 --640x480 --windowed --nosound &
   sleep 1
   xte "mousemove $xc $yc"
   xte "mouseclick 1"
   sleep 1
   xte "key Escape"
   sleep 2
   import -silent -window "Tux Paint" $testname-$1.png
   xte "mousermove -120 -40"
   xte "mouseclick 1"

for lang in `tuxpaint --lang help |awk '$1~/^[[:lower:]]/ {print $1}'`; do
   capture_tuxpaint $lang

I’m not entirely happy with it, but it’s at least a starting point. Ideally, I’d make .pat files to use with visgrep to find coordinates for the button images instead of hardwiring the approximate button positions. Also, the script needs a companion script to configure the system for testing (i.e. perform the locales configuration and install all fonts).

Here are the resulting screenshots which show up a few problems with the translations. It looks like the quit dialog strings have been updated since they were first translated, so now we need retranslation for several languages. Also, there are some languages, like Swahili and Klingon, for which there are no locales in glibc in Debian. I’ll have to talk to the glibc maintainers about that. And for that matter, I don’t even know if a DFSG-free Klingon font exists.

In any event, I’m delighted with the results, and look forward to using xautomation more for GUI testing.

1 For one thing, several languages require special fonts. For another, there is no way to get tuxpaint to tell you what locales it supports. Granted, there is --lang help, but this is a crude approximation, as the mapping between language and locale is arbitrarily hardwired (which hmh on #debian-devel irc pointed out to me is just plain wrong). It doesn’t help me at all in the arduous task of configuring glibc locales so I can test them. For that, I need to look at i18n.c.

2 I tried using xmacro at first, but xmacrorec just made my pointer jiggle back and forth. It seemed like it was updating the position for a short distance, and then X was resetting it back to the former position of the pointer. Some strange interaction with my window manager, perhaps? But ultimately I am happier with the xautomation approach anyway.