OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Cliff Brake]

On Wed, Aug 18, 2010 at 4:30 AM, Martyn Welch <martyn.welch@ge.com> wrote:
> On 17/08/10 16:02, Cliff Brake wrote:
>>
>> I think it would be very useful to have a "stable" branch that is only
>> synchronised with dev when X number of targets build from a clean
>> build.  It seems like this would be high value, with little effort.
>> Of course there will be corner things that break, but at least a new
>> beagleboard user can check out something and have reasonable
>> confidence that it will build images.
>>
>> Does anyone have suggestions for the branch name and a reasonable
>> subset of machines and build targets?  Perhaps someone is already
>> running these clean builds?  At one point we had a machine at OSUOSL
>> dedicated to this purpose, but no one ever set it up.
>>
>
> So something like Debian's stable, testing and unstable[1]?

That sounds good to me -- so how about org.openembedded.dev and
org.openembedded.testing branches?

I'll plan to start doing a clean build of dev every Monday for the
Beagleboard, and then merge to testing once it builds.  Initial
targets:

Angstrom Distro
beagleboard/beagleboard-linuxtag2010-demo-image
x86/minimal-image

My workstation runs a 64-bit OS, so that is probably worst case
(compared to i686).

Getting started
(http://wiki.openembedded.net/index.php/Getting_started) points to a
tarball for bitbake 1.8.18.  Is this still the recommended
version/mechanism for new users?  I much prefer simply pulling bitbake
from git.

Thanks,
Cliff

-- 
=================
http://bec-systems.com

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Jason Kridner]

On Wed, Aug 18, 2010 at 11:07 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
> On Wed, Aug 18, 2010 at 4:30 AM, Martyn Welch <martyn.welch@ge.com> wrote:
>> On 17/08/10 16:02, Cliff Brake wrote:
>>>
>>> I think it would be very useful to have a "stable" branch that is only
>>> synchronised with dev when X number of targets build from a clean
>>> build.  It seems like this would be high value, with little effort.
>>> Of course there will be corner things that break, but at least a new
>>> beagleboard user can check out something and have reasonable
>>> confidence that it will build images.
>>>
>>> Does anyone have suggestions for the branch name and a reasonable
>>> subset of machines and build targets?  Perhaps someone is already
>>> running these clean builds?  At one point we had a machine at OSUOSL
>>> dedicated to this purpose, but no one ever set it up.
>>>
>>
>> So something like Debian's stable, testing and unstable[1]?
>
> That sounds good to me -- so how about org.openembedded.dev and
> org.openembedded.testing branches?
>
> I'll plan to start doing a clean build of dev every Monday for the
> Beagleboard, and then merge to testing once it builds.  Initial
> targets:
>
> Angstrom Distro
> beagleboard/beagleboard-linuxtag2010-demo-image
> x86/minimal-image
>
> My workstation runs a 64-bit OS, so that is probably worst case
> (compared to i686).
>
> Getting started
> (http://wiki.openembedded.net/index.php/Getting_started) points to a
> tarball for bitbake 1.8.18.  Is this still the recommended
> version/mechanism for new users?  I much prefer simply pulling bitbake
> from git.

Koen pointed me to
http://gitorious.org/angstrom/angstrom-setup-scripts/blobs/master/oebb.sh
for setting up my environment.  I also prefer pulling bitbake from
git.  Koen seems to be pulling bitbake 1.10, instead of 1.8.18.

>
> Thanks,
> Cliff
>
> --
> =================
> http://bec-systems.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Frans Meulenbroeks]

2010/8/18 Jason Kridner <jkridner@beagleboard.org>:
> On Wed, Aug 18, 2010 at 11:07 AM, Cliff Brake <cliff.brake@gmail.com> wrote:

>>
>> Getting started
>> (http://wiki.openembedded.net/index.php/Getting_started) points to a
>> tarball for bitbake 1.8.18.  Is this still the recommended
>> version/mechanism for new users?  I much prefer simply pulling bitbake
>> from git.
>
> Koen pointed me to
> http://gitorious.org/angstrom/angstrom-setup-scripts/blobs/master/oebb.sh
> for setting up my environment.  I also prefer pulling bitbake from
> git.  Koen seems to be pulling bitbake 1.10, instead of 1.8.18.
>
1.10 is now officially released and is supposed to be better and faster.
I think we should change the wiki page to reflect using 1.10

Frans

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Khem Raj]

On Wed, Aug 18, 2010 at 8:07 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
> On Wed, Aug 18, 2010 at 4:30 AM, Martyn Welch <martyn.welch@ge.com> wrote:
>> On 17/08/10 16:02, Cliff Brake wrote:
>>>
>>> I think it would be very useful to have a "stable" branch that is only
>>> synchronised with dev when X number of targets build from a clean
>>> build.  It seems like this would be high value, with little effort.
>>> Of course there will be corner things that break, but at least a new
>>> beagleboard user can check out something and have reasonable
>>> confidence that it will build images.
>>>
>>> Does anyone have suggestions for the branch name and a reasonable
>>> subset of machines and build targets?  Perhaps someone is already
>>> running these clean builds?  At one point we had a machine at OSUOSL
>>> dedicated to this purpose, but no one ever set it up.
>>>
>>
>> So something like Debian's stable, testing and unstable[1]?
>
> That sounds good to me -- so how about org.openembedded.dev and
> org.openembedded.testing branches?


simply 'testing' is good (we were to rename org.openembedded.dev to master)

>
> I'll plan to start doing a clean build of dev every Monday for the
> Beagleboard, and then merge to testing once it builds.  Initial
> targets:
>
> Angstrom Distro
> beagleboard/beagleboard-linuxtag2010-demo-image
> x86/minimal-image
>

All qemu targets build and run too. So adding some of (qemuarm
qemumips qemumipsel qemuppc qemux86
qemush4) will be good too.



> My workstation runs a 64-bit OS, so that is probably worst case
> (compared to i686).
>
> Getting started
> (http://wiki.openembedded.net/index.php/Getting_started) points to a
> tarball for bitbake 1.8.18.  Is this still the recommended
> version/mechanism for new users?  I much prefer simply pulling bitbake
> from git.

yes git would be better. You can also checkout 1.10 branch and use it if needed.

>
> Thanks,
> Cliff
>
> --
> =================
> http://bec-systems.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: OE stable, testing, dev

[Florian Boor]

Hi,

Cliff Brake schrieb:
>> So something like Debian's stable, testing and unstable[1]?
> 
> That sounds good to me -- so how about org.openembedded.dev and
> org.openembedded.testing branches?

great to see this finally happen, I remember we discussed this years ago.

> I'll plan to start doing a clean build of dev every Monday for the
> Beagleboard, and then merge to testing once it builds.  Initial
> targets:
> 
> Angstrom Distro
> beagleboard/beagleboard-linuxtag2010-demo-image
> x86/minimal-image

I would start to make use of it right now. Starting with builds for armv6 and
armv4t. I would use a different distribution (minimal maybe) for one of the
builds at least to see how this behaves.

> My workstation runs a 64-bit OS, so that is probably worst case
> (compared to i686).

Did you ever build on a PowerPC? :-)

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Denys Dmytriyenko]

