[OE-core] [PATCH] u-boot: update to 2013.07

Bruce Ashfield bruce.ashfield at gmail.com
Mon Aug 26 22:03:19 UTC 2013


On Mon, Aug 26, 2013 at 5:48 PM, Peter A. Bigot <pab at pabigot.com> wrote:
> I can confirm this also works with the Gumstix Overo in a layer bbappend
> that used SRC_URI_append_overo for additional patches.  Thanks to you both
> for getting it merged.
>
> I did come up with a question, though.  The recipe uses:
>
>   PV = "v2013.07+git${SRCPV}"
>
> which creates an informative but ugly ${BPN}.  I'd like to use something
> like:
>
>   FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
>
> in the bbappend to simplify updates, but I don't want to have a directory
> named u-boot-v2013.07+gitAUTOINC+62c175fbb8.  For linux-yocto, this is
> solved through introduction of ${LINUX_VERSION} allowing
> ${PN}-${LINUX_VERSION}.
>
> Is there reason to create a parallel UBOOT_VERSION?
>
> Is there reason to have some way to access the default ${PV} inferred from
> the recipe name before the base recipe overrode it? (Is there already some
> way to get that value?)
>
> Is there a better approach than bbappend-in-layer that I should use for
> adding patches required for a specific u-boot machine?

That's the right approach. Only when complexity warrants is it worth
the effort to maintain
a targeted git tree that manages changes via branches. So until the
directories full of patches
and conflicting features collapse on themselves, go with SRC_URIs and bbappends.

Cheers,

Bruce

>
> Peter
>
>
> On 08/26/2013 12:55 PM, Saul Wold wrote:
>>
>> On 08/23/2013 09:57 AM, Laszlo Papp wrote:
>>>
>>> Any update? It would be nice not to miss the freeze ... ;-)
>>>
>> This has been merged, and I was informed by the QA team that it works
>> correctly for the mpc8315e-rdb and beagleboard, but NOT the beagleboard XM.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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



More information about the Openembedded-core mailing list