[Buildroot] Buildroot 2009.02 released

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

Hi,

Buildroot 2009.02 is released - Go download it at:

http://buildroot.uclibc.org/downloads/buildroot-2009.02.tar.gz

or

http://buildroot.uclibc.org/downloads/buildroot-2009.02.tar.bz2

It has been a long time coming, but we finally have a stable buildroot
release. This is not to say that there won't be any bugs, but we have
done a LOT of cleanups and bugfixes these last weeks, and it's IMHO a
good baseline.

As promised earlier, we are moving to a 3 month release cycle - So
expect the first release candidate of 2009.05 some time in late April,
and the final release mid May.

This release has a lot of old package versions marked as
deprecated. During the next development cycle a lot of those ancient
versions will be removed unless there's any real reason to not use the
more current versions. In other words, now is the time to shout if you
depend on something ancient, and the newer versions aren't working.

More specifically, expect to see non-sysroot versions of GCC
disappearing (<4.2.x), gdb <6.7, uClibc <0.9.29, kernel <2.6.25,
u-boot <2008.10 and busybox <1.12.x.

Thanks to everyone contributing and testing the release candidates!

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot 2009.02 released

[Hinko Kocevar]

Peter Korsgaard wrote:
> Hi,
> 
> Buildroot 2009.02 is released - Go download it at:
> 
> http://buildroot.uclibc.org/downloads/buildroot-2009.02.tar.gz
> 
> or
> 
> http://buildroot.uclibc.org/downloads/buildroot-2009.02.tar.bz2
> 

Building gdb for cris-v10 architecture fails with:

