linaro-android July 2012

linaro-android@lists.linaro.org

39 participants
59 discussions

Re: [Linaro-validation] Some thought about the implementation of black-box test

by YongQin Liu

+ @linaro-android + @linaro-validation On 27 July 2012 09:32, YongQin Liu <yongqin.liu(a)linaro.org> wrote: > > > On 13 July 2012 11:19, Michael Hudson-Doyle <michael.hudson(a)linaro.org>wrote: > >> YongQin Liu <yongqin.liu(a)linaro.org> writes: >> >> > Hi, All >> > >> > Here just some thought about the implementation of black-box test. >> > If you have any ideas, or something I missed, please give a comment. >> > Anything will be appreciated. >> >> Thanks for sending this. >> >> > ------------------------------------------------------------ >> > *Glue between lava and android* >> > In android there is a directory /data/blackbox_tesxt/, under it are >> TODO, >> > TESTING, DONE 3 direcories. >> > >> > - TODO: the flags for test that need to run will be put here >> > - TESTING: the flags for test that are running will be put here. >> > normally, there should be only one entry.In the future will be more >> > entries when we support test execution via thread >> >> Do we actually want to support running more than one test at once? It >> doesn't seem like a super good idea to me. >> > > Yeah, seems support only one test once is more realistic now. > If so, seems we just need one action that will do > install/run/wait/get_result > > >> > - DONE: the flags for test that have been completed will be put >> here >> > >> > About the entry format, will use JSON or just key/value pair. but need >> to >> > have the following two features >> > 1. one item to indicate the command to run >> > 2. other items used for pass information between android test tool and >> lava >> > job >> > >> > *Black-box test framework on Android* >> > On android, a test framework will check the entries in TODO, and run the >> > command indicated in the entry. >> > Before the test is start to run, the framework will put the entry to >> > TESTING, and after test finished will put the entry to DONE. >> > when run the test command, this framework will run the command and pass >> the >> > entry file as parameter. >> > >> > The black-box test framework in android mainly do: >> > 1. invoked after boot up and home screen is displayed. >> > also charge for prepare the test environment like unlock screen, >> > disable suspend >> > 2. charging for invoking test command and changing the status of the >> each >> > test >> > >> > *Framework on LAVA* >> > >> > Will have 2 actions >> > 1. install_black-box_test >> >> Will this action have a list of tests to install? >> > I'd like to install one test with one action. > as I described in another mail. > >> >> > 2. wait_black_test_finish >> > will loop to check until there is no entry in TODO and TESTING >> > also will check if the test framework is running, if it is not in ps >> > and there are still test to be run, will invoke it to run. >> > show the output of the running test >> >> Do we want to reboot between tests? >> > I think this can be done out the lava-dispatcher like the system-reboot on > android-build now. > > > Thanks, > Yongqin Liu >

12 years, 4 months

Some thought about the implementation of black-box test

by YongQin Liu

Hi, All Here just some thought about the implementation of black-box test. If you have any ideas, or something I missed, please give a comment. Anything will be appreciated. ------------------------------------------------------------ *Glue between lava and android* In android there is a directory /data/blackbox_tesxt/, under it are TODO, TESTING, DONE 3 direcories. - TODO: the flags for test that need to run will be put here - TESTING: the flags for test that are running will be put here. normally, there should be only one entry.In the future will be more entries when we support test execution via thread - DONE: the flags for test that have been completed will be put here About the entry format, will use JSON or just key/value pair. but need to have the following two features 1. one item to indicate the command to run 2. other items used for pass information between android test tool and lava job *Black-box test framework on Android* On android, a test framework will check the entries in TODO, and run the command indicated in the entry. Before the test is start to run, the framework will put the entry to TESTING, and after test finished will put the entry to DONE. when run the test command, this framework will run the command and pass the entry file as parameter. The black-box test framework in android mainly do: 1. invoked after boot up and home screen is displayed. also charge for prepare the test environment like unlock screen, disable suspend 2. charging for invoking test command and changing the status of the each test *Framework on LAVA* Will have 2 actions 1. install_black-box_test 2. wait_black_test_finish will loop to check until there is no entry in TODO and TESTING also will check if the test framework is running, if it is not in ps and there are still test to be run, will invoke it to run. show the output of the running test 3. collect_test_result parse and upload to lava ------------------------------------------------------------ *Related BPs* 1. lava side: https://blueprints.launchpad.net/lava-dispatcher/+spec/black-box-test-actio… 2. android-side: https://blueprints.launchpad.net/linaro-android/+spec/support-blackbox-test Thanks, Yongqin Liu

12 years, 4 months

Rehash of the BUILD-INFO roadmap

by Zygmunt Krynicki

