RFC: Upgrade OE.dev to bitbake 1.8.8

RFC: Upgrade OE.dev to bitbake 1.8.8

[Richard Purdie]

Hi,

There are lots of good changes in bitbake 1.8.8. Providing no major
issues are found with that bitbake release should we make it the minimum
version requirement for OE.dev in say two weeks? Any objections?

Regards,

Richard

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Khem Raj]

On 8/21/07, Richard Purdie <rpurdie@rpsys.net> wrote:
> Hi,
>
> There are lots of good changes in bitbake 1.8.8. Providing no major
> issues are found with that bitbake release should we make it the minimum
> version requirement for OE.dev in say two weeks? Any objections?

It builds angstrom-console-image for my arm targets. So the little I
use it for I have no objections. :)

>
> Regards,
>
> Richard
>
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Michael Krelin]

Works for me too, as far as I can tell. The package in question turned 
out to be pysqlite on gentoo (just for the record).

Love,
H

Richard Purdie wrote:
> Hi,
> 
> There are lots of good changes in bitbake 1.8.8. Providing no major
> issues are found with that bitbake release should we make it the minimum
> version requirement for OE.dev in say two weeks? Any objections?
> 
> Regards,
> 
> Richard
> 
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> Hi,
> 
> There are lots of good changes in bitbake 1.8.8. Providing no major
> issues are found with that bitbake release should we make it the minimum
> version requirement for OE.dev in say two weeks? Any objections?

Let's activate it on 20070904

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGzDdzMkyGM64RGpERAiTnAJ4oLpzp1ooBpt5EpxsYRoM1Jcc2wQCfZczH
N1lf6gH7oJEVFlvdpBfWsio=
=z44F
-----END PGP SIGNATURE-----

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Dr. Michael Lauer]

Koen Kooi wrote:
> Richard Purdie schreef:
>> Hi,
>> 
>> There are lots of good changes in bitbake 1.8.8. Providing no major
>> issues are found with that bitbake release should we make it the minimum
>> version requirement for OE.dev in say two weeks? Any objections?

> Let's activate it on 20070904

+1.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Leon Woestenberg]

Hello,

On 8/22/07, Dr. Michael Lauer <mickey@vanille-media.de> wrote:
> Koen Kooi wrote:
> > Richard Purdie schreef:
> >> Hi,
> >>
> >> There are lots of good changes in bitbake 1.8.8. Providing no major
> >> issues are found with that bitbake release should we make it the minimum
> >> version requirement for OE.dev in say two weeks? Any objections?
>
> > Let's activate it on 20070904
>
Are the OE->bitbake version-dependencies documented or tagged anywhere?

If not yet, I would propose to tag the OE repository with a tag like
"PRE-BITBAKE-1_8_8" or whatever is supported/desired for mtn/oe.

Regards,

Leon.

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Richard Purdie]

On Wed, 2007-08-29 at 23:21 +0200, Leon Woestenberg wrote:
> Are the OE->bitbake version-dependencies documented or tagged anywhere?
> 
> If not yet, I would propose to tag the OE repository with a tag like
> "PRE-BITBAKE-1_8_8" or whatever is supported/desired for mtn/oe.

$ cat conf/sanity.conf | grep VER
BB_MIN_VERSION = "1.8.5"

Cheers,

Richard

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Leon Woestenberg]

Hello Richard, all,

On 8/30/07, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Wed, 2007-08-29 at 23:21 +0200, Leon Woestenberg wrote:
> > Are the OE->bitbake version-dependencies documented or tagged anywhere?
> >
> > If not yet, I would propose to tag the OE repository with a tag like
> > "PRE-BITBAKE-1_8_8" or whatever is supported/desired for mtn/oe.
>
> $ cat conf/sanity.conf | grep VER
> BB_MIN_VERSION = "1.8.5"
>
This describes that, given a OE checkout, which bitbake I need minimally.

Now, suppose I have a given bitbake version, how do I find out which
OE revision should work with it?

My proposal is to tag the OE tree on 2007-09-03.

Regards,
-- 
Leon

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Michael Krelin]

>>> If not yet, I would propose to tag the OE repository with a tag like
>>> "PRE-BITBAKE-1_8_8" or whatever is supported/desired for mtn/oe.
>> $ cat conf/sanity.conf | grep VER
>> BB_MIN_VERSION = "1.8.5"
>>
> This describes that, given a OE checkout, which bitbake I need minimally.
> 
> Now, suppose I have a given bitbake version, how do I find out which
> OE revision should work with it?

mtn log? ;-)

> My proposal is to tag the OE tree on 2007-09-03.

It's not that I object the tag, but what's the use of it? I mean, I 
don't think OE is something you may possibly want to stick to old 
revision of?

Love,
H

Re: RFC: Upgrade OE.dev to bitbake 1.8.8

[Leon Woestenberg]

Michael,

On 8/30/07, Michael Krelin <hacker@klever.net> wrote:
> >>> If not yet, I would propose to tag the OE repository with a tag like
> >>> "PRE-BITBAKE-1_8_8" or whatever is supported/desired for mtn/oe.
> >> $ cat conf/sanity.conf | grep VER
> >> BB_MIN_VERSION = "1.8.5"
> >>
> > This describes that, given a OE checkout, which bitbake I need minimally.
> >
> > Now, suppose I have a given bitbake version, how do I find out which
> > OE revision should work with it?
>
> mtn log? ;-)
>
> > My proposal is to tag the OE tree on 2007-09-03.
>
> It's not that I object the tag, but what's the use of it? I mean, I
> don't think OE is something you may possibly want to stick to old
> revision of?
>

I found it too hard to combine
1) tracking OE changes
2) develop against OE.

time-wise in an environment where reproducability and deterministic
builds are top-priority. My current practice is to have both a frozen
and a current project for each target.

So yes, I would like to be able to freeze against something.  No
biggie though. Never mind my request,


-- 
Leon