hecking for long double support in printf... no
checking for long double support in scanf... no
checking whether <sys/syscall.h> has __NR_tkill... yes
checking compiler warning flags...  -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts 
checking for cygwin... no
checking for ELF support in BFD... yes
checking for X... disabled
enable_sim = no
enableval = no
configure: error: "*** Gdb does not support native target cris-axis-linux-uclibc"
make[2]: *** [configure-gdb] Error 1
make[2]: Leaving directory `/work/uclibc.buildroot/buildroot-2009.02/build_cris/gdb-6.8-target'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/work/uclibc.buildroot/buildroot-2009.02/build_cris/gdb-6.8-target'
make: *** [/work/uclibc.buildroot/buildroot-2009.02/build_cris/gdb-6.8-target/gdb/gdb] Error 2

Are we missing uclibc config.guess and config.sub?

Regards, hinko

-- 
Hinko Ko?evar, OSS developer
?ETRTA POT, d.o.o.
Planina 3, 4000 Kranj, SI EU
tel     ++386 (0) 4 280 66 03
e-mail  hinko.kocevar at cetrtapot.si
http    www.cetrtapot.si

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:

Hi,

 Hinko> Building gdb for cris-v10 architecture fails with:

Ahh, seems like you should have tested the release candidates better
;)

 Hinko> make: *** [/work/uclibc.buildroot/buildroot-2009.02/build_cris/gdb-6.8-target/gdb/gdb] Error 2

 Hinko> Are we missing uclibc config.guess and config.sub?

No, gdk.mk does the CONFIG_UPDATE stuff, and
package/gnuconfig/config.guess seems to have have the cris entries.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot 2009.02 released

[Hinko Kocevar]

Peter Korsgaard wrote:
>>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:
> 
> Hi,
> 
>  Hinko> Building gdb for cris-v10 architecture fails with:
> 
> Ahh, seems like you should have tested the release candidates better
> ;)
> 

Yep ;)

Wait a minute - I selected the wrong option: gdb for target.
I wanted to build gdbserver for target, that does compile. IIRC, I saw
the error when building gdb for target!

>  Hinko> make: *** [/work/uclibc.buildroot/buildroot-2009.02/build_cris/gdb-6.8-target/gdb/gdb] Error 2
> 
>  Hinko> Are we missing uclibc config.guess and config.sub?
> 
> No, gdk.mk does the CONFIG_UPDATE stuff, and
> package/gnuconfig/config.guess seems to have have the cris entries.
> 

Right. I found the problem - gdb-6.8/gdb/config/cris and
related config files for native gdb are missing. I seem no one
ever tried native cris gdb. Not a big problem, as I'm used to
debug with gdbserver + host gdb.

Thank you,
Hinko

-- 
Hinko Ko?evar, OSS developer
?ETRTA POT, d.o.o.
Planina 3, 4000 Kranj, SI EU
tel     ++386 (0) 4 280 66 03
e-mail  hinko.kocevar at cetrtapot.si
http    www.cetrtapot.si

[Buildroot] Buildroot 2009.02 released

[Ulf Samuelsson]

>>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:
>
> Hi,
>
> Hinko> Building gdb for cris-v10 architecture fails with:
>
> Ahh, seems like you should have tested the release candidates better
> ;)
>

As far as I have seen, there has been very little testing activitiy going on 
before the release.
There are several packages that does not build, at least for ARM.
Several packages build but crash when you start the target.

Zero documentation on what builds and what does not build.

Zero documentation on what builds but does not run.

Maybe we could put some focus on these points.

Best Regards
Ulf Samuelsson

[Buildroot] Buildroot 2009.02 released

[Hamish Moffatt]

On Thu, Feb 12, 2009 at 10:22:07AM +0100, Peter Korsgaard wrote:
> Buildroot 2009.02 is released - Go download it at:

Well done all, and especially Peter for the final sprint work.



Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Buildroot 2009.02 released

[Thomas Petazzoni]

Le Thu, 12 Feb 2009 10:22:07 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> Buildroot 2009.02 is released - Go download it at:

Thanks Peter for all the good work. Having a stable buildroot release
is definitely a very good thing.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Buildroot 2009.02 released

[Hinko Kočevar]

----- Original Message -----
From: "Ulf Samuelsson" <ulf.samuelsson@atmel.com>
To: "Hinko Kocevar" <hinko.kocevar@cetrtapot.si>, "Peter Korsgaard" <jacmet@uclibc.org>
Cc: buildroot at uclibc.org
Sent: Thursday, February 12, 2009 7:11:24 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Buildroot] Buildroot 2009.02 released


>>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:
>
> Hi,
>
> Hinko> Building gdb for cris-v10 architecture fails with:
>
> Ahh, seems like you should have tested the release candidates better
> ;)
>

As far as I have seen, there has been very little testing activitiy going on 
before the release.
There are several packages that does not build, at least for ARM.
Several packages build but crash when you start the target.

Zero documentation on what builds and what does not build.

Zero documentation on what builds but does not run.

True.

Maybe we could put some focus on these points.

I'll try to steal some time to try out basic packages (for starters) that build & run on cris-v10 arch. That's the only embedded arch I can test.

What about he packages that can not be built for some specific arch, for some reason or another (too few resources CPU, mem, flash, ..)? Should they be marked or noted somehow to inform us about its status on selected arch?

Regards,
Hinko


-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

>>>>> "Hinko" == Hinko Ko?evar <hinko.kocevar@cetrtapot.si> writes:

Hi,

 Hinko> I'll try to steal some time to try out basic packages (for
 Hinko> starters) that build & run on cris-v10 arch. That's the only
 Hinko> embedded arch I can test.

Good, I don't believe we have many others testing cris.

 Hinko> What about he packages that can not be built for some specific
 Hinko> arch, for some reason or another (too few resources CPU, mem,
 Hinko> flash, ..)? Should they be marked or noted somehow to inform
 Hinko> us about its status on selected arch?

Well, lets differenciate between stuff that doesn't build for a given
arch, and things that don't make sense to run (E.G. no graphical
output, no sound, lack of RAM, ..). The first thing I think we should
either hide or mark as broken in Kconfig, but the 2nd very much
depends on your specific board.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> Ahh, seems like you should have tested the release candidates better
 >> ;)
 >> 

 Ulf> As far as I have seen, there has been very little testing activitiy
 Ulf> going on before the release.

Some testing was certainly done, but more is ofcourse always welcome.

 Ulf> There are several packages that does not build, at least for ARM.

Well, let's work on them then. Please start by providing a list -
Either here or as bugtracker issues.

 Ulf> Several packages build but crash when you start the target.

Again, which ones?

 Ulf> Zero documentation on what builds and what does not build.

Everything (in the default versions atleast) is supposed to build,
what doesn't?

 Ulf> Zero documentation on what builds but does not run.

Which ones?

 Ulf> Maybe we could put some focus on these points.

Sure, but please be a bit more specific.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot 2009.02 released

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> Hi,
>
> >> Ahh, seems like you should have tested the release candidates better
> >> ;)
> >>
>
> Ulf> As far as I have seen, there has been very little testing activitiy
> Ulf> going on before the release.
>
> Some testing was certainly done, but more is ofcourse always welcome.
>

I am not aware that anyone but myself has published any test results.
There is no recommended way to publish test results.
No recommended format etc.

Once it is discovered that there is a problem, there is no clean
way to inform the user that there is a problem with a certain
package so each new user will waste a lot of time trying
to build what is known to be broken.

Depending on BROKEN is wrong if it builds for other architectures,
and as mentioned before, if a package is broken due to references
to the host files instead of target files they can still build
if the host has the same settings as buildroot.

> Ulf> There are several packages that does not build, at least for ARM.
>
> Well, let's work on them then. Please start by providing a list -
> Either here or as bugtracker issues.
>

My docs/buildall.sh has comments on what is broken for ARM.

I think that running this for different architectures will show if they 
build or not.

As for running different applications, I hear that gtk does not run,
but I dont extensively test applications.



> Ulf> Several packages build but crash when you start the target.
>
> Again, which ones?
>
> Ulf> Zero documentation on what builds and what does not build.
>
> Everything (in the default versions atleast) is supposed to build,
> what doesn't?
>
> Ulf> Zero documentation on what builds but does not run.
>
> Which ones?
>
> Ulf> Maybe we could put some focus on these points.
>
> Sure, but please be a bit more specific.


I think it is amateurish  to just go about trying to fix issues.
We need to establish the structure for how we test,
how we publish what we test and how we mark
packages with problem so that users do not waste their time.


> -- 
> Bye, Peter Korsgaard
>



Best Regards
Ulf Samuelsson 

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> Some testing was certainly done, but more is ofcourse always welcome.

 Ulf> I am not aware that anyone but myself has published any test results.

I did for the toolchains, and for everything else I just fixed the
problems when I found any.

 Ulf> There is no recommended way to publish test results.
 Ulf> No recommended format etc.

Sure, like with all other issues - Add an issue to the tracker or mail
the list, both preferably with a patch.

 Ulf> Once it is discovered that there is a problem, there is no clean
 Ulf> way to inform the user that there is a problem with a certain
 Ulf> package so each new user will waste a lot of time trying
 Ulf> to build what is known to be broken.

Well, if you mail the list or add an issue, there is.

 Ulf> Depending on BROKEN is wrong if it builds for other architectures,

Yes, it should be depends on BROKEN if BR2_<arch> ofcourse.

 Ulf> There are several packages that does not build, at least for ARM.
 >> 
 >> Well, let's work on them then. Please start by providing a list -
 >> Either here or as bugtracker issues.
 >> 

 Ulf> My docs/buildall.sh has comments on what is broken for ARM.

And as I commented several times, your setup is not representative for
normal buildroot users as several packages that didn't build with your
script builds just fine in a normal buildroot setup.

 Ulf> I think that running this for different architectures will show if
 Ulf> they build or not.

 Ulf> As for running different applications, I hear that gtk does not run,
 Ulf> but I dont extensively test applications.

I used it ~1 month ago on ARM without problems. If you find problems,
then please report them to the list / tracker.

 Ulf> Maybe we could put some focus on these points.
 >> 
 >> Sure, but please be a bit more specific.

 Ulf> I think it is amateurish  to just go about trying to fix issues.
 Ulf> We need to establish the structure for how we test,
 Ulf> how we publish what we test and how we mark
 Ulf> packages with problem so that users do not waste their time.

Heh, I would certainly prefer to spend our energy on actually fixing
stuff than arguing about how to show what's broken. Everything broken
is a bug, and bugs should get fixed.

Again, please use the bug tracker.

I'm not against doing more structured build tests, and will look into
getting buildbot running again with some sensible defconfigs soonish,
but that shouldn't stop you or anyone else from reporting (and fixing)
bugs.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot 2009.02 released

[Ulf Samuelsson]

fre 2009-02-20 klockan 09:23 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
>  >> Some testing was certainly done, but more is ofcourse always welcome.
> 
>  Ulf> I am not aware that anyone but myself has published any test results.
> 
> I did for the toolchains, and for everything else I just fixed the
> problems when I found any.
> 
>  Ulf> There is no recommended way to publish test results.
>  Ulf> No recommended format etc.
> 
> Sure, like with all other issues - Add an issue to the tracker or mail
> the list, both preferably with a patch.

You REALLY dont get it , do you?

If you for once stopped seeing Buildroot as a hobby
and take the view of someone wanting to build 
a root file system without digging deep into 
the internals of Buildroot, then you would realize
that Bugzilla is NOT the way this shoudl be communicated.

You want to know what builds and what doesn't.
If it does not build, then you do not even want 
to try to build it.

Bugzilla is useful to document what goes wrong.
For users, you want a simple yes/no answer if this builds or not.


>  Ulf> Once it is discovered that there is a problem, there is no clean
>  Ulf> way to inform the user that there is a problem with a certain
>  Ulf> package so each new user will waste a lot of time trying
>  Ulf> to build what is known to be broken.
> 
> Well, if you mail the list or add an issue, there is.

Not in a usable format.

> 
>  Ulf> Depending on BROKEN is wrong if it builds for other architectures,
> 
> Yes, it should be depends on BROKEN if BR2_<arch> ofcourse.
> 
>  Ulf> There are several packages that does not build, at least for ARM.
>  >> 
>  >> Well, let's work on them then. Please start by providing a list -
>  >> Either here or as bugtracker issues.
>  >> 
> 
>  Ulf> My docs/buildall.sh has comments on what is broken for ARM.
> 
> And as I commented several times, your setup is not representative for
> normal buildroot users as several packages that didn't build with your
> script builds just fine in a normal buildroot setup.

There are dependencies on the host distribution.
I have seen that some packages sometimes use the host includes.

If the host includes do things in the same way as the buildroot
includes that should have been used, then the build can
complete, even though the package is inherently BROKEN.

If they are different, then the build breaks.


> 
>  Ulf> I think that running this for different architectures will show if
>  Ulf> they build or not.
> 
>  Ulf> As for running different applications, I hear that gtk does not run,
>  Ulf> but I dont extensively test applications.
> 
> I used it ~1 month ago on ARM without problems. If you find problems,
> then please report them to the list / tracker.

>  Ulf> Maybe we could put some focus on these points.
>  >> 
>  >> Sure, but please be a bit more specific.

I think we should create a range of rootfs definitions
with reasonable combinations for testing purposes.

* Busybox only.
* A communications oriented (no graphics)
  Maybe an Internet Radio /Audio player
* DirectFB with a simple touch interface
* X-Windows

This should be tested on multiple distributions
(Ubuntu/Fedora/OpenSuSE etc.).

We then need to define certain tests that needs to be run on the target.

The result should be published as web pages in docs

> 
>  Ulf> I think it is amateurish  to just go about trying to fix issues.
>  Ulf> We need to establish the structure for how we test,
>  Ulf> how we publish what we test and how we mark
>  Ulf> packages with problem so that users do not waste their time.
> 
> Heh, I would certainly prefer to spend our energy on actually fixing
> stuff than arguing about how to show what's broken. Everything broken
> is a bug, and bugs should get fixed.
> 

That is because either you do not care about others
or you do not grip the situation.
Do you think that if buildroot was a commercial tool
that people would accept your opinion, or would they
go to someone more interested in their problems?

I want to spend my energy on making it easier for people 
without too much knowledge to get an embedded linux system
running and telling people up front what works and does not work
is key to get acceptance.

Bugs needs to be fixed, as time permits,
but if that is the only support provided, then this
is no tool for anything but hobbyists like yourself.


> Again, please use the bug tracker.
> 
> I'm not against doing more structured build tests, and will look into
> getting buildbot running again with some sensible defconfigs soonish,
> but that shouldn't stop you or anyone else from reporting (and fixing)
> bugs.
> 

It is not enough to report and fix bugs.
BR
Ulf Samuelsson

[Buildroot] Buildroot 2009.02 released

[Frank Hoeflich]

Ulf:

>fre 2009-02-20 klockan 09:23 +0100 skrev Peter Korsgaard:
>> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>> 
>> Hi,
>> 
>>? >> Some testing was certainly done, but more is ofcourse always welcome.
>> 
>>? Ulf> I am not aware that anyone but myself has published any test results.
>> 
>> I did for the toolchains, and for everything else I just fixed the
>> problems when I found any.
>> 
>>? Ulf> There is no recommended way to publish test results.
>>? Ulf> No recommended format etc.
>> 
>> Sure, like with all other issues - Add an issue to the tracker or mail
>> the list, both preferably with a patch.
>
>You REALLY dont get it , do you?
>
>If you for once stopped seeing Buildroot as a hobby
>and take the view of someone wanting to build 
>a root file system without digging deep into 
>the internals of Buildroot, then you would realize
>that Bugzilla is NOT the way this shoudl be communicated.
>
??? OK, enough.? Ulf, I am asking you to stop taking this tone with Peter (and for that matter the rest of us).

??? FWIW I agree with you (and more) that:
??? 1. Buildroot needs a real test plan for the new releases, and some method of
??????? distributing the test suite so that list members can contribute new individual tests as
??????? they see fit in order to fill out the BR test suite.
??? 2. Buildroot should meet its (reasonable) release test plan criteria before a release goes
??????? out the door, like any other software package worth its salt.? For now these could be
??????? pretty modest.
??? 3. Buildroot test results should be published and visible on the web and should cleanly
??????? hyperlink or otherwise refer back to test plan requirements.? Once the list agrees on a
??????? format for results it should be documented in the test plan.
??? 4. Buildroot test vectors should certainly include a reasonable selection of default
??????? configs, a representative set of architectures, host distributions and more.

??? However, I do *not* agree that:
??? 1. Anyone active on this list is treating BR like a hobby.? Nor is it like a commercial
??????? product for which users may expect polished manuals and 24x7 support for their
??????? RTFM questions.? It's an open source project; users need to be willing and able to
??????? follow the list and/or query Bugzilla in order to check that something they're seeing is
??????? a known issue.
??? 2. Issues posted to Bugzilla are not `in a usable format'.? They are searchable, are
??????? capable of being well-documented, may contain descriptive attachments as needed
??????? and have adequate flags for prioritisation and status.
??? 3. BR development should be targeted toward users `without too much knowledge'.
??????? Such users can always hire an active developer as an interpreter/jungle guide.? Linux
??????? and most of the open source world do not lend themselves at all well to users without
??????? a reasonable amount of hands-on knowledge.? `Fixing' that would mean grinding a
??????? much larger axe, I think.
??? 4. All of the testing and documentation issues mentioned should have been addressed
??????? in Buildroot's first release in years.? If this release serves 80%+ of the BR public
??????? with workaroundable annoyance only pending a next release of better stability, it will
??????? have done its job.? Getting to metricatable quality may take quite some time.

