s390 fans: As you can see from the attached debian-installer status report, s390 is one of a minority of Debian architectures which are currently not supported by debian-installer. Part of the reason for this is that access to create and reboot Linux/390 guests (as would be needed for installation testing) is hard to come by for most Debian developers. Without access to a development platform, it is unlikely that we will be able to support installation of Debian on s390 in the Debian 'sarge' release.
I would like to ask that if any of you are in a position to provide Debian developers with access to such a system, and are willing to do so, please contact either the installer development mailing list ([EMAIL PROTECTED]) or myself if you would prefer private mail ([EMAIL PROTECTED]) to work out the details. Feel free to forward this message to anyone else who might be in a position to help. -- - mdz
--- Begin Message ---The debian-boot team is working hard to produce a decent next generation installer for sarge, and we're making good progress. But in many areas we don't have enough people to do all the work. We're reaching the point where if some things are not done soon, they will simply not be supported in time for the release of sarge. This email lists some well-defined jobs, many of them easy for developers who are unfamiliar with the internals of the installer to take on, that can significantly improve debian-installer. 1. installation report processing With the release of betas 1 and 2 of d-i, we've gotten many installation reports from users. These tend to collect many problems, glitches, bugs, and observations into one bug report, and so they need to be processed, cloned off into separate bugs which are retitled and assigned to the right packages in debian-installer. We have over 150 of these that need processing. We are hoping to process at least 75 of these installation reports this week, with the help of the larger group of Debian developers, and so we have written a tutorial that should get developers quickly up to speed on processing installation reports. You can find it here: http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/debian-installer/doc/installation-reports.txt?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=d-i 2. The installation manual is half complete, and we need writers familiar with XML to work on the unfinished sections, as well as update and proofread what's already there. The manual has its own TODO list, here: http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/debian-installer/doc/manual/TODO?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=d-i 3. PCMCIA Do you have more than two PCMCIA cards? Have you ever edited config.opts by hand? Then you're more qualified than anyone on the d-i team to get our PCMCIA support working. Currently it fails about 75% of the time. Stealing the parts of pcmcia-cs's postinst that figure out what module to use for the bridge would be a good first step. 4. low memory support d-i barely supports installations on systems with 32 mb of memory. It's unlilkely to ever support lesser systems unless someone steps up to work on it. We have some ideas, that should work, but no time. 5. arm, s/390, sparc These are our lagging architectures, and if d-i is to support installing them for sarge, we need at least one person working on each. Currently we have none. hppa, m68k, and mipsel are a bit further along, but also need more developers. 6. lintian/linda checks for udebs debian-installer uses udebs, which are small, non-policy compliant packages in deb format. Actually we have our own minimal policy[1] for udebs, which prohibits them having preinst scripts, conffiles, pre-depends, conflicts, documentation, etc. It's kind of the anti-policy, and we occasionally screw up and put something into a udeb we should not. So we hope to get support in lintian or linda to check udebs for these problems. 7. graphical boot screen We would like to drag Debian kicking and screaming into the .. er, late 90's by giving its installer a fancy graphical boot screen. We have two candidates, but would be glad to see something even better. Note that it's limited to 16 colors and 640x480 resolution, and see the syslinux documentation for details. 8. ppp support If you care about ppp support for the first stage install, you need to put some time into getting it working in d-i. Otherwise, it just won't happen. 9. everything else Here is the rest of our "short" list for the next release. While we're working on everything in here, it's likely that at least some of it will not happen in time, unless we get more developers. - fix all beta2 errata (a must) - security fixed, 2.4.24 kernel (with SATA support) (done for stock i386 (but not SATA, probably?)) - discover 2 - partman (fixes many issues with current system) initial version available, not default yet needs some UI polishing - grub as default boot loader (done except testing) - XFS support in official release - 2.6 kernel - improved languagechooser (split out country chooser) in progress - less questions in base-config (using more answers from d-i) - better i18n in the second stage - improved image names 1 week to completion (ths) - udebs and debs with same names - better wireless support wireless-tools-udeb is available, but is not loaded by default on netinst CD no easy configurator yet (Joshua Kwan) - BIDI support (for Arabic) - subarchitecture support for powerpc and m68k in progress 10. testing We still need more people testing d-i on more strange and wonderful hardware. See http://www.debian.org/devel/debian-installer for details. -- see shy jo [1] http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/debian-installer/doc/modules.txt?cvsroot=d-i&only_with_tag=HEAD
signature.asc
Description: Digital signature
--- End Message ---
signature.asc
Description: Digital signature