linaro-validation July 2012

linaro-validation@lists.linaro.org

22 participants
25 discussions

by Michael Hudson-Doyle

Hi, We seem to build three vexpress pre-built images daily: vexpress alip lt-vexpress alip vexpress ubuntu-desktop Is that intentional? Can we at least have the jobs testing them put their results in separate bundle streams? Cheers, mwh

12 years, 6 months

Inconsistent canonicalization of test case IDs in lava-test vs lava-android-test

by Alexandros Frantzis

Hi all, I noticed that lava-test and lava-android-test canonicalize test case IDs differently. For example, "[build] usevbo" becomes "buildusevbo" in lava-test and "build_usevbo" in lava-android-test. This is caused by a reversal in the order of character replacement actions: lava-test first removes badchars and then replaces spaces with underscores, whereas lava-android-test does it the other way around (which is the correct way). This issue affects tests that can run both on android and ubuntu (like glmark2), because it makes it hard to process information across test runs that ran on different platforms. I see the following options: 1. Change lava-test behavior to match that of lava-android-test (which works as expected). This is going to create backwards-compatibility issues for some tests, but I am not sure how much people care (I don't mind this happening for glmark2). 2. Add a mechanism that can be optionally used to make the lava-test parser work correctly. For example, by making the badchars property writable one could set badchars to [^ a-zA-Z0-9\._-] (note the additional space ' ' character at the beginning of the character set) to work around the problem. 3. Let the user handle this by writing a custom parser (e.g. one that would just override badchars property as noted above). If (1) is acceptable, I would vote for it, as it will solve the problem once and for all, without the need for any action from the user. Thoughts? Thanks, Alexandros

12 years, 6 months

[PATCH] Include 'ubuntu.image_type' in job metadata.

by Michael Hudson-Doyle

As we want to separate the vexpress ALIP and Ubuntu Desktop builds for QA purposes. --- lava-submit.py | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lava-submit.py b/lava-submit.py index 2b65c3a..f9459b2 100755 --- a/lava-submit.py +++ b/lava-submit.py @@ -54,7 +54,8 @@ def get_test_actions(tests): }) return actions -def get_job(jobname, device_type, img_url, tests, image_name, image_number): +def get_job(jobname, device_type, img_url, tests, image_name, image_number, + image_type): stream = '/private/team/linaro/pre-built-%s/' % DEVICE_STREAM[device_type] job = collections.OrderedDict() @@ -69,7 +70,8 @@ def get_job(jobname, device_type, img_url, tests, image_name, image_number): }, 'metadata': { 'ubuntu.name': image_name, - 'ubuntu.build': image_number + 'ubuntu.build': image_number, + 'ubuntu.image_type': image_type, } }, { @@ -135,7 +137,7 @@ def main(): pass job = get_job(args.job_name, args.device_type, args.img_url, tests, - args.image_name, args.image_number) + args.image_name, args.image_number, args.image_type) user = os.environ.get('LAVA_USER') token = os.environ.get('LAVA_TOKEN') -- 1.7.9.5

12 years, 6 months

restoring staging db from backup

by Michael Hudson-Doyle

Hi all, I'm going to restore the staging db from the latest production snapshot today, so staging will be down for a while. Hope this isn't too disruptive! Cheers, mwh

12 years, 6 months

disk info in LAVA

by Andy Doan

We've tossed around this idea before, but I think its time to discuss something and put together a blueprint about pulling in SD card info into LAVA for each device. There are a few ways to do this, so I wanted to get some consensus on what people liked the most. My first thought was that ultimately the dispatcher is the component connected to the device, so it seems like its the place. However, that implies the scheduler ensuring the device is available, and probably taking the information from the dispatcher and pushing to our database. We'd also need to run this periodically. After thinking about that, I got to thinking we might be able to just piggy back off our health checks by simply adding a new dispatcher action (or maybe a lava-test) that from the master image pulls info like: /sys/block/mmcblk0/device/manfid /sys/block/mmcblk0/device/name /var/lib/lava/device.conf We could then roll this up into a test result and query from the DB? am i crazy?

12 years, 6 months

adding a dependency to LAVA post l-d-t

by Andy Doan

Hey Michael, I was trying to update our staging instance to use a new component today (lava-celery). I got it working, but I'm not sure if I followed the best practice for doing this. What I did: added entry to /srv/lava/instances/staging/code/current/buildout.cfg pulled in my local branch of the component to code/current/local ran ./bin/buildout So what's the proper way to do what I just hacked together? -andy

12 years, 6 months

[PATCH] Include image name and number in job metadata.

by Michael Hudson-Doyle

