Linaro Android kernels are very easy to find Browse to:
https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=142 Click on Downloads You'll see: http://snapshots.linaro.org/android/~linaro-android/staging-origen/142/source-manifest.xml and http://snapshots.linaro.org/android/~linaro-android/staging-origen/142/pinned-manifest.xml 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/android-toolchain-eabi-4.6-daily-linux-x86.tar.bz2 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/142/consoleText 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.mar...@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: > > > 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. > > > 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 > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
