This report covers two weeks. The first week was spent in Oxford at the
small conference hosted by Canonical software. The second week was spent
mostly sick at home with post-convention flu, which is why I didn't get the
report in last week..
Done week before last:
- Attended Canonical conference. See general notes below.
- Attended Canonical security BOF. Summary below.
- Spoke with Chris Halls and Matt Zimmerman about testing security support.
Summary below.
- Discussed ways to give debian-installer a useful graphical frontend.
Summary below.
- Worked with Colin Watson on improving the progress bar granularity
in base-installer when debootstrap is configuring the base system.
Canonical now have patches to do this, it will not be able to be
integrated into d-i in time for sarge though.
- Discussed and worked with Steve McIntyre on debian-cd.
- Added preseeding to d-i for automated installs like anaconda kickstart.
- Integrated lowmem updates into d-i, pushing minimum memory down to 24 mb.
Done last week:
- Worked on updating d-i to the 2.4.27 and 2.6.8 kernels.
- Documented d-i kernel update process in a checklist.
- Received and set up one more thin client test machine in home test
network.
Plans for this week:
- Assign bugs in the Debian BTS for the items listed in
http://lists.debian.org/debian-cd/2004/03/msg00017.html
(After verifying/reproducing them).
- Work on RC bugs on debian-edu packages.
General notes on the Canonical conference:
My hope in attending this conference, besides getting more in-person work
time with some of the great team of Debian developers employd by Canonical,
was to find ways that Debian-Edu and Canonical could work together, and
find out how we can exploit their existing work in Debian-Edu.
I learned a lot about how their Debian derived distribution works at the
conference, and indeed they have to solve some of the same problems as does
Debian-Edu. Some specific technical things that come to mind:
- Both Canonical and Debian-Edu have the problem that after a largely
automated direct stage install, the CD ejects, the system reboots, and
the user must now counter-intuitively re-insert the CD for the second
stage install. Canonical was developing an interesting workaround:
Before the reboot, they copy all the debs from the CD into the apt cache
of the installed system, so the CD is not needed later.
I discussed this with them, as well as other possibilities, like
installing _all_ the packages during the first stage install. That has
technical problems, but we though of a compromise, which is to unpack,
but not configure, all the packages in the first stage install, then
configure them after the reboot. This uses less disk space than
populating the apt cache. It will be interesting to see what scheme
Canonical settles on, and we could easily reuse their code for this in
Debian-Edu. It's even possible this might migrate into Debian proper
eventually.
- Canonical is working on a graphical boot process. This might be nice
to spiff up Debian-Edu.
- Canonical is working on laptop detection code and other laptop support
stuff. I am interested in adding automatic detection of laptops for both
Debian, in tasksel, so a laptop task can be automatically selected, and
possibly for Debian-Edu, so education-laptop can be automatically
selected, if that makes sense to do.
- Canonical is targeting a world-wide audience as we are, and could
probably use our work on localisation-config.
- We both do installs at critical priority; some of Canonical's patches for
problems encountered in d-i when doing that may prove useful to
Debian-Edu, though I hope they'll all get merged into d-i proper.
So lots of places where there is techical overlap. I did not find out
enough about Canonical's infrastucture to add any data in helping you
decide if it would be worthwhile for Debian-Edu to actually be based on the
Canonical distribution. I think it will be valuable to continue to consider
the idea, and continue working as closely with them as we can.
Canonical security BOF summary:
The attendees at this BOF included Matt Zimmerman, James Troup, Lamont
Jones, Jeff Waugh, Colin Watson, and several others.
Most of the BOF was spent discussing internal Canonical security plans and
procedures, not particularly relevant for us, and not things I need to
summarise as a third party observer. The interesting bits with respect to
Debian-Edu concern how Canonical and Debian-Edu can benefit from each other
for security updates.
Since Canonical's distribution includes a core part that they support, plus
a larger part that they support to a lesser extent, they're interested in
any third party support for the larger part. For example, if Debian-Edu
were based on Canonical's distribution, KDE would be in this larger set of
packages that could be maintained using the Canonical infrastucture, and
the possibility was raised that Debian-Edu could then be repsonsible for
general maintenance and security updates for KDE.
That makes sense from Canonical's perspective of wanting to have other
distrbutions based from theirs. Whether it makes sense for Debian-Edu to
maintain and security fix KDE in their distribution is an open question,
and would probably depend on what other benefits we derived from basing
Debian-Edu on Canonical.
There wasn't time to discuss general matters of security updates for
testing at this BOF, though I did make some progress in that area later in
the week.
Other security discussions, with Matt Zimmerman and Chris Halls:
Chris has a co-worker who may be interested in participating in a
testing security updates team, I sent him a copy of the draft proposal
for such a team.
Since mdz is a member of the Debian security team, I was interested
to know how he felt about the idea of doing security updates for
testing, and any advice he might have. He was encouraging about the
idea, said the draft looked "interesting" and gave me some valuable
tips.
I also talked some with mdz about enuring sarge has fixes for all known
security holes when released. Since I've already worked to get the DSAs
checked for sarge, this mostly leaves the CAN's. Unfortunatly, Matt knew of
no way to get a list of CAN's that affected sarge, short of reading over
the hundreds of them in the list and checking each manually. This will be
an enormous lot of work, and I may not have time to do it.
Discussion about giving debian-installer a useful graphical frontend:
Colin Watson, Jeff Waugh and I talked about how to give the Debian
installer a useful graphical frontend. I'm ussure if this is something we
care about for Debian-Edu, but it was interesting and is certianly
something Debian cares about for d-i in the long term. We settled on a
scheme that allows things like custom country/language and partitioning
dialogs while still using debconf underneath. I'm excited because this is
the first time I've seen an idea that had a hope of solving this problem. I
will not go into the details, as I'm hoping Colin or Jeff will prepare a
detailed design and maybe even an implementation eventually.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature