linaro-validation May 2013

linaro-validation@lists.linaro.org

18 participants
24 discussions

Re: [Linaro-validation] "android_install_binaries" failure after "deploy_linaro_android_image"

by Leo Wu

Hi Tyler: Thanks your information, it is useful. For current status, i can pass "android_install_binaries" but getting stuck in "boot_linaro_android_image". I think the problem is still relevant to panda-driver. This web have four files about pandaboard driver you posted( https://developers.google.com/android/nexus/drivers) 20111114 20111216 20120430 20120807 i dont know which one is suitable for my pandaboard so i have tried everyone. There have no one can pass "boot_linaro_android_image". The Log as following... LOG: 20111114: [ 521.131805] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 521.202728] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 521.552642] init: untracked pid 3766 exited [ 521.626464] init: untracked pid 3762 exited LEO COMMENT: PVR_K error. Does this driver not suitable for my pandaboard? 20111216 linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 37.700134] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 38.766967] init: untracked pid 1771 exited [ 41.124938] init: untracked pid 1774 exited LEO COMMENT: It looks like same as 20111114. 20120430: <LAVA_DISPATCHER>2013-03-27 02:30:45 PM DEBUG: expect (1800): '['Displayed com.android.launcher/com.android.launcher2.Launcher:']' logcat -s ActivityManager:I --------- beginning of /dev/log/main --------- beginning of /dev/log/system [ 96.093536] warning: `zygote' uses 32-bit capabilities (legacy support in use) I/ActivityManager( 1776): Memory class: 48 I/ActivityManager( 1776): Enabled StrictMode logging for AThread's Looper LEO COMMENT: No error message on this version. But it hang up and no more message print out. No console command line when i click "enter" key. 20120807: [ 53.677490] PVR_K:(Error): BridgedDispatchKM: Driver initialisation not completed yet. [4836, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 53.737884] PVR_K:(Error): BridgedDispatchKM: Driver initialisation not completed yet. [4836, /mnt/jenkins/workspace/linaro-android-member-ti_panda-linaro-13.02-release/build/kernel/drivers/gpu/pvr/bridged_pvr_bridge.c] [ 54.163696] init: untracked pid 1781 exited [ 55.792907] init: untracked pid 1784 exited LEO COMMENT: It looks like same as 20111114. One thing need to be mentiond, there have no "pvrsrvinit" but "pvrsrvctl" in version 20120807. Both files are same? LEO On 26 March 2013 20:57, Tyler Baker <tyler.baker(a)linaro.org> wrote: > Hi Leo Wu, > > The "android_install_binaries" dispatcher command will download, unpack, > and deploy proprietary shared objects to the Android file system. > > You can get these binaries from here: > https://developers.google.com/android/nexus/drivers - Choose the correct > binaries based on your Android build target. > > You will then have to create the following directory structure and tgz it: > > ./bin: > pvrsrvinit > > ./vendor: > lib > > ./vendor/lib: > egl hw libglslcompiler.so libIMGegl.so libpvr2d.so > libpvrANDROID_WSEGL.so libPVRScopeServices.so libsrv_init.so > libsrv_um.so libusc.so > > ./vendor/lib/egl: > libEGL_POWERVR_SGX540_120.so libGLESv1_CM_POWERVR_SGX540_120.so > libGLESv2_POWERVR_SGX540_120.so > > ./vendor/lib/hw: > gralloc.omap4.so > > At this point you have created your own panda-driver.tgz > > Now you will need to host it on a web server/file system that your LAVA > server can access. > > For instance, my LAVA server has the following defined: > > android_binary_drivers = http://192.168.1.2/panda-drivers.tgz <-- You > have to host this URL > > Hopefully this clears up any confusion you may have. Thanks. > > > > > > > On 26 March 2013 02:15, Leo Wu <leo.wu(a)linaro.org> wrote: > >> hi: >> Does anyone knows how to use "android_install_binaries" command in json >> file? Please give me some suggestion. >> I am trying to perfome lava android test on pandaboard. Currently, i face >> a problem while json file execute "android_install_binaries". >> The log shows it tries to connect to >> http://192.168.1.21/LAVA_HTTP/android-binaries/panda-drivers.tgz. >> >> log: http://192.168.1.21/LAVA_HTTP/android-binaries/panda-drivers.tgz Connecting >> to 192.168.1.21:80... failed:Connection timed out. >> RuntimeError: Extracting >> http://192.168.1.21/LAVA_HTTP/android-binaries/panda-drivers.tgz on >> target failed >> >> LAVA SERVER IP: 222.222.222.4 >> Board: pandaboard >> Master Image: Linaro PreBuild Image >> Test Image: LEB android >> >> >> 1. My LAVA SERVER ip is 222.222.222.4. i confused that why it tries to >> connect to 192.168.1.21? >> 2. what is panda-drivers.tgz? is it exist in lava server already or i >> need to download panda-drivers.tgz from somewhere by manual and stored it >> in local at first? >> 3. how to configure it? >> >> Thank you >> Leo >> >> _______________________________________________ >> linaro-validation mailing list >> linaro-validation(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-validation >> >> > > > -- > Tyler Baker > Technical Architect, Automation & CI > 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 >

10 years, 7 months

Re: [Linaro-validation] New publishing infra prototype report

by Paul Sokolovsky

On Wed, 29 May 2013 17:11:11 +0100 James Tunnicliffe <james.tunnicliffe(a)linaro.org> wrote: > Issues raised in > http://bazaar.launchpad.net/~linaro-automation/linaro-android-build-tools/t… > > Getting a token: > I see this as the service that starts the job has some secret allowing > it to request the token, which is then passed onto the job. Yes, just like that: we have fixed (and thus trusted) job scheduler, which can reliably authenticate itself to a token server, get a token and pass that token to a much less trusted builder. > This may > require a Jenkins plugin. Yes, that's one possibility, as line 94 of the doc you quote says. Another possibility is to have extra frontend on top of Jenkins, which would request a token and inject it into Jenkins job (as a paremeter during start). That's possible right away with android-build and would be possible with other Jenkins with original ci-frontend plan. > > Open Embedded Builds/rsync: > This is not required. OE has a list of package sources and versions > associated with each build so we should be able to write a simple > "upload packages if that version doesn't exist" script. This probably > requires us to host files in openembedded/sources/<package > name>/<version>/<package file>, but that is a simple enough change. James, for me, what you said translates into something "let's dig into adhoc peculiarities of one usecase, because it seems that it's easy to handle that, as if we don't know that it the end it still won't be that easy, but the result will not be reusable". Nope, let's shoot for general solution of problem of publishing arbitrary file sets. That's also "easy". The hardest part of that is to accept that we'll duplicate best-practice solution (rsync) and by duplicating it, we'll lose extra features like intra-file optimizations (because *that* we for sure don't want to duplicate). That's why I'd like who anyone has strong reasons for going with rsync is come up with them before we decide on architecture (keeping in mind that rsync comes with friends like ssh, LDAP, PAM, Kerberos, etc.) > > publish --token=<token> --type=<build_type> --strip=<strip> <build_id> > <glob_pattern>... > > This seems like a reasonable starting point. Lets make sure that it > uses a configuration file to specify what to do with those build types > etc. Preferably one that it can update from a public location so we > don't have to re-spin the tool to add a new build type (though I guess > we normally check it out of VCS as we go, so that works too). Well, on client side, it's ideally just a single file which just handle obvious filtering options (like <glob_pattern> or --strip=) locally and passes the rest to API/service. Server-side can handle the options in any way it wants, note that options above don't require much "configuration", for example --type= just maps to top-level download dir. Except for, well, we already have adhoc behavioral idiosyncrasies, like Android builds flattening happening on server. You hardly can "configure" that (though lambdas in YAML sounds cool (for debugging :-D)). Better approach would be to move that stuff to client side and have simple well-defined publishing semantics. > > James > > On 29 May 2013 16:57, James Tunnicliffe > <james.tunnicliffe(a)linaro.org> wrote: > > Hi Paul, > > > > Thanks for this. I need a mechanism for publishing from CI runtime > > jobs so this is important to me. I did look into using SSH/SFTP and > > it is simple to do in a reasonably insecure way, it would be much > > better to have an HTTP[S] based solution that uses temporary > > authentication tokens. > > > > I was looking at this today because I woke up early worrying about > > it. Clearly I need more interesting stuff to think about! (and now, > > more sleep). > > > > Anyway, it should be possible to do in Django: > > > > https://docs.djangoproject.com/en/dev/topics/http/file-uploads/ > > https://pypi.python.org/pypi/django-transfer/0.2-2 > > http://wiki.nginx.org/HttpUploadModule > > > > My own notes are more focused on an internal server that would > > upload files to releases/snapshots but could retain files until > > disk space was needed to act as a cache. I was going to look at > > extending linaro-licenese-protection for this so there was no way > > to use the cache to avoid licenses. I was also going to have > > completely private files that you could only access if you had the > > authentication token that a job was given. > > > > https://docs.google.com/a/linaro.org/document/d/1_ewb-xFDJc8Adk7AijV95XthGM… > > > > Feel free to add comments or insert more information and thoughts. > > > > Note that for high performance uploads we probably want to hand off > > the upload to a web server. That django-transfer module doesn't > > support any Apache related upload stuff, which may mean that it > > doesn't exist. Moving to an nginx based solution would be easy > > enough if we needed to (we could replace the mod-xsendfile with the > > equivalent nginx call). > > > > I think a prototype branch is ~1 day of engineering effort (no > > nginx, token based upload call in place, probably some kind of > > token request call, probably limited security, no > > proxy-publishing). Adding the rest of the features, testing etc > > probably takes it to more like 1 week. > > > > James > > > > > > On 29 May 2013 16:26, Paul Sokolovsky <paul.sokolovsky(a)linaro.org> > > wrote: > >> > >> > >> Begin forwarded message: > >> > >> Date: Wed, 29 May 2013 17:19:31 +0300 > >> From: Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> > >> To: Tyler Baker <tyler.baker(a)linaro.org>, Alan Bennett > >> <alan.bennett(a)linaro.org> Cc: Senthil Kumaran > >> <senthil.kumaran(a)linaro.org>, Fathi Boudra > >> <fathi.boudra(a)linaro.org> Subject: Re: New publishing infra > >> prototype report > >> > >> > >> Hello Tyler, > >> > >> As brought up today on IRC, it's a month since the below report and > >> proposal for further steps, and I don't remember any reply. This > >> whole publishing thing is peculiar, as it sits still when its not > >> needed, but it's actually in ambush there to cause havoc at any > >> time. > >> > >> For example, today Senthil came up with the question on how to > >> publish to snapshots. Fortunately, it turned out that it was > >> request for publishing a single file manually. But I know the guys > >> are working on Fedora builds, and that definitely will need > >> automated publishing (unless initial requirements as provided by > >> Fathi changed). And it's definitely needed for CBuild migration, > >> which I assume will be worked on next month. > >> > >> Btw, I discovered that a BP for that was submitted yet by Danilo: > >> https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/file-publ… > >> > >> > >> Thanks, > >> Paul > >> > >> > >> On Mon, 29 Apr 2013 18:58:39 +0300 > >> Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote: > >> > >>> Hello, > >>> > >>> Last month I worked on a blueprint > >>> https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/protot… > >>> to prototype an implementation of publishing framework which > >>> wouldn't depend on particular Jenkins features (and misfeatures) > >>> and could be reused for other services across Linaro CI > >>> infrastructure. Among these other projects are: > >>> > >>> 1. OpenEmbedded builds - efficient ("fresh only") publishing of > >>> source tarballs and cache files. > >>> 2. CBuild - publishing of toolchain build artifacts and logs. > >>> 3. Fedora/Lava - publishing of build artifacts and logs. > >>> > >>> So, the good news is that was possible to implement a publishing > >>> system whose interface is a single script which hides all the > >>> publishing complexity underneath. Implementation was a cumbersome, > >>> because existing publishing backend was reused, but it already > >>> opens possibility for better logging, debugging, profiling, etc. > >>> > >>> With proof-of-concept client-side available, the main complexity > >>> still lies in server-side backend. It's clear that current "SFTP > >>> + SSH trigger script" approach doesn't scale well in terms of > >>> ease of setup and security. I added my considerations to address > >>> that topic in " Conclusions and Future Work" section of > >>> http://bazaar.launchpad.net/~linaro-automation/linaro-android-build-tools/t… > >>> > >>> So, action items I suggest based on this report: > >>> > >>> 1. Tyler to consult with Fathi (Fedora), Marcin (OE) and me > >>> (CBuild) and prepare architecture/spec for the general publishing > >>> system. It would be nice to BP this task to start in 13.05. > >>> 2. Depending on the time required to prepare spec, implementation > >>> can be scheduled right away, or postponed until LCE13, so we had > >>> another chance to discuss it face to face (as adhoc meeting, or > >>> as a session, if it's really worth it). > >>> > >>> > >>> Thanks, > >>> Paul > >>> > >>> Linaro.org | Open source software for ARM SoCe > >>> Follow Linaro: http://www.facebook.com/pages/Linaro > >>> http://twitter.com/#!/linaroorg - > >>> http://www.linaro.org/linaro-blog > >> > >> > >> > >> -- > >> Best Regards, > >> Paul > >> > >> 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 > >> > >> > >> -- > >> Best Regards, > >> Paul > >> > >> 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 > > > > > > > > -- > > James Tunnicliffe > > > -- Best Regards, Paul 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

10 years, 10 months

validation.linaro.org Upgrade

by Dave Pigott

Hi All, This is just a reminder that we're doing the upgrade of the v.l.o production server starting on Sunday at 09:00 UTC. Boards will be off lined from this time. On Monday morning once all the boards have cleared their jobs, we will be performing backups and then doing the upgrade. If all goes well, then we will be back online late on Monday or worst case by 12:00 UTC on Tuesday. The server and scheduler will still be running until we do the upgrade, but I would recommend holding back submissions of jobs from Monday at 12:00 UTC until we give the all clear. Many thanks Dave LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

10 years, 10 months

Re: [Linaro-validation] New publishing infra prototype report

by Paul Sokolovsky

Hello James, On Wed, 29 May 2013 16:57:50 +0100 James Tunnicliffe <james.tunnicliffe(a)linaro.org> wrote: > Hi Paul, > > Thanks for this. I need a mechanism for publishing from CI runtime > jobs so this is important to me. I did look into using SSH/SFTP and it > is simple to do in a reasonably insecure way, it would be much better > to have an HTTP[S] based solution that uses temporary authentication > tokens. > > I was looking at this today because I woke up early worrying about it. > Clearly I need more interesting stuff to think about! (and now, more > sleep). Well, I guess each of us (individual engineers) was hit by publishing issues already, so that's clearly a thing to worry about and I share your concerns. So, thanks for joining the discussion (and let's nag Tyler for spec together ;-) ). > > Anyway, it should be possible to do in Django: > > https://docs.djangoproject.com/en/dev/topics/http/file-uploads/ > https://pypi.python.org/pypi/django-transfer/0.2-2 > http://wiki.nginx.org/HttpUploadModule > > My own notes are more focused on an internal server that would upload > files to releases/snapshots but could retain files until disk space > was needed to act as a cache. I was going to look at extending > linaro-licenese-protection for this so there was no way to use the > cache to avoid licenses. I was also going to have completely private > files that you could only access if you had the authentication token > that a job was given. > > https://docs.google.com/a/linaro.org/document/d/1_ewb-xFDJc8Adk7AijV95XthGM… > > Feel free to add comments or insert more information and thoughts. I'll look in more detail later. Just having a small window before restarting work on Crowd API auth ;-). > > Note that for high performance uploads we probably want to hand off > the upload to a web server. That django-transfer module doesn't > support any Apache related upload stuff, which may mean that it > doesn't exist. Moving to an nginx based solution would be easy enough > if we needed to (we could replace the mod-xsendfile with the > equivalent nginx call). Yeah, I had experience with all that stuff at SourceForge.net, where high availability and extra features (like progress indicator on web page) were a must. I'd think that we can start with simple Django-level PUT handler, but yes, we should be prepared that it'll have performance issues and for need to upgrade architecture. > I think a prototype branch is ~1 day of engineering effort (no nginx, > token based upload call in place, probably some kind of token request > call, probably limited security, no proxy-publishing). Adding the rest > of the features, testing etc probably takes it to more like 1 week. Well, I'd really like us (all) to first consider architecture well enough. I also lean towards having that as a web service, but I'd like someone who has other opinion to have their say too. > > James > > > On 29 May 2013 16:26, Paul Sokolovsky <paul.sokolovsky(a)linaro.org> > wrote: > > > > > > Begin forwarded message: > > > > Date: Wed, 29 May 2013 17:19:31 +0300 > > From: Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> > > To: Tyler Baker <tyler.baker(a)linaro.org>, Alan Bennett > > <alan.bennett(a)linaro.org> Cc: Senthil Kumaran > > <senthil.kumaran(a)linaro.org>, Fathi Boudra <fathi.boudra(a)linaro.org> > > Subject: Re: New publishing infra prototype report > > > > > > Hello Tyler, > > > > As brought up today on IRC, it's a month since the below report and > > proposal for further steps, and I don't remember any reply. This > > whole publishing thing is peculiar, as it sits still when its not > > needed, but it's actually in ambush there to cause havoc at any > > time. > > > > For example, today Senthil came up with the question on how to > > publish to snapshots. Fortunately, it turned out that it was > > request for publishing a single file manually. But I know the guys > > are working on Fedora builds, and that definitely will need > > automated publishing (unless initial requirements as provided by > > Fathi changed). And it's definitely needed for CBuild migration, > > which I assume will be worked on next month. > > > > Btw, I discovered that a BP for that was submitted yet by Danilo: > > https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/file-publ… > > > > > > Thanks, > > Paul > > > > > > On Mon, 29 Apr 2013 18:58:39 +0300 > > Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote: > > > >> Hello, > >> > >> Last month I worked on a blueprint > >> https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/protot… > >> to prototype an implementation of publishing framework which > >> wouldn't depend on particular Jenkins features (and misfeatures) > >> and could be reused for other services across Linaro CI > >> infrastructure. Among these other projects are: > >> > >> 1. OpenEmbedded builds - efficient ("fresh only") publishing of > >> source tarballs and cache files. > >> 2. CBuild - publishing of toolchain build artifacts and logs. > >> 3. Fedora/Lava - publishing of build artifacts and logs. > >> > >> So, the good news is that was possible to implement a publishing > >> system whose interface is a single script which hides all the > >> publishing complexity underneath. Implementation was a cumbersome, > >> because existing publishing backend was reused, but it already > >> opens possibility for better logging, debugging, profiling, etc. > >> > >> With proof-of-concept client-side available, the main complexity > >> still lies in server-side backend. It's clear that current "SFTP + > >> SSH trigger script" approach doesn't scale well in terms of ease > >> of setup and security. I added my considerations to address that > >> topic in " Conclusions and Future Work" section of > >> http://bazaar.launchpad.net/~linaro-automation/linaro-android-build-tools/t… > >> > >> So, action items I suggest based on this report: > >> > >> 1. Tyler to consult with Fathi (Fedora), Marcin (OE) and me > >> (CBuild) and prepare architecture/spec for the general publishing > >> system. It would be nice to BP this task to start in 13.05. > >> 2. Depending on the time required to prepare spec, implementation > >> can be scheduled right away, or postponed until LCE13, so we had > >> another chance to discuss it face to face (as adhoc meeting, or as > >> a session, if it's really worth it). > >> > >> > >> Thanks, > >> Paul > >> > >> Linaro.org | Open source software for ARM SoCe > >> Follow Linaro: http://www.facebook.com/pages/Linaro > >> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog > > > > > > > > -- > > Best Regards, > > Paul > > > > 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 > > > > > > -- > > Best Regards, > > Paul > > > > 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 > > > -- Best Regards, Paul 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

