[poky] Getting error in linux-yocto kernel during build.

[Bruce Ashfield]

On Wed, Sep 21, 2011 at 12:49 AM, chinmaya hoshing <cahoshing at gmail.com> wrote:
> Hi ,
> I have setup a git server that is clone of linux-yocto-3.0  from
> git://git.yoctoproject.org/linux-yocto-3.0 repository.

That's good! So where are you pushing your changes ? To that repo ? Are
you updating the SRCREV or using AUTOREV in your local layers ? I use
this workflow everyday, so it does work. I just need to understand where you
are putting your changes, and then we'll know why you aren't seeing them
on subsequent builds (or we'll have more ideas about where to look).

Cheers,

Bruce

> Regards
> C Hoshing
>
> On Tue, Sep 20, 2011 at 7:24 PM, Bruce Ashfield <bruce.ashfield at gmail.com>
> wrote:
>>
>> On Tue, Sep 20, 2011 at 5:51 AM, chinmaya hoshing <cahoshing at gmail.com>
>> wrote:
>> > Hi ,
>> > I have set up a git server for linux-yocto.
>> > Following is my recipe  :
>> > require linux-yocto.inc
>> > KMACHINE = "yocto/standard/base"
>> > KMACHINE_qemux86  = "yocto/standard/common-pc/base"
>> > KMACHINE_qemux86-64  = "yocto/standard/common-pc-64/base"
>> > KMACHINE_qemuppc  = "yocto/standard/qemu-ppc32"
>> > KMACHINE_qemumips = "yocto/standard/mti-malta32-be"
>> > KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
>> > KMACHINE_atom-pc  = "yocto/standard/common-pc/atom-pc"
>> > KMACHINE_routerstationpro = "yocto/standard/routerstationpro"
>> > KMACHINE_mpc8315e-rdb = "yocto/standard/fsl-mpc8315e-rdb"
>> > KMACHINE_beagleboard = "yocto/standard/beagleboard"
>> > KMACHINE_fishriver = "yocto/standard/fishriver"
>> > KBRANCH = ${KMACHINE}
>> > KMETA = meta
>> > LINUX_VERSION ?= "3.0"
>> > LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
>> > PR = "r0"
>> > #PV = "${LINUX_VERSION}+git${SRCPV}"
>> > #SRCREV_FORMAT = "meta_machine"
>> > SRC_URI =
>> >
>> > "git://xxx.xxx.xxx.xx/linux-yocto-3.0.git;protocol=git;nocheckout=1;branch=$%7BKBRANCH%7D,meta;name=machine,meta"
>> >
>> > COMPATIBLE_MACHINE =
>> >
>> > "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|mpc8315e-rdb|routerstationpro|beagleboard)"
>> > # Functionality flags
>> > KERNEL_REVISION_CHECKING ?= "t"
>> > KERNEL_FEATURES="features/netfilter"
>> > KERNEL_FEATURES_append_qemux86=" cfg/sound"
>> > KERNEL_FEATURES_append_qemux86-64=" cfg/sound"
>> > YOCTO_KERNEL_META_DATA=t
>> > # Temporary fix for oprofile and latencytop on qemux86-64
>> > KERNEL_FEATURES_append_qemux86-64=" features/profiling"
>> > KERNEL_FEATURES_append_qemux86-64=" features/latencytop"
>> > # extra tasks
>> > addtask kernel_link_vmlinux after do_compile before do_install
>> > addtask validate_branches before do_patch after do_kernel_checkout
>> > addtask kernel_configcheck after do_configure before do_compile
>> > require linux-tools.inc
>> >
>> >
>> > But still I am getting the same result as before . My previous git
>> > commits
>> > in poky source are flashed out , also the only recipe remains in
>> >  meta/recipe-kernel/ is linux .
>>
>> Just so I'm clear here. Are you still working with tarballs of the
>> source, or have
>> you setup a git server that is a clone of the linux-yocto-3.0 (as an
>> example) tree ?
>>
>> Where are you putting your changes in this scenario ?
>>
>> Bruce
>>
>> >
>> > Regards
>> > C Hoshing
>> >
>> > On Fri, Sep 16, 2011 at 8:52 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>> >>
>> >> On 2011-09-16 09:06, Richard Purdie wrote:
>> >>>
>> >>> On Fri, 2011-09-16 at 10:35 -0400, Bruce Ashfield wrote:
>> >>>>
>> >>>> On Fri, Sep 16, 2011 at 10:24 AM, Bruce Ashfield
>> >>>> <bruce.ashfield at gmail.com>  wrote:
>> >>>>>
>> >>>>> On Fri, Sep 16, 2011 at 8:38 AM, chinmaya
>> >>>>> hoshing<cahoshing at gmail.com>
>> >>>>>  wrote:
>> >>>>>>
>> >>>>>> Hi ,
>> >>>>>> I am building poky-build minimal live image for fishriver machine
>> >>>>>> on
>> >>>>>> 64 bit
>> >>>>>> host machine.
>> >>>>>> As I am having limited internet band-width, so I have identified
>> >>>>>> all
>> >>>>>> the
>> >>>>>> dependent packages and setup a Apache server on my local system so
>> >>>>>> that I
>> >>>>>> can redirect the SRC_URI of all the packages to my local server.
>> >>>>>> I have changed the related recipes to build  minimal live image,
>> >>>>>> and
>> >>>>>> modify
>> >>>>>> bitbake.conf to add LOCAL_MIRROR="xxx.xxx.xxx.xxx/packages" , in
>> >>>>>> side
>> >>>>>> packages I have tars which  was present "build/download" folder.
>> >>>>>> While building linux-yocto, fetch and unpack was done but during
>> >>>>>> kernel
>> >>>>>> checkout whatever git commits I have done previously in poky source
>> >>>>>> were
>> >>>>>> flashed out (lost),  also the only recipe remains in
>> >>>>>>  meta/recipe-kernel/ is
>> >>>>>> linux .
>> >>>>>>
>> >>>>>> Following are the changes made in
>> >>>>>> meta/recipes-kernel/linux/linux-yocto_git.bb
>> >>>>>> #SRCREV_FORMAT = "meta_machine"
>> >>>>>> SRC_URI = "${LOCAL_MIRROR}/linux-yocto-3.0-3.0.tar.bz2"
>> >>>>>>  // This tar file I took from
>> >>>>>>
>> >>>>>>
>> >>>>>> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/snapshot/linux-yocto-3.0-3.0.tar.bz2
>> >>>>>> PV = "${LINUX_VERSION}"
>> >>>>>> In file meta-intel/meta-fishriver/conf/machine/fishriver.conf I
>> >>>>>> modified
>> >>>>>> PREFERRED_VERSION_linux-yocto = "3.0"                (which  was
>> >>>>>> PREFERRED_VERSION_linux-yocto = "3.0+git%" )
>> >>>>>>
>> >>>>>> Can any one help me to find the solution that if I had to pull
>> >>>>>> linux
>> >>>>>> kernel
>> >>>>>> source from tar file or such and not from git repository. What
>> >>>>>> things
>> >>>>>> I have
>> >>>>>> to do.
>> >>>>>
>> >>>>> The linux-yocto recipes are designed from the ground up to work on a
>> >>>>> git
>> >>>>> based repository, and there's really no way to get around that fact
>> >>>>> (and no
>> >>>>> plans to make any changes in this area).
>> >>>>
>> >>>> Thinking further about this, if the tgz actually was just a tarball
>> >>>> of
>> >>>> the git
>> >>>> repositories (including the git blobs), it could work.
>> >>>
>> >>> This is exactly what we use behind the scenes for mirroring the git
>> >>> repositories so this should work. It should be possible to use our
>> >>> existing PREMIRROR code to avoid having to rewrite individual recipes
>> >>> though.
>> >>>
>> >>> It will firstly unpack the tarball, then access whether the revisions
>> >>> it
>> >>> needs are present. If they're not, it will then (and only then) try
>> >>> and
>> >>> fetch them over the network. If the tarball is complete it will
>> >>> therefore not touch the network. If its incomplete it will only fetch
>> >>> the different (delta).
>> >>
>> >> This does work as advertised - I use it exclusively.  I have a local
>> >> package cache which I use with PREMIRROR and I set BB_NO_NETWORK to
>> >> prove/protect that no network access is required.
>> >>
>> >> --
>> >> ------------------------------------------------------------
>> >> Gary Thomas                 |  Consulting for the
>> >> MLB Associates              |    Embedded world
>> >> ------------------------------------------------------------
>> >> _______________________________________________
>> >> poky mailing list
>> >> poky at yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/poky
>> >
>> >
>> > _______________________________________________
>> > poky mailing list
>> > poky at yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/poky
>> >
>> >
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"