Hi,
In preparation for the release of Linaro 11.09 images on 2011-09-29, we have collected candidate submissions for our Linaro Evaluation Build (LEB), Developers and Community images.
All primary developement boards supported by Linaro Landing Teams have an Android LEB candidate image submitted and an Ubuntu LEB hwpack submitted. Note: Due to the early stage of the enablement, some images might not work.
Based on your feedback, the Release Team will review the quality of those candidate builds and award builds that deliver a decent user experience with the "official LEB" badge. Builds not quite ready yet will continue to be published as Developers and Community builds for the final release until enough progress has been made.
Note: Your feedback to this call for testing will provide the main source of data used by the Release Team to determine the user experience and hence is essential to this process.
Linaro Evaluation Build (LEB) =============================
Please help our initiative by testing this month Linaro Evaluation Build (LEB) candidates for Android and Ubuntu:
* i.MX53 Quick Start: Android: http://bit.ly/nygm05 Ubuntu: http://bit.ly/q5GJjc
* Origen: Android: http://bit.ly/pOEGv7 Ubuntu: http://bit.ly/r4gGsk
* PandaBoard: Android: http://bit.ly/p4jjNH Ubuntu: http://bit.ly/nTI5Xj
* Snowball: Android: http://bit.ly/oMBTIH Ubuntu: http://bit.ly/pLHwk5
Developers and Community Build ==============================
On top of our officially supported Linaro Evaluation Build candidate images from above, the Linaro Platform Team is proud to also provide additional images and additional board support bits that were prepared by Linaro developers and community for a more specific target audience.
Note that the Developers and Community bits are provided on a best-effort basis and in the hope that they can be useful. We release last reported known to be working images.
If you are interested in running Nano, ALIP or Developer image _or_ want to try our LEB on one of the board support packs maintained by our community, please help and test by following the download and installation instructions included in the questionaire linked from below your board:
* BeagleBoard: http://bit.ly/nu9vll
* BeagleBoard-xM: http://bit.ly/rsBc1Z
* EFIKA MX: http://bit.ly/qAD5Pe
* IGEPv2: http://bit.ly/pRTcuB
* i.MX51 Babbage: http://bit.ly/oOq3yc
* i.MX53 Quick Start: http://bit.ly/nLrxj0
* Origen: http://bit.ly/oFH55A
* Overo: http://bit.ly/oZY3ex
* PandaBoard: http://bit.ly/pFdcLl
* Versatile Express: http://bit.ly/n0JpN7
Resources =========
Note: Wonder what to download? Instructions including download URLs are documented as part of the feedback form reachable through the URLs above.
Ubuntu: * ALIP (Xfce desktop): http://snapshots.linaro.org/11.05-daily/linaro-alip/20110926/0/images/tar/al... * Developer (text user interface + developer tools): http://snapshots.linaro.org/11.05-daily/linaro-developer/20110926/0/images/t... * Nano (think small): http://snapshots.linaro.org/11.05-daily/linaro-nano/20110926/0/images/tar/na... * Ubuntu: http://snapshots.linaro.org/11.05-daily/linaro-ubuntu-desktop/20110926/0/ima... * Hardware packs: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/%24%7BBOARD%7D/201109... * Installation Instructions: https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation
Android: * Android staging for i.MX53 Quick Start: https://android-build.linaro.org/builds/~linaro-android/staging-imx53-11.09-... * Android staging for Origen: https://android-build.linaro.org/builds/~linaro-android/staging-origen-11.09... * Android staging for PandaBoard: https://android-build.linaro.org/builds/~linaro-android/staging-panda-11.09-... * Android staging for Snowball: https://android-build.linaro.org/builds/~linaro-android/staging-snowball-11.... * Installation Instructions: https://wiki.linaro.org/Platform/Android/ImageInstallation
Known Issues ============
* ARM SMP scheduler performance bug (Ubuntu/PandaBoard) https://launchpad.net/bugs/709245
* Snowball USB not working (Android/Ubuntu/Snowball) https://launchpad.net/bugs/804091
* fails to mount system and user partition interminttently (Android/Snowball) https://launchpad.net/bugs/823313
* Combined V2/V3 Snowball hwpack (20110905) fails with l-m-c (Ubuntu/Snowball) https://launchpad.net/bugs/842973
* GLK3.0 allows processes to overwrite page frame data (Ubuntu/Snowball) https://launchpad.net/bugs/849005
You can find the complete list of known issues for the 11.09 release at: https://launchpad.net/linaro-android/+milestone/11.09 https://launchpad.net/linaro-ubuntu/+milestone/11.09
When filling new bugs, please check if it's not yet reported. You can use: https://bugs.launchpad.net/linaro-android/+bugs?orderby=-datecreated https://bugs.launchpad.net/linaro-ubuntu/+bugs?orderby=-datecreated
Hi Fathi,
Sorry for the top post.
Any specific reason why using the build from 0926 as the RC instead of 0927? This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images?
Thanks,
Ricardo
On Mon, Sep 26, 2011 at 10:30 PM, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi,
In preparation for the release of Linaro 11.09 images on 2011-09-29, we have collected candidate submissions for our Linaro Evaluation Build (LEB), Developers and Community images.
All primary developement boards supported by Linaro Landing Teams have an Android LEB candidate image submitted and an Ubuntu LEB hwpack submitted. Note: Due to the early stage of the enablement, some images might not work.
Based on your feedback, the Release Team will review the quality of those candidate builds and award builds that deliver a decent user experience with the "official LEB" badge. Builds not quite ready yet will continue to be published as Developers and Community builds for the final release until enough progress has been made.
Note: Your feedback to this call for testing will provide the main source of data used by the Release Team to determine the user experience and hence is essential to this process.
Linaro Evaluation Build (LEB)
Please help our initiative by testing this month Linaro Evaluation Build (LEB) candidates for Android and Ubuntu:
* i.MX53 Quick Start: Android: http://bit.ly/nygm05 Ubuntu: http://bit.ly/q5GJjc
* Origen: Android: http://bit.ly/pOEGv7 Ubuntu: http://bit.ly/r4gGsk
* PandaBoard: Android: http://bit.ly/p4jjNH Ubuntu: http://bit.ly/nTI5Xj
* Snowball: Android: http://bit.ly/oMBTIH Ubuntu: http://bit.ly/pLHwk5
Developers and Community Build
On top of our officially supported Linaro Evaluation Build candidate images from above, the Linaro Platform Team is proud to also provide additional images and additional board support bits that were prepared by Linaro developers and community for a more specific target audience.
Note that the Developers and Community bits are provided on a best-effort basis and in the hope that they can be useful. We release last reported known to be working images.
If you are interested in running Nano, ALIP or Developer image _or_ want to try our LEB on one of the board support packs maintained by our community, please help and test by following the download and installation instructions included in the questionaire linked from below your board:
* BeagleBoard: http://bit.ly/nu9vll
* BeagleBoard-xM: http://bit.ly/rsBc1Z
* EFIKA MX: http://bit.ly/qAD5Pe
* IGEPv2: http://bit.ly/pRTcuB
* i.MX51 Babbage: http://bit.ly/oOq3yc
* i.MX53 Quick Start: http://bit.ly/nLrxj0
* Origen: http://bit.ly/oFH55A
* Overo: http://bit.ly/oZY3ex
* PandaBoard: http://bit.ly/pFdcLl
* Versatile Express: http://bit.ly/n0JpN7
Resources
Note: Wonder what to download? Instructions including download URLs are documented as part of the feedback form reachable through the URLs above.
Ubuntu: * ALIP (Xfce desktop): http://snapshots.linaro.org/11.05-daily/linaro-alip/20110926/0/images/tar/al... * Developer (text user interface + developer tools): http://snapshots.linaro.org/11.05-daily/linaro-developer/20110926/0/images/t... * Nano (think small): http://snapshots.linaro.org/11.05-daily/linaro-nano/20110926/0/images/tar/na... * Ubuntu: http://snapshots.linaro.org/11.05-daily/linaro-ubuntu-desktop/20110926/0/ima... * Hardware packs: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/%24%7BBOARD%7D/201109... * Installation Instructions: https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation
Android: * Android staging for i.MX53 Quick Start: https://android-build.linaro.org/builds/~linaro-android/staging-imx53-11.09-... * Android staging for Origen: https://android-build.linaro.org/builds/~linaro-android/staging-origen-11.09... * Android staging for PandaBoard: https://android-build.linaro.org/builds/~linaro-android/staging-panda-11.09-... * Android staging for Snowball: https://android-build.linaro.org/builds/~linaro-android/staging-snowball-11.... * Installation Instructions: https://wiki.linaro.org/Platform/Android/ImageInstallation
Known Issues
* ARM SMP scheduler performance bug (Ubuntu/PandaBoard) https://launchpad.net/bugs/709245
* Snowball USB not working (Android/Ubuntu/Snowball) https://launchpad.net/bugs/804091
* fails to mount system and user partition interminttently (Android/Snowball) https://launchpad.net/bugs/823313
* Combined V2/V3 Snowball hwpack (20110905) fails with l-m-c (Ubuntu/Snowball) https://launchpad.net/bugs/842973
* GLK3.0 allows processes to overwrite page frame data (Ubuntu/Snowball) https://launchpad.net/bugs/849005
You can find the complete list of known issues for the 11.09 release at: https://launchpad.net/linaro-android/+milestone/11.09 https://launchpad.net/linaro-ubuntu/+milestone/11.09
When filling new bugs, please check if it's not yet reported. You can use: https://bugs.launchpad.net/linaro-android/+bugs?orderby=-datecreated https://bugs.launchpad.net/linaro-ubuntu/+bugs?orderby=-datecreated
-- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs
On Tue, Sep 27, 2011 at 5:23 AM, Ricardo Salveti <ricardo.salveti@linaro.org
wrote:
Hi Fathi,
Sorry for the top post.
Any specific reason why using the build from 0926 as the RC instead of 0927? This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
Due to release manager timezone etc. we aim for cutting ready to RC images by 1600 UTC on Monday. Can't we do the base-files update on Friday. Are there any other packages like kernel that need more up-front integration time?
On Tue, Sep 27, 2011 at 3:17 AM, Alexander Sack asac@linaro.org wrote:
On Tue, Sep 27, 2011 at 5:23 AM, Ricardo Salveti ricardo.salveti@linaro.org wrote:
Hi Fathi,
Sorry for the top post.
Any specific reason why using the build from 0926 as the RC instead of 0927? This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
Due to release manager timezone etc. we aim for cutting ready to RC images by 1600 UTC on Monday. Can't we do the base-files update on Friday. Are there any other packages like kernel that need more up-front integration time?
The base-files package was just one example, but it's also common to integrate other components, mostly from the landing teams. This time, for example, we were just able to push the TI LT kernel after the 0926 build, as the tree was properly rebased and tagged at friday.
Cheers,
Hi Ricardo,
On 27 September 2011 06:23, Ricardo Salveti ricardo.salveti@linaro.org wrote:
Any specific reason why using the build from 0926 as the RC instead of 0927?
According to the schedule, RC images are delivered 3 days before the release, Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926.
This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
For your specific example, base-files should be updated on Thursday, with Linaro components release. This changes doesn't affect the testing.
IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility.
Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images?
An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images.
Cheers,
Fathi
On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi Ricardo,
On 27 September 2011 06:23, Ricardo Salveti ricardo.salveti@linaro.org wrote:
Any specific reason why using the build from 0926 as the RC instead of 0927?
According to the schedule, RC images are delivered 3 days before the release, Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926.
This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
For your specific example, base-files should be updated on Thursday, with Linaro components release. This changes doesn't affect the testing.
Don't know if updating it on thursday would be the best case, but sure, it can be done at least at friday.
And it doesn't change the testing, but we need an image respin.
IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility.
We could just have a build job scheduled at 16 UTC at offspring, so we avoid requiring manual builds. I believe this would be our best option (and it usually takes around 3 hours to build all images).
Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images?
An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images.
Sure, but I also believe we should have a better way to communicate the community and others about an image respin, so we avoid people testing the images provided by the call for testing email when another one is already available.
Cheers,
On 27 September 2011 09:59, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi Ricardo,
On 27 September 2011 06:23, Ricardo Salveti ricardo.salveti@linaro.org wrote:
Any specific reason why using the build from 0926 as the RC instead of 0927?
According to the schedule, RC images are delivered 3 days before the release, Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926.
This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
For your specific example, base-files should be updated on Thursday, with Linaro components release. This changes doesn't affect the testing.
Don't know if updating it on thursday would be the best case, but sure, it can be done at least at friday.
And it doesn't change the testing, but we need an image respin.
IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility.
We could just have a build job scheduled at 16 UTC at offspring, so we avoid requiring manual builds. I believe this would be our best option (and it usually takes around 3 hours to build all images).
sounds a good compromise.
Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images?
An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images.
Sure, but I also believe we should have a better way to communicate the community and others about an image respin, so we avoid people testing the images provided by the call for testing email when another one is already available.
I'll try to better communicate to our wider community on the testing progress on linaro-dev ml by doing follow-up on the call for testing mail.
Cheers,
Fathi
On Tue, Sep 27, 2011 at 9:23 AM, Fathi Boudra fathi.boudra@linaro.orgwrote:
On 27 September 2011 09:59, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra fathi.boudra@linaro.org
wrote:
Hi Ricardo,
On 27 September 2011 06:23, Ricardo Salveti ricardo.salveti@linaro.org
wrote:
Any specific reason why using the build from 0926 as the RC instead of 0927?
According to the schedule, RC images are delivered 3 days before the
release,
Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926.
This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
For your specific example, base-files should be updated on Thursday,
with
Linaro components release. This changes doesn't affect the testing.
Don't know if updating it on thursday would be the best case, but sure, it can be done at least at friday.
And it doesn't change the testing, but we need an image respin.
IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility.
We could just have a build job scheduled at 16 UTC at offspring, so we avoid requiring manual builds. I believe this would be our best option (and it usually takes around 3 hours to build all images).
sounds a good compromise.
Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images?
An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images.
Sure, but I also believe we should have a better way to communicate the community and others about an image respin, so we avoid people testing the images provided by the call for testing email when another one is already available.
I'll try to better communicate to our wider community on the testing progress on linaro-dev ml by doing follow-up on the call for testing mail.
I got this idea to setup a linaro-release twitter/google+ feed to update folks about RC, release progress, critical bugs discovered during testing, respins etc.
You would probably announce one time before release week on linaro-dev that detailed release updates go there there and folks can then opt-into following the release team. Next, we can also write a bot that auto posts respins during release week there.
[CALL FOR TESTING] Linaro 11.09 Release Candidate - UPDATE
On 27 September 2011 04:30, Fathi Boudra fathi.boudra@linaro.org wrote:
* Snowball: Android: http://bit.ly/oMBTIH Ubuntu: http://bit.ly/pLHwk5
Please, use the following hardware packs for Ubuntu: V2 - http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/lt-snowball-v2/201109... V3 - http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/lt-snowball-v3/201109...
On Tue, Sep 27, 2011 at 04:30:07AM +0300, Fathi Boudra wrote:
Hi,
In preparation for the release of Linaro 11.09 images on 2011-09-29, we have collected candidate submissions for our Linaro Evaluation Build (LEB), Developers and Community images.
All primary developement boards supported by Linaro Landing Teams have an Android LEB candidate image submitted and an Ubuntu LEB hwpack submitted. Note: Due to the early stage of the enablement, some images might not work.
Based on your feedback, the Release Team will review the quality of those candidate builds and award builds that deliver a decent user experience with the "official LEB" badge. Builds not quite ready yet will continue to be published as Developers and Community builds for the final release until enough progress has been made.
Note: Your feedback to this call for testing will provide the main source of data used by the Release Team to determine the user experience and hence is essential to this process.
Linaro Evaluation Build (LEB)
Please help our initiative by testing this month Linaro Evaluation Build (LEB) candidates for Android and Ubuntu:
i.MX53 Quick Start: Android: http://bit.ly/nygm05 Ubuntu: http://bit.ly/q5GJjc
Origen: Android: http://bit.ly/pOEGv7 Ubuntu: http://bit.ly/r4gGsk
PandaBoard: Android: http://bit.ly/p4jjNH Ubuntu: http://bit.ly/nTI5Xj
Has anyone successfully tested on Panda? I don't seem to be able to get any video output from the lt kernel. (I don't have HDMI, but if I understand correctly it should still be possible to get output via DVI -- I've had that working in the past.)
Cheers ---Dave
[CALL FOR TESTING] Linaro 11.09 Release Candidate - UPDATE
On 28 September 2011 17:57, Dave Martin dave.martin@linaro.org wrote:
* PandaBoard: Android: http://bit.ly/p4jjNH Ubuntu: http://bit.ly/nTI5Xj
Has anyone successfully tested on Panda? I don't seem to be able to get any video output from the lt kernel. (I don't have HDMI, but if I understand correctly it should still be possible to get output via DVI -- I've had that working in the past.)
Issue reported: * DVI-D display not working on Pandaboard https://bugs.launchpad.net/bugs/860402
Please, use the following hardware packs for Ubuntu: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/lt-panda-x11-base-nat...
-- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs
Hi Fathi,
On Mon, Sep 26, 2011 at 6:30 PM, Fathi Boudra fathi.boudra@linaro.org wrote:
If you are interested in running Nano, ALIP or Developer image _or_ want to try our LEB on one of the board support packs maintained by our community, please help and test by following the download and installation instructions included in the questionaire linked from below your board:
Which is the correct mechanism for reporting testing results: these questionnaires (very slick btw) or the qatracker tool?
Thanks, Ash
Hi Ash,
On 28 September 2011 20:40, Ash Charles ash@gumstix.com wrote:
On Mon, Sep 26, 2011 at 6:30 PM, Fathi Boudra fathi.boudra@linaro.org wrote:
If you are interested in running Nano, ALIP or Developer image _or_ want to try our LEB on one of the board support packs maintained by our community, please help and test by following the download and installation instructions included in the questionaire linked from below your board:
Which is the correct mechanism for reporting testing results: these questionnaires (very slick btw) or the qatracker tool?
QATracker usage is deprecated. The correct mechanism it to use the questionnaire. Though, it's a temporary solution as we're working actively on a replacement tool: lava-qatracker - https://launchpad.net/lava-qatracker
For the Developer and Community Build, feel free to give comments on the form itself, the mailing list or me directly. It will help us to improve lava-qatracker as we don't plan to invest time on the current forms.
Cheers,
Fathi
-
Alexander Sack -
Ash Charles -
Dave Martin -
Fathi Boudra -
Ricardo Salveti