Re: Meeting(s) at FOSDEM
In gmane.linux.debian.devel.kernel, you wrote:
> On Mon, Feb 09, 2009 at 06:30:00PM -0200, Otavio Salvador wrote:
>>Steve McIntyre <steve@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)
Reply to: