Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: SRCREV defined too late -how to fix?
Date: Thu, 8 Apr 2010 06:18:01 +0200	[thread overview]
Message-ID: <20100408041801.GA3269@jama> (raw)
In-Reply-To: <4BBD4860.8070306@mwester.net>

On Wed, Apr 07, 2010 at 10:07:12PM -0500, Mike Westerhof wrote:
> 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:

Hi, that was me, sorry for inconvenience, but we should be able to
resolve it..

> >> 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}"

This is exact line from your local.conf? Where did you define that newer
SRCREV for this PV?. I've grepped whole tree for
defined SRCREV_pn-something and changed that (see OPKG_SRCREV also
defined in SlugOS conf).

Have you tried

SRCREV_pn-linux-ixp4xx = "4833"
PREFERRED_VERSION_linux-ixp4xx = "2.6.27.8+svnr${SRCREV_pn-linux-ixp4xx}"

in your local.conf?

> >> 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?)

Yes you can override it with _pn-something in local.conf (as ie
fso-autorev.conf, shr-autorev.conf), SRCREV_pn-abc = "123" is preferred
over SRCREV = "12" in abc_svn.bb. Doesn't matter if there was weak or
normal assignment in recipe.

The point for not-weak assignement is because some time ago, RP said,
that would be better to define SRCREV = None ie in bitbake.conf to get
better error message than those "svnr1". Using weak SRCREV in recipes
wouldn't be possible.

> >> 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?

Please try solution suggested above first.

> >>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?

Yes this needs bitbake master.

Regards,
-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         



  reply	other threads:[~2010-04-08  4:21 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
2010-04-08  4:18     ` Martin Jansa [this message]
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=20100408041801.GA3269@jama \
    --to=martin.jansa@gmail.com \
    --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