Hey everyone. I'd like to update you on where we are with BUILD-INFO support. Over the past few days I've been testing how our existing, mock/test BUILD-INFO.txt are handled by the current build and delivery system. The outcome of this tests show that it has a number of shortcomings that make it impractical to really deploy the new binary overlays there. Builds protected by OpenID cannot be integrated at all and all other builds would need to use the word 'blob' in the Jenkins configuration name for anything else to work. To address this, the current PHP-based codebase was rewritten as a Django application. We are currently waiting for two RT tickets to allow that application to land on a new staging server. As this is still 'far away' according to IS we need to come up with a new plan that would allow us to make progress and untangle us from a slow and frustrating RT-bound development cycle. I've discussed this with Asac just now and we came up with the following plan: 1) I will locally deploy the new Django codebase and feed it with some of the data from the snapshot server. This will allow me to verify how the codebase reacts to various BUILD-INFO.txt without really building anything or waiting for RT to land a file in certain spot. This will allow us to ensure that all the BUILD-INFO.txt overlays I've created work as intended. 2) I will manually patch and request uploads of three vendor tarballs: one for origen and two for snowball. We currently have two snowball overlays that have been patched but due to bugs detected later in testing they need to be updated again. 3) We will wait for the RT tickets 504 and 518 to land. This will allow us to have the new Django codebase on a staging server. Then, in coordination with Linaro Infrastructure and Canonical IS we'll do the switch. This part is the most risky step in my opinion. The switch involves two objects: our server software and tip configurations of all existing builds. The risky step is to prevent any old builds from bein downloaded without relying on the old PHP rules to serve EULAs. I will be working with gesha to ensure we have planned this step well. To allow us to track 1-3 we need to make some changes to our existing blueprints. Currently we have three blueprints that cover BUILD-INFO work: * https://blueprints.launchpad.net/linaro-android/+spec/include-build-info-txt This blueprint is already marked as implemented although Asac has raised concerns as to this being inappropriate as it clearly contradicts the acceptance criteria. Still I would like to keep it closed and just focus on the remaining two: * https://blueprints.launchpad.net/linaro-android/+spec/deploy-build-info-txt This blueprint currently captures testing in existing environment, generating real overlay tarballs and updating the configuration for tip builds. I'd like to extend it to cover testing in the new django codebase and anything that comes out of that. * https://blueprints.launchpad.net/linaro-license-protection/+spec/django-rew… This blueprint covers the new django rewrite and the deployment. It also has some aspects of BUILD-INFO such as job migration. Since there is overlap here I'd like to remove it from one of the blueprints so that there is exactly one person that is responsible for doing it and there is no confusion. One of the thing that is still problematic is the unfinished aspect of the rewritten code. According to this blueprint the final specification of BUILD-INFO is not yet finished. I'd like to avoid the situation where code bugs or bugs coupled with specification changes render existing vendor tarballs broken. I think we need to have a very clear idea on how to implement this to avoid any transition risks and know how to track progress. I'd like to propose the following actions to happen: [pfefferz or asac] * ack a change to include-build-info-txt Headline and Acceptance fields so that it can stay implemented * ack the production transition plan created by gesha * provide parts of snapshots.linaro.org files to zyga to recreate some of the builds for testing [zyga] * deploy the django rewrite locally, syncing with gesha if needed * test (on django codebase), fix if needed and upload snowball and origen tarballs to snapshots.linaro.org [gesha] * describe how to transition from old PHP to Django server and how the new staging instance is used in that transition. The critical part here is to understand what happens to files published without BUILD-INFO or writ damaged/wrong BUILD-INFO. * get IS to assist with the transition, ensure that we can revert to the old system if something goes wrong Once we all agree on the following plan I'd like to document it in our blueprints. Thanks. ZK -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/

12 years, 4 months

First-cut 12.08 Android plan available

by Zach Pfeffer

Take a look at: https://launchpad.net/linaro-android/+milestone/12.08 (lots of JB) -- 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

12 years, 5 months

Does Linaro Android supports USB webcam?

by 王子健

Hi, I'm developing a project which takes the video and sound from a USB webcam on pondaboard. And the webcam is Logitech C525. In 'Camera' application in Linaro Android 4.0.3, when switch to recording mode, the application will crash with camera error number 100. And this problem does not happen on Ubuntu. Does Linaro Android support USB webcam? Thanks, Martin

12 years, 5 months

BUILD-INFO.txt test results (failed)

by Zygmunt Krynicki