??? It may be that buildbot can nearly accommodate all of this now, or it may be that a good deal of further development is needed.

>You want to know what builds and what doesn't.
>If it does not build, then you do not even want 
>to try to build it.
>
>Bugzilla is useful to document what goes wrong.
>For users, you want a simple yes/no answer if this builds or not.
>
>>? Ulf> Once it is discovered that there is a problem, there is no clean
>>? Ulf> way to inform the user that there is a problem with a certain
>>? Ulf> package so each new user will waste a lot of time trying
>>? Ulf> to build what is known to be broken.
> >
>> Well, if you mail the list or add an issue, there is.
>
>Not in a usable format.
>
>>? Ulf> Depending on BROKEN is wrong if it builds for other architectures,
>> 
>> Yes, it should be depends on BROKEN if BR2_<arch> ofcourse.
>> 
>>? Ulf> There are several packages that does not build, at least for ARM.
>>? >> 
>>? >> Well, let's work on them then. Please start by providing a list -
>>? >> Either here or as bugtracker issues.
>>? >> 
>> 
>>? Ulf> My docs/buildall.sh has comments on what is broken for ARM.
>> 
>> And as I commented several times, your setup is not representative for
>> normal buildroot users as several packages that didn't build with your
>> script builds just fine in a normal buildroot setup.
>
>There are dependencies on the host distribution.
>I have seen that some packages sometimes use the host includes.
>
>If the host includes do things in the same way as the buildroot
>includes that should have been used, then the build can
>complete, even though the package is inherently BROKEN.
>
>If they are different, then the build breaks.
>
>
>> 
>>? Ulf> I think that running this for different architectures will show if
>>? Ulf> they build or not.
>> 
>>? Ulf> As for running different applications, I hear that gtk does not run,
>>? Ulf> but I dont extensively test applications.
>> 
>> I used it ~1 month ago on ARM without problems. If you find problems,
>> then please report them to the list / tracker.
>
>>? Ulf> Maybe we could put some focus on these points.
>>? >> 
>>? >> Sure, but please be a bit more specific.
>
>I think we should create a range of rootfs definitions
>with reasonable combinations for testing purposes.
>
>* Busybox only.
>* A communications oriented (no graphics)
>? Maybe an Internet Radio /Audio player
>* DirectFB with a simple touch interface
>* X-Windows
>
>This should be tested on multiple distributions
>(Ubuntu/Fedora/OpenSuSE etc.).
>
>We then need to define certain tests that needs to be run on the target.
>
>The result should be published as web pages in docs
>
>>? Ulf> I think it is amateurish? to just go about trying to fix issues.
>>? Ulf> We need to establish the structure for how we test,
>>? Ulf> how we publish what we test and how we mark
>>? Ulf> packages with problem so that users do not waste their time.
>> 
>> Heh, I would certainly prefer to spend our energy on actually fixing
>> stuff than arguing about how to show what's broken. Everything broken
>> is a bug, and bugs should get fixed.
>>
>That is because either you do not care about others
>or you do not grip the situation.
>Do you think that if buildroot was a commercial tool
>that people would accept your opinion, or would they
>go to someone more interested in their problems?
>
>I want to spend my energy on making it easier for people 
>without too much knowledge to get an embedded linux system
>running and telling people up front what works and does not work
>is key to get acceptance.
>
>Bugs needs to be fixed, as time permits,
>but if that is the only support provided, then this
>is no tool for anything but hobbyists like yourself.
>
>> Again, please use the bug tracker.
>> 
>> I'm not against doing more structured build tests, and will look into
>> getting buildbot running again with some sensible defconfigs soonish,
>> but that shouldn't stop you or anyone else from reporting (and fixing)
>> bugs.
>>
>It is not enough to report and fix bugs.
>BR
>Ulf Samuelsson

