SRCREV defined too late -how to fix?

SRCREV defined too late -how to fix?

[Mike Westerhof]

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?

-Mike (mwester)

Re: SRCREV defined too late -how to fix?

[Chris Larson]

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 :)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: SRCREV defined too late -how to fix?

[Mike Westerhof]

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

Re: SRCREV defined too late -how to fix?

[Martin Jansa]

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                         

Re: SRCREV defined too late -how to fix?

[Mike Westerhof]

Martin Jansa wrote:
> 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..

I hope so.  Cleaning stuff up and making it all pretty is great, but it
really sucks when it not only breaks things, but also removes
functionality we previously enjoyed. :(

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

This is the exact line from
openembedded/conf/distro/include/preferred-slugos-versions.inc, actually.

It doesn't matter if I remove the similar line from my local.conf; it
still fails because SRCREV is not defined when the line is evaluated.
Any user building any IXP4xx kernel in OE will be greeted with the
aforementioned messages, even if they have an empty local.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?

So basically, you are suggesting that we leave the SRCREV in the
package, but I should define it along with the preferred kernel in one
of the SlugOS distro config files -- in other words, it's reverting your
changes specifically for SlugOS and the ixp4xx kernel.

I'm fine with that; I like the old behavior far better than the
(mis)behavior I observe with the new model.  I'll try that and if it
works, I can commit that change.

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

But if understand your proposed solution, it is just putting it back to
the way it was for SlugOS.  (It'll still be broken for Angstrom and
other distros that build IXP4xx kernels, though).

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

That doesn't help me, then.  I can probably upgrade, but I'd like to get
this kernel issue resolved before I upgrade bitbake and do all the
testing necessary to make sure it all still works.

> Regards,



-Mike (mwester)

Re: SRCREV defined too late -how to fix?

[Martin Jansa]

On Thu, Apr 08, 2010 at 12:19:31AM -0500, Mike Westerhof wrote:
> This is the exact line from
> openembedded/conf/distro/include/preferred-slugos-versions.inc, actually.

Ah sorry, that I missed that (grep for SRCREV_pn).

> It doesn't matter if I remove the similar line from my local.conf; it
> still fails because SRCREV is not defined when the line is evaluated.
> Any user building any IXP4xx kernel in OE will be greeted with the
> aforementioned messages, even if they have an empty local.conf.

I don't think so, the only problem is when you have to define
PREFERRED_VERSION_linux-ixp4xx (without SRCREV-pn-linux-ixp4xx
definition).

To be honest SRCREV in linux-ixp4xx.inc is really strange, I put it
there as it's as close to previous state as possible (same SRCREV is
share between all versions of linux-ixp4xx recipe). I would expect
different SRCREV of patchset for different module=${KERNEL_RELEASE} (I
think it's harder to test all KERNEL_RELEASEs when you need to bump
patchset SRCREV for latest RELEASE or unnecesarry kernel upgrades for
users of older KERNEL_RELEASE when someone bumped patches only to get
more patches for latest RELEASE without any change in their old version.

> > 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?
> 
> So basically, you are suggesting that we leave the SRCREV in the
> package, but I should define it along with the preferred kernel in one
> of the SlugOS distro config files -- in other words, it's reverting your
> changes specifically for SlugOS and the ixp4xx kernel.

I really don't mind moving SRCREV_pn-linux-ixp4xx to SlugOS config if
it's easier for you. Or you can as well increase DEFAULT_PREFERENCE in
that 2.6.27.8 recipe for slugos or all and drop
PREFERRED_VERSION_linux-ixp4xx from config.

> I'm fine with that; I like the old behavior far better than the
> (mis)behavior I observe with the new model.  I'll try that and if it
> works, I can commit that change.
> 
> >>>> 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.
> 
> But if understand your proposed solution, it is just putting it back to
> the way it was for SlugOS.  (It'll still be broken for Angstrom and
> other distros that build IXP4xx kernels, though).

I don't see PREFERRED_VERSION_linux-ixp4xx in Angstrom configs so I
think that only those who has PREFERRED_VERSION_linux-ixp4xx in
local.conf needs to define preferred SRCREV there as well.

Regards,

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

Re: SRCREV defined too late -how to fix?

[Martin Jansa]

On Thu, Apr 08, 2010 at 08:07:27AM +0200, Martin Jansa wrote:
> To be honest SRCREV in linux-ixp4xx.inc is really strange, I put it
> there as it's as close to previous state as possible (same SRCREV is
> share between all versions of linux-ixp4xx recipe). I would expect
> different SRCREV of patchset for different module=${KERNEL_RELEASE} (I
> think it's harder to test all KERNEL_RELEASEs when you need to bump
> patchset SRCREV for latest RELEASE or unnecesarry kernel upgrades for
> users of older KERNEL_RELEASE when someone bumped patches only to get
> more patches for latest RELEASE without any change in their old version.

To finish my thought.. 

With this new layout (SRCREV in recipe) it will be much easier to bump
SRCREV ie only for linux-ixp4xx_2.6.29.bb (overwritting shared SRCREV
from linux-ixp4xx.inc after its include), but be aware that if you put
SRCREV_pn-linux-ixp4xx in distro config you will also overwrite this
locally bumped SRCREV which can be confusing a bit.

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