id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
132	produce debs with buildbot	Brian Warner		"Eventually, I'd like the buildbot to be responsible for producing .deb packages for a variety of platforms. My plan is to figure out how to use ""schroot"" to set up a chroot-based environment for each target platform (i.e. dapper through karmic, etch, lenny, sid)*i386, then run a buildslave in each one. I'm also thinking of using an EC2 instance for the lot of them, launched as a ""latent buildslave"" (which is started on demand and shut down when idle).

What I'd really like is to have two separate APT repositories. One should be updated continuously, on every commit. The other should only contain released versions. The buildslave which creates the .deb should notice whether the version is a tag or not, and only upload the .deb to the release-repo when it is a tag. It should upload it to the continuous-repo always.

Eventually I'd like the same schroot scheme to be used for installation testing. It should create a new+clean debian install, then do ""sudo dpkg --install X.deb"", and then run some tests, then destroy the chroot.

If the upload-deb process uses a flappclient, then the clean chroot could be required to use the just-installed foolscap for the upload. This would provide the neat property that a seriously broken foolscap would be unable to upload itself into the APT repo, almost like darwinian selection for software.

[http://allmydata.org/trac/tahoe/ticket/630 tahoe#630] has some of my notes on schroot, and [http://allmydata.org/trac/tahoe/ticket/422 tahoe#422] is a similar wishlist item for Tahoe debs."	task	closed	major	undecided	packaging	0.4.1	wontfix