--Frank



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090221/545ef610/attachment.htm>

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> Sure, like with all other issues - Add an issue to the tracker or
 >> mail the list, both preferably with a patch.

 Ulf> You REALLY dont get it , do you?

No, I think it's pretty obvious that I don't follow you.

 Ulf> If you for once stopped seeing Buildroot as a hobby
 Ulf> and take the view of someone wanting to build 
 Ulf> a root file system without digging deep into 
 Ulf> the internals of Buildroot, then you would realize
 Ulf> that Bugzilla is NOT the way this shoudl be communicated.

You seem to be mixing up developer/contributor communication such as
mailing list/bugzilla and some kind of known issues list for a release
(E.G. stuff that belongs in the release notes).

Issues needs to be reported / patches sent to the developers if you
want to get them solved - E.G. this is absolutely critical to improve
BR quality.

And sure, it could be that we decide to ship with known issues and
those should get mentioned in the release notes, but most of all we
try to fix all bugs we KNOW ABOUT.

 Ulf> Once it is discovered that there is a problem, there is no clean
 Ulf> way to inform the user that there is a problem with a certain
 Ulf> package so each new user will waste a lot of time trying
 Ulf> to build what is known to be broken.

That's what releases are for - With a 3 month release cycle I don't
see any real reason for casual / first time users to go to svn.

 >> Well, if you mail the list or add an issue, there is.

 Ulf> Not in a usable format.

