Linaro Android kernels are very easy to find
Browse to:
https://android-build.linaro.org/builds/~linaro-android/staging-origen/#buil...
Click on Downloads
You'll see:
http://snapshots.linaro.org/android/~linaro-android/staging-origen/142/sourc...
and
http://snapshots.linaro.org/android/~linaro-android/staging-origen/142/pinne...
The source-manifest contains:
<remote name="linaro-other" fetch="git://git.linaro.org/" review="review.android.git.linaro.org"/> <project path="kernel" name="landing-teams/working/samsung/kernel" remote="linaro-other" revision="android"/>
For the specific commit that got built in our CI loop use the pinned-manifest.xml:
<project name="landing-teams/working/samsung/kernel" path="kernel" remote="linaro-other" revision="41824b7e304cb4022dbcf893b7b0db272c2ab374"/>
Just
git clone git://git.linaro.org/landing-teams/working/samsung/kernel
Get the toolchain
wget http://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-bzr/141...
tar -jxvf android-toolchain-eabi-4.6-*
Get the config
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_staging-origen/1... or click on Raw
Get the build commands:
cat consoleText | grep ARCH=arm
Fix up the toolchain and bingo!
Amit is putting this all into a per build script, which you'll just download and run.
Enjoy!
On 13 January 2012 07:32, Dave Martin dave.martin@linaro.org 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:
The source package's control file must contain a Vcs-Git entry
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.
- 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)
- 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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev