Log in

No account? Create an account
30 January 2010 @ 01:50 pm
Please save the graphical installer  

The current state of g-i, the graphical version of the Debian installer is very concerning.

Currently, the GTK+ version in squeeze (2.18 and soon 2.20) has very serious bugs in the DirectFB backend, which make it unusable for g-i. Because of that, the first alpha version of d-i will ship without graphical installer support.

Unless someone steps up and does something, this will be the end of the graphical installer. Among other things, it means the end of support for several languages: Indic scripts, Thai, Amharic, and all RTL languages.

Option 1: fix GTK+ DirectFB support

Until now, we always found some good wills who volunteered to fix GTK+ so that g-i worked again. I’d like to thank Attilio Fiandrotti and Sven Neumann for their past work, but unfortunately it seems they have better things to do now.

If someone takes over their work and hacks on GTK+ to get it to work correctly again on DirectFB, we will be able to go on this way at least for the squeeze release. This requires someone with serious DirectFB knowledge who will not be afraid to dig into the GDK internals.

Option 2: switch to X11

If GTK+ doesn’t work on DirectFB, there is another plan, but it needs to happen fast. It should be possible to make the installer work on X11. This has the advantage that we know X11 works fine and is maintained in the long term, and so does the X11 GTK+ backend. This has also the drawback to make the installation media slightly larger.

This requires quite some work on udebs:

  • Packaging of a number of libraries: at least libx11, libxi, libxext, libxrender, libxft, libdrm, libgcrypt, libpciaccess, libpixman, libxau, libxfont, libudev
  • Maybe a few extras: libxcursor and dmz-cursor-theme (to have a nice cursor), libxrandr (to be able to select the installation resolution), libthai (for Thai language support)
  • Packaging of the X server: xorg-server, xserver-xorg-video-fbdev
  • Changes in the gtk+2.0 configure scripts so that other X11 extensions can be explicitly disabled
  • Rework of udebs for cairo, pango1.0 and gtk+2.0 so that they are built against X11
  • Rebuild the installer against the X11 GTK+ version
  • Changes in the installer startup scripts: start the X server, configure the keyboard the X11 way, etc.

It looks like a lot, but there’s nothing complicated in it. Anyone familiar enough with Debian can do this, with a little support from the maintainers of said packages. So this could well be you. Assuming you’re interested in keeping g-i alive.


Other possibilities to support complex languages include:

  • Use festival to ask questions and voice recognition software for the answers (we offer no guarantees for accidental wiping of your hard drive).
  • Boot a live OS in a virtual machine and ask the user to run Google translation on the text (unfortunately we’d need to ask in English).
  • Render PNGs of all questions that could be asked and display them directly using DirectFB (requires migrating to Blu-ray by default for installation media).
  • Port the installer to use the GTK+ Win32 port and pre-seed all the debconf questions before rebooting.
  • Come on, be creative.
    (Anonymous) on January 30th, 2010 01:28 pm (UTC)
    or switch d-i to use qt instead of gtk ?

    Qt/Embedded works and uses framebuffer. Needs to be packaged for debian though.

    debian-qt-kde team is ready to guide such work.
    np237np237 on January 30th, 2010 02:30 pm (UTC)
    Re: Qt/Embedded
    Basically this doesn’t mean porting g-i, it means rewriting from scratch in C++.

    If you find someone who wants to do that and maintain it after, why not? But it’s a lot more work than the other options.
    (Anonymous) on February 1st, 2010 08:13 am (UTC)
    Re: Qt/Embedded
    Or in Python using PyQt. Should be easier than C++.
    (Anonymous) on January 30th, 2010 02:24 pm (UTC)
    Option 3 qt (lighthouse).
    gravityboygravityboy on January 30th, 2010 04:37 pm (UTC)
    Ah, I was wondering when this would happen. When g-i was announced I told them that they should be focusing on using X11 as the backend rather than DirectFB. The response was "No, it's really well supported and RH is using it." Sure enough, here we are today. This could have been avoided years ago if the maintainer had been willing to listen to his own X team. I hope someone steps up and ports this over to X, since that's the future. DirectFB is a waste of time.
    schmexygeekschmexygeek on January 30th, 2010 09:07 pm (UTC)
    Not a troll. Dead serious
    Option 3) Use Ubuntu's casper
    np237np237 on January 30th, 2010 09:35 pm (UTC)
    Re: Not a troll. Dead serious
    Or anaconda.
    kbloom.myopenid.com on January 31st, 2010 01:37 am (UTC)
    Hebrew (and possibly Arabic, but I don't know anything about Arabic) can be supported on the console with Fribidi and an appropriate font.
    (Anonymous) on January 31st, 2010 03:08 am (UTC)
    What, does GTK+ upstream not have a test suite for GTK+ with DirectFB??
    (Anonymous) on January 31st, 2010 07:50 am (UTC)
    Switch to X11
    I would vote to switch to X11. The little disk space saved by the directfb means nothing for today's installer and storage devices (USB flash stick, CD/DVD). The harsel the directfb brings will be endless.
    (Anonymous) on January 31st, 2010 04:19 pm (UTC)
    So this could well be you.
    > So this could well be you.

    Why not YOU then? You seem to have interest enough to write a very long post, why not giving it a try to implement???
    (Anonymous) on January 31st, 2010 09:43 pm (UTC)
    Re: So this could well be you.
    LOL, yeah, why not you, Joss? If you have time to write long blog posts, it surely means you don't do enough (http://qa.debian.org/developer.php?login=joss&comaint=yes)...
    (Anonymous) on February 2nd, 2010 03:50 pm (UTC)
    Re: So this could well be you.
    He could do more if he wants to. But he is lazy, thats why he is searching for others to do his work. This is typically for Debian. Not getting stuff done right.
    Theppitak Karoonboonyanantheppitak on February 1st, 2010 11:02 am (UTC)
    libthai; some X11 problem
    > Maybe a few extras: ... libthai (for Thai language support)

    Right, it's an extra. g-i doesn't need libthai for Thai support. It just improves line wrapping a little bit.

    X11, however, won't work on my Fujitsu S6010 laptop at least, due to broken i830M support.
    (Anonymous) on February 5th, 2010 03:53 pm (UTC)
    Re: libthai; some X11 problem
    You're pointing at a bug in the intel driver. I don't think d-i will use that. So far we're looking at a generic fb kernel driver with xf86-video-fbdev on top.

    Julien Cristau
    (Anonymous) on February 2nd, 2010 02:01 pm (UTC)
    take X11, but only on big images
    I think a compromise would be to port to X11 and support RTL langs. This would be no problem on big images. On small images like the business netinst we could drop support for the g-i (if there is not enough space). This way all people with the need of RTL lang support can get it, but are forced to use the big images.