Include the name and number of the image that will be used for QA purposes in the job metadata so that these jobs and their results can be unambiguously identified in the LAVA database. --- I haven't tested this at all! lava-submit.py | 14 ++++++++++++-- submit-to-lava | 7 +++++-- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/lava-submit.py b/lava-submit.py index 185759f..ff014a3 100755 --- a/lava-submit.py +++ b/lava-submit.py @@ -54,7 +54,7 @@ def get_test_actions(tests): }) return actions -def get_job(jobname, device_type, img_url, tests): +def get_job(jobname, device_type, img_url, tests, image_name, image_number): stream = '/private/team/linaro/pre-built-%s/' % DEVICE_STREAM[device_type] job = collections.OrderedDict() @@ -66,6 +66,10 @@ def get_job(jobname, device_type, img_url, tests): 'command': "deploy_linaro_image", 'parameters': { 'image': img_url + }, + 'metadata': { + 'ubuntu.name': image_name, + 'ubuntu.build': image_number, } }, { @@ -98,6 +102,10 @@ def main(): help='The device type to execute on. ie "panda"') p.add_argument('-t', dest='image_type', default='nano', help='The image type to execute on, nano (default) or ubuntu-desktop') + p.add_argument('-n', dest='image_name', required=True, + help='The name of the image for QA purposes, e.g. "lt-panda-x11-base"') + p.add_argument('-c', dest='image_number', required=True, + help='The build number for this image') args = p.parse_args() # test sets specific to images and boards @@ -126,7 +134,9 @@ def main(): except ValueError: pass - job = get_job(args.job_name, args.device_type, args.img_url, tests) + job = get_job( + args.job_name, args.device_type, args.img_url, tests, args.image_name, + args.image_number) user = os.environ.get('LAVA_USER') token = os.environ.get('LAVA_TOKEN') diff --git a/submit-to-lava b/submit-to-lava index b297b5b..5f763dd 100755 --- a/submit-to-lava +++ b/submit-to-lava @@ -29,8 +29,11 @@ SCRIPT_ROOT=$(dirname $0) BUILD_PAT="_${TYPE}_[[:digit:]]*-[[:digit:]]*\.img\.gz$" for img in `find $PREBUILT_DIR -type f | grep "${BUILD_PAT}"` ; do - url="http://snapshots.linaro.org/precise/pre-built/${img#${PREBUILT_DIR}/}" + relpath="${img#${PREBUILT_DIR}/}" + url="http://snapshots.linaro.org/precise/pre-built/${relpath}" info_file=$(dirname $img)/$(basename $img .img.gz).html + image_name="echo $relpath | cut -d/ -f 1" + image_number="echo $relpath | cut -d/ -f 2" if `echo "$url" | grep /lt-panda/ >/dev/null` ; then DEVICE="panda" elif `echo "$url" | grep /lt-panda-x11-base/ >/dev/null` ; then @@ -55,7 +58,7 @@ for img in `find $PREBUILT_DIR -type f | grep "${BUILD_PAT}"` ; do if [ -n "$DEVICE" ] ; then echo "submitting $img to LAVA" - jid=`${SCRIPT_ROOT}/lava-submit.py -t ${TYPE} -j ${JOB_NAME}-${DEVICE} -u $url -d ${DEVICE}` + jid=`${SCRIPT_ROOT}/lava-submit.py -t ${TYPE} -j ${JOB_NAME}-${DEVICE} -u $url -d ${DEVICE} -n ${image_name} -c ${image_number}` if [ $? -eq 0 ] ; then echo "job id: ${jid}" sed -i -e "s/lavaJobId = 0;/lavaJobId=${jid};/" ${info_file} -- 1.7.9.5

12 years, 6 months

About the boot of omapzoom and aosp of panda build in LAVA

by YongQin Liu

Hi, all I met a problem that the omapzoom and aosp build of panda can't be booted up in lava. here is the bug link: https://bugs.launchpad.net/lava-dispatcher/+bug/1012546 When we passed the bootcmd and bootargs via u-boot, and run boot to boot the images deployed on partition3, the u-boot load kernel image and initrd file successfully, and displayed the line: "Uncompressing Linux... done, booting the kernel." but after this line, it seems that the board rebooted and boot the master image as default again, not boot up the android image. I guess it has relation with uboot in master image because I have tried to use the MLO and u-boot.bin and u-boot.img in omapzoom build to replace the files on boot partition of master image, then I can boot the omapzoom and aosp build successfully. (also can boot the tracking build) What I did was as following: 1. deploy omapzoom build to sdcard with linaro-android-media-create command 2. copy the MLO and u-boot.bin and u-boot.img 3 file from sdcard to someplace in local 3. use "./lava-create-master -r 2G panda" to create the sdcard used for master image we can get the lava-create-master script from lp:lava-master-image-scripts 4. plug in the sdcard and boot the board 5. wait the board to complete the partition job. after this, the uImage and uInitrd file in boot partition has been change, and then the master image can be booted with the uboot files from omapzoom build but I don't know why and what change has been done. 6. copy the MLO and u-boot.bin and u-boot.img 3 file to the boot partition of sdcard 7. plug the sdcard to the board and boot it, then it can be use to boot the tracking/omapzoom/aosp 3 builds of panda. The version original u-boot for master image is: U-Boot 2011.12 (Feb 16 2012 - 21:46:14) The u-boot version of omapzoom build is: U-Boot 2011.06 (Aug 20 2011 - 18:00:16). The u-boot version of tracking build is : U-Boot SPL 2012.04.01 (Jun 14 2012 - 08:05:54) The tracking build works fine with the original uboot of master image. So I guess there are some differences between the original uboot for master image and the uboot build in omapzoom build. Anyone know the details why it can not boot the omapzoom and aosp build on the 3rd partition, and if I can boot the omapzoom and aosp build of panda with the original u-boot of master image? Thanks, Yongqin Liu

