All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.