[oe] SRCREV defined too late -how to fix?

Mike Westerhof mike at mwester.net
Thu Apr 8 03:07:12 UTC 2010


Chris Larson wrote:
> On Tue, Apr 6, 2010 at 6:50 AM, Mike Westerhof <mike at mwester.net> wrote:
> 
>> After a recent commit that rearranged where (and how) SRCREVs are defined,
>> building results in:
>>
>> NOTE: preferred version 2.6.27.8+svnr1 of linux-ixp4xx not available (for
>> item kernel)
>> NOTE: preferred version 2.6.27.8+svnr1 of linux-ixp4xx not available (for
>> item kernel-module-ext2)
>> NOTE: preferred version 2.6.27.8+svnr1 of linux-ixp4xx not available (for
>> item kernel-module-jbd)
>> (etc.)
>>
>> Note the bogus "svnr1" on the end -- I think this has happened because
>> someone changed OE to define SRCREVs in each package.  So now, deep in
>> recipes/linux/linux-ixp4xx.inc, we find:
>>
>> SRCREV = "1089"
>>
>> I think that's wrong.
>>
>> It *does* (sort of) work -- it actually results in that SRCREV (1089) being
>> built, despite the messages (above) telling you that it can't find the
>> PREFERRED_VERSION with SRCREV == 1.
>>
>> But what that line does is not really what we (the ixp4xx kernel
>> maintainers) had in mind.
>>
>> The idea is that the SRCREV, along with the kernel version, would be
>> defined as a preferred version, like this line which is in
>> machine/include/ixp4xx.inc:
>>
>> PREFERRED_VERSION_linux-ixp4xx ?= "2.6.24.7+svnr${SRCREV}"
>>
>> Of course, SlugOS overrides that because that distro prefers a more recent
>> kerrnel:
>>
>> PREFERRED_VERSION_linux-ixp4xx = "2.6.27.8+svnr${SRCREV}"
>>
>> That's not really a "recent" kernel, of course -- my local.conf file has a
>> more recent one that I've not yet committed.  The point is that the way it
>> *USED* to work, one could use the normal means to set both PREFERRED_VERSION
>> and SRCREV.  With the recent commit, we can't do that anymore.
>>
>> Apparently SRCREV isn't defined soon enough with this new structure, so we
>> get the messages about svnr1 not being available.  And, of course, one
>> cannot override the preferred version anymore due to the use of "=" instead
>> of "=?" for the assignment.  (At the very least, when all the SRCREVs were
>> moved into the recipes, shouldn't the weak assignments have been preserved?)
>>
>> At any rate, I wish to remove the bogus messages about svnr1, and I want to
>> restore the behavior that would allow me to provide the SRCREV in my
>> local.conf.  What is the correct way to do this with the new "world order"
>> as it relates to SRCREVs?   To what config file do I move that
>> SRCREV="1089"?  Who would I anger if I just put it back to the way it was?
> 
> 
>>From what RP was saying on IRC the other day, you can utilize "%" in version
> preferences for versions that include srcrev, as a marker.  2.6.27.8+svnr%.
>  I haven't looked at that code, though, so I may be completely out in left
> field here :)

NOTE: preferred version 2.6.27.8+svnr% of linux-ixp4xx not available
(for item kernel)
NOTE: preferred version 2.6.27.8+svnr% of linux-ixp4xx not available
(for item kernel-module-ext2)
NOTE: preferred version 2.6.27.8+svnr% of linux-ixp4xx not available
(for item kernel-module-jbd)

:(  Does this %-sign feature perhaps require a new bitbake version?

-Mike




More information about the Openembedded-devel mailing list