All released kernel source is available on git.linaro.org.
Specifically:
Git:
git://git.linaro.org/landing-teams/leb/<landing_team>/kernel.git
HTML:
http://git.linaro.org/git/landing-teams/leb/<landing_team>/kernel.git
Gitweb:
http://git.linaro.org/gitweb?p=landing-teams/leb/<landing_team>/kernel.git;a=summary
The Gitweb has a description of what you can expect from each tag.
Kind regards,
Lee
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
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