Hi everyone. I've setup a set of builds to examine how my BUILD-INFO.txt overlays are interpreted by the build system. Sadly the tests seem to indicate that the system does not work. There are two tests to show this: Build: https://android-build.linaro.org/builds/~zkrynicki/origen-ics-gcc47-samsung… This build uses: 1) Samsung 'name' of the build 2) Panda source code 3) Fake overlay with snowball license The result is: samsung license presented. Build: https://android-build.linaro.org/builds/~zkrynicki/origen-ics-gcc47-samsung… Points 1-3 as before, the only difference is some switch in jenkins (that I cannot see as I don't have access to jenkins) that instructs it to pull BUILD-INFO.txt from the build tree. The result is: no license is presented, any file can be downloaded at will Both builds are correct in the term that BUILD-INFO.txt is copied to the output directory, alongside system.tar.bz2 This can be easily confirmed by grepping for BUILD-INFO.txt in the full build logs My suggestion for tomorrow: 1) I'd like to work with Gesha who implemented the php based system to debug why build #6 failed to work. Gesha: would you have some time to work on this (in sync) tomorrow? 2) I'd like to get it to work as intended. Getting access to jenkins would make this part much much easier (I suspect that requires danilos/asac to ack). 3) I'd like to ACK the plan on how to switch production builds to this with all the stakeholders (asac, pfefferz, gesha). Currently we are in position to switch everything bug samsung/origen builds (still waiting for a response from anyone on the samsung team, will reiterate/escalate to get response and move the topic). The only things that are preventing us from doing this is the actual build/download system integration. Thanks everyone. ZK -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/

12 years, 5 months

2012/7/25 Linaro Android Platform Team meeting agenda posted

by Zach Pfeffer

Linaro Android platform team agenda posted to https://wiki.linaro.org/Platform/Android/Meetings/2012-07-25. 13:00 UTC in #linaro-meeting on irc.freenode.net on 2012/7/25. We’re going to present our JB upgrade plan (basically put the kernels we’re currently using into the builds and start fixing stuff). -- 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

12 years, 5 months

Tripped up by TARGET_NO_HARDWAREGFX=1 and KERNEL_CONFIG=omap4plus_defconfig

by Zach Pfeffer

Hey everyone, So we put a hack in (that I fully endorsed) to allow us to easily switch between builds that have hardware acceleration and those that don't. We pass TARGET_NO_HARDWAREGFX=1 We also have a hack that allows us to easily switch the kernel config: KERNEL_CONFIG=omap4plus_defconfig If you see these in a build you're trying to recreate locally, please export these variables. We did this to cut down on build variants, but we're going to revisit things soon. :) -- 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

12 years, 5 months

Moving toolchain tarball into git

by Zach Pfeffer

Hey Bero/Paul Who sets up: http://snapshots.linaro.org/android/~linaro-android/toolchain-4.7-2012.07/1… and http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/l… I'm asking because I'd like to solve a problem our users are running into. The instructions listed on top of each build pages are wrong. They say things like: $ wget --no-check-certificate http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/l… $ tar -jxvf android-toolchain-eabi-linaro-* when the build is using TOOLCHAIN_URL=http://snapshots.linaro.org/android/~linaro-android/toolchain… I'd like to fix this so that the builds pull the right thing. I was thinking that we could commit the toolchain tarballs to git and then just pull things as part of the manifest. That would help our local users. We could also take a half step and write a script that would setup the environment and have people (and the build server) also use that. We have the same issue with: KERNEL_CONFIG=omap4plus_defconfig Which should be in the build. Anyway, I think its time to start making: MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git MANIFEST_BRANCH=linaro_android_4.0.4 MANIFEST_FILENAME=tracking-panda.xml TARGET_PRODUCT=pandaboard TARGET_SIMULATOR=false TARGET_BUILD_VARIANT=tests SOURCE_OVERLAY="open/20120716/build-info.tar.bz2" TOOLCHAIN_URL=http://snapshots.linaro.org/android/~linaro-android/toolchain… TOOLCHAIN_TRIPLET=arm-linux-androideabi REPO_SEED_URL=http://android-build.linaro.org/seed/uniseed.tar.gz LAVA_SUBMIT=1 LAVA_SUBMIT_FATAL=0 TARGET_NO_HARDWAREGFX=1 KERNEL_CONFIG=omap4plus_defconfig LAVA_ANDROID_BINARIES=False LAVA_TEST_PLAN="busybox,0xbench,glmark2,skia,v8,mmtest,monkey,monkey_long_run" MONKEY_RUNNER_URL_1="git://android.git.linaro.org/test/linaro/android/system.git" CTS_TIMEOUT=36000 turn into: MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git MANIFEST_BRANCH=linaro_android_4.0.4 MANIFEST_FILENAME=tracking-panda.xml -- 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

12 years, 5 months

Is anything weird going on w/ platform/hardware/linaro/tinyhal?

by Bernhard Rosenkränzer

Hi, I've ported git://android.git.linaro.org/platform/hardware/linaro/tinyhal.git to JellyBean - but somehow, the commit appears to get "forgotten" about. At first I thought I forgot to commit, but the port patch keeps disappearing. Since nobody has screamed at me, I don't think my patch broke anything causing it to be reverted. By any chance, is tinyhal being mirrored from git.linaro.org, killing off any changes made on android.git.linaro.org? ttyl bero

12 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-android July 2012