Botao, Amit: Here are the builds we'll be looking at for the 12.07 android
release. Please boot test them as soon as possible, and respond with the
results. Once they are good, David will tag and rebuild them in the
-release branch, and respond with the new URLs. We'll then need to pick up
the new builds from those URLs and do the rest of the testing on them.
Please take this opportunity to also double-check the gcc version that was
used to build the kernel and make sure it's the 12.07 release of gcc.
Panda:
https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc47-til…
- Boot test on both 4430 and 4460
Snowball:
https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-…
- Please check glmark2, it failed in the lava tests, but looks like it
was due to a networking glitch with linaro-android-test not detecting the
network in time. If this looks bad in the boot test, revert to build 369
and boot test it.
Origen:
https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc47-sa…
- Please check glmark2 on this one too. If this one doesn't look good,
revert to build 88
Vexpress-a9:
https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc47-…
Ryan/Tixy are testing the vexpress-tc2 release. Could one of you please
respond with the build URL? I couldn't seem to locate it. Also, after boot
testing, Zach may want it to be rebuilt in a -release branch. I'll defer
to him on that.
Thanks,
Paul Larson
Hi,
i am trying to compile linaro build ( panda-ics-gcc47-tilt-tracking-blob )
on ubuntu 12.04 machine.
The steps and other details.
1. i am using ubuntu 12.04 on intel 64 bit machine.
2. downloaded the latest source code.
3. install gcc-4.7.
4. download the latest tool chain.
5. i followed all the steps mentioned by you.
i am continuously getting the below error code.
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: skipping incompatible
/usr/gcc_4_7/lib/gcc/x86_64-linux-gnu/4.7.2/libgcc.a when searching for
-lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
pleas let me know which linux or other configuration should i use to easily
compile linaro android source code.
what is the easiest way to do that.
regards and thanks
Amit Kumar
Dear Sir or Madam,
At the website https://wiki.linaro.org/Platform/Android/ImageInstallation
What is the difference between quickstart section and Intro section? Those part suppose to do different thing or the same?
What is the pre-built image? Is that the image for kernel?
At the website
https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-til…
I can't automatically build the source via script, it tells me I don't have a pinned-manifest.xml.
And where can I find the download button mentioned in "How to Use Prebuilt Images".
When I follow the instructions to compile the Android source code, when it comes to compile kernel/drivers/usb/musb/tusb6010_omap.c it always terminate because of lack of mach/mux.h file.
Please help me.
Best wishes,
Shawn
Hello,
Over lifetime of Linaro CI services, we've been experiencing number of
episodes when service stability was influenced by Ubuntu package
mirror issues, with it being used to configure each and every build
slave, usually dozen times a day.
Linaro Infrastructure team and CI service stakeholders tried different
approaches to solve this issue, and over time we come to conclusion that
sustainable way to do it is to maintain custom Amazon Machine
Images (AMI) with preinstalled packages, which will simply cut the
dependency on Ubuntu mirror's 100% availability. In addition to that,
they also speed up build startup time noticeably.
A special tool, linaro-ami, was developed to help maintain custom AMIs,
with two main requirements being centralized configuration location for
EC2 admins control, as well as being easy to use for individual custom
AMI maintainers. We still may need to improve UI functionality for the
latter, and would need stakeholder feedback for that, but otherwise the
tool seems to work pretty well. It is available as part of
linaro-aws-tools project, https://launchpad.net/linaro-aws-tools . The
README is available at
http://bazaar.launchpad.net/~linaro-aws-devs/linaro-aws-tools/trunk/view/he…ci.linaro.org and android-build.linaro.org has been already switched to
new custom AMIs. Using custom AMIs for CBuild service is under
consideration by Toolchain group.
So, from this point on, it's important that all stakeholders follow
build slave configuration change process centered around linaro-ami
tool: any package set changes should be applied to slave init script
(as referenced in linaro-ami config), a new version of corresponding AMI
generated, and Jenkins configuration updated with new AMI ID. (No
package installation should be happen directly in Jenkins.)
The Infrastructure team can help with maintaining AMIs, and is open for
suggestions on improving new setup.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
+ android team
This is becoming a big problem. I just checked and the load on the
system was growing out of control again.
Upon inspection, I found several Java (CTS) processes that were
consuming lots of CPU cycles, but upon inspection there was no ADB
connection to the board they were supposed to be testing.
I also found a couple of places where MonkeyRunner seemed to crash, but
keep running (and also consume CPU cycles).
In addition the mmtest output is ridiculous. It just dumps %download
info throughout our log file making it really hard to read through the logs.
I think we need to do a few things quickly here:
1) We need to limit the amount of builds sending CTS jobs until we
understand what's going on. I'd suggest doing it for something like
Origen or Panda since we have the most of those boards. Right now, the
jobs are queuing up on snowball faster than it can unsuccessfully
execute them
2) We need to understand what's going on with CTS. Is this due to the
patched version we deployed, etc?
3) For sanity sake update the logic for the wgets in mmtest.py to not
dump so much junk.
We'll need the android team's help on item 1. I also think we may need
their help on item 2.
On 07/16/2012 10:06 PM, Michael Hudson-Doyle wrote:
> Hi gang,
>
> We had a fright today with LAVA being unreachable. Luckily, we could
> log in again after a time and notice the cause of the load: 10 or so
> Java processes like this:
>
> root 31180 53.2 0.5 8175148 159856 ? Sl Jul16 603:22 java -cp :./android-cts/tools/../../android-cts/tools/ddmlib-prebuilt.jar:./android-cts/tools/../../android-cts/tools/tradefed-prebuilt.jar:./android-cts/tools/../../android-cts/tools/hosttestlib.jar:./android-cts/tools/../../android-cts/tools/cts-tradefed.jar -DCTS_ROOT=./android-cts/tools/../.. com.android.cts.tradefed.command.CtsConsole run cts --serial 192.168.1.199:5555 --plan CTS
>
> Clearly, this is related to the CTS upgrades we've done recently. There
> was no device connected to 192.168.1.199:5555 so somehow we're leaking
> these processes. I guess we should stop that :-)
>
> While looking into this, I noticed that monkeyrunner tests are quite CPU
> heavy. Is this expected? Do we need to limit how many of these we run
> at once?
>
> Cheers,
> mwh
>
