On Sat, 1 Oct 2011 15:13:33 +0200 Kurt Roeckx <kurt@roeckx.be> wrote: > I can't really follow what you're writing very good. :-) There are lots of bits of what we do which are quite different to how normal Debian processes work. 0: Emdebian deals with binaries from other buildds, not from source 1: Emdebian handles all architectures identically on one machine 2: For Grip, there is no recompilation - just unpacking and repacking. 3: Packages get an em1 version suffix and go to bespoke suites. 4: the source package is completely unchanged > With "buildd" do you mean what we run, or the thing you do > to generate your new files? Maybe sometimes one, sometimes > the other? Always the same Emdebian process - it never involves compilation. It is architecture-neutral / architecture-agnostic in that it is a set of scripts which unpack the .deb, remove files and repack the .deb with appropriate management + version suffix. It's been working for Emdebian now since before Lenny. Resulting binaries are binary compatible with Debian but average out ~40% of original size. Being architecture-neutral, the same machine processes packages for all supported architectures: i386, amd64, armel, mips, mipsel & powerpc currently. The process is also v.v.fast - typically takes 30 seconds per package or ~1minute for large packages like the kernel, mainly because we can do all the work on a fast amd64 machine. However, once done, I get a normal .changes file which could be uploaded to the new suites just as an existing buildd does. It is this stage which interests me now, esp. for the auto-signing. For Emdebian, I'd be uploading .changes files to ftp-master - one .changes file per arch per package version - but quite often uploading binaries of the same package, same version for i386 and then armel and then mips and then .... (There is the added complication that the Emdebian process changes the package from unstable to unstable-grip, from testing-proposed-updates to testing-proposed-updates-grip etc. but this is managed in the current process, so the .changes file is correct.) > How the auto signing works for our buildds is that after the build > the generated files are moved from the chroot to the "build" > directory (as it has always done), but then signs it with the key > specificied in the config file (if any) and after signing it > moves it to the upload directory. And then we have a cron job > doing the actual uploads. I don't use chroots because there's no compilation. It's all handled in /tmp/grip.XXXXXX dirs. However, the directory layout is easy to mimic. So the secret key to sign the .changes file lives on the buildd, just outside the chroots normally used? My question really comes down to how that secret key is managed - does DSA have to have access to the machine where that secret key is kept? How is that managed currently? (Does DSA just have normal user access or sudo?) Does the wb team need access? Currently, the machine in question is accessible by me, zumbi & wookey. > We need to generate the keys on the buildd and then add them to > a file on ftp-master, which then gets added to a special keyring. > ftp-master has rules on which machines are allowed to have such keys, > and things like that. Thanks. > I think you really need to talk to ftp-master about all this. I've been talking to ftp-master since the start of the integration process. Most of the current plan is derived from ftp-master ideas. Before the key is generated and submitted to ftp-master, I just wanted to clarify who from Debian needs access to the box where the key is stored (esp. as the key will be passphrase-less) and what kind of access is required. I then need to get the new suites setup on ftp.debian.org which I understand will be delayed as ftp-master are awaiting new hardware. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpEFjskErk69.pgp
Description: PGP signature