There is another question, I think I mentioned it earlier also in this
chain. I have also asked it in other time as own subject. No-one seems to
have opinion about that.
Koen, you might know, if it is a "feature" misbehaviour or problem in my
set-up.
For instance when I ran those tests I did first "fetch". Then I ran
"unpack". Unpacking ran again fetch and then unpack. Then I ran "patch".
Again, at least unpack was run again and then patch. Similar behaviour
seems to happen with "configure" so that patch will be run again even
though it had been ran manually before. This feature makes paching quite
awkward as if I edit some file that has been unpacked and applied with
other patches, that will be written over when running "configure" or
"compile" to check how edits worked.
I always get two warnings when I run bitbake:
WARNING: No recipes available for:
/home/sw/cpr3/oe/sources/meta-handheld/recipes-core/udev/udev_164.bbappend
/home/sw/cpr3/oe/sources/meta-intel/meta-fri2/recipes-core/tiny-init/tiny-init.bbappend
But I suppose they are nothing to do with this issue.
So, Is this something that should happen or should I try to find set-up
problem of some kind?
Thanks,
Matti
2013/10/28 matti kaasinen <matti.kaasi...@gmail.com>
>
> 2013/10/27 Koen Kooi <k...@dominion.thruhere.net>
>
>> On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
>> > 2013/10/23 Khem Raj <raj.k...@gmail.com>
>> >
>> > > > Hi Ulf,
>> > > > Yes, linux.inc seems doing the job as you told - this clears a lot.
>> I had
>> > > > been patching wrong file:${S}/defconfig instead of
>> ${WORKDIR}/defconfig.
>> > > > It seems that I'm not alone with this mistake. ${S}/defconfig seems
>> to be
>> > > > created by two patches:
>> > > > 0002-add-defconfig-file-to-use-as-.config.patch makes skeleton and
>> > > > 0073-defconfig-Update-bone-default-config.patch makes some
>> modefications.
>> > > >
>> > >
>> >
>> > What I mean above is that beaglebone folks have made those patches for
>> some
>> > reason that is not quite clear tome now considering how ${S}/defconfig
>> is
>> > produced in linux.inc.
>>
>> ${S}/defconfig is neither used nor produced by OE.
>>
>> I was wrong in that there are two patches that create ${S}/defconfig.
> Instead there are three of them:
> 0002-add-defconfig-file-to-use-as-.config.patch
> 0044-am33xx-Add-default-config.patch
> 0073-defconfig-Update-bone-default-config.patch
>
> Quoted from oe_manual "The patch will be applied from the unpacked source
> directory, ${S}".
> Above patches create and modify defconfig file. 0002-add created it and
> next two tweak it slightly. I double checked this by first deleting:
> ${WORKDIR}/defconfig and ${S}/defconfig and then running:
> bitbake -f -c unpack linux-mainline
>
> At this point there is ${WORKDIR}/defconfig that my layer provides.
> Then I run:
> bitbake -f -c patch linux-mainline
>
> Now there is also ${S}/defconfig.
> Then I executed patches with those three patch files in quite a different
> place - and that produced there defconfig file that was identical with
> ${S}/defconfig. BTW Koen, please check who has signed off:
>
> https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/not-capebus/0002-add-defconfig-file-to-use-as-.config.patch
> He might be someone you know :-)
> So, I would say OE produces ${S}/defconfig.
>
> >
>> > > ${WORKDIR}/defconfig (important one) is most likely coming from
>> > > > ...../linux/linux-mainline-3.8/beaglebone/defconfig as there is
>> only one
>> > > > difference that could have come from configuration process.
>> > > >
>> > > > It seems that configuration fragments do not work in regular
>> Angstrom - I
>> > > > suppose they are just Yocto stuff.
>> > >
>> > > yes.
>> > >
>> > > > Providing defconfig directly did not work - most likely it was
>> written
>> > > over
>> > > > by the patching the seems creating the ${WORKDIR}/defconfig
>> > >
>> > > what do you mean ? defconfig is provided as any other file and then
>> munged
>> > > over
>> > > in WORKDIR to make a .config
>> > >
>> > >
>> > This is outdated information - wild quess - before I noticed how that
>> > ${S}/defconfig was really generated by those patches I explained above.
>>
>> As I said above, ${S}/defconfig is not used in the build.
>>
> Good to know
> Thanks
>
>
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
