Hi,
In preparation for the release of Linaro 11.07 images on 2011-07-28, a suitable candidate has been selected for testing.
Please help our initiative by testing the official Linaro Evaluation Build (LEB):
* Android: http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/
* Ubuntu: http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/
Another exciting development worth sharing is the arrival of very early Linaro android builds for snowball. Our snowball builds are combining AOSP based Linaro Platform code with a landing team kernel based on a recent linux-linaro and linux-linaro-android with an androidized linux-linaro kernel with landing team goodies on top. http://releases.linaro.org/platform/linaro-n/android/latest/leb-snowball/
On top of our officially supported Linaro Evaluation Builds images above, the Linaro Platform Team is proud to also provide a set of images prepared by Linaro developers and community for specific target audience. Developers and
Community Builds images are provided on a best-effort basis and in the hope that they can be useful. Last reported known to be working images can be found below:
* Nano: http://releases.linaro.org/platform/linaro-n/nano/latest/
* ALIP: http://releases.linaro.org/platform/linaro-n/alip/latest/
* Developer: http://releases.linaro.org/platform/linaro-n/developer/latest/
* Ubuntu-desktop http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/latest/
A list of all hardware packs hosted by Linaro Platform can be found below:
http://releases.linaro.org/platform/linaro-n/hwpacks/latest/
Please support the Developers and Community Builds images efforts by testing
and providing feedback for our builds.
As a side note, hwpacks that have an -lt- in their name are outputs from the Linaro Landing teams, using some of their components.
Similar to the spirit of the Ubuntu based Developers and Community images,
the Linaro Android Platform Team provides a set of vanilla AOSP builds that use Linaro toolchain and the Linaro mainline kernel for development boards that have good enough mainline support to run a full AOSP user
experience. Those builds are not officially supported and are provided in the hope that they might be useful.
* Android Vanilla AOSP for BeagleBoard-xM: http://releases.linaro.org/platform/linaro-n/android/latest/beaglexm/
* Android Vanilla AOSP for PandaBoard: http://releases.linaro.org/platform/linaro-n/android/latest/panda/
Make your way to the installation instructions:
https://wiki.linaro.org/Platform/Android/ImageInstallation https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation
For an explanation of how to test and submit your results to the QA tracker at:
For an explanation of how to use the qatracker please see:
https://wiki.linaro.org/QA/QATracker
Known Issues ============
Android: * ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07 - See https://launchpad.net/bugs/807230
* No HDMI display working linux-linaro-android 3.0-2011.07 with pandaboard - See https://launchpad.net/bugs/810049
* Two bugs reported against beagle XM rev C board suggest that there are issues severly impacting the stability and potentially usefulness of Linaro Android builds for the rev C boards. - See https://launchpad.net/bugs/812098 - See https://launchpad.net/bugs/808773
Ubuntu: * Pulseaudio consumes 100% of the cpu when trying to play a sound with natty's linaro LEB and 3.0.0-1402-linaro-lt-omap - See https://launchpad.net/bugs/816638
* Only half of RAM useabe when using Devive Tree on Panda Board - See https://launchpad.net/bugs/7 https://launchpad.net/bugs/7070470https://launchpad.net/bugs/707047 7047 https://launchpad.net/bugs/707047
Hi,
Executive summary: James opens up a can of worms and volunteers to fix it.
I am not suggesting that we change anything for this release. I don't mind what the directory structure on releases.linaro.org is, as long as it is consistent. But...
As someone who cares more about structure on the file server than most (because I try and maintain an index) I thought I should reply. It is clear that we now have two structures living side by side on the server. We used to have: http://releases.linaro.org/platform/%5Blinaro release]/[distribution name]/[milestone]/
And we now seem to be going with http://releases.linaro.org/platform/linaro-n/%5Bdistribution name]/[release name]/
The problem is these exist side by side, so looking in http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/ I see 11.05, 11.06, 11.07, alpha-3, beta-2, beta, final, latest. alpha/beta/final are from the old 6 month release cycle and final became 11.05. The other [year].[month] directories are a Linaro release, with no tagging to say if they are a release candidate - a bit confusing!
A couple more observations:
First we have duplication of hardware packs, but not the checksum files and GPG signatures to go with them. The hardware packs are hardware, not distribution specific, so it is difficult to justify to have them in multiple locations. I imagine that this structure was designed to put everything in one directory that someone may need to get up and running with a Linaro distribution, but if they want to check their hardware packs are signed and correctly downloaded they still need to visit the hwpacks directory.
Second we are still using http://releases.linaro.org/platform/linaro-n. I thought we had done away with the lettered naming convention to go with the date based ones.
To index the releases server automatically I need a predictable file structure. I don't mind what it is, as long as we stick to it. My suggestion is:
All OS binaries structured as: http://releases.linaro.org/platform/%5Brelease%5D/%5Bdistribution name]/[milestone]/
Hardware packs all in one place: http://releases.linaro.org/platform/%5Brelease%5D/hwpacks/%5Bmilestone%5D/
If we would like to have hardware packs closer to the distributions, we have a problem of the hwpack directory being rather large - copying it into each distribution would make it more difficult to find the right files. This problem does go away completely if we automate the downloading of files for the user, which we now do with linaro-fetch-image[-ui].
I personally find it unnecessary to have separate directories for the linaro evaluation builds. The Ubuntu desktop and LEB builds seem to be identical (the md5sums files match at least!). Since we can link to specific places on the releases server in a release note, why not just link to the ubuntu-desktop directory? If we want to separate out Linaro Evaluation Builds we could have a structure like: http://releases.linaro.org/platform/11.07/linaro-evaluation-builds/ubuntu-de... http://releases.linaro.org/platform/11.07/community-supported/alip/release-c... http://releases.linaro.org/platform/11.07/hwpacks/release-candidate/
I can see why http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/ exists, but I believe it is obsolete with the release of linaro-fetch-image or linaro-fetch-image-ui, which automate the whole download and install process. Those tools don't support Android builds yet though. In another twist though the Android builds exist in a third directory structure! http://releases.linaro.org/platform/linaro-n/android/11.07/panda/
Clearly this makes it easy for people with a panda board to get the files they need to run Android on it. The files seem to be unique, so it looks like it can be left alone, other than getting rid of the linaro-n.
It should be simple enough to script copying the files from snapshots.linaro.org over to releases for the non-Android builds. I am happy to put together something like: create-linaro-release --source-snapshot YYMMDD:build --relese-type <alpha/beta/eac/rc/final> --relase-name <YY.MM>
For the Android builds there are two XML files that aren't in the snapshots at the moment. If these are easily generated or supplied, we could automate that release as well.
James
On 27 July 2011 03:57, Mounir Bsaibes mounir.bsaibes@linaro.org wrote:
Hi, In preparation for the release of Linaro 11.07 images on 2011-07-28, a suitable candidate has been selected for testing. Please help our initiative by testing the official Linaro Evaluation Build (LEB):
- Android:
http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/
- Ubuntu:
http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/ Another exciting development worth sharing is the arrival of very early Linaro android builds for snowball. Our snowball builds are combining AOSP based Linaro Platform code with a landing team kernel based on a recent linux-linaro and linux-linaro-android with an androidized linux-linaro kernel with landing team goodies on top. http://releases.linaro.org/platform/linaro-n/android/latest/leb-snowball/ On top of our officially supported Linaro Evaluation Builds images above, the Linaro Platform Team is proud to also provide a set of images prepared by Linaro developers and community for specific target audience. Developers and Community Builds images are provided on a best-effort basis and in the hope that they can be useful. Last reported known to be working images can be found below:
- Nano:
http://releases.linaro.org/platform/linaro-n/nano/latest/
- ALIP:
http://releases.linaro.org/platform/linaro-n/alip/latest/
- Developer:
http://releases.linaro.org/platform/linaro-n/developer/latest/
- Ubuntu-desktop
http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/latest/
A list of all hardware packs hosted by Linaro Platform can be found below: http://releases.linaro.org/platform/linaro-n/hwpacks/latest/ Please support the Developers and Community Builds images efforts by testing and providing feedback for our builds. As a side note, hwpacks that have an -lt- in their name are outputs from the Linaro Landing teams, using some of their components. Similar to the spirit of the Ubuntu based Developers and Community images, the Linaro Android Platform Team provides a set of vanilla AOSP builds that use Linaro toolchain and the Linaro mainline kernel for development boards that have good enough mainline support to run a full AOSP user experience. Those builds are not officially supported and are provided in the hope that they might be useful.
- Android Vanilla AOSP for BeagleBoard-xM:
http://releases.linaro.org/platform/linaro-n/android/latest/beaglexm/
- Android Vanilla AOSP for PandaBoard:
http://releases.linaro.org/platform/linaro-n/android/latest/panda/ Make your way to the installation instructions: https://wiki.linaro.org/Platform/Android/ImageInstallation https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation For an explanation of how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker
Known Issues
Android: * ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07 - See https://launchpad.net/bugs/807230 * No HDMI display working linux-linaro-android 3.0-2011.07 with pandaboard - See https://launchpad.net/bugs/810049 * Two bugs reported against beagle XM rev C board suggest that there are issues severly impacting the stability and potentially usefulness of Linaro Android builds for the rev C boards. - See https://launchpad.net/bugs/812098 - See https://launchpad.net/bugs/808773 Ubuntu: * Pulseaudio consumes 100% of the cpu when trying to play a sound with natty's linaro LEB and 3.0.0-1402-linaro-lt-omap - See https://launchpad.net/bugs/816638 * Only half of RAM useabe when using Devive Tree on Panda Board - See https://launchpad.net/bugs/707047
-- Mounir Bsaibes Project Manager
Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#%21/linaroorg http://www.linaro.org/linaro-blog
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 27 July 2011 11:48, James Tunnicliffe james.tunnicliffe@linaro.org wrote:
Hi,
First we have duplication of hardware packs, but not the checksum files and GPG signatures to go with them. The hardware packs are hardware, not distribution specific, so it is difficult to justify to have them in multiple locations. I imagine that this structure was designed to put everything in one directory that someone may need to get up and running with a Linaro distribution, but if they want to check their hardware packs are signed and correctly downloaded they still need to visit the hwpacks directory.
I like having the hwpacks and image in the same directory; I previously spent a bizarre amount of time trying to find them on each release. I agree the signatures need to be with them though.
Second we are still using http://releases.linaro.org/platform/linaro-n. I thought we had done away with the lettered naming convention to go with the date based ones.
Yeh I think that component just needs losing out of the path.
Dave
On Wed, 27 Jul 2011 11:48:11 +0100, James Tunnicliffe james.tunnicliffe@linaro.org wrote:
A couple more observations:
First we have duplication of hardware packs, but not the checksum files and GPG signatures to go with them. The hardware packs are hardware, not distribution specific, so it is difficult to justify to have them in multiple locations. I imagine that this structure was designed to put everything in one directory that someone may need to get up and running with a Linaro distribution, but if they want to check their hardware packs are signed and correctly downloaded they still need to visit the hwpacks directory.
I think that if we are going to put the hwpacks in every directory then the other files should be there too.
I don't think it's a good idea to do this, as it implies that hwpack are rootfs specific, when they aren't. That ship seems to have sailed though.
Second we are still using http://releases.linaro.org/platform/linaro-n. I thought we had done away with the lettered naming convention to go with the date based ones.
To index the releases server automatically I need a predictable file structure. I don't mind what it is, as long as we stick to it. My suggestion is:
All OS binaries structured as: http://releases.linaro.org/platform/%5Brelease%5D/%5Bdistribution name]/[milestone]/
Hardware packs all in one place: http://releases.linaro.org/platform/%5Brelease%5D/hwpacks/%5Bmilestone%5D/
What's the release/milestone distinction here?
I think that the only thing not considered here is multiple versions of a single rootfs or hwpack.
We are currently generating both natty-based and oneiric-based rootfs. I don't know if we plan to release both ever, or if oneiric-based is just snapshots for now, and we will switch one month to release the oneiric-based and not release the natty-based. If someone could clarify the intent here it will help us decide if the hierarchy needs to accommodate that too.
If we would like to have hardware packs closer to the distributions, we have a problem of the hwpack directory being rather large - copying it into each distribution would make it more difficult to find the right files. This problem does go away completely if we automate the downloading of files for the user, which we now do with linaro-fetch-image[-ui].
Yes.
We can do both and use symlinks though :-)
I personally find it unnecessary to have separate directories for the linaro evaluation builds. The Ubuntu desktop and LEB builds seem to be identical (the md5sums files match at least!). Since we can link to specific places on the releases server in a release note, why not just link to the ubuntu-desktop directory? If we want to separate out Linaro Evaluation Builds we could have a structure like: http://releases.linaro.org/platform/11.07/linaro-evaluation-builds/ubuntu-de... http://releases.linaro.org/platform/11.07/community-supported/alip/release-c... http://releases.linaro.org/platform/11.07/hwpacks/release-candidate/
My guess is that Alexander will want something like this to maintain that separation.
I can see why http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/ exists, but I believe it is obsolete with the release of linaro-fetch-image or linaro-fetch-image-ui, which automate the whole download and install process. Those tools don't support Android builds yet though. In another twist though the Android builds exist in a third directory structure! http://releases.linaro.org/platform/linaro-n/android/11.07/panda/
Clearly this makes it easy for people with a panda board to get the files they need to run Android on it. The files seem to be unique, so it looks like it can be left alone, other than getting rid of the linaro-n.
It seems like these should fit in to your proposed structure above, with an image name of "android" or similar?
It should be simple enough to script copying the files from snapshots.linaro.org over to releases for the non-Android builds. I am happy to put together something like: create-linaro-release --source-snapshot YYMMDD:build --relese-type <alpha/beta/eac/rc/final> --relase-name <YY.MM>
While this is a good idea, I don't think it's organised enough to be done all at once right now. Builds are currently copied in chunks as they are ready.
While a script might be useful let's not make it a focus of this discussion. If the RMs want a script we can write it, but let's first decide on a layout.
Thanks,
James
On 27 July 2011 15:12, James Westby james.westby@canonical.com wrote:
On Wed, 27 Jul 2011 11:48:11 +0100, James Tunnicliffe james.tunnicliffe@linaro.org wrote:
All OS binaries structured as: http://releases.linaro.org/platform/%5Brelease%5D/%5Bdistribution name]/[milestone]/
Hardware packs all in one place: http://releases.linaro.org/platform/%5Brelease%5D/hwpacks/%5Bmilestone%5D/
What's the release/milestone distinction here?
Release is a YY.MM release and a milestone is alpha/beta/eac/release candidate/final. I realise that we are being far more agile than we were and we probably won't have anything before a release candidate.
I think that the only thing not considered here is multiple versions of a single rootfs or hwpack.
We are currently generating both natty-based and oneiric-based rootfs. I don't know if we plan to release both ever, or if oneiric-based is just snapshots for now, and we will switch one month to release the oneiric-based and not release the natty-based. If someone could clarify the intent here it will help us decide if the hierarchy needs to accommodate that too.
Agreed. Clarification required++
If we would like to have hardware packs closer to the distributions, we have a problem of the hwpack directory being rather large - copying it into each distribution would make it more difficult to find the right files. This problem does go away completely if we automate the downloading of files for the user, which we now do with linaro-fetch-image[-ui].
Yes.
We can do both and use symlinks though :-)
Well, quite. We already have a custom header on most of the pages so having some help text in there with links to the root of the OS binaries and hwpack directories may help as well.
I personally find it unnecessary to have separate directories for the linaro evaluation builds. The Ubuntu desktop and LEB builds seem to be identical (the md5sums files match at least!). Since we can link to specific places on the releases server in a release note, why not just link to the ubuntu-desktop directory? If we want to separate out Linaro Evaluation Builds we could have a structure like: http://releases.linaro.org/platform/11.07/linaro-evaluation-builds/ubuntu-de... http://releases.linaro.org/platform/11.07/community-supported/alip/release-c... http://releases.linaro.org/platform/11.07/hwpacks/release-candidate/
My guess is that Alexander will want something like this to maintain that separation.
I can see why http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/ exists, but I believe it is obsolete with the release of linaro-fetch-image or linaro-fetch-image-ui, which automate the whole download and install process. Those tools don't support Android builds yet though. In another twist though the Android builds exist in a third directory structure! http://releases.linaro.org/platform/linaro-n/android/11.07/panda/
Clearly this makes it easy for people with a panda board to get the files they need to run Android on it. The files seem to be unique, so it looks like it can be left alone, other than getting rid of the linaro-n.
It seems like these should fit in to your proposed structure above, with an image name of "android" or similar?
I was deliberately quiet on this point because I am unfamiliar with how all the files work together and if there is any duplication. Guidance welcome :-)
It should be simple enough to script copying the files from snapshots.linaro.org over to releases for the non-Android builds. I am happy to put together something like: create-linaro-release --source-snapshot YYMMDD:build --relese-type <alpha/beta/eac/rc/final> --relase-name <YY.MM>
While this is a good idea, I don't think it's organised enough to be done all at once right now. Builds are currently copied in chunks as they are ready.
While a script might be useful let's not make it a focus of this discussion. If the RMs want a script we can write it, but let's first
Sounds good to me. I didn't want to start a discussion about a problem without offering up a solution though!
Thanks,
On Wed, 27 Jul 2011 15:48:06 +0100, James Tunnicliffe james.tunnicliffe@linaro.org wrote:
Release is a YY.MM release and a milestone is alpha/beta/eac/release candidate/final. I realise that we are being far more agile than we were and we probably won't have anything before a release candidate.
Right, I wonder if it's useful to have RC on releases.linaro.org, or we should just point to whatever build we are testing on snapshots.linaro.org?
It seems like these should fit in to your proposed structure above, with an image name of "android" or similar?
I was deliberately quiet on this point because I am unfamiliar with how all the files work together and if there is any duplication. Guidance welcome :-)
Android is a bit different in that it doesn't need a hwpack and rootfs, but I'm not sure that it needs to be a separate thing in the filesystem hierarchy.
Thanks,
James
James, This is a good topic to tackle. I have struggled myself to generalize a script I wrote that helps with the media creation. I think we should start doing retrospectives on the monthly releases and this topic can be one of the first ones to address. Mounir
On Wed, Jul 27, 2011 at 5:48 AM, James Tunnicliffe < james.tunnicliffe@linaro.org> wrote:
Hi,
Executive summary: James opens up a can of worms and volunteers to fix it.
I am not suggesting that we change anything for this release. I don't mind what the directory structure on releases.linaro.org is, as long as it is consistent. But...
As someone who cares more about structure on the file server than most (because I try and maintain an index) I thought I should reply. It is clear that we now have two structures living side by side on the server. We used to have: http://releases.linaro.org/platform/%5Blinaro release]/[distribution name]/[milestone]/
And we now seem to be going with http://releases.linaro.org/platform/linaro-n/%5Bdistribution name]/[release name]/
The problem is these exist side by side, so looking in http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/ I see 11.05, 11.06, 11.07, alpha-3, beta-2, beta, final, latest. alpha/beta/final are from the old 6 month release cycle and final became 11.05. The other [year].[month] directories are a Linaro release, with no tagging to say if they are a release candidate - a bit confusing!
A couple more observations:
First we have duplication of hardware packs, but not the checksum files and GPG signatures to go with them. The hardware packs are hardware, not distribution specific, so it is difficult to justify to have them in multiple locations. I imagine that this structure was designed to put everything in one directory that someone may need to get up and running with a Linaro distribution, but if they want to check their hardware packs are signed and correctly downloaded they still need to visit the hwpacks directory.
Second we are still using http://releases.linaro.org/platform/linaro-n. I thought we had done away with the lettered naming convention to go with the date based ones.
To index the releases server automatically I need a predictable file structure. I don't mind what it is, as long as we stick to it. My suggestion is:
All OS binaries structured as: http://releases.linaro.org/platform/%5Brelease%5D/%5Bdistributionname%5D/%5B...
Hardware packs all in one place: http://releases.linaro.org/platform/%5Brelease%5D/hwpacks/%5Bmilestone%5D/
If we would like to have hardware packs closer to the distributions, we have a problem of the hwpack directory being rather large - copying it into each distribution would make it more difficult to find the right files. This problem does go away completely if we automate the downloading of files for the user, which we now do with linaro-fetch-image[-ui].
I personally find it unnecessary to have separate directories for the linaro evaluation builds. The Ubuntu desktop and LEB builds seem to be identical (the md5sums files match at least!). Since we can link to specific places on the releases server in a release note, why not just link to the ubuntu-desktop directory? If we want to separate out Linaro Evaluation Builds we could have a structure like:
http://releases.linaro.org/platform/11.07/linaro-evaluation-builds/ubuntu-de...
http://releases.linaro.org/platform/11.07/community-supported/alip/release-c... http://releases.linaro.org/platform/11.07/hwpacks/release-candidate/
I can see why http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/ exists, but I believe it is obsolete with the release of linaro-fetch-image or linaro-fetch-image-ui, which automate the whole download and install process. Those tools don't support Android builds yet though. In another twist though the Android builds exist in a third directory structure! http://releases.linaro.org/platform/linaro-n/android/11.07/panda/
Clearly this makes it easy for people with a panda board to get the files they need to run Android on it. The files seem to be unique, so it looks like it can be left alone, other than getting rid of the linaro-n.
It should be simple enough to script copying the files from snapshots.linaro.org over to releases for the non-Android builds. I am happy to put together something like: create-linaro-release --source-snapshot YYMMDD:build --relese-type <alpha/beta/eac/rc/final> --relase-name <YY.MM>
For the Android builds there are two XML files that aren't in the snapshots at the moment. If these are easily generated or supplied, we could automate that release as well.
James
On 27 July 2011 03:57, Mounir Bsaibes mounir.bsaibes@linaro.org wrote:
Hi, In preparation for the release of Linaro 11.07 images on 2011-07-28, a suitable candidate has been selected for testing. Please help our initiative by testing the official Linaro Evaluation Build (LEB):
- Android: http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/
- Ubuntu: http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/
Another exciting development worth sharing is the arrival of very early Linaro android builds for snowball. Our snowball builds are combining
AOSP
based Linaro Platform code with a landing team kernel based on a recent linux-linaro and linux-linaro-android with an androidized linux-linaro kernel with landing team goodies on top.
http://releases.linaro.org/platform/linaro-n/android/latest/leb-snowball/
On top of our officially supported Linaro Evaluation Builds images above, the Linaro Platform Team is proud to also provide a set of images
prepared
by Linaro developers and community for specific target audience. Developers
and
Community Builds images are provided on a best-effort basis and in the
hope
that they can be useful. Last reported known to be working images can be found below:
- Nano: http://releases.linaro.org/platform/linaro-n/nano/latest/
- ALIP: http://releases.linaro.org/platform/linaro-n/alip/latest/
- Developer: http://releases.linaro.org/platform/linaro-n/developer/latest/
- Ubuntu-desktop http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/latest/
A list of all hardware packs hosted by Linaro Platform can be found
below:
http://releases.linaro.org/platform/linaro-n/hwpacks/latest/ Please support the Developers and Community Builds images efforts by
testing
and providing feedback for our builds. As a side note, hwpacks that have an -lt- in their name are outputs from the Linaro Landing teams, using some of their components. Similar to the spirit of the Ubuntu based Developers and Community
images,
the Linaro Android Platform Team provides a set of vanilla AOSP builds that use Linaro toolchain and the Linaro mainline kernel for development boards that have good enough mainline support to run a full AOSP user experience. Those builds are not officially supported and are provided in the hope that they might be useful.
- Android Vanilla AOSP for BeagleBoard-xM: http://releases.linaro.org/platform/linaro-n/android/latest/beaglexm/
- Android Vanilla AOSP for PandaBoard: http://releases.linaro.org/platform/linaro-n/android/latest/panda/
Make your way to the installation instructions: https://wiki.linaro.org/Platform/Android/ImageInstallation https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation For an explanation of how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker
Known Issues
Android:
- ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07
- No HDMI display working linux-linaro-android 3.0-2011.07 with
pandaboard
- Two bugs reported against beagle XM rev C board suggest that there are
issues severly impacting the stability and potentially usefulness of
Linaro
Android builds for the rev C boards.
Ubuntu:
- Pulseaudio consumes 100% of the cpu when trying to play a sound with
natty's linaro LEB and 3.0.0-1402-linaro-lt-omap
- Only half of RAM useabe when using Devive Tree on Panda Board
-- Mounir Bsaibes Project Manager
Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#%21/linaroorg http://www.linaro.org/linaro-blog
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- James Tunnicliffe
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Thanks james for your feedback and input.
On Wed, Jul 27, 2011 at 12:48 PM, James Tunnicliffe james.tunnicliffe@linaro.org wrote:
Hi,
Executive summary: James opens up a can of worms and volunteers to fix it.
I am not suggesting that we change anything for this release. I don't mind what the directory structure on releases.linaro.org is, as long as it is consistent. But...
As someone who cares more about structure on the file server than most (because I try and maintain an index) I thought I should reply. It is clear that we now have two structures living side by side on the server. We used to have: http://releases.linaro.org/platform/%5Blinaro release]/[distribution name]/[milestone]/
As you know we started discussing new releases.linaro.org layout a whilte back; we paused it due fathi being off in July. Now that Fabo will be back I am happy to resume this discussion so we can close that in time for august release.
Fabo will probably organize a session at Linaro Connect on this topic and Infrastructure Team should definitely have a liaison participating in that effort as tools update will definitely be needed ultimately.
-
Alexander Sack -
David Gilbert -
James Tunnicliffe -
James Westby -
Mounir Bsaibes