10 years, 10 months

Linux-next: vexpress failed to mount rootfs.

by Naresh Kamboju

Hi Team, while monitoring lava dashboard page: - > http://validation.linaro.org/lava-server/dashboard/image-reports/linux-next… And following job failed. - > http://validation.linaro.org/lava-server/scheduler/job/56073/log_file Today issue i can see from job 56073 is failed to mount rootfs. Kernel command line passed to boot from /dev/mmcblk0p5 and which is not mounting. but the device is available. Kernel command line: console=ttyAMA0,38400n8 root=/dev/mmcblk0p5 rootwait ro mem=1024M ip=dhcp clcd=xvga mmci.fmax=4000000 ... mmcblk0: p1 p2 p3 p4 < p5 p6 p7 > ... mount: mounting /dev/mmcblk0p5 on /root failed: No such device I am assuming that guest image should boot from mmcblk0p2. but the master image is booting from mmcblk0p2. which is a conflict. i am not sure about the way we are copying lava.img on to mmc or sda ? and the reason for kernel boot args defined to boot from mmcblk0p5 ? please look in to this issue. Best regards Naresh Kamboju

10 years, 10 months

Re: [Linaro-validation] Reminder: (Reminder) Update Headlines for ALL current sprint bluepr... @ Wed 2013-05-29 15:00 - 16:00 (paul.sokolovsky@linaro.org)

