On Thursday 11 February 2010, Cyril Brulebois wrote: > You can find the pool at: > http://people.debian.org/~kibi/udebs-v1/
Thanks. I was going to ask for that. Only i386 should do fine for the time being. > I think my next moves are going to be: > - Tweaking lowmem case for X (should be easy once I've figured out > how this and that components in d-i work) There is not really a lowmem case for the graphical installer. Just a point at which it falls back to using the newt frontend instead of the gtk frontend. Memory usage is not the main issue for the graphical installer; initrd size is. I'll explain more in other mails. > - Fixing the build of the fbdev driver to get 2 proper flavours > (should be easy), and maybe having a look at the HACK/TODO bits > I've left along the path in the various git branches/standalone > patches. You mean deb and udeb? That would be great. And the same goes for other new packages too. Almost anything that can be disabled at compile time is worth doing. IMHO this should be the main focus for now. > - Trying to integrate console-setup properly this time, so that once > one has set it up once in d-i, preferences can be fed directly into > the installed system, so that one doesn't need to answer the very > same questions again. Even though console-setup might chosen in the > end (although it looks like the way to go to tweak X), that's going > to be a good exercise for me. :) That's a fairly big issue. Please have a look at the post-base-installer script for kbd-chooser which already does that if kbd-chooser is used in D-I (basically it preseeds console-setup in the target environment based on the keyboard selection in D-I). Maybe there's an alternative implementation possible, but I don't really see why. I'd say that using preseeding is a more obvious solution when console-setup-udeb is used than when kbd-chooser is used as the questions should be the same (and thus also the desired values). But my general opinion remains that console-setup-udeb does not yet have the quality we want for D-I, although I also see that it's probably unavoidable for an X.Org based G-I. More on that in a later mail as well. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
