[Debian-eeepc-devel] The future of Debian eeepc installer, TODOs up for grabs

[Ben Armstrong]

The wiki is gradually being updated to reflect the preference now for 
most models to use the standard Squeeze installer.  Here are my thoughts 
on how things should look once Squeeze releases:

1. we will no longer support debian-eeepc.img (custom lenny installer)
2. eeepc-acpi-scripts should be present in standard install images, so 
there is no need for any user to use our custom image (see 4) to install 
Debian on any model of Eee PC
3. eeepc-acpi-scripts should therefore also be present in standard 
debian-live USB images, which will also include live-installer and 
live-installer-launcher
4. we will provide a custom eeepc-installer live USB image with a few 
things tweaked for convenience (likely only one edition, LXDE-based)

It's 4. I've been working on for the past couple of months.  Here are 
the issues remaining to finish the work:

a) The cdrom-detect udeb does not properly support 
cdrom-detect/try-usb=true, causing it to fail to locate debian-installer 
on the USB image and look for a CD-ROM instead.  My workaround: tell it 
'no' when it prompts to load from external media, but proceed to select 
drivers manually, choosing 'none' and then specify /dev/sdb1, or 
whatever your USB device is for the installer as the CD-ROM device.  
I've been discussing this with the debian-live team on irc and hope to 
have something to test soon.  Ultimately this is an issue the 
debian-boot team needs to resolve, not debian-live itself.

b) The 'lxde' metapackage Recommends gdm which causes a whole chain of 
other dependencies to be dragged in, eventually bloating the image with 
most of GNOME!  Ideally lxdm should replace it, but it needs more work 
upstream.  Slim has been suggested as a possible replacement, so I'm 
using that in my test images, but we haven't yet settled on that as 
*the* solution.  In particular, I want to ensure that slim is really 
release-ready, and it has been pointed out to me that there are some 
security issues listed at 
http://security-tracker.debian.org/tracker/source-package/slim that 
should be addressed (at least the second one).  We'll have to talk to 
the security team about that.

c) Obviously, we want to finish items 1 and 2 from the list above to go 
into the image.  Finishing the eeepc-acpi-scripts integration branch 
that Luca Niccoli started (see 
http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-May/003595.html 
and the discussion that follows in that thread) is necessary to make 
this work.

d) The WPA support I mentioned again in my previous post today is a 
candidate to add to a custom image, should it fail to make it into 
Squeeze proper.

e) The misbehaving battery applet in lxpanel mentioned here 
http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-June/003644.html 
needs to be fixed.

f) wicd fails to default the wifi interface to 'wlan0' and fails to meet 
our expectations as a lightweight alternative to network-manager-gnome 
(measuring ram consumption shows NM is actually lighter!) Given that NM 
in Squeeze now surpasses wicd in terms of features and 'just works' with 
LXDE, I have discussed with the LXDE team upstream and we agree that it 
should be installed by default.  (Of course, die-hard wicd fans can 
switch this after installation.)  This isn't really an outstanding issue 
because I have already had a patch accepted in git for live-helper to 
make this change in the lxde packages list.  All we need now is to wait 
for the next release to be uploaded.

g) live-installer-launcher needs more work.  i've been discussing this 
on #debian-live with the team and am working with them on some finishing 
touches.  a) is a big blocker for me making progress, as the workaround 
I mentioned fails in that case (probably because /dev/sdb1 is already 
mounted -- I thought maybe I'd try using the 'toram' option at boot to 
work around this, but haven't yet tried it).

h) some key mappings that used to 'just work' with eeepc-acpi-scripts 
(notably the sound hotkeys) will be dropped, as the kernel input layer 
now handles these as ordinary keysyms, so the WM/Desktop Environment 
should just be configured to respond to the appropriate keys instead.  
Just this week I discussed this with the LXDE team and they agree we 
need to provide openbox key bindings by default.  All that remains is to 
see this accepted into the upstream codebase and a new package release 
uploaded.  I haven't yet thought about how the LCD/VGA toggle will be 
handled.

As you can see, there is lots left to do for Squeeze, so if anyone has 
been itching to help with the release but doesn't know where to start, 
pick something that looks like you could help with and dive in.

If editing the wiki is more your speed, I've already mentioned in prior 
posts (which you can find in the archives) some tasks that need to be 
done, or you can bug me here on the list or in irc for tasks to do.  
That is also important work, and there's lots of it.

Ben