by Paul Sokolovsky

Hello Alan, On Wed, 29 May 2013 11:49:49 +0000 Google Calendar <calendar-notification(a)google.com> wrote: > This is a reminder for: > > Title: (Reminder) Update Headlines for ALL current sprint blueprints > ALL, the headlines for all Blueprints in process need to be reviewed > > Please consider that the headline > - could be sent out for external consumption without alteration > - should concisely summarize your efforts > > A list of the current blueprints (in the current sprint): > http://cards.linaro.org/issues/?filter=10806 It seems that this filter no longer exists, or is private, I and other folks are getting "The requested filter doesn't exist or is private." trying to follow that link. I also thought the plan was to start with BPs in Jira form next month. But seeing that cards even for older BPs were created, I proceeded to them, but so that my cards are all empty except the title, e.g. http://cards.linaro.org/browse/LAVA-136 . With Jira capabilities, I'd expect Headline/Acceptance to be fields of the cards, but I don't see those either. So, I'd appreciate more guidelines how to do that, like reference to known good BP card to do it by example. In the meantime, I updated BP status in LP. Thanks, Paul > > Please add any missing blueprints and let me know so they aren't > forgotten. When: Wed 2013-05-29 15:00 – 16:00 Riga > Video call: Join Google+ Hangout > <https://plus.google.com/hangouts/_/calendar/YWxhbi5iZW5uZXR0QGxpbmFyby5vcmc…> > Calendar: paul.sokolovsky(a)linaro.org > Who: > * Alan Bennett - organizer > * Fu Wei > * Tyler Baker > * James Tunnicliffe > * Dave Pigott > * Paul Sokolovsky > * Georgy Redkozubov > * Arthur She > * Stevan Radakovic > * Neil Williams > * Milo Casagrande > * Nicholas Schutt > * Senthil Kumaran S > * Antonio Terceiro > * Matt Hart > > Event details: > https://www.google.com/calendar/event?action=VIEW&eid=bDE4ZDNrZ2JwbWd1Nmtnc… > > Invitation from Google Calendar: https://www.google.com/calendar/ > > You are receiving this email at the account > paul.sokolovsky(a)linaro.org because you are subscribed for reminders > on calendar paul.sokolovsky(a)linaro.org. > > To stop receiving these notifications, please log in to > https://www.google.com/calendar/ and change your notification > settings for this calendar. -- Best Regards, Paul 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

