Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Mike Westerhof <mike@mwester.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: SRCREV defined too late -how to fix?
Date: Wed, 07 Apr 2010 22:07:12 -0500	[thread overview]
Message-ID: <4BBD4860.8070306@mwester.net> (raw)
In-Reply-To: <q2mb6ebd0a51004060826wb048ffa2ge1fbcfb1892a9bac@mail.gmail.com>

Chris Larson wrote:
> On Tue, Apr 6, 2010 at 6:50 AM, Mike Westerhof <mike@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



  reply	other threads:[~2010-04-08  3:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-06 13:50 SRCREV defined too late -how to fix? Mike Westerhof
2010-04-06 15:26 ` Chris Larson
2010-04-08  3:07   ` Mike Westerhof [this message]
2010-04-08  4:18     ` Martin Jansa
2010-04-08  5:19       ` Mike Westerhof
2010-04-08  6:07         ` Martin Jansa
2010-04-08  6:14           ` Martin Jansa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BBD4860.8070306@mwester.net \
    --to=mike@mwester.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox