In gmane.linux.debian.devel.kernel, you wrote: > On Mon, Feb 09, 2009 at 06:30:00PM -0200, Otavio Salvador wrote: >>Steve McIntyre <st...@einval.com> writes: >> >><...> >>> The main focus of the meeting was how d-i builds and releases work, >>> and I think we made quite some progress on that. There are a few >>> changes that we think should be made that will help a great deal in >>> building, publishing and releasing d-i. I'm not posting any of the >>> details here just yet because my memory fails me... :-) >><...> >> >>Please let me know those details as soon as possible :-) > > Oh, of course. :-) My beer-addled memory is not as reliable as it used > to be, so I'm hoping that Mark's notes are more reliable. > > mhy: ping!
Ok, here are my notes from that meeting. I'm sure people will correct me when I make mistakes / omissions. Unfortunately, my notes aren't anywhere near as copious as I'd like so if people could jump in, it'd be helpful. People present: broonie, enrico, fjp, Maulkin, mhy, Sledge, sgran, Kinnison, kyllikki, Womble2 Issues Discussed: ----------------- Kernel: * The issue of linux-modules-extra binaries having been built using sources which are not referenced within dak (and hence not guaranteed to be kept around for the right length of time was discussed). This was also discussed under D-I Builds [0] D-I Builds: * Some facts about D-I builds were clarified by fjp: * Pulls in d-i source (installer/) * Pull in udebs * Daily builds take udebs from unstable * RC builds take udebs from testing * debian/rules performs a testing build * manual builds using installer uses unstable (?) * D-I builds need to be run as root; fakeroot doesn't suffice (? would it be possible/desirable to use sudo to do builds on a per-package basis?) * D-I changes come from * Installer build system * debs * cd build scripts * Metadata generation * How D-I can declare an interest in certain debs/udebs to assist the release team? Could a file be produced listing the relevant packages? * How we can ensure that source is available for everything in D-I images? [0] * Virtual d-i package for Depends to prevent migration of 'bad stuff' to testing? * debian.org daily builds * Would it be possible / feasible to move the daily builds to the normal autobuilder network? [0] This led to further discussion culminating in a proposal for two new fields in .changes files. This is not a full specification or proposal, which is yet to be fully written: * Built-Using-Binary: * Built-Using-Source: These fields would be placed in a .changes file of a single architecture binary upload (rationale for not putting them in the DEBIAN/control file; we want to avoid bloating udebs and also allow the use of these fields for non-package uploads, such as the debian-installer tarballs which may not contain a control file). They must be specified with a strict versioned Depends; e.g. Built-Using-Binary: foo (= 1.2.1-3). At upload time the archive will check that the version specified is known, in the case of the Built-Using-Binary field resolve it to its source package/version and store a reference that the binary packages uploaded were built using that source package/version. The archive will then refuse to remove source packages from the pool whilst any existing binary still references them. PS - I have to say that having looked at this and thought again, I'm fairly sure that the .changes file is fundamentally the wrong place for this and that we need to discuss it further. Normal packages should just put it in control and we should come up with some other mechanism (maybe some form of extra control file which is uploaded) for things which go through byhand (such as d-i tarballs) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org