Re: raring ringtail test rebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 02.01.2013 16:58, Matthias Klose pisze: A test rebuild of raring ringtail started in 2012 for the amd64, i386 and armhf architectures is now finished for all components on armhf. The amd64 and i386 rebuilds will hopefully finish in a few days. I think this is the first time that I recall, where arm finished before any intel-like parts :-) Was the rebuild for arm smaller or just started earlier? Thanks ZK -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5GClAAoJEOvx/vtfL8ZX2ooQAJ4GDkDh2hKz5Jn9quEHcfQq pdVt6SlPLptZVPLKToTpymKFpzrxim6WLa8CikZBP7ckO6GvCMKLHTCK2qtmA7WM iAR9fEiXvFL8/V0gCyJcy6mReZ5OzdXgI/wxjFbDTrWVju4ygEe7B9ZTXAx2mIuM glzq4yk39xYG33jtygaFEs63WF/huOqRKGWma+pSS/i2cgj/WvoV9nz6serRx/Vw gEFIf3rMPoS880cwJK2+H0fcxlxLHYLwDZ7Zwk877uGScQp9+mUl7FcT5jbJPHYj xmcEcm5pZ8voXbRx1eTN3hbc5+an3cs209Lx8Z4SDf/9uqP3Sht17R1J7/l9lhJ6 /+nMu02vIXNivxlQIdnp6DNaGxvvYe51axLi5DnTKNpwso1r0enSwNHRNZp3MPw6 gWgCVvdLbP2i7EnCTORf0etkYdT3zDDS7EWpeWTqMoLhvXFf77ozyBGVWhPFinqd FtHATi1FeyyqKQf0vYXV9ROZoCfPWHP4G51q/q+uPDVwqBtBMWKuqy28Uy5SMLih WKg/+3wzi2Zi3wycPWEp1MF17GPn8xfeglNFscbMTRvFho8NOZzD2gaAVqGiH1HZ Dtcd3bYWTayuYsBlZpkFg3Q3JQe2IVX5n3nmuIPy5vPsMC/fv3Y0xjwumkkkge9V nNQcZIkqtMQryZ+PLmlZ =cEiU -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 2012-09-12 Android Platform Team Meeting Agenda Posted
W dniu 11.09.2012 23:56, Zach Pfeffer pisze: Take a look at: https://wiki.linaro.org/Platform/Android/Meetings/2012-09-12 Feel free to add to the agenda and join us in #linaro-meeting on irc.freenode.net at 13:00 UTC on 2012/9/12. Yay, google tester is in the agenda, thanks zach! ZK -- Zygmunt Krynicki s/Linaro Validation Team/Canonical Certification Team/ s/Validation/Android/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Utter lunacy of Linaro license protection Re: Deploying new code to snapshots.linaro.org
W dniu 29.08.2012 09:58, Danilo Šegan pisze: У пон, 27. 08 2012. у 19:21 +0200, Zygmunt Krynicki пише: If we offer both the protected, click through, EULA, downloads and the tools to download them without seeing any license then I cannot see how this is any more legally fine than just ignoring the whole damn mess. The scripts have an explicit yes, I agree to the license step in them. We are making it even more explicit very soon now (that's why it's in tests until we make it even stronger and have it display the license unconditionally and prompt the user before the download begins). Those scripts will not solve the problem that people have. The problem will remain, that there is an interactive step in an otherwise batch processing. I cannot expect linaro's automation pipeline to fall apart because of this requirement so I can only predict that such improved scripts will continue to exist. For whitelisting, our general approach is to simply have a hard-coded list of IPs internal to Linaro that can access downloads without any license restrictions, and if a Linaro box has a static IP, we'd gladly add any of them to the whitelist. White-listing is not a good solution. In lava we had two code paths, one that would use white-listing and another that would attempt to 'accept' the license. In practice the second code path is better as it makes the program more robust (as it behaves the same whatever IP you have) and easier as there is less code to maintain. None of the user facing code we provide can download anything without the explicit license acceptance. FWIW, that's why linaro-fetch-image cannot download protected images still: we haven't provided the license acceptance functionality. This is not true. In lava, we have at least two such copies of code. One that downloads any image without prompt and another that combines images and auto-accepts the interactive license. This was essential for automation. I cannot determine if there are any other similar pieces of code available but I cannot imagine only we had that problem. I still believe that there is a need for a good general purpose _technical_ solution that would scale beyond linaro and would allow batch processing without jumping through burning hoops. Best regards ZK -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Utter lunacy of Linaro license protection Re: Deploying new code to snapshots.linaro.org
W dniu 27.08.2012 18:01, Danilo Šegan pisze: Hi John, У нед, 26. 08 2012. у 17:15 -0600, John Rigby пише: Probably related or same issue. On the old site I was able to download hwpacks with for example: wget -q -k --no-cookies --header 'Cookie: redirectlicensephp=200' http://oldsnapshots.linaro.org/precise/hwpacks/lt-snowball/latest/hwpack_linaro-lt-snowball_20120815-254_armhf_supported.tar.gz This no longer works and I get the license acceptance page instead. We have provided a script which can download stuff for you in lp:linaro-license-protection (license_protected_file_downloader inside tests/ directory - should be moved to scripts/ though). This has been present for a while now, and has been a recommended way to download binaries from snapshots.l.o. (Or, if you are doing this from a static IP, we've got support for allowing that through if it's an automated service [we do that for eg. validation.linaro.org].) We will look into providing a nicer API, but until we do, any interface we've got is going to be unstable and internal. IMHO this is utter lunacy, is there any oversight on how we do this? If we offer both the protected, click through, EULA, downloads and the tools to download them without seeing any license then I cannot see how this is any more legally fine than just ignoring the whole damn mess. The stuff we are doing here feels like DRM but it is even more insane as we are the senders and recipients and we _still_ cannot get it right! Maybe it's time to write an RFC on the eula compliance bit, get a new HTTP header defined, offer a patch for wget and couple of other tools and not reinvent the download tools over and over. Frustrated ZK PS: In Linaro we _wrote_ code that generates, displays, enforces, avoids and side-steps licenses. We have scripts that send magic cookies. We have tools that click or type I ACCEPT. I wonder how much time was wasted on this, instead of, say, writing better kernel code, or LAVA, or whatever... -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Fwd: Re: Linux 2.6.35.3 Kernel for ARM and SATA problems
Forwarding a post from debian-arm. I think I may be affected by this bug. Could anyone help me check if this still applies to 3.1.1-1400-linaro-lt-mx5. Best regards ZK -- Wiadomość oryginalna -- Temat: Re: Linux 2.6.35.3 Kernel for ARM and SATA problems Odesłano-Data: Tue, 20 Mar 2012 01:25:53 + (UTC) Odesłano-Od:debian-...@lists.debian.org Data: Mon, 19 Mar 2012 18:25:03 -0700 Nadawca:Mike Thompson mpthomp...@gmail.com Adresat:Phil Endecott spam_from_debian_...@chezphil.org Kopia: debian-...@lists.debian.org On Sun, Mar 18, 2012 at 1:38 PM, Phil Endecott spam_from_debian_...@chezphil.org mailto:spam_from_debian_...@chezphil.org wrote: It works for me. I seem to recall a small amount of agro getting the kernel config right, but u-boot was always able to recognise the device. I suggest that you find (borrow) another SATA device to test with. Good luck! I was able to borrow another SATA drive and that works, thank heaven. I thought I was going crazy for a while -- don't ask how many times I re-compiled the kernel. I did trace the problems I having to the ahci code in the kernel not properly handling an ahci CONINIT event generated by my WD5000BEVT drive. Seems this drive has extra SATA features implemented so that it can be used in hot-plug arrays and these features aren't recognized by the kernel driver so it just seems to shut down the drive and ignore it. The other SATA drive that I do have working with the kernel doesn't implement the extra features so the kernel is happy. Presumably these problems were fixed in later kernels and the patches didn't make it into Freescales 2.6.35.3 branch. On the other hand, the kernel might be fine and the firmware in the drive isn't conforming to the ahci specs, but I think that wold cause problems with the drive on other systems. I'm going to keep looking into this as I do want to get my 500GB SATA drive working with the iMX53 Quick Start. Mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Help: Is my Beagle C4 dead?
Hi Today morning I've noticed that my beagle C4 is not working well. This is the output a seen on serial: (Also here: https://pastebin.linaro.org/424/) 40W U-Boot SPL 2011.12 (Feb 16 2012 - 21:43:13) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 mmc_send_cmd: timedout waiting for cmddis! ** Can't read from device 0 ** spl: fat register err - -1 ### ERROR ### Please RESET the board ### The SD card is connected via uSD - SD adapter and works fine in other boards. I've tried re-attaching everything a dozen times. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Help: Is my Beagle C4 dead?
W dniu 09.03.2012 13:41, Zygmunt Krynicki pisze: Hi Today morning I've noticed that my beagle C4 is not working well. Update: it seems that SD card is working somewhat as without it U-Boot does not load and none of the output is there. I'll try re-flashing that card (brand new, used _once_) and check again. This is the output a seen on serial: (Also here: https://pastebin.linaro.org/424/) 40W U-Boot SPL 2011.12 (Feb 16 2012 - 21:43:13) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 mmc_send_cmd: timedout waiting for cmddis! ** Can't read from device 0 ** spl: fat register err - -1 ### ERROR ### Please RESET the board ### The SD card is connected via uSD - SD adapter and works fine in other boards. I've tried re-attaching everything a dozen times. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Zygmunt Krynicki Linaro Validation Team ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: hi
Hi. You are welcome to join the Linaro LAVA team. We are working on tools for automating tests (we are _not_ writing or running manual tests :-). If you know python I can find a lot of good places where you can immediately contribute. We are also looking for web developers, designers, documentation writers, code reviewers. If you would like to talk feel free to ping me (zyga) on #linaro (on freenode) or ask here. Thanks for your interest! Zygmunt On Sat, Feb 25, 2012 at 12:45 PM, Mayank Agarwal mayank77fromin...@gmail.com wrote: Hi, I want to contribute to any of the projects of linaro.Please guide me how can i contribute. Thanks and Regards, Mayank ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
12.02 efika smart book (MX?) images are totally borked
Hi. I'd like to let everyone know that our 12.02 images for Efika are bogus: http://releases.linaro.org/12.02/ubuntu/oneiric-images/ubuntu-desktop/ The desktop image is 3MB big. The reason for this is that linaro media create crashes while trying to build it: (this is on 12.02 LMC release) $ linaro-media-create --image-file efika.img --dev efikasb --rootfs ext2 --hwpack .cache/linaro/image-tools/fetch_image/releases.linaro.org/12.02/ubuntu/oneiric-hwpacks/hwpack_linaro-efikamx_20120221-1_armel_supported.tar.gz --hwpack-force-yes --image-size 4G --binary .cache/linaro/image-tools/fetch_image/releases.linaro.org/12.02/ubuntu/oneiric-images/nano/linaro-o-nano-tar-20120221-0.tar.gz --align-boot-part [sudo] password for zyga: Installing (linaro-hwpack-install) hwpack_linaro-efikamx_20120221-1_armel_supported.tar.gz in target rootfs. Unpacking hardware pack ...Done Updating apt package lists ... Ign file: ./ InRelease Ign file: ./ Release.gpg Ign file: ./ Release Ign file: ./ Translation-en Ign http://ports.ubuntu.com oneiric InRelease Ign http://ports.ubuntu.com oneiric-security InRelease Ign http://ppa.launchpad.net oneiric InRelease Ign http://ports.ubuntu.com oneiric-updates InRelease Get:1 http://ppa.launchpad.net oneiric Release.gpg [316 B] Ign http://ports.ubuntu.com oneiric-security InRelease Ign http://ports.ubuntu.com oneiric InRelease Get:2 http://ppa.launchpad.net oneiric Release [9759 B] Ign http://ports.ubuntu.com oneiric-updates InRelease Get:3 http://ports.ubuntu.com oneiric Release.gpg [198 B] Get:4 http://ports.ubuntu.com oneiric-security Release.gpg [198 B] Get:5 http://ppa.launchpad.net oneiric/main armel Packages [202 kB] Get:6 http://ports.ubuntu.com oneiric-updates Release.gpg [198 B] Get:7 http://ports.ubuntu.com oneiric-security Release.gpg [198 B] Ign http://ppa.launchpad.net oneiric/main TranslationIndex Get:8 http://ports.ubuntu.com oneiric Release.gpg [198 B] Get:9 http://ports.ubuntu.com oneiric-updates Release.gpg [198 B] Ign http://ppa.launchpad.net oneiric/main Translation-en Get:10 http://ports.ubuntu.com oneiric Release [40.8 kB] Get:11 http://ports.ubuntu.com oneiric-security Release [40.8 kB] Get:12 http://ports.ubuntu.com oneiric-updates Release [40.8 kB] Get:13 http://ports.ubuntu.com oneiric-security Release [40.8 kB] Get:14 http://ports.ubuntu.com oneiric Release [40.8 kB] Get:15 http://ports.ubuntu.com oneiric-updates Release [40.8 kB] Get:16 http://ports.ubuntu.com oneiric/main Sources [1095 kB] Get:17 http://ports.ubuntu.com oneiric/universe Sources [5792 kB] Get:18 http://ports.ubuntu.com oneiric/main armel Packages [1562 kB] Get:19 http://ports.ubuntu.com oneiric/universe armel Packages [5611 kB] Hit http://ports.ubuntu.com oneiric/main TranslationIndex Hit http://ports.ubuntu.com oneiric/universe TranslationIndex Get:20 http://ports.ubuntu.com oneiric-security/main Sources [34.9 kB] Get:21 http://ports.ubuntu.com oneiric-security/universe Sources [12.1 kB] Get:22 http://ports.ubuntu.com oneiric-security/main armel Packages [96.3 kB] Get:23 http://ports.ubuntu.com oneiric-security/universe armel Packages [31.7 kB] Get:24 http://ports.ubuntu.com oneiric-security/main TranslationIndex [73 B] Get:25 http://ports.ubuntu.com oneiric-security/universe TranslationIndex [73 B] Get:26 http://ports.ubuntu.com oneiric-updates/main Sources [157 kB] Get:27 http://ports.ubuntu.com oneiric-updates/universe Sources [51.9 kB] Get:28 http://ports.ubuntu.com oneiric-updates/main armel Packages [369 kB] Get:29 http://ports.ubuntu.com oneiric-updates/universe armel Packages [122 kB] Get:30 http://ports.ubuntu.com oneiric-updates/main TranslationIndex [74 B] Get:31 http://ports.ubuntu.com oneiric-updates/universe TranslationIndex [73 B] Get:32 http://ports.ubuntu.com oneiric-security/main armel Packages [96.3 kB] Get:33 http://ports.ubuntu.com oneiric-security/universe armel Packages [31.7 kB] Get:34 http://ports.ubuntu.com oneiric-security/main TranslationIndex [73 B] Get:35 http://ports.ubuntu.com oneiric-security/universe TranslationIndex [73 B] Get:36 http://ports.ubuntu.com oneiric/main armel Packages [1562 kB] Get:37 http://ports.ubuntu.com oneiric/universe armel Packages [5611 kB] Get:38 http://ports.ubuntu.com oneiric/multiverse armel Packages [134 kB] Get:39 http://ports.ubuntu.com oneiric/main TranslationIndex [3289 B] Get:40 http://ports.ubuntu.com oneiric/multiverse TranslationIndex [2265 B] Get:41 http://ports.ubuntu.com oneiric/universe TranslationIndex [2640 B] Get:42 http://ports.ubuntu.com oneiric-updates/main armel Packages [369 kB] Get:43 http://ports.ubuntu.com oneiric-updates/universe armel Packages [122 kB] Get:44 http://ports.ubuntu.com oneiric-updates/main TranslationIndex [74 B] Get:45 http://ports.ubuntu.com oneiric-updates/universe TranslationIndex [73 B] Hit http://ports.ubuntu.com oneiric/main Translation-en Hit http://ports.ubuntu.com oneiric/universe Translation-en Get:46
Re: Minimum timing resolution in Ubuntu/Linaro on the PandaBoard ES
On 02/07/2012 11:43 PM, Andrew Richardson wrote: Greetings, I'm experiencing what appears to be a minimum clock resolution issue in using clock_gettime() on a PandaBoard ES running ubuntu. * uname -r* 3.1.1-8-linaro-lt-omap * cat /proc/version* Linux version 3.1.1-8-linaro-lt-omap (buildd@diphda) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #8~lt~ci~20120118001257+025756-Ubuntu SMP PREEMPT Thu Jan 19 09: I'm using clock_gettime() (and have tried gettimeofday()) to compute the Which clock_t were you using? I think CLOCK_MONOTONIC makes sense for what you are trying to do and perhaps it has different resolution/accuracy. elapsed time around roughly 15ms of computation (image processing). While the computed time is stable on my x86_64 machine, it is not on my PandaBoard ES. I have tried various clocks (e.g. CLOCK_REALTIME), but the issue remains. No error codes are returned by clock_gettime(). The result on my x86_64 machine looks like this: *elapsed (s) elapsed (ns) elapsed (us) time (after) time (before)* 0s 532260ns *532us* (t1: 73741s 92573265ns) (t0: 73741s 92041005ns) 0s 544413ns *544us* (t1: 73741s 109390136ns) (t0: 73741s 108845723ns) 0s 529328ns *529us* (t1: 73741s 126024860ns) (t0: 73741s 125495532ns) A: 1.7s in total. *0.536ms* on average. If I move over to my PandaBoard ES, I calculate elapsed times of 0us on some iterations. *elapsed (s) elapsed (ns) elapsed (us) time (after) time (before)* 0s 0ns *0us* (t1: 269529s 192626951ns) (t0: 269529s 192626951ns) 0s 0ns *0us* (t1: 269529s 215606688ns) (t0: 269529s 215606688ns) 0s 2655030ns *2655us* (t1: 269529s 252349852ns) (t0: 269529s 249694822ns) 0s 2593994ns *2593us* (t1: 269529s 286163328ns) (t0: 269529s 283569334ns) 0s 30518ns *30us* (t1: 269529s 317657469ns) (t0: 269529s 317626951ns) If I crank up the amount of work done between the time calls (timetest.c:18: inneriters = 1e7;) such that the timed loop takes around 72ms, the timing results seem accurate and none of the intermediate calculations result in a 0us elapsed time. If I reduce it to around 10-25ms (inneriters=1e6), I get occasional 0us elapsed times. Around 2ms (inneriters=1e5), most results measure an elapsed time of 0us. I'm trying to optimize image processing functions, which take on the order of 2-15ms to process. Am I stuck with this timing resolution? I want to be careful to not omit issues like cache performance when timing, as I might if I repeatedly process an image to average the results. Currently, that seems like the best option. Source code and makefile attached, as well as /proc/timer_list Is this a property of the hardware, or might it be a bug? Thanks, Andrew ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Zygmunt Krynicki Linaro Validation Team ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
How to participate in the connect remotely
Hi. I'm curious how/if remote participation is going to work during this connect. Unlike past events we will not have the advantage of the Canonical IS teams that made everything just work. This probably includes the microphones in each room, the IRC channels, the projectors and the magic wifi. Is there any general way to participate remotely during this event or should I just bug my friends to place a laptop on a chair and run google hangouts? Thanks ZK -- Zygmunt Krynicki Linaro Validation Team ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to participate in the connect remotely
Please disregard this question. I've found an earlier message from Stephen. Thanks ZK On Mon, Feb 6, 2012 at 2:54 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Hi. I'm curious how/if remote participation is going to work during this connect. Unlike past events we will not have the advantage of the Canonical IS teams that made everything just work. This probably includes the microphones in each room, the IRC channels, the projectors and the magic wifi. Is there any general way to participate remotely during this event or should I just bug my friends to place a laptop on a chair and run google hangouts? Thanks ZK -- Zygmunt Krynicki Linaro Validation Team ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Linaro kernel tree for A15 for daily builds
On Fri, Jan 27, 2012 at 12:47 PM, Alexander Sack a...@linaro.org wrote: On Wed, Jan 25, 2012 at 9:33 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? We can do builds on ci.linaro.org - as soon as we have a branch/tag of a public git tree and a defconfig we would be ready to go. Might require a few minor tweaks if the LAVA job for A15 needs different input parameters, so if that's the case let Deepti and Danilo know about the details. It definitely will. There will be a different job specification for simulation targets. I'll send an update when this part becomes ready ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On Thu, Jan 26, 2012 at 5:26 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: Adding Amit. Looks like getting a big cloud instance running may help. Is the simulator I/O or compute bound? Compute bound. It also requires a license from arm for each machine that runs it (it binds to mac address) and a lot of memory (6GB is a good start). On 26 January 2012 03:22, Dave Pigott dave.pig...@linaro.org wrote: On 25 Jan 2012, at 20:53, Zygmunt Krynicki wrote: It takes a _long_ while to get to raw serial console login prompt of a stripped-down ubuntu nano image. On my core i7 (first gen) the simulator can sometimes reach around 1M instructions per second but is usually slower. On top of that I don't know if it has any kind of support for graphics. Depends what you mean, but I've run stuff with graphical output on a FastModel before, most notably the Mandelbrot generator. Dave -- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On Thu, Jan 26, 2012 at 7:24 PM, Dave Martin dave.mar...@linaro.org wrote: On Wed, Jan 25, 2012 at 09:33:35PM +0100, Zygmunt Krynicki wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider The basic A15 CPU support is upstream, but no board support. The board support emulation on the model is for obscure reasons not exactly the same as a real VExpress, but it's pretty close. With Pawel Moll's VExpress device tree support patches on top of mainline, we can produce a single kernel config and a set of device trees which allow booting on all the A15-based model variants. I'll be pushing a tree onto git.linaro.org soon with that stuff. Would you mind telling me which git tree to watch and which config to build? I'll be building it locally for testing before we get the CI loop into place. Thanks ZK The ARM landing team guys should be able to advice on the amount of effort required to merge android with such a kernel. I don't currently know anything in that area. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Linaro kernel tree for A15 for daily builds
On Thu, Jan 26, 2012 at 8:52 PM, Ryan Harkin ryan.har...@linaro.org wrote: On 26 January 2012 19:34, Scott Bambrough scott.bambro...@linaro.org wrote: On 12-01-26 01:24 PM, Dave Martin wrote: On Wed, Jan 25, 2012 at 09:33:35PM +0100, Zygmunt Krynicki wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider The basic A15 CPU support is upstream, but no board support. The board support emulation on the model is for obscure reasons not exactly the same as a real VExpress, but it's pretty close. With Pawel Moll's VExpress device tree support patches on top of mainline, we can produce a single kernel config and a set of device trees which allow booting on all the A15-based model variants. About device trees, does the simulator need an explicitly provided device tree (in a way we currently provide the kernel image and ramdisk) or is the dt table built into the image? I'll be pushing a tree onto git.linaro.org soon with that stuff. Why don't you push the changes to the ARM LT and let them manage pushing the tree out. Then we can maintain it and take the burden off of you. I suspect you will be rather busy. Indeed, my tree is already hosting your (dmart's) AMBA Device Discovery fixes and Pawel's Device Tree additions, so placing your A15 model stuff on top is not a problem for me. Here's our current working tree: http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=summary This is already booting real A15 Versatile Express hardware, so we're part the way there already. R. ___ linaro-validation mailing list linaro-validat...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro kernel tree for A15 for daily builds
HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider Thanks Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
Hi Zach It takes a _long_ while to get to raw serial console login prompt of a stripped-down ubuntu nano image. On my core i7 (first gen) the simulator can sometimes reach around 1M instructions per second but is usually slower. On top of that I don't know if it has any kind of support for graphics. With those limitations are there any tests that you may want to run? We can run this for a week if you need to but let's try to keep it useful. ZK On Wed, Jan 25, 2012 at 9:43 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: On 25 January 2012 14:33, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider We'll want to run Android. Thanks Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Sources for 11.11 kernel release
This is a recap of the discussion we did about source meta data for
packages. While interesting it was fruitless, nothing has happened.
I'd like to propose to put lava-friendly meta data in:
/usr/share/lava/{srcpackagename}/source.json
The file should look like this (for bzr-based projects)
{
branch_revision: 93556,
branch_url: lp:gcc-linaro/4.4,
branch_vcs: bzr,
commit_timestamp: 2010-09-07T14:49:43Z,
project_name: linaro-gcc
}
And like this for git-based projects
{
branch_revision: 69f19fbedf6b88eb314b22f1263e2624d4477ac8,
branch_url:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git,
branch_vcs: git,
commit_timestamp: 2011-11-23T14:15:50Z,
project_name: linux
}
If needed we can add support for svn (although I'd prefer to work with
a bzr-svn import on launchpad in that case).
The field commit_timestamp can be removed. It is optional and can be
resolved automatically assuming the repository is still alive. Still
it is highly recommended to include this information directly.
The field project_name should refer to a launchpad project (when using
bzr branches) or to a consistently-named upstream project (otherwise).
I'm not saying this will help to solve OPs problem but at least it
will feed LAVA with loads of meta-information about source that runs
on the tested boards. If someone likes this format it could be adopted
by other tools.
Best regards
Zygmunt Krynicki
On Tue, Jan 24, 2012 at 4:01 PM, Christian Robottom Reis
k...@linaro.org wrote:
On Tue, Jan 24, 2012 at 12:59:33PM -0200, Christian Robottom Reis wrote:
On Tue, Jan 24, 2012 at 09:29:34AM -0500, Chris Lalancette wrote:
(I'm aware that there is a thread on linaro-dev discussing this
exact topic; this is a request for specific information, so I
decided to start a new thread)
Hello,
As has been pointed out elsewhere, it is very difficult to find
the exact git tree that corresponds to a kernel release. Currently
the problem I am having is that the 11.11 linaro kernel release
(linux-linaro-lt-omap_3.1.0-1402.5~oneiric1) works well on my new
board, but later kernels do not. While I can download the kernel
tarball for 3.1.0-1402.5 from launchpad, I would much prefer to use
the git tree that it was produced from. Can anybody tell me exactly
which git tree was used to create that kernel, and which tag/branch
I should be looking at?
That's a really good question. The answer is that it's this tag and
branch:
linux-release-2011-12
http://git.linaro.org/git/landing-teams/leb/ti/kernel.git
Sorry, for 11.11 that's tag linux-release-2011-11-1 -- you can see all
the tags here:
http://git.linaro.org/gitweb?p=landing-teams/leb/ti/kernel.git;a=summary
--
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LiveBuild failure creating nano image
On Fri, Jan 20, 2012 at 10:40 PM, Matt Waddel matt.wad...@linaro.org wrote: Hi, I have encountered a failure running live-build that I could use some help debugging. Using the instructions in the LiveBuild wiki page: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild the procedure fails during the adduser step. The failure is: I: create linaro user Can't set $0 with prctl(): Bad address at /usr/sbin/adduser line 86. Here is the perl code around line 86 in adduser: my %config; # configuration hash my @defaults = (/etc/adduser.conf); my $nogroup_id = getgrnam(nogroup) || 65534; $0 =~ s+.*/++; Line 86 This line attempts to set $0 to the substitution of a regular expression, it takes $_ as an argument and replaces the value matched by a regular expression .*/ with an empty string. I don't pretend to understand the error message, it just seems to me that $0 is the implicit variable that contains the entire string when using regular expressions ($1... and so on are subsequent matches) and that $0 in that context might be read only. Best regards ZK This is the call to adduser from the 01-setup_user_linaro.chroot script that causes the problem: adduser --gecos linaro --disabled-login linaro The funny thing about this failure, if I chroot into the build area and run that command manually, everything works fine. 1st, what is that perl command doing? 2nd, anybody have any ideas on what would cause this failure? TIA, Matt ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LAVA maintenance 2012-01-19 23:00 UTC COMPLETE
Dear LAVA users, We have finished the planned maintenance. The lab was down for approximately: 23 minutes (we did not estimate the downtime before). We have installed the 2012.01 release from this .pybundle file [1]. It contains the following software packages [2] We did encounter some problems in the upgrade procedure which will be addressed in the subsequent release [3, 4] [1]: https://launchpad.net/lava-project/+milestone/2012.01 [2]: http://bazaar.launchpad.net/~linaro-validation/lava-deployment-tool/trunk/view/head:/requirements/requirements-2012.01.txt [3]: https://bugs.launchpad.net/lava-deployment-tool/+bug/918944 [4]: TBD -- The Validation Team. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: l-m-c hacking for UEFI
On 01/13/2012 10:38 AM, Jon Medhurst (Tixy) wrote: On Thu, 2012-01-12 at 17:35 -0300, Guilherme Salgado wrote: I wonder if it wouldn't be better to make hwpacks include just one bootloader (whichever is chosen by the hwpack author)? This could make the transition difficult. Some users (like LAVA) require U-Boot, whereas others might want to use the new UEFI. We don't require U-Boot. If we can somehow script UEFI (remotely tell it to boot from something) then we'll gladly support UEFI as well. -- Zygmunt Krynicki Linaro Validation Team ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Audio Roadmap - requirements and comments?
W dniu 09.12.2011 20:01, Kurt Taylor pisze: Here is a list of the upcoming audio work for Linaro. I am planning on putting this together into a much more polished roadmap and schedule, but its a start. This is absolutely not set and I am actually looking for any additional requirements and comments. I am sure I have forgotten some, if you don't see your hot topic here, please respond. Hi, I have two questions: * What is the testing plan? * What are the LAVA requirements (things you'd like to see in LAVA to allow you to integrate any kind of automated testing) Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LAVA Maintenance 2011-12-07 22:00 UTC
Hi LAVA users We'll be taking the system down for a brief maintenance session. We will be running a stale database migration to address the issues of https://bugs.launchpad.net/lava-dashboard/+bug/892562 specifically to run the migration we did not run two days ago due to a special one-off upgrade process. Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Coming up with a upgrade plan
Hi I think we should document the current LAVA upgrade plan. Please review this page if you are interested in this topic. There are some ISSUES and unfinished parts, please post your ideas about that. https://wiki.linaro.org/Platform/Validation/DevOps/LavaProductionUpgrade Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Master images are a mess
Hi, sorry for the topic, I wanted to catch your attention. This is a quick brain dump based on my own observations/battle with master images last week. 1) Unless we use external USB/ETH adapters then cloning a master image clones the mac address as well. This has serious consequences and I'm 100% sure that's why lava-test had to be switched to the random UUID mode. This problem applies to the master image mode. In the test image the software can do anything so we may run with a random MAC or with the mac that master images' boot loader set (we should check that). Since making master images is a mess, unless is becomes automated I will not be convinced that people just know how to make them properly and are not simply copying from someone. There is no reproducible master image creation process that ensure two people with the same board can run a single test in a reproducible way! (different starting rootfs/bootloader/package selection/random mistakes) 2) Running code via serial on the master image is a mess. It is very fragile. We need an agent on the board instead of a random master image+serial shell. The agent will expose board identity, capabilities and standard APIs to LAVA (notably the dispatcher). The same API, if done sensibly, will work for software emulators and hardware boards. Agent API for a software emulator can do different things. Dispatcher should be based on agent API instead of ramming the serial line. 3) The master image, as we know it today, should be booting remotely. The boot loader can stay on the board until we can push it over USB. The only thing that absolutely has to stay in the card is the lava board identity file which would be generated from the web UI. There is no reason to keep rootfs/kernel/initrd there. This means that a single small card can fit all tests as well. It also means we can reset the master image (as currently it is writeable by the board and can be corrupted) before booting to ensure consistent behaviour. I did some work on that and I managed to boot panda over NFS. Ideally I want to boot over nbd (netblock device) which is much faster and with proper master image init script we can expose a single read only net block device to _all_ the boards. 4) With agent on each board, identity file on the SD card LAVA will know if cloning happened. We could do dynamic board detection (unplug the board - it goes away, plug it back - it shows up). We could move a board from system to system and have 0config transitions. 5) Dispatcher should drop all configuration files. Sure it made sense 12 months ago when the idea was to run it standalone. Now all of that configuration should be in the database and should be provided by the scheduler to the dispatcher as a big serialized argument (or a file descriptor or a temporary file on disk). Setting up the dispatcher for a new instance is a pain and unless you can copy stuff from the validation server and ask everyone around for help it's very hard to get right. If master images could be constructed programmatically and with a agent on each master image lava would just get that configuration for free. 6) We should drop conmux. As in the lab we already have TCP/IP sockets for the serial lines we could just provide my example serial-tcp script as lava-serial service that people with directly attached boards would use. We could get a similar lava-power service if that would make sense. The lava-serial service could be started as an instance for all USB/SERIAL adapters plugged in if we really wanted (hello upstart!). The lava-power service would be custom and would require some config but it is very rare. Only lab and me have something like that. Again it should be instance based IMHO so I can say: 'start lava-power CONF=/etc/lava-power/magic-hack.conf' and see LAVA know about a power service. One could then say that a particular board uses a particular serial and power services. That's it. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Master images are a mess
W dniu 07.12.2011 18:44, Paul Larson pisze: On Wed, Dec 7, 2011 at 10:01 AM, Zygmunt Krynicki zygmunt.kryni...@linaro.org mailto:zygmunt.kryni...@linaro.org wrote: Hi, sorry for the topic, I wanted to catch your attention. This is a quick brain dump based on my own observations/battle with master images last week. 1) Unless we use external USB/ETH adapters then cloning a master image clones the mac address as well. This has serious consequences and I'm This doesn't ring true. We do have different mac addresses, even on boards without flash and on-board ethernet. How does it work? As far as I know mac address is burned in boot.scr, if you copy that (and tell me we don't) then we get duplicates. Update: after a quick discussion on #linaro it seems that the mac address is actually burned into the hardware pack and lmc does not make one (at least not for panda). I have not verified this yet but if true then _all_ pandas with a given hwpack build get the same mac. 100% sure that's why lava-test had to be switched to the random UUID Incorrect - I hunted down that problem. We can switch back if you really like, but I don't see any advantage to it. What was the problem? I don't remember we actually traced that to the root cause. mode. This problem applies to the master image mode. In the test image the software can do anything so we may run with a random MAC or with the mac that master images' boot loader set (we should check that). Since making master images is a mess, unless is becomes automated I will not be convinced that people just know how to make them properly and are not simply copying from someone. There is no reproducible master image creation process that ensure two people with the same board can run a single test in a reproducible way! (different starting rootfs/bootloader/package selection/random mistakes) That's a pretty big exaggeration to say that it can't be done by others, or that it affects reproducibility of tests. Try assisting others in getting master images. It takes a long while before you get from lava installed to lava ran stream for the first time. The reason for that is provisioning a board is HARD and should not be. The process isn't *that* hard. It's essentially just a nano image, a couple of extra packages installed, and add a few partitions. However, I do agree with the sentiment that this should be automated as much as possible. 2) Running code via serial on the master image is a mess. It is very fragile. We need an agent on the board instead of a random master image+serial shell. The agent will expose board identity, capabilities and standard APIs to LAVA (notably the dispatcher). The same API, if done sensibly, will work for software emulators and hardware boards. Agent API for a software emulator can do different things. Dispatcher should be based on agent API instead of ramming the serial line. This sounds like a good connect topic. It has some advantages, but also a lot of things to address. 3) The master image, as we know it today, should be booting remotely. The boot loader can stay on the board until we can push it over USB. em The problem is getting it to a state that we can push it over usb for every board. Not all boards support this, and the ones that do sometimes have issues with the tools to make it possible. I don't want to push 100% over usb but pushing 99.9 (all except to boot loader) works for all boards as far as I know. This would give us controllable master image (hell we could install tests before turning the power on). We've talked about other solutions like a SD interface we can write from an external host over USB, then boot the board. One potential pitfall here is that this would mean we can no longer offload the lmc process with celery. It would HAVE to be done from the attached host. I'm not proposing anything like that. I just want to keep the master rootfs + kernel away from the sd card. It is not in any way related to how we run testrootfs. That means we are back to serializing LMC processes, or we have a host for every single dev board! I'm not proposing anything like that. LCM can still run anywhere we want. The only thing that absolutely has to stay in the card is the lava board identity file which would be generated from the web UI. There is If that's needed, then why couldn't it be written when we deploy to the board? It should be written once (when we create the master image) for a particular board. It should be written then and never touched before. no reason to keep rootfs/kernel/initrd there. This means that a single small card can fit all tests as well. It also means we can reset the master image (as currently it is writeable by the board and can be corrupted) before booting to ensure consistent behaviour. I did some work on that and I
Re: Master images are a mess
Hi Andy. On Wed, Dec 7, 2011 at 11:24 PM, Andy Green andy.gr...@linaro.org wrote: On 12/08/2011 02:36 AM, Somebody in the thread at some point said: Just briefly commenting on the bits I have some experience with... 1) Unless we use external USB/ETH adapters then cloning a master image clones the mac address as well. This has serious consequences and I'm This doesn't ring true. We do have different mac addresses, even on boards without flash and on-board ethernet. How does it work? As far as I know mac address is burned in boot.scr, if you copy that (and tell me we don't) then we get duplicates. Update: after a quick discussion on #linaro it seems that the mac address is actually burned into the hardware pack and lmc does not make one (at least not for panda). I have not verified this yet but if true then _all_ pandas with a given hwpack build get the same mac. If you're running TI LT kernels for Panda, and it has also been true for linux-linaro- on Panda, then I added patches a while back to munge a MAC address from the CPU's allegedly-GUID ID number. That is consistent for a particular Panda board, and there's at least a selection of possible MAC addresses to reduce chance of collision. It's unclear how wide that selection is but it isn't tiny. I see, that would make some sense (sadly not as much as putting a 1K NV storage on a panda by TI). I need to check how my boot.scr got a hard-wired mac address in its boot.src because I'm 100% sure that I did not touch it though. corrupted) before booting to ensure consistent behaviour. I did some work on that and I managed to boot panda over NFS. Ideally I want to boot over nbd (netblock device) which is much faster and with proper master image init script we can expose a single read only net block device to _all_ the boards. FWIW I used NBD some years ago and it worked great. You have to take care about building some userland footprint for it but otherwise I found it much more effective and reliable than NFS. Edubuntu uses NBD and I talked with the person that implemented that part. It seems very fast and reliable and with single readonly rootfs image they export it seems to be just perfect for what we wanted. 1) Start with what we have but make it 100% automatic. Fix MAC issues. If you're faced with a board that has no on-PCB NV storage for this kind of identity information, if the CPU has a GUID then I can recommend forming the MAC from it. Right now I would use a explicitly set mac that lava also knows about. It's something you would generate on the server. Then plaster a file on the SD card. The boot script would load that file and set the mac address accordingly. This only applies to boards with no NV storage and on-board ETH. For beagle C4 and origen we can depend on non-crappy USB/ETH adapters. Doing stuff like that based on the board id sounds nice but has some drawbacks: 1) It does not work in all cases (older kernels, older bootloaders maybe) 2) It requires some per board magic which might take a time to happen in all the kernel trees (unless it is already done) 3) Lava does not know it. We can do smarter things when we know the mac of each board we have (like allow it to tftp boot + nbd boot later). We can also do tests on static IP addresses if we want to as we can control dhcp. Thanks for your feedback! ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA Maintenance 2011-12-07 22:00 UTC
On Wed, Dec 7, 2011 at 3:29 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Hi LAVA users We'll be taking the system down for a brief maintenance session. We will be running a stale database migration to address the issues of https://bugs.launchpad.net/lava-dashboard/+bug/892562 specifically to run the migration we did not run two days ago due to a special one-off upgrade process. Upgrade has finished successfully. No running jobs were affected. Database migration took 17 seconds. Overall downtime was slightly longer but we managed to keep it short enough that few jobs, if any, were lost (at this time we don't have a way to check) All bundles that failed to deserialize due to the bug mentioned above have been deserialized now. Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Master images are a mess
W dniu 08.12.2011 05:16, Andy Green pisze: On 12/08/2011 10:56 AM, Somebody in the thread at some point said: On Thu, Dec 8, 2011 at 12:49 AM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: W dniu 08.12.2011 02:54, Ricardo Salveti pisze: On Wed, Dec 7, 2011 at 4:36 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: I don't want to push 100% over usb but pushing 99.9 (all except to boot loader) works for all boards as far as I know. This would give us controllable master image (hell we could install tests before turning the power on). I guess this will only be an issue with Origen, as to make ethernet to work at the boot loader you also need to have USB support (kind of similar as Panda). For the others I believe it should just work (if not, it's a bug). What is a bug, bootloader not supporting Ethernet? Well all the other boot loaders seem to ;-) Getting it to work with panda would be a major milestone. I don't treat boards as equal as they are not equal. Last time I checked uboot has lots of USB and ethernet support so we might be able to eventually do it assuming actual bugs in both linux kernel and uboot for origen are fixed. For Panda at least you should have everything you need: 1 - USB booting for SPL/U-Boot with USB SPL support; 2 - Ethernet support at U-Boot with TFTP and PXE support; 3 - Unique mac address at both u-boot and kernel (same one, same code to calculate it); Once you make it work with Panda, we can later then try to have the same support at the other boards we have. Do all the supported SoC ROMs support USB booting, or workable alternative? The alternative is to keep a static copy of uboot on the SD card as we've been doing all the time now. ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LAVA upgrade and deployment change
Hi LAVA users, The Linaro Validation Team is preparing to change the way we deploy LAVA in production. We expect this will require 1 hour of downtime or less on Monday beginning at 22:00 UTC. This upgrade will streamline our deployment process, allowing us to deploy changes more frequently and quickly deliver incremental improvements. This change will also allow others to deploy LAVA in the same way, for development or production purposes. As the API will not be working during the downtime, there is the chance that some automatically-submitted jobs (e.g. from android-build) will be lost. We hope to work soon on an approach that will avoid this risk. Cheers, The Validation Team ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
(cross-post) Efika MX anyone?
W dniu 11.11.2011 03:55, Adilson Oliveira pisze: Hi. I'm re-posting a question from a canonical folk about Efika MX, I think the audience here will be more capable of helping out. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello I got an Efika MX and I wondered if anyone qwas able to instrall a more recent Ubuntu on it. I tried Linaro's image but the SD is not recognized at boot time. Am I missing something or was the SD supposed to be detected automatically? TIA Adilson. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk68jroACgkQYaKG37RGLIp/pACdFvTB3hVssnVCeXNL9EulVb9Z UccAn3z3YUvON/ji1gdRDaRuHq/IZrA1 =73EU -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Debian GNU/Linux on tablet hardware
W dniu 28.10.2011 17:46, Jeremiah Foster pisze: Android's Linux kernels are supported (maintained?) by Linaro. With my Linaro hat on I must object. Depending on what you meant the statement above is either highly inaccurate or simply untrue. Hence the question mark. :) I think what I originally meant is that we don't focus solely on Android. Improved is the word I would use, that implies neither support nor maintenance as we are between the vendors (that are also part of Linaro) and upstream kernel community (that we are a part of) and we have no control of either side and their actions. As to what we do check our FAQ (http://www.linaro.org/faqs/) and read on. Android kernel situation is complicated and varies per board/SoC. What Linaro does is try to upstream and unify the kernel for Linaro member companies SoCs. What does that mean in practice? Disclaimer: I'm not a kernel developer. I have experience in the non-Intel part of the world but I'm not the sort of person with up-to-date hands-on experience. For those folks please look at traffic in linaro-dev@lists.linaro.org and at our patchwork instance at patches.linaro.org. You can see what kind of patches we push upstream and if they have landed yet. As for your question, read on. A lot of ARM devices have a BSP kernel (android or not) that is prepared by some 3rd party (sometimes also by the vendor themselves if the device is a clone of the reference design) and that kernel is generally not pushed upstream. This affects, by far, the vast majority of devices out there (I'd say that nothing gets pushed by those companies simply because their work mode does not require such a step - we are working on educating them in the benefits of working both towards products and common code base). The ARM tree in the upstream kernel is, again, by far, the largest of all the other architectures. If I remember correctly it is in fact larger than *all* the other trees combined. The reasons for this are complicated but can be generally simplified to code duplication between the different devices and greater diversity in the actual hardware as compared to other platforms. To get ARM Linux healthy we need to reduce that clutter and make sure that support for the latest and greatest hardware is upstream quickly and the code is being actively maintained by everyone. This is far from finished and uniform. The BSP kernel that hardware vendors provide is not supported by Linaro and in fact often contains code that cannot go upstream. What does it use this proprietary code for? To know the APIs or to get other hardware interface info? Isn't that a little risky? Won't proprietary, and potentially patented IP leak into the Linaro work? (Not that I believe in IP.) The term proprietary is a bit misleading, the code IS released as GPL. It is simply there to support some parts (often userspace or firmware) that is not open sourced and cannot be for all practical considerations. As for the patches in general, there are different reasons why they are not suitable for being proposed and included upstream: 1) Shabby code, against old trees, copy-pasted from another similar device, maintenance hell. This is, by my unqualified judgment, the vast majority of the problem. 2) Code that has no good place in the kernel just yet because the kernel interfaces are insufficient for the extremely complicated world of ARM SoCs. Off the top of my, unqualified, head: power management, memory management, everything related to graphics and probably many more. Here the reason for not being upstream is that there is no consensus on how to do something (how to support a certain class of SoC components) that could be applied to many vendors and non-arm world as well. Here the people that write the BSP cannot solve the problem and just implement their own solution to meet the deadline. Such code is often very good but there are many similar solutions that are quite nontrivial to merge into one sensible codebase. One such example is memory management where we have no less than 3 or 4 competing interfaces from various companies and there is a working group inside Linaro and the greater Linux community that tries to solve this problem. 3) Bits that enable proprietary userspace drivers. The reasons are obvious. This could be related to lots of different things, not only graphics as people often think. IP and software edge (optimizations that make otherwise identical hardware perform better than competition) is probably a big motivation here. The IP protection is not only used as in don't steal our stuff but rather hey, with this being binary it is harder to prove that we violate a specific patent you have. In retrospective this is a thing those companies obviously need. Just look at how many Android handset vendors pay to, for example, Microsoft, for patents that allegedly apply there. The world of graphics is riddled
Re: Debian GNU/Linux on tablet hardware
W dniu 28.10.2011 20:10, Luke Kenneth Casson Leighton pisze: On Fri, Oct 28, 2011 at 5:59 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Disclaimer: I'm not a kernel developer. I have experience in the non-Intel part of the world but I'm not the sort of person with up-to-date hands-on experience. For those folks please look at traffic in linaro-dev@lists.linaro.org and at our patchwork instance at patches.linaro.org. You can see what kind of patches we push upstream and if they have landed yet. ok - this is potentially misleading, zygmunt, at best irrelevant. ok, shall i point out a correction, and you, or someone else from linaro, can, if it is incorrect, provide the required corrections, yes? I was just trying to state my opinion that Linaro supporting android kernels is kind of misleading in its own way. While I'm not a kernel developer I'm deep in Linaro and I try to stay informed about what is going on. I would love to see responses from other Linaro engineers as that would correct my personal opinion if I got something wrong. Note: if the discussion below is off-topic to the original thread please feel free to ignore me. by mentioning the above patch queue (on the debian-arm list), then *despite* previously mentioning that linaro is between the vendors and the kernel developers, there is a risk that people could not connect the dots between this and the previous paragraph (seen that happen so many times it's unreal) and thus it would appear - to them - that linaro is *still* seen to quotes be an authority unquotes regarding patches [for specific hardware]. the correction - if any is needed - is that linaro is NOT an authority of ANY KIND regarding definitive patchsets or in fact an authority of any kind PERIOD. Linaro is more than a random collection of kernel hackers. The key advantage we have is that those hackers come from hardware vendors directly (and here I mean the people that actually design the SoC and then produce chips you can buy). Linaro is in a special position as it can attempt cross-vendor solutions on a scale nobody has attempted before. That is much stronger than any other group that I know of. We can, in a way, discuss and implement de-facto standards that the main ARM vendors will use in BSPs for subsequent products. linaro is, in fact an accelerator, helping SoC vendors to push lowest common denominator code into the linux kernel for the Yes, Linaro is an accelerator. I would not, however, limit us to the lowest common denominator. We are working on solving the big problems that ARM kernel faces. That affects and involves everyone but is not equivalent to lowest common denominator in my opinion. convenience of *MULTIPLE* hardware and software developers using that PARTICULAR SoC, but linaro are not, repeat NOT direct suppliers of linux kernel source code for a specific device. No, that is not our goal (to be the supplier of kernel trees for random hardware). What you may find interesting however is that some hardware device manufactures (not SoCs vendors) want to use or sometimes even _require_ Linaro-based trees for their devices. I think that is a fantastic validation of our efforts. Working with Linaro trees is faster and thus cheaper for those vendors. perhaps if any code for a particular device _is_ pushed upstream by linaro, it is almost by accident, by nature of it, for example, being a particular example BSP or convenient Reference Platform. Not by accident and not for a particular device. Our intention is to support the _next_ set of SoCs in the upstream kernel. When a company goes out to search for devices to build their next product those SoC will be already enabled and not only in a random BSP package but straight in the upstream vanilla kernel. putting it into context: linaro is paid by _SoC Vendors_. linaro is *not* paid by individual Hardware Factories (afaik) to do hardware-specific, device-specific linux kernel development. Some of the device vendors are coming closer to Linaro. I can cite one example from memory, Genesi, the manufacturer of several interesting freescale based products has joined Linaro to improve cooperation between their engineers working on next Genesi products and Linaro's common vision on how things should work. thus in that context, whilst it is nice that linaro is doing upstream patches, and it's nice that you mentioned it, it is in the context of this discussion, off-topic. As stated at the beginning of this message I was attempting to correct an inaccurate, in my opinion, assessment of what Linaro is doing. In a finishing note I'd like to state that the devices that we work on daily (and improve GNU/Linux experience on) are being used to form products we'll see on the market. Initially development boards were a queer concept for the SoC vendors but I think that is rapidly changing and more vendors start to see the effect making those
On OS-autoinst and LAVA
Hi. I noticed your project (http://os-autoinst.org/) and I decided to say hello. :-) I'm one of the developers behind LAVA. Essentially LAVA is an automated testing thing focused on practical ARM testing. We have a scheduler for planning, dispatcher for automating boot and starting the test, a test wrapper framework, a bit of existing open source tests wrapped, an android equivalent with some initial tests that work well there, a data (test results) interchange format, a server piece that houses a few of those items, a dashboard piece that allows you to browse/analyze results, a kernel regression piece (in the making now) and a few other things. Sounds familiar? All of the code is free software (we use a mixture of LGPL, AGPL and GPL depending on purpose of the component). We would love to know more about you and see if you'd like to share development effort. I can easily see us collaborating on wrapping tests (we use mostly python but we could easily support tests written in perl, oh we have LTP amongst others, one of the items in Your TODO list), building a free test catalogue and perhaps I could convince you that our data interchange format is very valuable and worth adopting. We have a few mailing list (http://lists.linaro.org/mailman/listinfo), linaro-dev is the one where most of the LAVA work is being discussed (although to be fair I have to say that we prefer IRC for quick discussions, we are on freenode in #linaro). The code can be found on launchpad, most notably on https://code.launchpad.net/lava-dashboard, https://code.launchpad.net/lava-server, https://code.launchpad.net/lava-scheduler, https://code.launchpad.net/lava-test (see all the projects linked from lava project group here: https://launchpad.net/lava) We have some documentation with more coming every week: https://wiki.linaro.org/Platform/Validation/KnowledgeBase, you might be interested in http://lava-test.readthedocs.org/en/latest/index.html and http://lava-dashboard.readthedocs.org/en/latest/index.html although the latter is sorely out of date. Looking forwards to your response. Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LAVA 2011.09 installed on validation.linaro.org
Hi. I have finished updating LAVA installation on our server to the latest release. Precise version numbers can be always checked here: http://validation.linaro.org/lava-server/version/ If you spot some issues please report them here: https://bugs.launchpad.net/lava-lab/+filebug or follow up here on the mailing list. Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Internal License for PyCharm available
W dniu 12.09.2011 12:49, James Tunnicliffe pisze: Hi, If you are a Python developer you are now able to use the commercial IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer. Since the license is for Linaro engineers only I have put it on the internal wiki at https://wiki.linaro.org/Internal/Licenses. I just tried to use this license but apparently something is not right. Perhaps there is a typo in the license or it has to be formatted in a certain way. Could you double-check how the license looks like in your registration window? Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Internal License for PyCharm available
W dniu 12.09.2011 13:31, James Tunnicliffe pisze:
On 12 September 2011 12:17, Zygmunt Krynicki
zygmunt.kryni...@linaro.org wrote:
W dniu 12.09.2011 12:49, James Tunnicliffe pisze:
Hi,
If you are a Python developer you are now able to use the commercial
IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
Since the license is for Linaro engineers only I have put it on the
internal wiki at https://wiki.linaro.org/Internal/Licenses.
I just tried to use this license but apparently something is not right.
Perhaps there is a typo in the license or it has to be formatted in a
certain way.
Could you double-check how the license looks like in your registration
window?
In my registration window I have the user name Linaro and the license
key exactly as shown on the wiki page (the bit in the {{{code}}}
block).
I got that, I also fixed the wiki to use proper formatting for the license.
Out of curiosity, did you use the django-related features of pycharm yet?
Thanks
ZK
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Internal License for PyCharm available
W dniu 12.09.2011 15:56, James Tunnicliffe pisze:
On 12 September 2011 13:27, Zygmunt Krynicki
zygmunt.kryni...@linaro.org wrote:
W dniu 12.09.2011 13:31, James Tunnicliffe pisze:
On 12 September 2011 12:17, Zygmunt Krynicki
zygmunt.kryni...@linaro.orgwrote:
W dniu 12.09.2011 12:49, James Tunnicliffe pisze:
Hi,
If you are a Python developer you are now able to use the commercial
IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
Since the license is for Linaro engineers only I have put it on the
internal wiki at https://wiki.linaro.org/Internal/Licenses.
I just tried to use this license but apparently something is not right.
Perhaps there is a typo in the license or it has to be formatted in a
certain way.
Could you double-check how the license looks like in your registration
window?
In my registration window I have the user name Linaro and the license
key exactly as shown on the wiki page (the bit in the {{{code}}}
block).
I got that, I also fixed the wiki to use proper formatting for the license.
Odd. I take it that you don't have it working still? I checked the
license code against what was in the wiki and it is identical.
I got it working now. The devil is in the details as they say. The
license needs to be split into multiple lines to work correctly. If you
just copy-paste from the wiki page it used to be bad (the source of the
wiki page was correct though).
Out of curiosity, did you use the django-related features of pycharm yet?
A little. It will do nice things like restart the dev server when you
save a python file, but I haven't done much django development.
Django does that by itself.
I would like to know how it works for you if you continue to use it.
Let's stay in touch.
Thanks
ZK
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Re: Preliminary wiki starting page for i.MX53 QuickStart board
W dniu 03.09.2011 09:57:36, nadawca Fabio Estevam feste...@gmail.com,Christian Robottom Reis k...@linaro.org, Linaro Dev linaro-dev@lists.linaro.org, Eric Miao napisał: On Fri, Sep 2, 2011 at 6:15 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: ... I read all about how to boot that board. I'm working on booting via USB. I Can you explain what you mean by booting via USB? iMX53 can use the micro USB port to boot. You have to make the CPU enter serial download mode which polls 5 UARTs and the micro USB port. This is described in IMX53RM.pdf, You can use USB to enter in bootstrap mode, so that you can program a binary into some media, like SD card for example. Is that what I refer to as serial downloader? You can´t boot via a USB pen drive for example. MX53 allows you to boot from: NOR, NAND, MMC, PATA, SATA, EEPROM. You are correct, my description was vague. Thanks Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Re: Preliminary wiki starting page for i.MX53 QuickStart board
W dniu 03.09.2011 10:05:59, nadawca Eric Bénard e...@eukrea.com,Lists Linaro-dev linaro-dev@lists.linaro.org, Eric Miao eric.m...@linaro.org, Christian Robottom Reis napisał: Hi Zygmunt, Le 02/09/2011 23:15, Zygmunt Krynicki a écrit : BTW: if anyone is interested in helping me out, have some work-in-progress code at lp:~zkrynicki/+junk/lava-imx53-serial-boot (serial as in serial download mode offered by the boot-rom, not serial cable). here is a quick and dirty program which works in uart boot mode on i.MX25/35/51 (and should work on the i.MX53) and the corresponding configuration files for these 3 targets : it performs minimal CPU/memory initialization and upload a bootloader in RAM which allows recovery. For the i.MX53 init file, you can find a starting working base here : http://download.ronetix.info/peedi/cfg_examples/cortex-a8/mx53.cfg Eric Thanks for all of that. I'll use it to check for basic activity (that it works on my board) and then use it to finish my script. I wanted to use USB because it allows for 0-end-user activity device provisioning. Unlike pure serial USB allows for device discovery. With a few udev rules an user with LAVA server running on their machine might simply plug an iMX53 device to the system to have it automatically detected and ready for testing. Thanks. This is what I was looking for! ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Preliminary wiki starting page for i.MX53 QuickStart board
W dniu 02.09.2011 20:31, Christian Robottom Reis pisze: On Tue, Aug 30, 2011 at 03:41:34PM +0800, Eric Miao wrote: https://wiki.linaro.org/Boards/MX53QuickStart Sorry guys, although been pushed and pinged several times by various people we are finally able to come up with a preliminary starting page for i.MX53 QuickStart board. It's currently very simple, and hopefully we'll get it more detailed in the future. Feedback is welcome! Oh, this is excellent. Thanks for putting the effort into the write-up. All I need now is an actual board to tell you how well it works ;-) I had one comment, which is that the Downloading Hardware Pack section seems to only specify the lt variant; does it make sense to also point to the pure upstream variant for comparison (or for people that are hell-bent on an upstreamable kernel?) Also, there is nothing mentioned in the text about the bootloader (what comes on the board, and what the default boot media ordering is, and how to replace it). Is that not worth mentioning? I read all about how to boot that board. I'm working on booting via USB. I think the best way to proceed is to link to the official board documentation (a hefty PDF) with page/paragraph references. BTW: if anyone is interested in helping me out, have some work-in-progress code at lp:~zkrynicki/+junk/lava-imx53-serial-boot (serial as in serial download mode offered by the boot-rom, not serial cable). I'm interested in looking at payloads that can be injected. The complicated part is that unlike my initial assumption (hey, just put the bootloader at some correct address and go) one may to put three kinds of payload. It seems one is the bootloader, one ... and I'm just guessing here... determines how to initialize DRAM and other peripherals and the third one is anyone's guess. I read about this more on freescale developer forum and it seems that the freescale documentation is a cut-down version of the NDA-required document that also describes secure boot. If anyone can help me sign the NDA to give Linaro (and LAVA) solid USB boot support for iMX53 (hey, we could test bootloaders this way) feel free to email me in private. Thanks ZK PS: I'll find the PDF on my disk, figure out where I got it from and update the wiki. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Preliminary wiki starting page for i.MX53 QuickStart board
On Fri, Sep 2, 2011 at 11:15 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: I read all about how to boot that board. I'm working on booting via USB. I think the best way to proceed is to link to the official board documentation (a hefty PDF) with page/paragraph references. The document I was referring to is: IMX53RM.pdf from: http://cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf The interesting parts are: Section 7.2.1: Boot Mode Pin Settings Section 7.6.2: Device Configuration Data (DCD) Section 7.8.3: Serial download protocol Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: edge.validation.linaro.org
W dniu 31.08.2011 01:30, Alexander Sack pisze: On Tue, Aug 30, 2011 at 6:55 PM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Hi there. The validation team has a new edge website, http://edge.validation.linaro. **org/http://edge.validation.linaro.org/ that reflects the development trunk of all of our components. This site can be used to check latest development effort, test bug fixes and, to some degree, use new features. This website mimics the concept of now-defunct edge.launchpad.net. That is, it allows for new code to run on top of the production database. This has important ramifications: 1) Unsafe code could cause data loss 2) New features that depend on database schema modifications cannot be tested this way. 3) Non-website features such as dispatcher and part of the scheduler cannot be tested this way. For addressing those we will soon deploy staging.validation.linaro.orgthat works on a periodic snapshot of the production database. I will be posting an update with instructions on how to replicate this setup if necessary and details about the periodic automatic roll out/upgrade procedure. Thanks for the heads up. I wonder, once we have staging.v.l.o, do we really need edge anymore? Perhaps not. We will see once we have both. What problems does edge protect us from that we really care about? Maybe we can avoid running 3 instead of two instances and have 3 instead of 2 code rollout stages? What do you mean by rollout stages? Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: edge.validation.linaro.org
W dniu 31.08.2011 16:39, Paul Larson pisze:
On Wed, Aug 31, 2011 at 6:57 AM, Zygmunt Krynicki
zygmunt.kryni...@linaro.org wrote:
Edge is just a point on the roadmap. If staging is fast enough to
scrap/deploy then we may just use staging all the time.
I was actually thinking it might be nice to have staging as more of a fluid
concept using VMs. We could set up a semi-permanent staging VM that gets
updated with trunk of everything every {day, week, whatever}, but also have
other VMs available for upgrade testing, and testing individual changes.
That way, for instance, if you need to test a dispatcher change that
affects a certain type of board you don't have at home, you can simply wait
for one of those boards to become available in the lab, mark it offline,
bring up a vm and do some testing with it. Likewise, it could be used to
setup and test an invasive change to the dashboard. All that would be
required is a few static port mappings on the firewall, and a server capable
of handling a few KVM sessions (which I'd like to look at getting soon for
this purpose and others).
I agree with usefulness of staging as a fast-to-production model While
using VMs is a possibility it does not really preclude me from
experimenting with this design.
For safety reasons a VM might be needed once we start to run stuff as
root. Currently all edge stuff is owned by a normal user and runs as the
web server.
One thing that worries me is KVMs lack of (can anyone correct me if I'm
wrong) USB pass-through support. This means we may have a hard time
reaching USB serial adapters or USB-to-device links in general. For that
reason my testing will use headless virtualbox instances.
I have created lp:~zkrynicki/+junk/edge where this stuff is being created.
Thanks
ZK
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
edge.validation.linaro.org
Hi there. The validation team has a new edge website, http://edge.validation.linaro.org/ that reflects the development trunk of all of our components. This site can be used to check latest development effort, test bug fixes and, to some degree, use new features. This website mimics the concept of now-defunct edge.launchpad.net. That is, it allows for new code to run on top of the production database. This has important ramifications: 1) Unsafe code could cause data loss 2) New features that depend on database schema modifications cannot be tested this way. 3) Non-website features such as dispatcher and part of the scheduler cannot be tested this way. For addressing those we will soon deploy staging.validation.linaro.org that works on a periodic snapshot of the production database. I will be posting an update with instructions on how to replicate this setup if necessary and details about the periodic automatic roll out/upgrade procedure. Thanks Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: playing with the lava scheduler
W dniu 24.08.2011 15:08, Prince Mathew pisze: i installed lava-server as described in steps 12 To simplify support we do not support installing from source. Use our official PPA (ppa:linaro-validation/ppa) and install from packages. If you choose to go on with source code you must know how to deploy and administer webapps and databases yourself. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA 2011.07 Release
W dniu 25.07.2011 09:58, Alexander Sack pisze: Congrats to the Validation Team for this great release! A first few points from looking at the current deployment at http://validation.linaro.org: + The Image Status dashboard view is not self-explanatory to me. I only see raw numbers, but no info whether all is good or not is visible there. Whats the goal of this view? How is that different to a image status report? or is that just a special report that got promoted to a top-level menu item? I'll rewrite that report to be more explanatory. I would encourage you to look at the Image Status section as it is a little bit better. http://validation.linaro.org/lava-server/dashboard/image_status/ + I tried to look at a few Reports, but the AJAX request never finishes for me I'll look at that. + Any strong reason why we use a framed webUI? That feels so much last century to me. Here, I would very much like to be able to just take the location URL, paste it somewhere and then someone can open the same view with that URL. This framed layout also seems to cause issues on my small screen (e.g. parts of the tabls are hidden and no scrollbar etc.) It's just a temporary measure. By the end of the week v.l.o will look totally different. There will be no frames around. + i get 500 internal errors when clicking on data views, like: http://validation.linaro.org/lava-server/dashboard/data-views/recent-test-runs-for-board-and-hwpack-and-rootfs-4/ I'll look at that. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA 2011.07 Release
W dniu 25.07.2011 09:58, Alexander Sack pisze: Congrats to the Validation Team for this great release! A first few points from looking at the current deployment at http://validation.linaro.org: + The Image Status dashboard view is not self-explanatory to me. I only see raw numbers, but no info whether all is good or not is visible there. Whats the goal of this view? How is that different to a image status report? or is that just a special report that got promoted to a top-level menu item? I must have been sleeping while responding previously. Please try digging deeper, there is much information on what is going on. In general there are three levels: 1) High-level matrix showing rootfs * hwpack combinations that were tested. Clicking on any combination moves you to level 2 2) A status page for each combination, this shows both the summary of the entire testing history (in the left part) as well as latests status (in the right part). Clicking on various items can either move you to level 3 (history of a particular test for this rootfs * hwpack) or to details page of a the latest test run. 3) Test history for the specified rootfs * hwpack. This shows _all_ the invocations of a particular test. You can easily see the number of failures, etc and how they were changing over time. + I tried to look at a few Reports, but the AJAX request never finishes for me After restarting apache2 I cannot reproduce this. + i get 500 internal errors when clicking on data views, like: http://validation.linaro.org/lava-server/dashboard/data-views/recent-test-runs-for-board-and-hwpack-and-rootfs-4/ I could reproduce this a few times (but there was nothing in the log file which is strange) but after restarting apache the page works flawlessly. I suspect that one of the apache processes could have some problems and whenever it served your connection you'd get some problems, perhaps the same problem is responsible for the issues in report pages above. I'll monitor the situation to see what's going on, if you can reproduce it again please tell me about it. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
validation.linaro.org/lava-server upgraded to 2011.07 packages
Hi. I just updated our validation server. If you spot any issues do not neglect to report them. Thanks. ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: lava-dispatcher extensions
On Sat, Jul 23, 2011 at 1:05 AM, David Schwarz david.schw...@calxeda.comwrote: Several of us at Calxeda have been working on extensions to lava-dispatcher with an eye toward using it as a general test management engine not just for individual platforms, but for whole clusters of machines as well. We've broken our extensions into three feature branches, which can be found at https://code.launchpad.net/~david-schwarz: [branch details removed] We'd be interested in any feedback anyone has about these features, our implementations, etc. Awesome work guys. I'll look at those branches in more detail first thing next week. I'm sure they will land very fast, glad to see you use LAVA :-) Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Django 1.3 and openid
Hi. While I was trying to get our docs published on readthedocs.org I stumbled on a odd thing. Apparently they use django 1.3 internally and our requirement on django 1.3 conflicts with that. I have quickly upgraded lava-server to use 1.3 and (surprisingly) all tests passed. I will play around with 1.3 to see if there are any issues that test suite does not spot. Apart from staticfiles transition (which I just realized can happen in parallel, as we can keep using staticfiles 0.3.4 and django 1.3 (and only transition to contrib.staticfiles or staticfiles 1.x when we wish) I found one issue: openid It seems that the openid backend we are using is somewhat outdated and does not implement the required interfaces. For 1.3 that's okay but 1.4 will not be compatible with that API any more. This causes three tests to be skipped, and a warning message to be logged. I was wondering how we should proceed: 1) Upgrade to latest django-openid-auth/openid in hopes that it works better. 2) Ignore the problem 3) Upgrade as in 1) and fix any missing issues. What do you guys think? ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Fwd: Re: ppas, version numbers, releases and validation.linaro.org
Forwarding at it got bounced (odd?)
-- Wiadomość oryginalna --
Temat: Re: ppas, version numbers, releases and validation.linaro.org
Data: Mon, 11 Jul 2011 11:35:46 +0200
Nadawca: Zygmunt Krynicki zygmunt.kryni...@linaro.org
Firma/Organizacja: Linaro
Adresat: Michael Hudson-Doyle michael.hud...@linaro.org
Kopia: linaro-...@linaro.org, paul.lar...@linaro.org
W dniu 11.07.2011 06:34, Michael Hudson-Doyle pisze:
Hi Paul Zygmunt ( others),
I spent a while today fixing a couple of bugs in lava-tool and in the
packaging of lava-server, and was wondering what the process should be
for getting them into the ~linaro-validation ppa and onto v.l.o
(although there's no particular urgency in getting these precise fixes
deployed, there will be changes that are more urgent).
In some sense these are basic debian packaging questions I guess. But
my understanding of the process is that it should go like this:
If there are upstream changes, make a new release (update the version in
__init__.py, tag the branch, make an sdist and upload it to pypi).
Agreed
Then (whether there is an upstream change or not) it should be uploaded
to a PPA. I think the part here that I don't really get is basically
how to use bzr build-deb in practice. But I've just found
http://jameswestby.net/bzr/builddeb/user_manual/merge.html so I think I
should read that first :)
I do bzr bd bzr bd -S followed by some pbuilder commands. Look at
.bzr-builder/ in each packaging branch.
Another question I have is around version numbers. Currently we're
using version numbers like 0.2-0ubuntu0~zyga1. I don't really see why
the zyga is in there :) I think simply dropping the zyga and using
versions like 0.2-0ubuntu0~1 would be fine, or if we want to know who
uploaded a particular version we can use things like
0.2-0ubuntu0~2mwhudson.
In short: ~zygaN is the thing we can increment. We should KEEP and
perhaps change the name to ~lava (but this has to be coordinated as
~lava ~zyga.
There are three possible scenarios which this system correctly handles:
1) We need a new release, the pattern is always the same:
${UPSTREAM}-0ubuntu0~${PACKAGE}${PACKAGE_VERSION}
Where PACKAGE is the marker (currently zyga) and PACKAGE_VERSION is
reset to 0 each time UPSTREAM changes.
2) Our packages land in Ubuntu. The version becomes:
${UPSTREAM}-0ubuntu${PACKAGE_VERSION}
Where PACKAGE_VERSION is = 1 (this is important to differentiate from
all of our internal releases
3) Our packages land in Debian. The version in Debian becomes:
${UPSTREAM}-${PACKAGE_VERSION}
The version in Ubuntu becomes/changes to:
${UPSTREAM}-${PACKAGE_VERSION}ubuntu${UBUNTU_PACKAGE_VERSION}
Where PACKAGE_VERSION is the one from Debian and UBUNTU_PACKAGE_VERSION
is something Ubuntu developers can increment.
Finally, I think that we should be triggerhappy about releases, and so
going through the above process shouldn't take very long. I guess
lava-dev-tool can help here.
Agreed. I will look at this problem this week, hopefully I'll resurrect
the package builder code.
Thanks
ZK
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Launch Control to LAVA migration script
Hi folks. I wrote this script that allows one to upgrade from l-c to lava-dashboard. The script is interactive due to debconf which we are currently stuck with. I tested it in several configurations on a snapshot of l-c 0.4.1 I would like to use this script in the migration guide, feedback welcome! Thanks ZK migrate-to-lava.sh Description: application/shellscript ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
lava-dev-tool + lava-server installation/development and local data
Hi. This is just a reminder for Michael but I think it's worth to share that to the rest of the validation team. When using lava-dev-tool to hack on lava-dashboard or any other component that is based on lava-server the location of the database and the actual data contained is easily lost. I think we need to stop using the development settings quickly and switch to django-debian based model where we just use a different configuration file for local development. This would make the testing environment much more similar to production (definitely django-debian would see more testing this way) and would help us locate and control application state. I would like to propose the following changes: When hacking lava-server would setup the following stuff (all relative to localenv root). /etc/lava-server/default_database.conf - location of the database /etc/lava-server/settings.conf - django-debian way to alter settings.py /var/lib/lava-server/media/ - upload root /var/lib/lava-server/static/ - django-staticfiles root /var/lib/lava-server/database.db (only when using sqlite) For postgresql (which I would like to use more by default) this is roughly the same except for default_database.conf pointing at something else than the file mentioned earlier. I'll see how I can make that happen in practice. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Renaming miscellaneous python projects that currently abuse linaro
Hi. I'd like to update you on the rename process: For linaro-json: This project started as a huge collection of tools for JSON but was later on refocused on one important thing - schema validation. Proposed names: - json-schema-validator This project has been renamed to json-schema-validator. PyPi: http://pypi.python.org/pypi/json-schema-validator/ Documentation: http://packages.python.org/json-schema-validator/ The old linaro_json is now frozen for development except for critical bug fixes (which I don't anticipate). Thanks. ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: implementing queues safely in (generic) SQL
W dniu 22.06.2011 00:21, Michael Hudson-Doyle pisze: Fortunately django almost never runs in autocommit mode. There is an implicit transaction around the whole request. It is easy to control the transaction processing around a piece of code, see [1]. I got very confused by this, I admit. In general, calling .save() on a model does a COMMIT, unless you're managing the transactions yourself (or using TransactionMiddleware)? Something like that. It's easier to read the source than read my explanations. django.db.models.base:Model.base_save() calls transaction.commit_unless_managed(). In practice, django is almost always managed so save is never commits. The transaction middleware you mentioned makes django views managed using commit_on_success decorator on the request method. You need to disable that manually and I don't see any reason why someone would such a thing. And of course, the way this is being done in the scheduler at the moment is not part of the web app, so the usual stuff doesn't always apply. On PostgreSQL we also need to properly implement handling of IngegrityError as it differs significantly from SQLite [2] It's just that it dooms transactions, right? Not really, it just makes supporting them a little trickier. I do that with deserialization of bundles. In practice it's quite easy if you remember to use save points correctly. See my 1-4 points below for explanation why. The approach we'll take on integrity errors is to rollback and retry so that's easy. You can rollback to a savepoint. (it's confusing that https://docs.djangoproject.com/en/dev/topics/db/transactions/#transaction-rollback says that the changes made by a.save() will be lost when the default is for .save() to commit, so they must be assuming that you're using TransactionMiddleware). It's not only transaction middleware. Any code that earlier (in the call history of a particular function) enabled transactions will behave this way. In reality this is all manageable: 1) Proper code will work regardless autocommit mode :-) 2) PostgreSQL does not break things, you just need to take account for savepoints. 3) Handling transactions manually implies you use savepoints and thus get 1 and 2 right. 4) Handling transactions automatically (around a view) implies you get shielded from most of the complexity, if your actual application logic is happy not to use explicit manual transactions in such cases. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Listing android tests in LAVA
W dniu 18.06.2011 11:07, Zygmunt Krynicki pisze: One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page. It is listed, unless I'm mistaken: http://validation.linaro.org/launch-control/dashboard/test-results/399109/ See the Android.URL below. Hey cool. Now if I can search and see all the test runs. I can make a report that will list all for you with links to test results. Let's do that on Monday. Hi, this was a very simple report, have a look. It shows the 10 most recent test runs of anything that has android.url attribute. http://validation.linaro.org/launch-control/dashboard/reports/android-runs/ Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
I'm unable to connect to IRC (xchat-gnome crashes)
Hi everyone. I'm online but my xchat-gnome is crashing on startup. I'm trying to figure out what might be causing this. zyga@W510:~$ gdb xchat-gnome GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/xchat-gnome...(no debugging symbols found)...done. (gdb) r Starting program: /usr/bin/xchat-gnome [Thread debugging using libthread_db enabled] [New Thread 0x7fffed6fe700 (LWP 5355)] [New Thread 0x7fffe2f8f700 (LWP 5356)] XChat CRITICAL *** default event text failed to build! Program received signal SIGABRT, Aborted. 0x73f65d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x73f65d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x73f69ab6 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x0045cfc0 in pevent_make_pntevts () #3 0x00460a0f in ?? () #4 0x00461535 in main () (gdb) Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Listing android tests in LAVA
W dniu 20.06.2011 10:50, Paul Sokolovsky pisze: Hi, this was a very simple report, have a look. It shows the 10 most recent test runs of anything that has android.url attribute. http://validation.linaro.org/launch-control/dashboard/reports/android-runs/ Just to remind, at https://android-build.linaro.org , there can be other build types besides Android platform, e.g. Android toolchain: https://android-build.linaro.org/jenkins/job/pfalcon_linaro-toolchain/ Err. I don't quite understand. Does it mean that android-build.linaro.org can build things other than android itself? I remember that at LDS I heard that you guys have input artifact classifier on the entry to Lava, so I hope you use it to differentiate among the builds. If you need any info for that from Android build system, let's discuss it. I have no knowledge of that. I currently list all TestRuns that have a custom attribute called 'android.url'. Have a look: http://bazaar.launchpad.net/~linaro-validation/lava-dashboard/data-views-and-reports/revision/18 Can you tell me if I should do some kind of filtering/processing? Thanks for letting me know about this ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Listing android tests in LAVA
W dniu 20.06.2011 11:20, Paul Sokolovsky pisze: Have a look: http://bazaar.launchpad.net/~linaro-validation/lava-dashboard/data-views-and-reports/revision/18 Can you tell me if I should do some kind of filtering/processing? Yes, apparently. Can you point me to the code which queues and sets 'android.url' attribute on a test input? I have no idea how that works. Paul Larson is the person to ask I think. It could be in the dispatcher code or in some local configuration for the dispatcher on validation.linaro.org. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA Dashboard user forum
W dniu 17.06.2011 23:50, Zach Pfeffer pisze: On 17 June 2011 11:45, Zygmunt Krynickizygmunt.kryni...@linaro.org wrote: W dniu 17.06.2011 18:24, Zach Pfeffer pisze: One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page. It is listed, unless I'm mistaken: http://validation.linaro.org/launch-control/dashboard/test-results/399109/ See the Android.URL below. Hey cool. Now if I can search and see all the test runs. I can make a report that will list all for you with links to test results. Let's do that on Monday. Ideally each build would trigger a test to be scheduled, results of each test should be uploaded to the dashboard. This way we could retain identity in all participating components. Yeah. Perhaps the android-build should just kick the test off. Is there a simple API to request this? Something like: test(build_url, target, type) Michael is working on the scheduler. He recently added API for submitting a job to the system. It's still some time before this can be used in production though. AFAIR there is no code that would take jobs and actually ask dispatchers to run them. ...and if the target it busy, we just skip the test and provide a link on the android-build site that lets you re-request? I'll file a bp for this. The scheduler will queue jobs. Once a dispatcher is idle it will simply run another test. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA Dashboard user forum
W dniu 17.06.2011 16:49, Fathi Boudra pisze: Why don't you use ask.linaro.org, a Linaro official provided service, instead of opening a personal forum dedicated to LAVA dashboard? Hi. I was not aware of ask.linaro.org, it looks much better than other options I considered. FYI: I have discussed this issue with asac and plars and we agreed to wait a few weeks and then decide on what to do. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA Dashboard user forum
W dniu 17.06.2011 18:24, Zach Pfeffer pisze: One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page. It is listed, unless I'm mistaken: http://validation.linaro.org/launch-control/dashboard/test-results/399109/ See the Android.URL below. Then I'd like to see a link from a android-build.linaro.org build like: https://android-build.linaro.org/builds/~linaro-android/leb-panda/ This is a little bit more complex. Whatever submits the result can build an URL to the result page on the dashboard. The problem is that the android build system has no knowledge of tests. Ideally each build would trigger a test to be scheduled, results of each test should be uploaded to the dashboard. This way we could retain identity in all participating components. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LAVA Dashboard user forum
Hello everyone. Since a few people started asking me questions about lava dashboard, reports and other things I though I we could benefit from sharing this knowledge. I created user forum for the dashboard at: http://fracture.suxx.pl/projects/lava-dashboard/boards Please go there and post questions you may have. You will need an account which you can quickly create here: http://fracture.suxx.pl/account/register I hope that will make the communication smoother. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA Dashboard user forum
W dniu 16.06.2011 00:19, Michael Hudson-Doyle pisze: I created user forum for the dashboard at: http://fracture.suxx.pl/projects/lava-dashboard/boards Is there a way I can subscribe via email? There's a watch icon in each thread/forum. AFAIK you will be notified of changes in the objects you subscribed to. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Design and implementation of lava-ci tool
W dniu 15.06.2011 22:49, Paul Larson pisze: But what about where other non-python packages need to be installed for it to work properly? That was the main thing I was trying to sort out? Does the recipe have a rule to do this? For building this knowledge is contained in the source package. Nothing new or special here (we can build all the debs in pbuilder after all). For development it will be provided by virtualenv (thanks to setup.py meta-data). The only thing that would not be provided are things that are not available on pypi such as usb utils for lava-test. This is a more complicated issue that I did not approach yet. We can observe the extreme when we consider that adb is something we kind-of require sometimes for some components. Thanks for pointing that out. In the case where post-install configuration is needed, does it point the user to instructions for how to do that? None of this is for end users. This is for developers of the lava stack and automatic testing of arbitrary collection of branches of said stack. We _can_ and _should_ document how to use it in practice though and I plan to do that :-) Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Design and implementation of lava-ci tool
of distributions and their status (default) - enable - Enable one or more distributions - disable- Disable one or more distributions - update - Update one or more distributions $ ./lava-ci package help Usage: lava-ci package [COMMAND] Summary: Manipulate source and binary packages Available commands: - srcpkg - Create a source package from a recipe - help - This message - show - Display list of packages and their status (default) - wipe - Remove all source and binary packages - sequence - Build a sequence of packages following - binpkg - Create binary packages from a source package A subset of the README file: lava-ci - CI and release tools for the LAVA project (and others). The purpose of this tool is to facilitate teamwork and monthly releases by automating the act of creating and testing a release from source repositories all the way to the binary packages for various platforms. Workflow example: *) Prepare recipe files (bzr help builder) for each maintained source package and put them in a bzr repository. Each recipe file *MUST* be named like the source package it builds. *) Use `lava-ci project init lp:BRANCH-WITH-RECIPES`. This will create .lava-ci directory and a local checkout of you recipes in the current directory. *) Use `lava-ci distro` to list the distributions you wish to target. For each one you are interested in do `lava-ci distro enable $distro`. For example to enable lucid and maverick you could use `lava-ci distro enable lucid maverick`. *) Use `lava-ci package` to list available packages (based on recipes). You can add/edit more just by creating additional *.recipe files. *) Use `lava-ci package src $package` to build source packages for the selected recipe. There will be one source package per distribution. You can check `lava-ci package [show]` to see what source packages are already available. *) Use `lava-ci package bin $package` to build binary packages for the selected recipe. Again there will be multiple builds, one for each distribution. Each build will result with a number of additional debian packages being produced. You can use those packages as build-dependencies of other packages you maintain, similar to a Lauchpad PPA. *) Write down a sequence of build operations to perform in and save it as `recipe/sequence`. This file should contain one word per line - the name of the source package to build. The order will depend on the build-dependencies among your packages. To test that building the whole sequence works do `lava-ci package wipe` followed by `lava-ci package sequence`. If the build succeeds you can tag your recipes as a working configuration and make a release. Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
lp:lava-server overwritten
Hello. I had to bzr push --overwrite lava-server. I did this to remove all the release tags we inherited from the dashboard. I also tagged this as release-0.1. Next time you push something make sure not to litter the tree with old launch-control tags. If bzr push complains about conflicting tags you know you did this ;-). Thanks Zygmunt ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: current status -- releases^H recipes needed
W dniu 07.06.2011 02:16, Zygmunt Krynicki pisze: I think at this point we should do some releases. If you agree Zygmunt, can you do that? (a) because it's nearly the end of my work day and (b) you're more experienced at it :) I guess this means uploading to pypi and building in a ppa? Do you upload releases to lp too? I'll release everything after I get myself together (staying up past 3AM again). Did this happen yet? It doesn't look like it. No :/ I got stuck making the process easier. I'll post details soon. I got unstuck but more work is required. I wrote something that assists ISV developers (like us) to develop, release and publish for multiple ubuntu versions efficiently. You can find the early version (in shell, yuck) at: lp:~zkrynicki/+junk/lava-project-ci. Have a look at the README file and at the recipes. Before you can start using this tool please build each pbuilder with lava-project-ci create $distro (for distro: lucid, maverick, natty). After that you can build the 'versiontools' package and see the recipes for more hints. I started porting all our packages over. I'll finish this tomorrow and finalize the release. HELP wanted here! Please port django (look at my code branches to lookup the relevant django backport) to speed up the process. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ANNOUNCE] dh_splitpackage 0.2.2
Hello everyone. I'd like to announce a new version of dh_splitpackage. This version improves documentation to a point where it's rather easy to get started and use this helper while packaging. A new manual page has been created with tool description documentation of all the command line options, configuration file schema, pattern matching extensions and many examples. Some additional changes to the actual script made it possible to build and work on Ubuntu Lucid 10.04 LTS. An Ubuntu PPA with this script is now available at [1]. In addition to this, a launchpad project has been registered to simplify development [2]. Finally the source tarball for the release has been uploaded to pypi [3]. (a copy of the initial announcement) I wrote dh_splitpackage, a helper script that unambiguously splits the files of a binary package into multiple packages based on a configuration file. The configuration file may point the primary package (the one that gets leftover files by default) as well as any number of additional packages with any number of inclusion and exclusion patterns. The new script can be called instead of dh_install (assuming all the files you are interested in are already in debian/tmp/) or afterwards. The biggest advantage compared to existing tools is clear and not-that-error-prone classification of files to packages. Any file that would be classified to more than one package (hitting patterns in both files) is clearly reported and prevents the package from building properly. In addition running the script displays each file from debian/tmp and the package it was classified to. Using this script could greatly simplify many packages that currently rely on numerous *.install files and custom dh_install overrides in debian/rules. Best regards Zygmunt Krynicki [1]: https://launchpad.net/~zkrynicki/+archive/dh-splitpackage [2]: http://launchpad.net/dh-splitpackage [3]: http://pypi.python.org/pypi/dh_splitpackage/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] dh_splitpackage 0.1
W dniu 03.06.2011 21:17, Evan Broder pisze: Ubuntu has gotten quite a bit of flack from the debhelper maintainer for making independent changes in the past ([1], [2]), and doing so again seems like a bad plan. Perhaps posting this from my @canonical.com address was a bad idea. I'm not doing this as a Canonical employee, nor as a ubuntu developer. I'm doing this as an upstream (actually working on Linaro tools) that uses Debian/Ubuntu as the delivery platform. My response below may seem to be quite harsh but I hope to keep it factual. For context. I wrote dh_splitpackage yesterday after being upset with dh_install and failing to find any packages that would do what I wanted easily. I did it while packaging the tools I'm developing daily so that my users can install them easily. Nothing in this has any relation to my employer, Canonical, Ubuntu or Linaro. I made this and the fault, if any, is mine. dh_install already has a --fail-missing option. It seems that this would cover half of your use case, To the best of my knowledge dh_install cannot do what I wish. Well, I could copy file by file, directory by directory, carefully observing the right paths, adding exclusion patterns and so on. That's not my goal. My goal is to split a package (which I understand as move each file from debian/tmp into the appropriate sub-package) easily, without too much, error-prone, shell scripting and without doubts I missed something and it's actually failing silently (or will fail silently when upstream files move around later). though I gather there are some outstanding issues with it ([3]). CDBS also has a list-missing target, though it doesn't seem that it can be made to fail the build, and also doesn't cover your overlapping files issue. See, that's not solving my problem. It seems like it would be much more productive to work with Joey to try and fix dh_install --fail-missing, and possibly add a new --fail-on-overlap option or something. Productive for who? I never even knew Joey (no disrespect to him). I solved my problem and shared the solution. My problem is solved. Better yet, I did not make the general problem worse. Look at this as a contribution to possible pool of solutions that the greater Debian community may choose to adopt. But in any case, I think that adding a new debhelper script without consulting Joey at all will hurt Ubuntu's image in Debian's eyes, and that's a bad thing. I'm sorry I did not know Joey. Perhaps if I was working on packaging lots of 3rd party software I would get know him eventually. Should that prevent me (or anyone) from coming up with a good technical solution to a problem? Even if dh_splitpackage will rot in the internet archive it _did_ solve my problem and I _did_ share the solution hoping for the best. Now for some rants of my own: Let's play a game that I did knew Joey or other dh_* maintainers. IMHO engaging in platform development would be pointless. It might end up being political. It would most likely drag on and on, possibly never reaching a consensus. It might require me to rewrite the script in perl, shell or another language. And it could easily fail. Why would I engage in any of that? Why would any upstream do? (and see how friendly upstream I am to even share my solution with anyone, do you think random upstream developer would?). Debian is an insanely complex political being, with many rules that are fully versed only by people that dwell in this environment for many years. That's not a good ISV environment. Perhaps this is not a popular view but IMHO it's rather true (why would I be writing this email otherwise?) Getting involved in fixing the platform the way Debian maintainers and many of my colleagues at Canonical do would be diverging from my goals. I'm an upstream working on a project. This project is not Debian. Getting involved with Debian, dh_* maintainers, authors and contributors, while noble, would prevent me from attaining my goal on a predictable and timely basis, which is to get the software I'm working on into the hands of my users. End of rant. Now I understand that you had no bad intentions towards me and this is all caused by me posting from @canonical.com without giving any kind of explanation on why I did this. Sincerely Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ANNOUNCE] dh_splitpackage 0.1
Hello everyone. I wrote dh_splitpackage, a helper script that unambiguously splits the files of a binary package into multiple packages based on a configuration file. The configuration file may point the primary package (the one that gets leftover files by default) as well as any number of additional packages with any number of inclusion and exclusion patterns. The new script can be called instead of dh_install (assuming all the files you are interested in are already in debian/tmp/) or afterwards. The biggest advantage compared to existing tools is clear and not-that-error-prone classification of files to packages. Any file that would be classified to more than one package (hitting patterns in both files) is clearly reported and prevents the package from building properly. In addition running the script displays each file from debian/tmp and the package it was classified to. Using this script could greatly simplify many packages that currently rely on numerous *.install files and custom dh_install overrides in debian/rules. You can find the code at lp:~zkrynicki/+junk/dh_splitpackage (tag: release-0.1) The source tree also includes debian packaging that makes use of the new script. Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: reorganzing the lava projects on launchpad
W dniu 01.06.2011 09:56, Paul Larson pisze: Any good suggestions for a new name for abrek? I don't want to encourage bike shedding on this, so unless someone has a much better suggestion, I would suggest we just go with lava-test (skip the -tool) and be done with it. I like lava-test (despite not following foo-tool) ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: designing the scheduler command line api
W dniu 30.05.2011 06:54, Michael Hudson-Doyle pisze: Hi all, $ lava-tool submit-job --farm https://mwhudson:$to...@validation.linaro.org test.json This could then remember, bzr style, that it's is the farm you want to talk to. Unlike bzr the knowledge would be global (per user) so it would be stored in ~/.config/lava/... (unlike in git/bzr in some local directory). This is clearly a bad idea though: tokens will be long and unwieldy and passing it on the command line means they will be disclosed in ways that we should avoid (they'll appear in ps output for all users and could easily end up in log files). For a brief moment, yes. IMHO we should not care about this. If you want 'ps privacy' you can do that on a system wide level. If we really want we can supply some argument that will trigger /dev/tty interaction. $ lava-tool submit-job --farm https://mwhud...@validation.linaro.org test.json --token Token for mwhud...@validation.linaro.org: *** So we need a way of storing tokens. The easiest thing to do would be to store a token for a (username, host) pair, so you'd run a command like: IMHO that should be python-keyring. Let's not reinvent .netrc again. I guess the point I've argued myself to here is that I should implement this long form for now, and if a need arises add more conveniences (for example, reading from an environment variable or adding a command to set the defaults). Does anyone disagree too strongly with that? Yeah. One more thing to think about though. Should lava-tool have per-command auth support (as in your examples above) or some side-band subcommands for auth that would be implicitly picked up by other commands (lava-tool auth ... lava-tool submit-job ... VS lava-tool submit-job --auth-option ...) Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: designing the scheduler command line api
W dniu 30.05.2011 16:35, Christian Robottom Reis pisze: Storing a default (on first use, maybe?) seems sensible: lava-tool submit-job --farm $myfarm Storing https://mwhud...@validation.linaro.org in ~/.lava/default You obviously meant to say: Storing https://mwhud...@validation.linaro.org in ~/.config/lava/settings.conf Let's not add another dot directory to ~. XDG config directories are far better for users and of no real change for developers. lava-tool submit-job Using https://mwhud...@validation.linaro.org from ~/.lava/default How does that look? I like it, let's do it Michael, would you like to do client-side auth or should I do it? Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: designing the scheduler command line api
W dniu 30.05.2011 19:04, Alexander Sack pisze: I prefer the ability to explicitly register shortnames for farms like I proposed further above. We can also have a shortname default or so that would be used if you don't provide a --farm short-name ;). +1 Was there any argument against having shortname feature? or did you guys just ignore me ;)? Just missed that, sorry. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
lava-dashboard and lava-server and beyond
Hi I finally made lava-dashboard run on lava-server. The relevant code is in lp:lava-server (trunk) and in lp:~zkrynicki/lava-dashboard/zyga (merge request). Feel free to look at the request to see if I did some accidental edits (bzr commit --interactive does not work for me on bzr 2.4 :-( The next step is to make development smooth by packaging prerequisites (a few new packages are needed both in debian and pypi) and sorting out setup-dev-env.sh I'm considering rewriting setup-dev-env.sh to be .py file that calls into extensions to set themselves up properly but it may be non-trivial. I'll see how it will work, if you have any suggestions feel free to say so. If nothing breaks tomorrow I'll release lava-server 0.1 and lava-dashboard 0.5 and start 11.06 cycle. Initial stories plus a few tasks are listed here: http://fracture.suxx.pl/rb/taskboards/12 I'll be adding more items to that as I sort out priorities with plars this evening. Michael: when can we expect the shuffle of launchpad projects? Are we staying with lava-server and lava-dashboard and abandoning launch-control? Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Blueprint dilemma: validation website vs dashboard improvements
Hi guys. After looking hard at those blueprints and our discussions during UDS I'm getting this impression that the line between the two is blurred. It would significantly to frame the problem help if we could determine the architecture of validation website and how it differs from lava (especially after we did lava-server), where it ends up being (which project?) and so on. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The need for more verbose work item updates
W dniu 24.05.2011 20:55, James Westby pisze: On Tue, 24 May 2011 18:36:18 +0100, Dave Martindave.mar...@linaro.org wrote: It really feels like it could be time to promote the work items to a real entity in launchpad. Has this been discussed before? Many times. It's not something that the Launchpad team is likely to work on at all this year, even if there was consensus on what should be done. And this is why we should not keep being stuck with Launchpad. The Infastructure team could work on it, if it is high enough priority, but it doesn't seem to me that we have reached that point yet. A better solution may be to stop using the whiteboards and just have everyone manipulate status.linaro.org directly. That's a fair chunk of work itself though, and again it needs to be high enough priority to beat out other things. Or we could just deploy Redmine and wait, less painfully, till Launchpad becomes a better productivity suite for teams of developers that are NOT working on a distribution. In addition, I'm wary of adding lots of extra features to workitems, as I feel they tend to be symptomatic of trying to load up engineers with too much process. We should always be careful to balance the desire for more information with the overhead that it causes. You can say that the features are optional, but having them there will always push people towards using them. While I agree with you completely about not throwing too much process at developers I need to stress not having a first-class work item object means we have no real tool, just a gimmick. We should absolutely have work item history, we should also be allowed to grow from a simple one-line work item to something more resembling real tasks, with comments, code references, rich state changes, full history and participation of any number of people. I know I'm biased here but Redmine provided all of that one year ago when we started and it still does today. Let's use it! It has all the right APIs for talking to status.linaro.org so we could retain our custom tools. (shameless advertisement below) If anyone is interested in Redmine (or just heard of it now) feel free to access my personal instance at http://fracture.suxx.pl/. In particular I would encourage *everyone* to look at my work item rooster at: http://fracture.suxx.pl/rb/taskboards/11 Each item there is a full-fledged task with all the features of a launchpad bug and more. I can just drag them around to indicate I'm done working on something. I can click on the task number to access the full rich state. If anyone is interested in _experimenting_ with this feel free to sign-in with your launchpad and either start a new project or ping me for being added to a group to work on validation projects). Note: Redmine is not perfect by any means but it's hands down _better_ at solving blueprints + work items than Launchpad ever was. Best regards Zygmunt Krynicki. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro development cycle thoughts
W dniu 17.05.2011 10:54, Alexandros Frantzis pisze: Hi all, I completely missed the Linaro release process session during LDS, but here are my thoughts on the Linaro development cycle. Currently, the Linaro cycle lags behind the Ubuntu cycle by one month. This is done so that the Linaro releases are based on a stable system. Unfortunately, this scheme causes some disruption for me (and I suspect for other engineers, too). The problem is that while the current Linaro cycle is still ongoing, we need to start planning for next-cycle/LDS, attend LDS and after that investigate some more and create the specifications. This is hard and time consuming work and I am sure not many people (including me) can continue to work effectively on their remaining work items while drafting specifications or attending LDS. The problem is exacerbated further because the end of cycle is usually a very strenuous period for engineers. So my questions/suggestions are: 1. Do other engineers feel this way? Yes. I think that linaro has 5-month cycle with one month squandered on LDS, blueprints and catch-up with the previous release where we are still (supposedly) going to make improvements. I would rather have the very same cycle or even one cycle _before_ Ubuntu ships so that by the time we're at UDS we can have a UDS/sprint hybrid where we already discussed some things earlier, already have some blueprints and code rolling. 2. From people's experience, has the one-month-after-ubuntu schedule provided concrete advantages? Could we get away with less (e.g. one week)? From my point of view it's hard to judge as Validation is strictly outside the main archive, kernel and toolchain where we mostly interact with our Ubuntu brethren. It is however interesting to consider how our cycle would impact Ubuntu if _all_ of Linaro were really releasing once a month. Thoughts? Thanks for bringing this up Alf :-) Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Display setups on your work desks
W dniu 06.05.2011 10:27, Marcin Juszkiewicz pisze: Hi I would like to ask about your display setups on work desks because recent changes in pandaboard kernel moves me into 'lets buy another lcd' direction... Switching ports on panda requires powering it off in order to not damage it. Guessing which port works is not a way. Connecting panda HDMI to 24 HDMI is also no solution cause this will leave me without display for my desktop. How you people solve that in other way then buying yet-another-lcd? I've got ATEN CS1794 HDMI+USB KVM available here [1]. It comes with 4 fat cables for connecting HDMI, USB, Sound IN/OUT, is quite compact and optionally rack-mountable. I use it to drive my monitor+USB hub and switch between my laptop, beagle, helper desktop and PS3. 1: http://www.aten.com/products/productItem.php?pid=20090211152610001psid=20070130114411002pcid=20070130111333003layerid=subClass3 Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Display setups on your work desks
W dniu 06.05.2011 12:12, James Tunnicliffe pisze: Yes, it is two buttons to press instead of one, but having a real USB switcher instead of a KVM solution where you can only switch a mouse and keyboard (the set up I have) sounds great to me. The KVM I mentioned has full selective switching support, I can plug a thumb drive to device A, sound to device B, display to device C and input to device D. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LTP test result collecting
W dniu 02.05.2011 10:59, Shawn Guo pisze: I'm drafting the blueprint [1], and need your favors to collect LTP (Linux Test Project [2]) result on boards that Linaro supports with Natty kernel running on. Have you seen abrek, launch-control and lava? You can run LTP via abrek on any board, submit results to launch-control, automate the whole process with lava and poke at the results to create reports with launch-control dashboard. http://validation.linaro.org/ Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
IMPORTANT: Upgrade instructions for launch-control 0.3~c10
IMPORTANT: If you have your own instance of 0.3 deployed from .debs please read on. Hello. This email contains upgrade instructions for 0.3~c9 - 0.3~c10 upgrade. The upgrade process is not automatic due to django-debian maintainer script backwards-incompatible change. This had to be done because of design bug I discovered while attempting to implement south support. UPGRADE INSTRUCTIONS: 0) Optional step: backup your database (pgdump or copy the sqlite file) 1) Backup database settings: /etc/dbconfig-common/launch-control.conf /etc/launch-control/default-database.conf 2) Upgrade maintainer script support library from the PPA. Install 0.5~c1 of django-debian and python-django-debian 3) Upgrade launch-control to transitional 0.3~c10 from the PPA. First install 0.3~c10 of launch-control and launch-control-$backend (where backend is sqlite or pgsql) Maintainer script will ask you if you want to reinstall database, SAY NO here. At this stage your database settings are lost due to, unfortunately mandatory, django-debian redesign (due to design flaw). 4) Recover two files you backed up earlier. Just copy them over. 5) Reconfigure launch-control. Run sudo dpkg-reconfigure launch-control, this should not ask anything, syslog should have a lot of details about what's happened. 6) Remove legacy configuration directory: rm -rf /etc/django-debian/ Verify that everything works as before. If you encounter any problems please let me know, thanks Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
I'm away today.
Hi everyone. Unfortunately I have to attend my young ones to the hospital. I will take a swap day for Saturday once we return. Best regards Zygmunt ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Packaging Django applications and projects
(AFAIR) be treated equally as upgrade failure. That's rather extreme IMHO. I'd rather require that applications can be safely upgraded because the system will create appropriate database/media files backups before it triggers the process. Data: I like to differentiate between data supporting the package and data that belongs to the sysadmin/site. IMO the former belongs in /var somewhere and the latter at a path chosen by the sysadmin. I don't think this is gotten right by much software, including by all database packages. How do you differentiate which data belongs to the sysadmin/site and which to the package? Do I understand correctly that user-submitted content is application data and static resources are package data? Thanks for the feedback! Zygmunt Krynicki [1] http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html#s-httpd-location ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Monthly component release candidate dates
W dniu 01.03.2011 16:49, Jamie Bennett pisze: Please take a look at the dates and highlight any problems that could arise from them. If there is positive feedback we can make these dates 'official' very soon meaning teams could start using this format next month. Sice having no planned releases is worse than having hardcoded release pattern I'm all for having monthly pulse that synchronizes all of Linaro outputs (speaking for my point of view in the validation team) Even if initially it would not be any more productive I'm sure it would help us align in few months. If anything we could plan features so that they make more sense in context (having an option to do A then B we can choose at random or have a look at what would be released next month by other teams and if A or B would fit better in context). Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please review blueprint linaro-n-validation-job-dispatcher
On 02/17/2011 11:28 AM, Spring Zhang wrote: Hi, Paul, For the python environment in the deployed test image, how much support will it provide? Can we deploy additional python libs to the test image if required? Dispatcher client part may need some. What dependencies are you thinking of? IMHO when the client is present on the device we can assume normal system and be okay with most dependencies. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] agent-based remote validation invocation for LAVA
W dniu 16.02.2011 15:10, Paul Larson pisze: Another crazy option would be to expose LAVA Job Dispatcher directly and allow people to run jobs. In this case one job I hope you don't really think this is a crazy idea, because it's *exactly* what we discussed doing, and I think it is still the direction I did not give it much thought when I wrote that email but I think the direction is sensible and would be much more flexible than anything else. After more conversations and some experiments I think this is the way forward for all testing. forward. Even back at the sprint, we talked about the fact that though we don't know exactly what our android images will look like yet (so specifics are hard to plan around), we do have a pretty good idea that things like abrek are not going to be a good fit there. Additionally, there are other tests that may eventually need to run from the outside. For that matter, the boot test itself is exactly one of those things. If a system doesn't boot, we still want to capture the serial log and save it for later debugging. We certainly need, and have already discussed the fact that the dispatcher has a server component that drives execution of such things. This isn't, in any way, bypassing the dispatcher, but rather using a different interface of it to run a non-abrek based test. Yeah, when you mentioned this now I started thinking. Do we really need a daemon-like component for the dispatcher in general or just in the farm environment. Can we assume that having the implementation the daemon can be replaced with a command line tool that simply interacts with one device - strictly for development purpose? I'm thinking about stuff like volatile device state and device monitoring requirements. Other than that it seems that our device overwatch + dispatcher looks quite similar to android debug bridge. I think this is good. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] agent-based remote validation invocation for LAVA
W dniu 15.02.2011 21:01, Jim Huang pisze: Hi Jim, great work! ** Why can't we execute LAVA/Abrek directly on Android devices? I agree that direct abrek is not the right solution for Android. I think there is a class of use cases that also falls into this category: * testing early silicon * testing very primitive systems * testing other foreign systems They all have either no python or running python is not desirable. ** So, what's agent-based remote validation invocation for LAVA? There are three key items: (a) Agent (b) Remote validation invocation (c) LAVA We keep in mind that we make no technical impact to LAVA architecture, and the Agent is just the helper. Originally, the client-server communication looks like the following: LAVA server LAVA client -- Abrek test suite Currently LAVA is just taking shape. Things like server and client are still not very well defined. You don't have to be constrained by this. The only thing that is somewhat well defined is abrek that was produced in the previous cycle. Abrek was designed to run _on_ the device. For use cases where Abrek is just interacting with the test device we may want to extend it sensibly to clearly separate those cases where necessary while retaining as much common code and user interface as possible. There are a few things to consider here: Device context: Currently abrek has some logic to probe the running system for context information. Context is loosely defined as the collection of relevant software and hardware information that might be interesting to analyze or that can be used to connect distinct test results in post-process analysis. If we are just interacting with a remote device we need to determine this information in some other way _and_ ensure we're not adding any dummy information from the host system. Remote device registration: A single host may talk to possibly large number of such devices. At the very least we should plan how we intend to manage the process of defining/adding/removing a device and how to allow remote tests to be invoked on registered devices, if possible (if the device supports this test). Test classes: So far abrek tests could run on any Linux box (where any was poorly defined as any ubuntu-like system. This is no longer the case so we should be able to classify tests (and devices) somehow. IMHO we could define a new tool (or just a new sub-command class for abrek), say abrek-remote that will be used instead of the normal abrek call. Another crazy option would be to expose LAVA Job Dispatcher directly and allow people to run jobs. In this case one job would use abrek and some other tools to invoke tests, process results and send them to the dashboard while other job (one for android) would not run abrek at all, instead it would call some other helper, while still reusing identical components for process results and send to result storage phases. This is still in flux but has some advantages: 0) Jobs are simple text files that can be stored and shared with others 1) Jobs can encapsulate device information like which android device to connect to and how. 2) Jobs can still call to other parts of the LAVA stack such as result submission 3) Jobs can be extended locally (by LAVA plugins) so that anyone can develop specialized use cases for their very specific needs without altering the stack or having to write something completely custom. Another upside is that such job definitions (and any required LAVA plugins) would just integrate with the rest of LAVA (farm backend, frontend, etc). You could work on a job description on your workstation and once it's finished you could add it to a job scheduler for automatic processing. ** Show me the use case The attached patch is just trivial proof-of concept implementation done by Jeremy Chang that adds a 'monkey' test definition file for abrek. Once TCP/IP or USB is ready, for Android's monkey testing, the procedure is like as following: (1) abrek run monkey (2) abrek dashboard put /anonymous/ monkey1297752359.0 Could you please forgive my android ignorance and tell me how I can run this test? Please include any hardware/software I should have. Can I run this on a beagle board with some android installation? Do I need a real android phone? This is just so that I can participate in the discussion and not make clueless and pointless arguments later. Any suggestion is appreciated. Thank you in advance. I hope we can work on making this solid. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: v4l2 vs omx for camera
On 09.02.2011 08:34, Hans Verkuil wrote: On Wednesday, February 09, 2011 07:23:49 Subash Patel wrote: In the reference architecture in ppt, we can directly wait for the RSZ interrupt, if we configure the hardware pipe. It was my mis-understanding as each of those hardware blocks can deliver interrupts too. In that way ARM needs to just work at finished frame, like forward it to the display or codec engine etc. V4L2 can be easily used for such hardware architecture. What hardware are you developing for anyway? If it is Samsung hardware, then you should be aware that Samsung Poland is doing a lot of work in V4L2 to add support to the s5p SoC series. I know a lot of people from the polish RD office. A lot of them work in the open hacking on the kernel daily. Perhaps we should contact them and encourage them to work with us more closely. Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Lava: Scope
W dniu 08.02.2011 17:48, Paul Miles pisze: Greetings Linaro-dev, I have joined the mailing list today and as a newbie Codethink(er) I am looking at contributing around the Linaro Validation area, especially Lava. My background is as a programme manager, generally around embedded mobile and have just completed a significant webkit based development project. First up on Linaro I have been digesting blueprints to get a feel for the Lava project scope and produce a system use-case (or story) list. The blueprints are not really giving me a system level picture that pulls together all the threads at the moment. Once I get this I can then spot some gaps where we can add value. Typical questions I am trying to answer are: Hi, Welcome! What Mechanism is used by the community member to trigger/request an evaluation run? None, we're not planning that right now. What needs to be provided by the community member in the evaluation package? What is the minimum? What will be present on the boards? Will the test run content be configurable by the evaluation requester? Lots of questions here. Technically our system will be able (it's not running yet) run jobs. Jobs are described by a bunch of data attributes (it's not approved yet, it might still change during the development stage as we implement the components and see how they work together. Currently the job will be able to specify hardware and software required (that's fuzzy but it's the general idea) and a set of tests to perform where tests are pluggable and can be defined by the end users via our framework. Finally the results need to be processed in certain way to fit our outgoing format and then be stored in a designated results repository. To this end, is there a Lava system-level requirement/scope? I have come across Linaro burn-down graphs, so maybe there is a Scrum type requirements backlog I can pick up on. Jump to #linaro on freenode and grab me (zyga) or paul larson (plars) Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Please review other-linaro-n-test-result-display-in-launch-control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I'd like to get your feedback on this blueprint: https://blueprints.edge.launchpad.net/linaro/+spec/other-linaro-n-test-result-display-in-launch-control Thanks Zygmunt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2+VfAAoJEKkR4hQBRI+lqgwH/2R7UlgDRnLdqTeEq0V2CUhz qa/v1TgAXMKXOp86hjBk8/sojS6gIbRJ5iEAdytNB8BR4/rqadZKlyh0IiZSF1uv zt0Rpg/+yhkjpnuFBxPqyBa5Z/Z2X+nuqIZQcvmINzyB8c1VgaQi902neuBs3iUb QkLcIGpCNZ6re0/XpW4pJLin9FkOq59Lkvc5kZ3WJH8G7Gtd38jVTQ4xBjT69qQT Z3OJplEZ29MVTyfgRkwDMUB+PjAd/1S2kAndfJJFb/KDNFjRLrBSSCCB4/5QXrWF xT7C8TmeyMbnMI7LY8a73mheERX+pGYdgqKGY8weiuW7ohEiTk0k79wW+eNUaaA= =eLf1 -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Dashboard API authentication issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 14.10.2010 04:19, Michael Hudson pisze: It has to be said, I'm not sure the aesthetic appeal of oauth outweigh these costs. It smells a bit overengineered. Alternatives? 1) We need to allow users to authenticate before we allow them to upload test results (bundles) to certain directories (bundle streams) in a simple and efficient manner (client side code matters) Is this all we want? As salgado asked in another mail, where is this API going? Currently that's the only thing we _require_. We will want more things but I'd like to solve one problem at a time. 2) Currently our only client is abrek Is this going to change? Most likely it's going to grow to more programs. I'd like to ship an official client-side library that programs like abrek can use to be isolated from how we do stuff internally. 3) We'd like to offer this very quickly, definitely before the UDS I don't think we should allow time pressures to force us into a bad decision. That said, I'm not sure the decision being made here is necessarily that bad to get wrong at this stage. While I agree I also value the act of shipping useful stuff even if we need to clean some bits up later on. Having said that, I don't think the bad scenario is that wrong either. Having said that let's look at the options we have: A) Continue hacking oauth in good faith that it'll work as intended without falling apart/being insecure/being hard to deploy/missing deadlines. I think the tone of your voice suggests you don't like this plan :-) If I used oauth before and knew if like the back of my hand I'd be more optimistic here. My primary concern is that 1) we'll miss deadline 2) it's not going to be pretty on the client side 3) we'll get it wrong somewhere. Some other points to consider: 1) Offspring nee lexbuilder also has an XML-RPC interface (cody, please correct me if I'm wrong) and we should align the technology if possible I don't really see the value in this, tbh. If cody has to solve the same problem then we could at least share the solution later on. Given that UDS is so soon, is there much value on working on it furiously before UDS, where the real requirements might become clear? Having authentication doesn't seem a requirement for doing demos at the summit to me. I think it solves an important aspect of having some sensibility to how we push our data. Currently anyone can push anything anywhere. That's just bad IMHO. It's not devastating but not something I'd like to give. Regards ZK -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMtrX3AAoJEKkR4hQBRI+lS1IIAKih0+coeq+UsFzSVl5aHbe0 kryGTi8VLbUZz6MYhgS0hu3kHqTOEHpZButZU0IwFs0GF15/Zvwgcmc77EhivjLe NA1ItPFR4KvvDc1HK2tYnCQkLL/yRsHn5rH671RfLy2hiP6nVz4kiICiexD+n7nd rD/uUfx9XFmUcRG5REsbSLw5Y0FZCfC51kncKtMi5Y8818zQz3DoFxn33Gn8HWyj t2ZY9dfp7IPJ9V/LlhSLsTV1to50NRghQaASI30MTwBjrj3+Ue8j+XnWXoSuVzmh GkT2NDU8Er2bfdDwcUWNkX7QH+hpOhnTMhwv36Y1fBZtyrpw84p9o3W4YLpiMn0= =AsxF -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Dashboard API authentication issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 13.10.2010 19:52, James Westby pisze: On Wed, 13 Oct 2010 12:35:54 -0300, Guilherme Salgado salg...@canonical.com wrote: I think we can use existing libraries (python-oauth and lazr.authentication) and follow the examples of Canonical django projects that support OAuth, to support OAuth on launch-control. However, given that the deadline is very close, the alternative you propose above might be acceptable if the API is served over HTTPS. lazr.authentication is fairly nice, but also fairly minimal. What is missing from the combination of python-oauth and lazr.authentication is the models for storing tokens etc. via the Django ORM. We could extract those parts from canonical-identity-provider in to a new app, which would be of use to everyone that wants to do this. What I like about the lazr.authentication solution is that it integrates with the Django auth system in that you just get a request.user that you can check as you like. Plain django-oauth and django-piston don't seem to have that, and I'd like to keep that separation of concerns if possible. I think that given that most of the code for the lazr.authentication based solution already exists we could deliver something by Tuesday, but we still don't have an answer to the question of external dependencies. If we work together we might do that. Don't worry about external dependencies yet. If it works we'll worry about solving that problem. Zygmunt, have you discussed that question with Spike? Does anyone else know what IS would prefer there? No but that's a good idea. I'll talk with him about this today. Thanks ZK -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMtreHAAoJEKkR4hQBRI+liZAIAMInd8ClTX6NB7LJS+3nDM52 WHkKEvRCCGWft/xWeib7NTMyaOW6xJD4rWBc6nFYjn4HByjo+Y/v8gxJHtN6e2TA UjRzn0OEG1Twz17emvfnx/SzoP3VtpFfUIGEYlyRjbyDR2gZc1o3C1hOwgon9cs+ 27gimWPP2sxyD7v7uxNb8hnhhR7R1v9STInohQkYp+wdYrQNFRgpLY0QllvNFzqC xg1/ewbWwplkotzLRWuLlTocuqIpYTZbAcFZHMS+Mvfc3F019FwIwOysLJSdNk/s 8v3JBzjn5Nm17nB50Gyvu/YVcxg2Ubpuv4W27xPlsLEN6v0cK790XTA4wIvBYYk= =P9pt -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Dashboard API authentication issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. As you know we've been trying to deliver an authenticated interface for the dashboard for quite some time now without success. Recently we've decided to add oauth support to the current XML-RPC interface we have. James implemented a rough support for this here [1] but it's not clear that we should accept this work yet. To quote James there are some issues with it today: 1. This relies on an external project that is unpackaged at this time. 2. That external project ships a patched embedded copy of python-oauth, though I don't know what the patches are for. 3. That project requires consumers to be pre-registered, and I'm not sure we want that. It would be possible to work around it, but would require some work. 4. I'm not sure I have the Resource stuff correct in this branch. 5. I'm not convinced that I have thought through all the corners and so there may be security holes. 6. There is nothing so far for the view to know if the request is oauth, which consumer it is etc., and no support for differing token access levels. We won't need any of that right away, but if we want that then django-piston may be the way to go rather than adding all of that. All in all those issues make me think that it's not as easy as we assumed and we should pursue another path. Before we do that let's summarize our current needs and priorities: 1) We need to allow users to authenticate before we allow them to upload test results (bundles) to certain directories (bundle streams) in a simple and efficient manner (client side code matters) 2) Currently our only client is abrek 3) We'd like to offer this very quickly, definitely before the UDS Having said that let's look at the options we have: A) Continue hacking oauth in good faith that it'll work as intended without falling apart/being insecure/being hard to deploy/missing deadlines. B) Fall back to one of the B-plans: B1) use something other than oauth (like HTTP digest authentication) B2) use something entirely different like: B2.1) django-piston B2.2) lazr.restful B2.1 (piston) cannot directly replace our current API as it does not support named methods (it only has CREATE/READ/UPDATE/DELETE). The upsides are that is seems to support oauth out of the box. The downside is that it's not packaged (at least properly on lucid which we target). We'd also have to pick a client-side library to use (lazr.resful most likely but I'm not sure really). We're also not sure if they work together out of the box. B2.2 (lazr-restful) might work but I don't know anything about it. Some other points to consider: 1) Offspring nee lexbuilder also has an XML-RPC interface (cody, please correct me if I'm wrong) and we should align the technology if possible 2) We're not sure if we need full API but we're not sure that we don't need it either. Currently our _only_ requirement is to allow people to submit test results in whatever means necessary. 3) Having looked at various web APIs it seems that passing an API key is a common practice. While not as fancy as oauth perhaps we should consider this. Having said that I'd like to propose my opinion: 1) Postpone oauth for UDS milestone (7 days left) 2) Work on alternative scheme that can be integrated with abrek easily in time for release 3) Continue on oauth path in a longer cycle (while retaining current interface). Thanks ZK [1] https://code.edge.launchpad.net/~james-w/launch-control/oauth/+merge/38013 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMtKqqAAoJEKkR4hQBRI+lRzAIAJGtprqkZqdbP7+bOLar2JNM N9Q1vWHcGfp7BLhG/Cvu30w5jBvyQ0+CKfVUbyBBE8Ig3v2/jbGfZRC5c4t38c0B 9WD7i6COk/KiMN2rPzv6PPgoLhiA7tpxhajNA/rzYQJU3HIDIe1O12rnC+xCBdfp FuzqeKISIuUBKGSI/TUdZx1z0PTIE9bEr+6Cr1es+6XRZvav+vkbIotIqJWJfxmj oxUbfYU92Q7VzxpxMuxZQz8a1DFMuckkIRT4Goh17WFXZYcFgr9jMLgKwiJWytos WIGQLZWJXo++GZC83585yGd2yMlzyP0iF0KocDPQtwPW9bZCVxyYMBK55PLUJw4= =OKuR -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Launch Control 0.2 feature plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I'd like to discuss my plans for 0.2 release for the validation dashboard a.k.a. launch control. I would like to have a roughly two-week development cycle. This will ensure that we don't get carried away with large features taking lots of time without planning them ahead of time. I would also like each release to feature some user-visible improvements (features or bug fixes) as well as backend infrastructure improvements (better tests, better internals, new feature elements that take 1 cycle to develop). I would like to reuse the proposal laid out by James Westby that defines how the infrastructure team plans future work and mix it a little with the original blueprint for the dashboard. What this means in practice is that each release should bring us closer to the feature set outlined in the blueprint _and_ introduce features/changes requested via the stakeholder process. I think this will work fine until we finish all of the features originating in the blueprint. For the upcoming 0.2 release (currently scheduled exactly two weeks after 0.1) I'd like to focus on the following topics: * Support for migrations south. South allows us to change the database on upgrades and plays nice with distributed version control. South is like rails migrations and is in general a very good thing. Without it we will soon start rolling out upgrade scripts that are just an ugly reimplementation of the idea. * Support for background (asynchronous) bundle processing. Currently the bundle is deserialized immediately during the put() request. This does not scale very well and we should really do this in the background. There are several solutions on how to implement background processing for Django apps and I'd like to select something _really_ simple until it is obvious we need more. There is a project called django-chronograph that essentially allows to use cron-like tasks inside django. Chronograph itself is triggered from cron (or some other external cron-like program) and then proceeds to process jobs defined within django apps. For this cycle I'd like to add chronograph dependency and move deserialization into a periodic task. * Better information about failed bundle imports. Currently there are some issues with the way databrowse application works (it seems to choke on OneToOne fields and GeneralRelation fields. This makes it impossible (AFAIR) to navigate to bundle deserialization information from the bundle itself and in general makes it hard to know what went wrong. I'd like to provide a basic set of views that show streams and bundles and provide a clear indication of deserialization errors there. This would be based on existing work on bundle stream views so it should fit in this cycle. * Better unit tests for django views. As discussed with James Westby we should have several approaches to each view we offer. We should test for the contents of the django rendering context (the data that goes in the template) _and_ scrub some of the HTML output to see we didn't make a typo in the template or other similar issue. In general we should add the front-facing view tests and I'd like to spend some time on this. * Initial work for JSON validator. There is a branch with generic JSON schema validator. I'd like to finish this branch (add several missing validators we need) and make it possible to include this validator in 0.3. It would change how we do deserialization from JSON to the database. It would no longer require us to use launch_control.models.* (so less dependency on client side code, something we wanted to have to be able to release them separately in the future). It would also dramatically improve the error messages. I would not merge the branch into trunk yet but rather merge several extra branches into the .json-schema branch itself and get those reviewed as usual. * Initial support for user authentication. I would like to add sign-in/sign-out elements to the web UI. This will allow us to have private/team streams and while not exciting in the short term it is a required step to getting full support for private (and non-anonymous) test data in the system. A roughly identical list of planned changes is also here in my redmine instance: http://suxx.pl/redmine/projects/launch-control/roadmap That is all. Please tell me what you think. Best regards Zygmunt Krynicki -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMnwZ1AAoJEKkR4hQBRI+lXmQIAJ+JUlYfz1bHWbEc47GqNZ/I w1JwFHDpmKNsDRvNAeYgYC1IRFSIhf8XiKOgCwWya4HHePmL5gTDA8AaTCz3R5zj mgNHOqawYLnx5reaffYDAKY8L4mDFknScUV5M416YIBvy//Cgfn4yJ4oY0e+3Lkv 6Z1fP607mokZzZNGYb1GOel51JZ4JpCnZqI+UJSOaIvLv2S2zyVtB9dhzNNCWNlf cFwtacwBEG7lTrftB98NzzkvHRkD76Qwt596wEpdaQqHe4oiqP2fUC+9+0X7XPkW XYJzRTKMA6M5dJNohtC5PChqhfR2JohSTiV+LMFyMh/smWqg1k4IrslsC69kXqI= =ZWBF -END PGP SIGNATURE
XML-RPC authentication options for the validation dashboard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello guys. I'd like to ask for your advice in for implementing authentication mechanism for the XML-RPC interface to the dashboard. I believe this problem has two aspects: user needs and client program needs. I was about to implement HTTP Digest authentication that will authorize the user against the Django user database. James pointed out that we should discuss this topic more. I'd like to know what you think. What users need to have. I think that for our internal use cases a best option would be launchpad integration. We don't mind using launchpad, we already have accounts there. We could use oauth for authentication. I'm not an expect on oauth so I'm not sure what kind of impact it has on the API itself, if any (do we need to pass some special argument to each call?). I suspect it has a negotiation phase where the client and oauth provider exchange some messages after which the client can authenticate by providing some extra header in each request. In any way that's one option. For a centralized installation this would be pretty good. For ad-hoc installations it could be difficult to setup but I'm just guessing here. Other options are (off the top of my head): - - Basic/Digest HTTP authentication. Digest is pretty good (or so wikipedia tells me) and has a very nice property of not requiring any changes to the API. User identity is provided as out-of-band HTTP header. - - Custom authentication via special XML-RPC methods and some user/pass/token/whatever arguments. This is IMHO pretty ugly as it affects the interface. The upside is that we can build any authentication options we like. - - No authentication at all. All XML-RPC interfaces are public and anyone may call them. Surprisingly this is not such a bad option. Since all request would be anonymous all the users would be allowed to do is upload data to public directories. All other interaction would have to be performed via the website or the administration panel. What clients need to implement. === So this is about everyone who has to interact with the API, currently that's just dashboard itself (we have a command-line client that can use each exposed method) and of course abrek. While I don't mind changing the API or security method to make it better we need to consider that each client will have to adapt as well. Worse, if one client has to interact with two servers it may be required to discover/negotiate supported authentication before we can even connect. Thanks Zygmunt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMgnSeAAoJEKkR4hQBRI+lvRUIAKs90kr/238PoltUbb+ET5ti qnEgQA0UYR1ocykxlL+8gkNhDLroQuSE6HpFBlVXZb2kLc1wqb5ggK0XpwViuzwo qr7aZ2HfkL6gMBQNhdW1OOSK7RxI1Z731vG6dFAo3UTCX737lCitYW6ipkqA//h3 slbIn5Voh43cbBKneRZvpIeHJbd6oKW4HKLeEVAzheuprXtjvhyXkg1qjUVH3V+Y FHRp7V1fVAYvTlObhVVW2j95OEyVJK+7dbdpmwQ/8vai2WiDXdDlqJqpO2PuZNuy mu8C0gBdZsP+ZYB2AER5RKbhZIPISf2l1fmwem79yVaxstFmHU+/KwO7AeWCR3I= =h4TW -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
