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
---BeginMessage---
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.2content-type=text/x-cvsweb-markupcvsroot=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.1content-type=text/x-cvsweb-markupcvsroot=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
