I have noticed this as well and it is highly irritating,
Best Regards
Ulf Samuelsson
28 okt 2013 kl. 09:23 skrev matti kaasinen <matti.kaasi...@gmail.com>:
> 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
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
