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
next prev parent 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