(reply-to: debian-boot) Debian Installer team meeting number 10 has been held from 17:00UTC to 18:30UTC on Saturday March 4th 2006. There were about 80 people connected to the channel during the meeting and 13 of them spoke during the meeting at least once. The full log of the meeting is available at http://people.debian.org/~bubulle/d-i/irc-meeting-20060304/log Beta2 release summary --------------------- Because of CD build problems, the release has been delayed a bit. It is expected to happen during the next week, possibly before Saturday March 11th (post-meeting comment: that is *today*, folks..:-))). The whole team thanks Frans Pop for the great work managing this release as his first release with the release manager hat. Issues that will pop up during the last tests will have to be mentioned in the errata file. Next release: beta3 or RC1? --------------------------- Deciding about the "name" of the release is not trivial. Naming it "beta3" means more new features allowed while "RC1" would mean a begin of a freeze targeted at etch release. The discussion concludes that a beta3 release is possible. A very short schedule is needed as beta2 is very likely to be broken by the upcoming mirror reorganization, except for i386 and powerpc. Frans proposes to target a beta3 release for early April but indicates he might be unavailable for managing it. No candidate popped up to act as temporary release manager (post-meeting note: Joey Hess mentions he's OK to manage the release if Frans isn't available). This means that the post-beta2 changes should be focused on issues that are identified as important. The next 2-3 weeks are OK for (tested!) changes and development should again slow down after. Kernel .udeb and the way to handle out-of-tree and non-free modules ------------------------------------------------------------------- We need some way to load non-free or third-party modules or firmware into d-i. The kernel team will probably drop several modules from the main tree, which is likely to drop support for several hardware (tg3, ql, etc). Such work would also be an occasion to offer entry points to load third party drivers, non-free firmware and all kinds of additionnal hardware-supprote related stuff inside d-i. Bastian Blank and Sven Luther summarize the needed changes in D-I: - anna: allow selection of the components - libdebian-installer: support reading of more than one packages file - ftp.debian.org: experimental udeb section (post-meeting comment by Joey Hess: "which Leaves off the whole issue of modules needed before anna is available") Loading non-free firmware is mentioned to be only dropping the firmware files in /lib/firmware so that they're loaded by udev (post-meeting comment: we also need to install them in /lib/firmware on the installed system in base-installer, probably) The idea of non-free installation images pops up but, later, there were comments that it would make the maintenance of D-I builds more complicated, and it is enough complicated already. Another argument is: as soon as non free images will be available, people will always use them. Sven Luther proposes a mini plan: 1) we (Bastian?) will implement the needed anna/libd-i changes so more than one source is possible 2) The kernel team splits out non-free modules into a non-free packages, or eventually non-free firmware only 3) once both are done, come up with a test-case which shows how it works, and present it to the d-i team. 4) we do all this in time for beta3, and everyone is happy Frans (with Colin Watson's agreement) thinks that the schedule is pretty irrealistic, especially if to be done before beta3. A more detailed plan, posted on the debian-boot mailing list, is requested. Joey Hess later mentions that 2) should be done in experimental as doing it in unstable before everything is ready would be problematic. He mentions that 1) and 2) are OK to be worked on right now but we're getting closer of the time we'll need to stop sweeping changes because of freeze/release for Etch. As a conclusion, some discussion about the general directions to go has to happen in the debian-boot mailing list even though some early work on 1) could be done as long as it doesn't close options for the final implementation plan. An important issue is how to handle non-free packages in d-i: just treat them as regular packages for now (at least until Etch) or somehow make users load them separately. Work about persistent device naming scheme ------------------------------------------ Devices changing their name between the installation step and the installed system step is a recurrent problem in D-I. Some work has been done in Ubuntu by Scott James Remnant (keybuk) for iftab parsing, but hasn't got deep agreement by Marco d'Itri (Md). Working closely with Marco is important so that D-I implements solutions which get full support by the udev package maintainer. Colin mentions a plan by Marco to make some bit of udev write out rules itself to remember the name of each device it sees. Then, D-I would only have to copy those to the installed system. Frans Pop proposes a dedicated meeting with the interested people and he will organize it. Flexible way to reorder menu items ---------------------------------- Several features require to either reorder menu items, or drop some of them: - network-console after loading extra components (#288053) - language-chooser after network-console - Apply last patch proposed to close bug #339855 or don't offer 'start a shell' in G-I (as it won't work) - using Etch d-i to install Sarge Dropping menu items can be done with the "isinstallable" feature. It is ack'ed that this can be the solution for the "use Etch d-i to install Sarge" item. Frans will work on sarge installs support as soon as possible (post-meeting comment: the work began immediately after the meeting!). Work done by Colin Watson for "kickseed" in Ubuntu may help in solving some of these issues. This work is recognized by Colin himself as "hacks" but could at least help working on cleaner solutions later. 2.6 floppies ------------ Given that abandoning 2.4 is wished by the kernel team, getting 2.6 floppies for x86 is a requisite. However, even 2.4 floppy builds currently fail in sid for x86 because of extra disk space required by the new glibc udeb. No immediate solution to recover space is currently popping up, so integrating 2.6 probably require we first solve this space issue and not only by allowing 2.4 floppies. Powerpc already uses 2.6 floppies by dropping out root from the boot floppy. Sylvain Ferriol had some success in 2.6 floppies builds, but with load_ramdisk and prompt_ramdisk with root floppy using cramfs. Sylvain will continue some work on that issue. Committing ideas and proposed changes in people/ in SVN is suggested. Changes in lowmem ----------------- Lowering the memory requirement of d-i has been the subject of many investigations by Sylvain Ferriol who had some successes in 16MB installs by hacking lowmem. Sylvain proposed changes some weeks ago, but these were judged a bit too invasive and reverted. Colin Watson suggests working to bring swap as early as possible, for instance before partman, in case the disk already has a swap partition that could be temporarily used. Frans mentions that lowmem is currently mostly a collection of hacks. Having a more structural solution to load some udebs only after partman would be better than only hacking lowmem. Suggestion here is summarizing ideas and propose them to the mailing list for discussion. g-i integration --------------- Since the last meeting, several blockers have been raised and, actually, the integration of Graphical Installer builds in the main build system is theoretically possible. Frans will resume work on the udeb lib dependency immediately after the release. As expected, there won't be any g-i release with beta2. The goal is having one with beta3. Another blocker is the line spacing issue in ttf-freefont (#254113). There is currently no sign that it can be solved as it seems to be puzzling even for the freefont upstream maintainer. The fonts in ttf-dejavu could be a good replacement for ttf-freefont in case the line spacing issue is a blocker. Thus, Davide Viti will try to check whether these DejaVu fonts cover enough glyph ranges. About freefont, the deal is either have a less complete font without line spacing problem (20051102-2) or a more complete one with the problem (20060126-1). This is only a matter of requesting ttf-freefont to enter testing. The ttf-freefont maintainer (Christian Perrier) still keeps an eye on that issue very closely. Graphical partitioner --------------------- The goal is having some tool that better fits in a graphical installer than partman. gparted could be OK for this but, being written in C++, it requires a C++ udeb, which is not supported by the glibc maintainers. As a consequence, Xavier Oswald began working on a C rewrite of gparted named gdisktool (http://oskar-box.hd.free.fr/debian/screenshots/gdisktool.jpg). Given the still early stage of this development, having it in the etch graphical installer is not very likely to happen (as the graphical installer is itself just stabilizing right now). However, Xavier is encouraged to build a tentative udeb so that unofficial images can be easily built and give gdisktool more exposure. The source code will soon be committed in gparted SVN. This graphical partitioner tool should also include a partimage utility which can be used to backup/restore partitions to disk or network. Netinst images needing network ------------------------------ As a consequence of apt-setup integration to 1st stage, the current netinst image insist on configuring the network before further actions can take place. Joey suggests that maybe abandoning the netinst image is the way to go. However, there is a demand for it as a convenient way to install a minimum working base system. A minimal option is probably making it possible to skip the network/mirror steps. A hack exists for Ubuntu needs and could probably be adapted. Colin will merge this code in. Conclusion ---------- The next meeting (which we again forgot to schedule) will be held on Wednesday April 5th at 20:00UTC. Given the timeframe set for beta3, it should be the beta3 final preparation meeting.
Attachment:
signature.asc
Description: Digital signature