12 years, 6 months

anon bundlestream cleanup

by Alexander Sack

Hi,, i did a run through anon bundlestreams and identified the following that we want to remove: All anon ci- bundlestreams: ======================= /anonymous/ci-asac-linux-linaro-3_0/ not set 36 4 /anonymous/ci-asac-linux-linaro-3_0-build/ not set 4 4 /anonymous/ci-asac-linux-linaro-3_1/ not set 28 4 /anonymous/ci-asac-linux-linaro-3_1-build/ not set 4 4 /anonymous/ci--build/ not set 18 2 /anonymous/ci-build/ not set 15 7 /anonymous/ci-build-build/ not set 4 4 /anonymous/ci-build-with-ext4-3_0/ not set 41 9 /anonymous/ci-build-with-ext4-3_0-build/ not set 12 12 /anonymous/ci-lci-build-changes/ not set 3 3 /anonymous/ci-lci-build-changes-build/ not set 6 6 /anonymous/ci-linux-igloo-kernel-snowball/ not set 1 1 /anonymous/ci-linux-Igloo-Kernel-Snowball/ not set 5 4 /anonymous/ci-linux-igloo-kernel-snowball-build/ not set 1 1 /anonymous/ci-linux-linaro-snowball-cma-test/ not set 3 3 /anonymous/ci-linux-linaro-snowball-cma-test-build/ not set 5 5 /anonymous/ci-linux-maintainers-build/ not set 10 2 /anonymous/ci-linux-maintainers-build-build/ not set 2 2 /anonymous/ci-linux-maintainers-kernel/ not set 5 5 /anonymous/ci-linux-maintainers-kernel-build/ not set 18 18 /anonymous/ci-packaged-linux-linaro-3_0/ not set 62 10 /anonymous/ci-packaged-linux-linaro-3_0-build/ not set 24 24 /anonymous/ci-packaged-linux-linaro-3_1/ not set 190 51 /anonymous/ci-packaged-linux-linaro-3_1-build/ not set 144 144 /anonymous/ci-packaged-linux-linaro-build/ not set 1 1 /anonymous/ci-packaged-linux-linaro-build-build/ not set 1 1 /anonymous/ci-packaged-linux-linaro-lt-3_1/ not set 10 5 /anonymous/ci-packaged-linux-linaro-lt-3_1-build/ not set 30 30 /anonymous/ci-Test-TI-working-tree/ not set 21 19 /anonymous/ci-Test-TI-working-tree-build/ not set 28 28 /anonymous/ci-TI-working-tree/ not set 28 15 /anonymous/ci-TI-working-tree-build/ not set 18 18 /anonymous/ci-triage-build/ not set 3 3 /anonymous/ci-upstream/ not set 119 48 All anon lava-android-: =================== /anonymous/lava-android-leb-panda/ not set 910 770 /anonymous/lava-android-panda/ not set 13 13 /anonymous/lava-android-test/ not set 7 7 More random picks: ================= /anonymous/anonymous/ not set 8 5 /anonymous/bootchart/ not set 8 4 /anonymous/chander-kashyap/ /anonymous/lava-daily/ /anonymous/linux-linaro-tracking/ /anonymous/miscellaneous/ /anonymous/panda01-ltp/ Restored from backup 45 44 /anonymous/panda01-posixtestsuite/ Restored from backup 1 1 /anonymous/panda01-stream/ Restored from backup 1 1 /anonymous/qemu-testing-dumping-ground/ not set 12 7 /anonymous/smem/ smem 2 1 /anonymous/USERNAME/ not set 87 69 If we can just hide them that's also fine I guess. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

12 years, 6 months

Monkey and long monkey trip over new test apks

by Zygmunt Krynicki

Hey everyone. It seems that monkey trips over new test apks that have been added as a side effect of building TARGET_BUILD_VARIANT=tests images. For example, see: https://pastebin.linaro.org/636/ We may need to blacklist some (all?) of them initially to get meanigful results. Best regards ZK -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/

12 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation July 2012