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