10 years, 10 months

Deploy to production?

by Dave Pigott

Hi - I just landed a change https://code.launchpad.net/~dpigott/lava-dispatcher/fix-uefi-sendline/+merg… and would like to roll out to production, since it's keeping the arndale-uefi offline. Any objections? I'll roll it out this time tomorrow or thereabouts unless someone objects. Thanks Dave

10 years, 10 months

need help

by Novello Giampiero

lava-dispatch test.json --target panda01 made in this way: { "job_name": "foo", "target": "panda01", "timeout": 18000, "actions": [ { "command": "lava_test_shell", "parameters": { "timeout": 1800, "testdef_urls": ["file:///home/novello/ae/test/lava/test-definitions/openembedded/etherner.yaml"] } } ] } Then I see thei ERROR Target includes no deployment_data:::: What does it means . Best regards The ethernet.yaml file is made in this way: metadata: name: ethernet format: "Lava-Test-Shell Test Definition 1.0" description: "Test network in OE." install: git-repos: - git://git.linaro.org/qa/test-definitions.git run: steps: - "cd test-definitions/openembedded/scripts" - "./ethernet.sh" parse: pattern: "^(?P<test_case_id>[a-zA-Z0-9_-]+):\\s(?P<result>\\w+)" fixupdict: PASS: pass FAIL: fail The path is correct because from explorrer I can open it. emb)root@hp:/home/novello/ae/test/lava/lava-dispatcher/doc# ~ bash: /root: È una directory (emb)root@hp:/home/novello/ae/test/lava/lava-dispatcher/doc# lava-dispatch test1.json --target panda01 <LAVA_DISPATCHER>2013-05-28 10:53:44 AM INFO: Attempting to connect to device Connected. <LAVA_DISPATCHER>2013-05-28 10:53:44 AM INFO: Matched 'Connected\\.\r' which means all-good <LAVA_DISPATCHER>2013-05-28 10:53:44 AM INFO: [ACTION-B] lava_test_shell is started with {u'testdef_urls': [u'file:///home/novello/ae/test/lava/test-definitions/openembedded/etherner.yaml'], u'timeout': 1800} <LAVA_DISPATCHER>2013-05-28 10:53:44 AM WARNING: [ACTION-E] lava_test_shell is finished with error (Target includes no deployment_data). Lava failed at action lava_test_shell with error:Target includes no deployment_data Traceback (most recent call last): File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/563-tyler.baker(a)linaro.org-20130219062639-8ooe0nuv759tv1ls/lava_dispatcher/job.py", line 177, in run action.run(**params) File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/563-tyler.baker@linaro.org-20130219062639-8ooe0nuv759tv1ls/lava_dispatcher/actions/lava_test_shell.py", line 486, in run self._assert_target(target) File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/563-tyler.baker@linaro.org-20130219062639-8ooe0nuv759tv1ls/lava_dispatcher/actions/lava_test_shell.py", line 626, in _assert_target raise RuntimeError('Target includes no deployment_data') RuntimeError: Target includes no deployment_data Then I seee this error: Traceback (most recent call last): File "/srv/lava/instances/emb/code/r115/bin/lava", line 61, in <module> lava.tool.main.LavaDispatcher.run() File "/srv/lava/.cache/eggs/lava_tool-0.6-py2.7.egg/lava/tool/dispatcher.py", line 147, in run raise SystemExit(cls().dispatch(args)) File "/srv/lava/.cache/eggs/lava_tool-0.6-py2.7.egg/lava/tool/dispatcher.py", line 137, in dispatch return command.invoke() File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/563-tyler.baker(a)linaro.org-20130219062639-8ooe0nuv759tv1ls/lava/dispatcher/commands.py", line 129, in invoke job.run() File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/563-tyler.baker(a)linaro.org-20130219062639-8ooe0nuv759tv1ls/lava_dispatcher/job.py", line 177, in run action.run(**params) File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/563-tyler.baker@linaro.org-20130219062639-8ooe0nuv759tv1ls/lava_dispatcher/actions/lava_test_shell.py", line 486, in run self._assert_target(target) File "/srv/lava/.cache/branch-cache/lava-dispatcher/checkouts/563-tyler.baker@linaro.org-20130219062639-8ooe0nuv759tv1ls/lava_dispatcher/actions/lava_test_shell.py", line 626, in _assert_target raise RuntimeError('Target includes no deployment_data') RuntimeError: Target includes no deployment_data BEST REGARDS NOVELLO G.

