Hello Zach,
On Sun, 22 Jul 2012 10:38:15 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
Hey Bero/Paul
Who sets up:
http://snapshots.linaro.org/android/~linaro-android/toolchain-4.7-2012.07/1/...
and
http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/la...
Well, not "who", but "what": Android build system (android-build.linaro.org) automatically executes number of builds daily (including toolchain builds) and publishes results on snapshots.linaro.org. Some builds also still publish on android-build.linaro.org, even though now we have complete setup on snapshots.linaro.org (in other words, archiving on android-build.linaro.org should be turned off).
I'm asking because I'd like to solve a problem our users are running into. The instructions listed on top of each build pages are wrong.
Well, that's probably a known issue, that instructions on individual jobs' pages are out-of-date/incorrect. One reason being that we have them duplicated multiple times, so it's very hard/impossible to keep them all up to date over extended period of time. One solution proposed earlier was to not have adhoc per-job instructions, but instead make those pages link to one central wiki page, with single instructions applicable to all builds, maintained and up-to-date.
They say things like:
$ wget --no-check-certificate http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/la... $ tar -jxvf android-toolchain-eabi-linaro-*
when the build is using
TOOLCHAIN_URL=http://snapshots.linaro.org/android/~linaro-android/toolchain-4.7-2012.07/1/...
I'd like to fix this so that the builds pull the right thing.
I guess, build config is more maintained than description, so the latter what should be fixed, or do you suspect build the config being incorrect? And what specific build is that?
I was thinking that we could commit the toolchain tarballs to git and then just pull things as part of the manifest. That would help our local users.
There're 2 problems with that. 1st: who exactly will commit it to git? Again, toolchain build is automated daily process, and automated build script cannot commit to git (unless we're talking security issues). 2nd: git (or any other source code version control system) is not designed to store large binary blobs and cannot handle them efficiently. So, toolchain tarball is currently 88Mb. In ten days, we'll have extra 880Mb in git repository. In a month, 2.5Gb, in half-year - 15Gb. We won't see that time though, because git server will come to a halt trying serve that to users much earlier.
We could also take a half step and write a script that would setup the environment and have people (and the build server) also use that.
But we have a build script already, which should handle all aspects of the build, including this. (linaro_android_build_cmds.sh at (https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc47-i... ).
We have the same issue with:
KERNEL_CONFIG=omap4plus_defconfig
Which should be in the build.
Anyway, I think its time to start making:
MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git MANIFEST_BRANCH=linaro_android_4.0.4 MANIFEST_FILENAME=tracking-panda.xml TARGET_PRODUCT=pandaboard TARGET_SIMULATOR=false TARGET_BUILD_VARIANT=tests SOURCE_OVERLAY="open/20120716/build-info.tar.bz2" TOOLCHAIN_URL=http://snapshots.linaro.org/android/~linaro-android/toolchain-4.7-2012.07/1/... TOOLCHAIN_TRIPLET=arm-linux-androideabi REPO_SEED_URL=http://android-build.linaro.org/seed/uniseed.tar.gz LAVA_SUBMIT=1 LAVA_SUBMIT_FATAL=0 TARGET_NO_HARDWAREGFX=1 KERNEL_CONFIG=omap4plus_defconfig LAVA_ANDROID_BINARIES=False LAVA_TEST_PLAN="busybox,0xbench,glmark2,skia,v8,mmtest,monkey,monkey_long_run" MONKEY_RUNNER_URL_1="git://android.git.linaro.org/test/linaro/android/system.git" CTS_TIMEOUT=36000
turn into:
MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git MANIFEST_BRANCH=linaro_android_4.0.4 MANIFEST_FILENAME=tracking-panda.xml
Do you mean switching to build configs in git which use following syntax:
BUILD_CONFIG_REPO=... BUILD_CONFIG_BRANCH=... BUILD_CONFIG_FILENAME=...
?