For the developers it is.

 Ulf> There are dependencies on the host distribution.
 Ulf> I have seen that some packages sometimes use the host includes.

 Ulf> If the host includes do things in the same way as the buildroot
 Ulf> includes that should have been used, then the build can
 Ulf> complete, even though the package is inherently BROKEN.

 Ulf> If they are different, then the build breaks.

Yes, bug reports and patches are welcome.

 >> >> Sure, but please be a bit more specific.

 Ulf> I think we should create a range of rootfs definitions
 Ulf> with reasonable combinations for testing purposes.

 Ulf> * Busybox only.
 Ulf> * A communications oriented (no graphics)
 Ulf>   Maybe an Internet Radio /Audio player
 Ulf> * DirectFB with a simple touch interface
 Ulf> * X-Windows

 Ulf> This should be tested on multiple distributions
 Ulf> (Ubuntu/Fedora/OpenSuSE etc.).

Are you offering to do this? As always, talk is cheap and actions
speak louder than words.

 >> Heh, I would certainly prefer to spend our energy on actually
 >> fixing stuff than arguing about how to show what's
 >> broken. Everything broken is a bug, and bugs should get fixed.

 Ulf> That is because either you do not care about others
 Ulf> or you do not grip the situation.

I don't see you helping people on the mailing list or fixing issues in
the bugtracker, so don't give me that 'you don't care about others'.

 Ulf> Do you think that if buildroot was a commercial tool
 Ulf> that people would accept your opinion, or would they
 Ulf> go to someone more interested in their problems?

