On Thu, 15 Sep 2011 16:13:32 -0500, Zach Pfeffer <zach.pfef...@linaro.org> wrote: > It just does it by name. > > Thinking more about this. > > Replacing a kernel is a pretty normal operation. I think if we just > generated a script that had the relevant paths from the build and > posted that on the build page then that would streamline this > operation. Something like:
Sorry, let me clarify something, this is with the intent of building an updated kernel to put back in the image, for the purpose of testing a new kernel without rebuilding the whole image? > git clone git://git.linaro.org/people/jstultz/android.git > cd android > git checkout linaro-android-3.0 > > wget --no-check-certificate > https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-linaro-master-with-generic-target/18/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 > > tar -jxvf > android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2 > > make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- > defconfig android_omap4_defconfig && make ARCH=arm > CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage > > Most of those values come out of the build system and you can find > most of them, but have a script would be just one more way we're > making it easier to work with these builds. That looks like something that would be fairly easy to generate. I generally prefer producing data, and then have scripts to act on that data (e.g. in linaro-image-tools,) but this looks ok. Would you want e.g. the kernel repo to be the one from the build, or to always be jstultz's? If this is something you want you can spin up a blueprint for this work. Paul, would you be interested in completing this one? Thanks, James _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