On Wed, Aug 18, 2010 at 07:05:48PM +0200, Frans Meulenbroeks wrote:
> 2010/8/18 Jason Kridner <jkridner@beagleboard.org>:
> > On Wed, Aug 18, 2010 at 11:07 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
> 
> >>
> >> Getting started
> >> (http://wiki.openembedded.net/index.php/Getting_started) points to a
> >> tarball for bitbake 1.8.18.  Is this still the recommended
> >> version/mechanism for new users?  I much prefer simply pulling bitbake
> >> from git.
> >
> > Koen pointed me to
> > http://gitorious.org/angstrom/angstrom-setup-scripts/blobs/master/oebb.sh
> > for setting up my environment.  I also prefer pulling bitbake from
> > git.  Koen seems to be pulling bitbake 1.10, instead of 1.8.18.
> >
> 1.10 is now officially released and is supposed to be better and faster.
> I think we should change the wiki page to reflect using 1.10

1.10 is Python 2.6 based (AFAIK) and some people are not up to speed with 
that, i.e. using older distros with 2.5 or even 2.4...

-- 
Denys

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Esben Haabendal]

On 8/20/10, Denys Dmytriyenko <denis@denix.org> wrote:
> On Wed, Aug 18, 2010 at 07:05:48PM +0200, Frans Meulenbroeks wrote:
>> 2010/8/18 Jason Kridner <jkridner@beagleboard.org>:
>> > On Wed, Aug 18, 2010 at 11:07 AM, Cliff Brake <cliff.brake@gmail.com>
>> > wrote:
>>
>> >>
>> >> Getting started
>> >> (http://wiki.openembedded.net/index.php/Getting_started) points to a
>> >> tarball for bitbake 1.8.18.  Is this still the recommended
>> >> version/mechanism for new users?  I much prefer simply pulling bitbake
>> >> from git.
>> >
>> > Koen pointed me to
>> > http://gitorious.org/angstrom/angstrom-setup-scripts/blobs/master/oebb.sh
>> > for setting up my environment.  I also prefer pulling bitbake from
>> > git.  Koen seems to be pulling bitbake 1.10, instead of 1.8.18.
>> >
>> 1.10 is now officially released and is supposed to be better and faster.
>> I think we should change the wiki page to reflect using 1.10
>
> 1.10 is Python 2.6 based (AFAIK) and some people are not up to speed with
> that, i.e. using older distros with 2.5 or even 2.4...
>
> --
> Denys
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Esben Haabendal, Senior Software Consultant
DoréDevelopment ApS, Ved Stranden 1, 9560 Hadsund, DK-Denmark
Phone: +45 51 92 53 93, E-mail: eha@doredevelopment.dk
WWW: http://www.doredevelopment.dk

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Frans Meulenbroeks]

