Math is hard, but please pay attention to PV

Math is hard, but please pay attention to PV

[Koen Kooi]

Hi,

I know math is hard and noone care about QA, but this shouldn't happen:

Old version:
libedje0 1:0.9.9.043+cvs20080610-r0

New version:
libedje0 1:0.5.0.043+svnr35727-r1

Hint: '9' > '5', so package upgrades just got broken.

Now, normally someone would eventually get the math right and bump PE, 
but this is the *second* time that EFL stuff goes backwards in PV.

Some googling suggests that openmoko/fso 'solved' this by completely 
deleting the package feeds and having people reflash their devices. That 
is just wrong.

Anyway, PE has been bumped, things should work again this the next EFL 
'upgrade' happens. I just need to find a way to get the past 2 hours of 
my life back.

Re: Math is hard, but please pay attention to PV

[Holger Freyther]

On Friday 19 September 2008 14:48:40 Koen Kooi wrote:

> Anyway, PE has been bumped, things should work again this the next EFL
> 'upgrade' happens. I just need to find a way to get the past 2 hours of
> my life back.

Thanks!

Re: Math is hard, but please pay attention to PV

[Koen Kooi]

Holger Freyther wrote:
> On Friday 19 September 2008 14:48:40 Koen Kooi wrote:
>
>> Anyway, PE has been bumped, things should work again this the next EFL
>> 'upgrade' happens. I just need to find a way to get the past 2 hours of
>> my life back.
>
> Thanks!

I just fixed linux-openmoko as well, '0' is _less_ than '7', so changing 
PR from 'r7' to 'r0' is *bad*, I've increased it to 'r8' now.

Seriously, is math that hard for openmoko people?

Re: Math is hard, but please pay attention to PV

[Michael 'Mickey' Lauer]

Holger, can you please push your SRCPV changes so we can have sane PV
also for those strange SCM which both lack increasing revision numbers
as well as an idea of a day?

I really don't want to see more workarounds in OE for git and friends.

:M:

Re: Math is hard, but please pay attention to PV

[Michael 'Mickey' Lauer]

Am Mittwoch, den 24.09.2008, 10:17 +0200 schrieb Koen Kooi:
> Holger Freyther wrote:
> > On Friday 19 September 2008 14:48:40 Koen Kooi wrote:
> >
> >> Anyway, PE has been bumped, things should work again this the next EFL
> >> 'upgrade' happens. I just need to find a way to get the past 2 hours of
> >> my life back.
> >
> > Thanks!
> 
> I just fixed linux-openmoko as well, '0' is _less_ than '7', so changing 
> PR from 'r7' to 'r0' is *bad*, I've increased it to 'r8' now.

> Seriously, is math that hard for openmoko people?

Much less the math but rather being used to reset PR on version updates.
Alas this breaks with hash-based SCMs. I begin to regret the decision to
use git in my projects.

:M:

Re: Math is hard, but please pay attention to PV

[Alessandro Pellizzari]

Il giorno ven, 19/09/2008 alle 14.48 +0200, Koen Kooi ha scritto:

> Old version:
> libedje0 1:0.9.9.043+cvs20080610-r0
> 
> New version:
> libedje0 1:0.5.0.043+svnr35727-r1

Speaking of this, last weekend I tried to create a recipe for fbreader
0.8.17, but bitbake insisted on compiling fbreader 0.8.2a because 2 > 1
I had to remove the recipe for 0.8.2a from packages/fbreader.

Bye.

P.S.: No, I didn't succeed. I must study bb recipes better and review
some patches that don't apply.

-- 
Alessandro Pellizzari

Re: Math is hard, but please pay attention to PV

[Koen Kooi]

Alessandro Pellizzari wrote:
> Il giorno ven, 19/09/2008 alle 14.48 +0200, Koen Kooi ha scritto:
>
>> Old version:
>> libedje0 1:0.9.9.043+cvs20080610-r0
>>
>> New version:
>> libedje0 1:0.5.0.043+svnr35727-r1
>
> Speaking of this, last weekend I tried to create a recipe for fbreader
> 0.8.17, but bitbake insisted on compiling fbreader 0.8.2a because 2>  1
> I had to remove the recipe for 0.8.2a from packages/fbreader.

The proper way to fix that is to set PE = "1" in 0.8.17 and upward 
recipes. This will increase the package epoch making it always sort higher.

regards,

Koen

Re: Math is hard, but please pay attention to PV

[Koen Kooi]

