[oe] [oe-commits] Koen Kooi : opkg-native: bump to r522 to get a fix to remove duplicate messages from do_rootfs logs

[Tom Rini]

On Wed, 2010-02-17 at 22:22 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 17-02-10 21:18, Tom Rini wrote:
> > On Wed, 2010-02-17 at 08:59 +0000, git version control wrote:
> >> Module: openembedded.git
> >> Branch: org.openembedded.dev
> >> Commit: 74501117c261f743c76ae3c2988cbcfdc141cf3a
> >> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=74501117c261f743c76ae3c2988cbcfdc141cf3a
> >>
> >> Author: Koen Kooi <koen at openembedded.org>
> >> Date:   Tue Feb 16 13:08:53 2010 +0100
> >>
> >> opkg-native: bump to r522 to get a fix to remove duplicate messages from do_rootfs logs
> > 
> > I'd like to RFC that we do something like:
> > OPKGREV ?= "522"
> > SRCREV_pn-opkg ?= "${OPKGREV}"
> > SRCREV_pn-opkg-native ?= "${OPKGREV}"
> > SRCREV_pn-opkg-sdk ?= "${OPKGREV}"
> > 
> > And if -nogpg or what have you is broken, it either gets fixed or the
> > distribution takes advantage of that ?=. 
> 
> I haven't been able to properly test a target opkg yet, so no bump for
> that. Unless people would like broken opkg binaries on their target ;)

Seriously tho, this isn't the first or fifth time the revs have gotten
wildly out of sync.  I'm suggesting that we want to keep them together,
intentionally.  We don't say we have different versions of gcc or bison
between native and target.  This is possibly even more important to make
sure all of the operations are right, all around.

> Personally, I want sanesrcrev.inc to die and put the revs in the recipes
> where they belong.

Unless opkg's would live in opkg.inc, same problem.

> > It seems a bit silly,
> > especially given the nature of the fixes, to split things up like this.
> > Heck, assuming 521 -> 522 is the patch from RP, the original report was
> > for on target opkg, not do_rootfs
> 
> The commit does what is says in the message, it removes duplicate
> entries in do_rootfs logs (and makes narciusses XHR smaller), so what is
> it you're complaining about?

I'm saying that this is a bugfix for a problem that you reported (or at
least commented on the thread / bug entry) as being a problem on device.
Is it intentional that you didn't update on device to have this fixed
too?  I was guessing no, it wasn't (and that you would have found time
to test on device).

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation