I forgot to mention that I spoke with some of the buildd maintainers today. Apparently a lot of buildds block network entirely even if it is available. Still I think using a source package and the buildds gives us so many advantages we should still try to do it, even if it will need special cases. Worse case we could include all the udebs it'll need for all arches in the "source" package. I also verified that we do need to upload an arch all deb or udeb if we want the buildds to notice the source package for build/. I have not had any idea much better than putting the build logs in the package, but here are a few other ideas I've brainstormed: - Include the entirity of the d-i tree, build various parts or the whole thing. Not palatable. - Find a udeb that is somehow tightly bound to build/, and include it. Nothing except maybe the kernel udeb does, and we do *not* want those bound together though. - Include the docs in the debian-installer source package, since they will need per-arch builds. Of course, there is no Makefile for the docs yet, and they are in a different directory in CVS. Still, this has something to recommend it, especially if the docs need to reference information that can be taken from the built images. (filesystem sizes, versions, etc). - Make a deb that you can install to boot into d-i. It would add an appropriate menu item to lilo/grub/whatever, and use my from hd-media install stuff. Would need a lot of work for various arches, for fairly little gain. - Make a deb that could be used to demo the installer in a chroot. Like an installable, upgradable 'make demo'. Kind of out there, dubious utility, but it sorta feels better than the other options. -- see shy jo
Attachment:
signature.asc
Description: Digital signature