Michael 'Mickey' Lauer wrote:
> Am Mittwoch, den 24.09.2008, 10:17 +0200 schrieb Koen Kooi:
>> Holger Freyther wrote:
>>> On Friday 19 September 2008 14:48:40 Koen Kooi wrote:
>>>
>>>> Anyway, PE has been bumped, things should work again this the next EFL
>>>> 'upgrade' happens. I just need to find a way to get the past 2 hours of
>>>> my life back.
>>> Thanks!
>> I just fixed linux-openmoko as well, '0' is _less_ than '7', so changing
>> PR from 'r7' to 'r0' is *bad*, I've increased it to 'r8' now.
>
>> Seriously, is math that hard for openmoko people?
>
> Much less the math but rather being used to reset PR on version updates.
> Alas this breaks with hash-based SCMs. I begin to regret the decision to
> use git in my projects.

What I'm wondering (and according to google Rod is wondering the same), 
are you actually testing package upgrades? My gta01 running angstrom 
needs a reimaging almost every time after an upgrade since 
openmoko/fso/efl stuff goes backwards in PV more that it goes forward.
I'm trying to keep[1] FSO up-to-date and working in angstrom, but I'm 
very close on giving up on that.

regards,

Koen

[1] I think I had it working a few months ago

Re: Math is hard, but please pay attention to PV

[Michael Krelin]

Michael 'Mickey' Lauer wrote:
> Am Mittwoch, den 24.09.2008, 10:17 +0200 schrieb Koen Kooi:
>> Holger Freyther wrote:
>>> On Friday 19 September 2008 14:48:40 Koen Kooi wrote:
>>>
>>>> Anyway, PE has been bumped, things should work again this the next EFL
>>>> 'upgrade' happens. I just need to find a way to get the past 2 hours of
>>>> my life back.
>>> Thanks!
>> I just fixed linux-openmoko as well, '0' is _less_ than '7', so changing 
>> PR from 'r7' to 'r0' is *bad*, I've increased it to 'r8' now.
> 
>> Seriously, is math that hard for openmoko people?
> 
> Much less the math but rather being used to reset PR on version updates.
> Alas this breaks with hash-based SCMs. I begin to regret the decision to
> use git in my projects.

What about using something like the output of `git describe --tags $(git 
rev-parse HEAD)` as a sortable key?

Love,
H

Re: Math is hard, but please pay attention to PV

[Holger Freyther]

On Wednesday 24 September 2008 11:15:53 Michael 'Mickey' Lauer wrote:
> Holger, can you please push your SRCPV changes so we can have sane PV
> also for those strange SCM which both lack increasing revision numbers
> as well as an idea of a day?
>
> I really don't want to see more workarounds in OE for git and friends.

I have send the proposal _twice_ without any feedback.

z.

Re: Math is hard, but please pay attention to PV

[Holger Freyther]

On Wednesday 24 September 2008 12:11:29 Michael Krelin wrote:

> What about using something like the output of `git describe --tags $(git
> rev-parse HEAD)` as a sortable key?

this requires that there is a tag in the history, it is not always true. :)

Re: Math is hard, but please pay attention to PV

[Holger Freyther]

On Wednesday 24 September 2008 12:11:00 Koen Kooi wrote:

> What I'm wondering (and according to google Rod is wondering the same),
> are you actually testing package upgrades? My gta01 running angstrom
> needs a reimaging almost every time after an upgrade since
> openmoko/fso/efl stuff goes backwards in PV more that it goes forward.
> I'm trying to keep[1] FSO up-to-date and working in angstrom, but I'm
> very close on giving up on that.

I test the upgrade path on org.openmoko.asu.stable. I don't know if and when 
XorA merged that back properly. At Openmoko we will have to establish going 
from the stable branch to org.openmoko.dev and John filed a ticket on the 
upgrade path.

z.

Re: Math is hard, but please pay attention to PV

[Michael Krelin]

> On Wednesday 24 September 2008 12:11:29 Michael Krelin wrote:
> 
>> What about using something like the output of `git describe --tags $(git
>> rev-parse HEAD)` as a sortable key?
> 
> this requires that there is a tag in the history, it is not always true. :)

That's true. In fact, I'm not well acquainted with the problem (like I 
thought it has to do with the sources fetched, but why would then 
mickeyl regret using git for *own* projects?). My point is - perhaps 
sometimes it's applicable and  then it could be used. A nice addition to 
git-describe would be counting from initial commit or the oldest merge 
if there's more than one ;-)

Love,
H