[51] in athena10
Athena 10 project infrastructure status
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jan 23 14:26:17 2008
Date: Wed, 23 Jan 2008 14:26:04 -0500
Message-Id: <200801231926.m0NJQ47K010216@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: athena10@MIT.EDU
Build server: I had snuggle reinstalled with edgy (which I upgraded to
lenny) and I can make chroot environments, but I realized belatedly
that I will need a 64-bit machine for this purpose. Until I get
replacement hardware I will just do builds for gutsy-i386 instead of
the full gamut.
Build area: I wrote a script which can create and maintain a build
area, which I will stick under /afs/dev.mit.edu/project/release/10.
However, there are two issues, which I'll discuss below the cut.
Apt repository: Doesn't exist yet pending resolution of the build area
issues.
Apt repository HTTP server: For simplicity, I think we'll just use
stuff.mit.edu for development. Once things are off the ground I'll
try to figure out what kind of hardware will be necessary for
production.
---
The build area issues are:
1. The imported debian control files list tabbott or andersk as
maintainer. debuild -S looks for a key for the listed
maintainer, which I obviously don't have, and blows out when it
doesn't find one.
2. debuild -S does not like seeing Debian version numbers without an
orig tarfile or directory. (This gets back to "I want Athena 10
packages to be treated as Debian-native" vs. "existing Debathena
packages aren't".)
My first thought is to change all of the maintainer fields to
release-team@mit.edu and create a corresponding private key which
would be available to the developers, and to bump all of the version
numbers to not include a Debathena component. (Also requires a change
to dadch.) I'm a little concerned about how those changes might
affect the relationship of Athena 10 development to production
Debathena, so I wanted to bring up the issue for discussion here
first.
I could have my build area script create dummy orig tarfiles to make
debuild happy. However, this would be a bit of a lie unless I
arranged for the orig tarfile to be the same across changes to the
debathena version component.