People are free to go elsewhere (so are you), that's the basic concept
of open source.

 Ulf> I want to spend my energy on making it easier for people 
 Ulf> without too much knowledge to get an embedded linux system
 Ulf> running and telling people up front what works and does not work
 Ulf> is key to get acceptance.

 Ulf> Bugs needs to be fixed, as time permits,
 Ulf> but if that is the only support provided, then this
 Ulf> is no tool for anything but hobbyists like yourself.

Hobbyist == care about quality? Yes, then I'm definately a hobbyist.

 >> Again, please use the bug tracker.
 >> 
 >> I'm not against doing more structured build tests, and will look into
 >> getting buildbot running again with some sensible defconfigs soonish,
 >> but that shouldn't stop you or anyone else from reporting (and fixing)
 >> bugs.

 Ulf> It is not enough to report and fix bugs.

No, that's why I'm doing releases - Nevertheless, fixing bugs is
absolutely critical. Are you going to contribute or just continue
to make noise on the list?

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot 2009.02 released

[Ulf Samuelsson]

----- Original Message ----- 
From: "Peter Korsgaard" <jacmet@uclibc.org>
To: <ulf.samuelsson@atmel.com>
Cc: "Peter Korsgaard" <jacmet@uclibc.org>; <buildroot@uclibc.org>
Sent: Sunday, February 22, 2009 10:47 AM
Subject: Re: [Buildroot] Buildroot 2009.02 released


>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> Hi,
>
> >> Sure, like with all other issues - Add an issue to the tracker or
> >> mail the list, both preferably with a patch.
>
> Ulf> You REALLY dont get it , do you?
>
> No, I think it's pretty obvious that I don't follow you.
>
> Ulf> If you for once stopped seeing Buildroot as a hobby
> Ulf> and take the view of someone wanting to build
> Ulf> a root file system without digging deep into
> Ulf> the internals of Buildroot, then you would realize
> Ulf> that Bugzilla is NOT the way this shoudl be communicated.
>
> You seem to be mixing up developer/contributor communication such as
> mailing list/bugzilla and some kind of known issues list for a release
> (E.G. stuff that belongs in the release notes).
>

No, I am not mixing up things.
This thread is about how a release should look like.
You are mixing this up with how to ensure a package is working.

Bugzilla shows that a package is not working.
It does not show that a package is working.
The fact that you can build something on your machine
does not mean that it can build on other machines.

What you are doing is creating a *snaphot* without going through
a proper testing procedure, and the call it a release.


> Issues needs to be reported / patches sent to the developers if you
> want to get them solved - E.G. this is absolutely critical to improve
> BR quality.

Yes, but there is no documentation what works so you have no clue
what has been tested and what has not been tested.

>
> And sure, it could be that we decide to ship with known issues and
> those should get mentioned in the release notes, but most of all we
> try to fix all bugs we KNOW ABOUT.
>

> Ulf> Once it is discovered that there is a problem, there is no clean
> Ulf> way to inform the user that there is a problem with a certain
> Ulf> package so each new user will waste a lot of time trying
> Ulf> to build what is known to be broken.
>
> That's what releases are for - With a 3 month release cycle I don't
> see any real reason for casual / first time users to go to svn.

Undocumented releases are only a little better than svn

>
> >> Well, if you mail the list or add an issue, there is.
>
> Ulf> Not in a usable format.
>
> For the developers it is.

You are well aware that I am discussing non-developers.

>
> Ulf> There are dependencies on the host distribution.
> Ulf> I have seen that some packages sometimes use the host includes.
>
> Ulf> If the host includes do things in the same way as the buildroot
> Ulf> includes that should have been used, then the build can
> Ulf> complete, even though the package is inherently BROKEN.
>
> Ulf> If they are different, then the build breaks.
>
> Yes, bug reports and patches are welcome.
>
> >> >> Sure, but please be a bit more specific.
>
> Ulf> I think we should create a range of rootfs definitions
> Ulf> with reasonable combinations for testing purposes.
>
> Ulf> * Busybox only.
> Ulf> * A communications oriented (no graphics)
> Ulf>   Maybe an Internet Radio /Audio player
> Ulf> * DirectFB with a simple touch interface
> Ulf> * X-Windows
>
> Ulf> This should be tested on multiple distributions
> Ulf> (Ubuntu/Fedora/OpenSuSE etc.).
>
> Are you offering to do this? As always, talk is cheap and actions
> speak louder than words.

I have already created a framework for testing, and I have provided test 
results
for ARM on OpenSuSE 11.0. Is that loud enough for you?

I do not consider it to be complete and I do not plan to test on another 
host,
but I am prepared to extend or modify to meet other people requirements.
If people are encouraged to test vs a real framework, and to documents
the results, by making it easy to do so, then the other hosts/archs
will get documented.

You, on the other hands has always shown that you are against all attempts
to include selftesting functionality and are only talking about it, while
keeping on using the same old building defconfigs which does not
result in a comprehensive testreport.

>
> >> Heh, I would certainly prefer to spend our energy on actually
> >> fixing stuff than arguing about how to show what's
> >> broken. Everything broken is a bug, and bugs should get fixed.
>

I think we need to 
When you stop to resist adding selftest in the svn which can automatically
document whats broken and what is not, then
we can go on to the implementation stage.

> Ulf> That is because either you do not care about others
> Ulf> or you do not grip the situation.
>
> I don't see you helping people on the mailing list or fixing issues in
> the bugtracker, so don't give me that 'you don't care about others'.

