> On 24/01/12 10:18, Dave Martin wrote:
> > Hi again,
> >
> > After a report of yet another instance of un-findable source for a
> > kernel released from a landing team, it would be good if we could move
> > forward with this.
> >
> > Does anyone have any significant disagreements with the proposal
> > below?
> >
> > If not, I can try to write up a formal specification somewhere.
> >
> > Can we then plan to implement it?
> >
> >
> > If anyone has any preference for the common prefix for tag names,
> > please speak up (otherwise we will proceed with the "ubuntu/" prefix).
> >
> > Cheers
> > ---Dave
> >
> > On Fri, Jan 13, 2012 at 01:32:35PM +0000, Dave Martin wrote:
> >> For everyone who packages kernel trees:
> >>
> >>
> >> I've had some questions about getting the source for linaro kernel
> >> packaged, and it seems that this is still not straightforward:
> >>
> >> Getting the debian package source (i.e., flat tarball) for a binary
> >> kernel is possible, but only if it is a non-superseded version.
> >>
> >> Working out which source package you need is non-obvious (You have to
> >> check for installed kernel packages, and guess which source package
> >> you need, based on that. Non-linaro folks may not understand the
> >> difference between the various meta- and real kernel packages and may
> >> get pretty confused along the way.)
> >>
> >> Finding the git tree and the relevant commit to reproduce the source
> >> (including that for superseded kernels) is hard or impossible. It
> >> requires guesswork and/or specific knowledge about the way the
> >> relevant team manages their trees. For some platforms, it looks like
> >> there may be no single tree containing the packaged kernel at all, in
> >> which case you would also need more guesswork and/or scripts or help
> >> from the relevant landing team in order actually to reproduce a
> >> release.
> >>
> >> Am I correct in these conclusions?
> >>
> >>
> >> If so, here's a proposal -- I welcome people's comments (and please do
> >> say if any of these problems are actually solved already!):
> >>
> >>
> >> For every binary kernel package (.deb) publicly released by any linaro
> >> team, including those produced by the platform team and the landing
> >> teams:
> >>
> >>
> >> 1) The source package's control file must contain a Vcs-Git entry
> >>
> >>
> >> 2) The Vcs-Git entry must reference a git tree which contains the
> >> _exact_ source code which appears in the source package.
> >>
> >> * Such a tree must exist and must be publicly readable. It does not
> >> have to be on
git.linaro.org (though this is the recommended place).
> >>
> >> * Referring to git://
git.linaro.org/ubuntu/linux-linaro.git is not
> >> acceptable, unless that repo is populated with the real source for
> >> that specific kernel as well as the packaging.
> >>
> >> * Manufacturing the source package from the contents of multiple
> >> repositories or branches at source package upload time is not
> >> acceptable, unless the result is also recorded as a tagged commit in
> >> the repository referenced by the Vcs-Git entry in the debian/control
> >> file contained in that same commit. The commit must have full
> >> history: importing tarballs directly into a repository for the purpose
> >> of release tagging is not acceptable.
> >>
> >> * Referring to a tree which does not contain the whole contents of
> >> the debian source package (for example, debian/ and other packaging
> >> files/dirs are missing) is not acceptable.
> >
> > Note: this means that the released binary packages must be reproducible
> > from the tagged source using standard package build mechanisms, to the
> > extent that the exact versions of build tools and other build-time
> > dependencies used to build the originally released binaries are still
> > avilable.
> >
> >>
> >>
> >> 3) Tagging of packaged kernels must be done in a standard way.
> >>
> >> * I recommend <source package name>_<package version>, matching the
> >> Source field of debian/control and the version number of the most
> >> recent debian/changelog entry respectively (which must both be present
> >> in the repository as a consequence of (2)). If we want to avoid
> >> namespace pollution, we probably want to add a prefix such as debian/
> >> or ubuntu/ to the tag name to indicate that the tag describes the
> >> source for a published .deb package. If so, we must standardise that
> >> prefix so that it is identical in all out trees.
> >>
> >> * Tree maintainers are of course free to add any other additional
> >> tags for their own use if they want to.
> >>
> >> All teams already do release tagging of some sort, but the lack of
> >> consistency creates difficulties when anyone from outside the team
> >> tries to understand that team's trees.
> >>
> >> * We _could_ standardise the following, but it is not essential:
> >>
> >> * ubuntu/<release>: The tagged source for the _original_ kernel
> >> which was distributed in <release> (where <release> is a linaro
> >> monthly release such as 11.12 or 12.01)
> >>
> >>
> >> 4) No specific branch naming requirements exist.
> >>
> >> * Release tags do not necessarily need to appear on any branch.
> >>
> >> * We _could_ standardise the following, but it is not essential:
> >>
> >> * ubuntu/latest - the tagged packaged source for the most recent
> >> kernel release made from this tree
> >>
> >>
> >> (In the above, we could choose a diferent prefix instead of ubuntu/,
> >> but as described in (3) ,this should be chosen globally and _not_ on a
> >> per-tree basis).
> >>
> >> Cheers
> >> ---Dave
>
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> M:
+44 77 88 633 515