2010/8/18 Cliff Brake <cliff.brake@gmail.com>:
> On Wed, Aug 18, 2010 at 4:30 AM, Martyn Welch <martyn.welch@ge.com> wrote:
>> On 17/08/10 16:02, Cliff Brake wrote:
>>>
>>> I think it would be very useful to have a "stable" branch that is only
>>> synchronised with dev when X number of targets build from a clean
>>> build.  It seems like this would be high value, with little effort.
>>> Of course there will be corner things that break, but at least a new
>>> beagleboard user can check out something and have reasonable
>>> confidence that it will build images.
>>>
>>> Does anyone have suggestions for the branch name and a reasonable
>>> subset of machines and build targets?  Perhaps someone is already
>>> running these clean builds?  At one point we had a machine at OSUOSL
>>> dedicated to this purpose, but no one ever set it up.
>>>
>>
>> So something like Debian's stable, testing and unstable[1]?
>
> That sounds good to me -- so how about org.openembedded.dev and
> org.openembedded.testing branches?

Good plan!

>
> I'll plan to start doing a clean build of dev every Monday for the
> Beagleboard, and then merge to testing once it builds.  Initial
> targets:

Cool!
>
> Angstrom Distro
> beagleboard/beagleboard-linuxtag2010-demo-image
> x86/minimal-image

It would be nice to have some additional distro's (e.g. minimal, shr)
and machines (what would be a good coverage here) tested before it is
pushed
>
> My workstation runs a 64-bit OS, so that is probably worst case
> (compared to i686).
>
What OS? If you want to make things really nasty go to RHEL4 (but I
think most people would be fine with e.g. ubuntu 10.04)
Ideally you'd do this in a clean vm to make sure that there is no
dependency on whatever happens to be installed on your workstation for
other purposes.

Frans

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Gary Thomas]

On 08/21/2010 12:26 AM, Frans Meulenbroeks wrote:
> 2010/8/18 Cliff Brake<cliff.brake@gmail.com>:
>> On Wed, Aug 18, 2010 at 4:30 AM, Martyn Welch<martyn.welch@ge.com>  wrote:
>>> On 17/08/10 16:02, Cliff Brake wrote:
>>>>
>>>> I think it would be very useful to have a "stable" branch that is only
>>>> synchronised with dev when X number of targets build from a clean
>>>> build.  It seems like this would be high value, with little effort.
>>>> Of course there will be corner things that break, but at least a new
>>>> beagleboard user can check out something and have reasonable
>>>> confidence that it will build images.
>>>>
>>>> Does anyone have suggestions for the branch name and a reasonable
>>>> subset of machines and build targets?  Perhaps someone is already
>>>> running these clean builds?  At one point we had a machine at OSUOSL
>>>> dedicated to this purpose, but no one ever set it up.
>>>>
>>>
>>> So something like Debian's stable, testing and unstable[1]?
>>
>> That sounds good to me -- so how about org.openembedded.dev and
>> org.openembedded.testing branches?
>
> Good plan!
>
>>
>> I'll plan to start doing a clean build of dev every Monday for the
>> Beagleboard, and then merge to testing once it builds.  Initial
>> targets:
>
> Cool!
>>
>> Angstrom Distro
>> beagleboard/beagleboard-linuxtag2010-demo-image
>> x86/minimal-image
>
> It would be nice to have some additional distro's (e.g. minimal, shr)
> and machines (what would be a good coverage here) tested before it is
> pushed
>>
>> My workstation runs a 64-bit OS, so that is probably worst case
>> (compared to i686).
>>
> What OS? If you want to make things really nasty go to RHEL4 (but I
> think most people would be fine with e.g. ubuntu 10.04)
> Ideally you'd do this in a clean vm to make sure that there is no
> dependency on whatever happens to be installed on your workstation for
> other purposes.

Perhaps share this load?  I'd volunteer to make some tests using
my Fedora servers.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: OE stable, testing, dev (was Re: What to do about the poor bitbake Quality Control?)

[Koen Kooi]

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

On 20-08-10 02:02, Denys Dmytriyenko wrote:
> On Wed, Aug 18, 2010 at 07:05:48PM +0200, Frans Meulenbroeks wrote:
>> 2010/8/18 Jason Kridner <jkridner@beagleboard.org>:
>>> On Wed, Aug 18, 2010 at 11:07 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
>>
>>>>
>>>> Getting started
>>>> (http://wiki.openembedded.net/index.php/Getting_started) points to a
>>>> tarball for bitbake 1.8.18.  Is this still the recommended
>>>> version/mechanism for new users?  I much prefer simply pulling bitbake
>>>> from git.
>>>
>>> Koen pointed me to
>>> http://gitorious.org/angstrom/angstrom-setup-scripts/blobs/master/oebb.sh
>>> for setting up my environment.  I also prefer pulling bitbake from
>>> git.  Koen seems to be pulling bitbake 1.10, instead of 1.8.18.
>>>
>> 1.10 is now officially released and is supposed to be better and faster.
>> I think we should change the wiki page to reflect using 1.10
> 
> 1.10 is Python 2.6 based (AFAIK)

works fine with 2.5 over here (8.04LTS)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMcjU/MkyGM64RGpERAhSbAJwLAY/K429qH8Rq9OuPoFxJWxRVbgCfVwby
iLU4YAHHZHzYX3r00sSmNMg=
=RqVd
-----END PGP SIGNATURE-----