Which of course does not mean that I am not fixing bugs.

>
> Ulf> Do you think that if buildroot was a commercial tool
> Ulf> that people would accept your opinion, or would they
> Ulf> go to someone more interested in their problems?
>
> People are free to go elsewhere (so are you), that's the basic concept
> of open source.
>
> Ulf> I want to spend my energy on making it easier for people
> Ulf> without too much knowledge to get an embedded linux system
> Ulf> running and telling people up front what works and does not work
> Ulf> is key to get acceptance.
>
> Ulf> Bugs needs to be fixed, as time permits,
> Ulf> but if that is the only support provided, then this
> Ulf> is no tool for anything but hobbyists like yourself.
>
> Hobbyist == care about quality? Yes, then I'm definately a hobbyist.

You have a very limited scope which drives the project towards
something that is useful for the initiated, but is hostile towards others
This results in something where the overall quality is poor
and your arrogance is not promising for the future.

Hobbyist can make important contributions, but noone can rely on
something which is driven by a hobbyist approach for a real project.

>
> >> Again, please use the bug tracker.
> >>
> >> I'm not against doing more structured build tests, and will look into
> >> getting buildbot running again with some sensible defconfigs soonish,
> >> but that shouldn't stop you or anyone else from reporting (and fixing)
> >> bugs.
>
> Ulf> It is not enough to report and fix bugs.
>
> No, that's why I'm doing releases - Nevertheless, fixing bugs is
> absolutely critical. Are you going to contribute or just continue
> to make noise on the list?

You are providing poorly tested SNAPSHOTS which you call a release.

As for contributing, I think that I both increase functionality, and fix 
bugs.
I am also the only one to provide test results.



>
> -- 
> Bye, Peter Korsgaard
>


Best Regards
Ulf Samuelsson

[Buildroot] Buildroot 2009.02 released

[Ulf Samuelsson]