10 years, 11 months

Android upstream mirroring system is now fully automatic

by Paul Sokolovsky

Hello, I would start with saying that we with Milo and Ben today fixed admin access issue with Gerrit, https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1185061 . It's unclear why it happened, and there're existing 3rd-party reports of it, so I suggest all Gerrit admin to look at bug to be aware of symptoms and report them ASAP if they reoccur. Otherwise, upgrading to Gerrit 2.5 finally allowed us to automatically mirror new AOSP projects as they appear, without compromising security. I also improved detection method of new projects - previously we used manifest from master branch as the source, but as not all projects listed there, we missed some. I switched to using list of projects as provided by gitweb at https://android.googlesource.com/ , and that picked up bunch of new projects. So, from now on, we should have truly complete AOSP mirror all the time. To remind we sync existing projects twice a day and pick up new once a day. Follow up if you think that needs adjustment. Gerrit/mirror also proved to be quite stable during previous exploitation, and now should be fairly feature-complete, and as ITS folks are proactive with supporting services after migration, so I guess this signifies point where LAVA team can hand over Gerrit/mirror to them for ongoing maintenance. Philip, Ben, let me know is that's ok with you. That means that any users of Gerrit and Android upstream mirror are welcome to report any issues directly to its(a)linaro.org (cc: infrastructure(a)linaro.org , so we know how well it goes). The rest on Android infra issue should still go to https://bugs.launchpad.net/linaro-android-infrastructure/ (well, if you want LAVA team to react to it first). Philip, Ben, all notes Gerrit/mirror are reachable from https://wiki.linaro.org/Platform/Android/Gerrit . That's not intended to duplicate official docs, but should provide fairly complete reference of typical usecases and issues we faced. Caveat: it may be not always up to date. Feel free to "officially" request improvements to docs via https://bugs.launchpad.net/linaro-android-infrastructure/ (besides just consulting via irc/email of course). I'm excited about these changes - it's first time in 2-month marathon I really feel that migration brings stabilization and improvements to our process and infrastructure. I'm sure that over coming months more improvements will be made and that feeling will be shared by all teams in Linaro. Thanks, Paul mailto:pmiscml@gmail.com -- Best Regards, Paul 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

10 years, 11 months

lava-tool CI job - how to get dependencies installed

by Antonio Terceiro

Hello guys, Can someone please review the job I created for running the lava-tool unit tests? https://ci.linaro.org/jenkins/job/lava-tool/ The CI build script is very simple: virtualenv ci-build-venv ci-build-venv/bin/python ./setup.py test My first try did not go well, since virtualenv is not installed: https://ci.linaro.org/jenkins/job/lava-tool/1/console What's the appropriate way to make sure virtualenv is installed? I presume I cannot add `apt-get install -q -y python-virtualenv` in the top of the build script ... -- Antonio Terceiro Software Engineer - Linaro http://www.linaro.org

10 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation May 2013