----- Original Message ----- 
  From: Frank Hoeflich 
  To: Ulf Samuelsson 
  Cc: buildroot at busybox.net 
  Sent: Sunday, February 22, 2009 8:22 AM
  Subject: Re: [Buildroot] Buildroot 2009.02 released


        Ulf:

        >fre 2009-02-20 klockan 09:23 +0100 skrev Peter Korsgaard:
        >> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
        >> 
        >> Hi,
        >> 
        >>  >> Some testing was certainly done, but more is ofcourse always welcome.
        >> 
        >>  Ulf> I am not aware that anyone but myself has published any test results.
        >> 
        >> I did for the toolchains, and for everything else I just fixed the
        >> problems when I found any.
        >> 
        >>  Ulf> There is no recommended way to publish test results.
        >>  Ulf> No recommended format etc.
        >> 
        >> Sure, like with all other issues - Add an issue to the tracker or mail
        >> the list, both preferably with a patch.
        >
        >You REALLY dont get it , do you?
        >
        >If you for once stopped seeing Buildroot as a hobby
        >and take the view of someone wanting to build 
        >a root file system without digging deep into 
        >the internals of Buildroot, then you would realize
        >that Bugzilla is NOT the way this shoudl be communicated.
        >
            OK, enough.  Ulf, I am asking you to stop taking this tone with Peter (and for that matter the rest of us).

            FWIW I agree with you (and more) that:
            1. Buildroot needs a real test plan for the new releases, and some method of
                distributing the test suite so that list members can contribute new individual tests as
                they see fit in order to fill out the BR test suite.

        The traditional way of testing buildroot is to make a "defconfig".
        I came to the conclusion that doing this is no good, since this will crash 
        on the first build error, and you will lose valuable time.
        It is also hard to get a nice log for each package.

        make <package> from the command line should work (assuming the .config file is OK)
        and that is why I generated the build script which goes through a number of packages
        and builds them printing out the result.

        I think the first decision we need to make, is if we can use defconfigs or not
        to fulfil a testplan.

        If we decide not to use the defconfigs, then we need to decide 
        how to implement package specific testing.
        Do we continue to use bash scripts, or do we use python or similar.

        My build script creates a result file which indicates if the package built OK or not OK.
        Not in html/xml format, which is a weakness,at first sight.
        We need to decide on the format of the test reports as well as the format of the
        documentation.

        For each package, it creates a build log which is moved to either
        log/OK or log/FAIL depending on success.
        I think we should consider making build reports available on a web server.

            2. Buildroot should meet its (reasonable) release test plan criteria before a release goes
                out the door, like any other software package worth its salt.  For now these could be
                pretty modest.

        So we need to agree on which host distributions we want to support,
        and then we need to have a list of reasonable combinations of packages/kernels

        Once the list of packages is available, then you could make a number of defconfigs,
        or you can forceenable each package by a select statement in the test harness.
        By introducing a package specific depend on !BR2_PACKAGE_<PACKAGE>_DISABLE
        you will have total control and ensure that you build identically root file systems
        for each archtiecture/host
        That is also a key decision.

        What is then lacking is any real test on H/W.
        It is nice if the package, build but that is no good, if the 
        end result does not boot, or does not behave as expected.

        Since some people may lack hardware but still be interested in helping
        building on a host, it would be good to publish binaries,
        which can be downloaded to targets and tested by others
        having access to the board

        We need to develop some kind of tests that uses the key functionality.


            3. Buildroot test results should be published and visible on the web and should cleanly
                hyperlink or otherwise refer back to test plan requirements.  Once the list agrees on a
                format for results it should be documented in the test plan.


            4. Buildroot test vectors should certainly include a reasonable selection of default
                configs, a representative set of architectures, host distributions and more.

            However, I do *not* agree that:
            1. Anyone active on this list is treating BR like a hobby.  Nor is it like a commercial
                product for which users may expect polished manuals and 24x7 support for their
                RTFM questions.  It's an open source project; users need to be willing and able to
                follow the list and/or query Bugzilla in order to check that something they're seeing is
                a known issue.

        Your comments above certainly shows that you see the problem with the current approach.
        I believe that the goal should be that noone sees any issues at all, unless they are
        interested in becoming a developer and contribute.
        This goal might not be shared by others, but it is sad, if people are against making
        Buildroot easier to use.

        For this to work, I think there is a need for configuration of user properties in buildroot.
        User properties are distinct from project properties, and should therefore not be 
        in the defconfigs.


            2. Issues posted to Bugzilla are not `in a usable format'.  They are searchable, are
                capable of being well-documented, may contain descriptive attachments as needed
                and have adequate flags for prioritisation and status.

        The context for this discussion, is how users perceive Buildroot.
        Bugzilla/mailing list is excellent to help resolve a problem, but is fairly 
        useless/timeconsuming if you want to figure out what will run and what will not.

            3. BR development should be targeted toward users `without too much knowledge'.
                Such users can always hire an active developer as an interpreter/jungle guide.  Linux
                and most of the open source world do not lend themselves at all well to users without
                a reasonable amount of hands-on knowledge.  `Fixing' that would mean grinding a
                much larger axe, I think.

        When design decisions are made, you often have a several ways to implement things.
        Some decisions will result in high maintenance and high learning threshold,
        and some will result in low maintenance and a low learning treshold.
        I want to see more of the latter, or a good argument why not.

            4. All of the testing and documentation issues mentioned should have been addressed
                in Buildroot's first release in years.  If this release serves 80%+ of the BR public
                with workaroundable annoyance only pending a next release of better stability, it will
                have done its job.  Getting to metricatable quality may take quite some time.


        Rome was not built in a day, but I think you can agree that there was *zero* effort
        to document anything for the first "release".

        I think that if this had gotten *any* priority, we would have now have a list of combinations
        host/arch/filesystems where this had been tested without delaying the release.
        There would certainly be holes, but since these would be visible, it would allow
        people to put in some effort to fill these holes.


            It may be that buildbot can nearly accommodate all of this now, or it may be that a good deal of further development is needed.
        --Frank

        BTW, Thanks for a constructive email!


        BR
        Ulf Samuelsson

       


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090224/776084c3/attachment.htm>

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Hi,

 Peter> As promised earlier, we are moving to a 3 month release cycle
 Peter> - So expect the first release candidate of 2009.05 some time
 Peter> in late April, and the final release mid May.

 Peter> This release has a lot of old package versions marked as
 Peter> deprecated. During the next development cycle a lot of those
 Peter> ancient versions will be removed unless there's any real
 Peter> reason to not use the more current versions. In other words,
 Peter> now is the time to shout if you depend on something ancient,
 Peter> and the newer versions aren't working.

 Peter> More specifically, expect to see non-sysroot versions of GCC
 Peter> disappearing (<4.2.x), gdb <6.7, uClibc <0.9.29, kernel
 Peter> <2.6.25, u-boot <2008.10 and busybox <1.12.x.

I plan to release 2009.05-rc1 this coming weekend, so if you have any
new features that you would like to see in the release, NOW is the
time to post them / remind me. After the release candidate I'll only
look@patches fixing problems so we can stabilize the tree for a
release mid May.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot 2009.02 released

[Sven Neumann]

Hi,

On Wed, 2009-04-29 at 11:38 +0200, Peter Korsgaard wrote:

> I plan to release 2009.05-rc1 this coming weekend, so if you have any
> new features that you would like to see in the release, NOW is the
> time to post them / remind me. After the release candidate I'll only
> look at patches fixing problems so we can stabilize the tree for a
> release mid May.

It would be nice to get the GStreamer and Samba updates into the next
release:

 https://bugs.busybox.net/show_bug.cgi?id=101
 https://bugs.busybox.net/show_bug.cgi?id=293

And of course I'd welcome the addition of the gupnp stack and gvfs. But
since there are some unresolved difficulties with these, perhaps focus
on the updates mentioned above.


Sven

[Buildroot] Buildroot 2009.02 released

[Peter Korsgaard]

>>>>> "Sven" == Sven Neumann <s.neumann@raumfeld.com> writes:

Hi,

 Sven> It would be nice to get the GStreamer and Samba updates into
 Sven> the next release:

 Sven>  https://bugs.busybox.net/show_bug.cgi?id=101
 Sven>  https://bugs.busybox.net/show_bug.cgi?id=293

Yes, I'll run through the bugtracker once more before doing -rc1.

 Sven> And of course I'd welcome the addition of the gupnp stack and
 Sven> gvfs. But since there are some unresolved difficulties with
 Sven> these, perhaps focus on the updates mentioned above.

Ok.

-- 
Bye, Peter Korsgaard