[Buildroot] Buildroot maintainer and stable releases

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

Hi, and happy new year everyone,

The end of the year is a moment to take a step back and take a bigger
look at the situation. I have done that for buildroot, and as I see it
the two biggest problems we have are:

 - Lack of an active maintainer. No hard feelings, but lets face it -
   Erik hasn't really been active in buildroot development for quite
   some time. This isn't a big deal for day to day development, but it
   means that there's no one doing stuff like keeping the website
   up to date, a central contact point for infrastruture issues (like
   the recent break in), make decissions when there is disagreements
   among developers (we already lost Bernhard because of that), and:
 - Lack of releases. It has often been discussed, but nothing has come
   of it.

I offer to do something about both: Take over maintainership and get
atual stable releases out the door (if Erik and the other developers
agree).

What is the plan? Getting the first release out is always the hardest,
so I would on purpose aim low for the first release and get it out
soon (February). The target is to get all architectures to build (and
run where hw is available for test) using the default toolchain config
and busybox, anything else is just a bonus. I will put out the first
release candidate early next week, so from then on please don't add
anything else than bugfixes until the release it out. I believe in
time based releases, so any architectures that we cannot fix in time
will simply be disabled in kconfig (E.G. depend on BROKEN).

After that I would like us to move to a regular release schedule every
3 months with 2 months of development and 1 month of stabilization.

The big issue with buildroot quality control is the mindblowing number
of configuration combinations and specialized hardware needed to
test. I am therefore convinced we need to leverage qemu and
agressively deprecate legacy versions / packages + actively work with
upstream to keep the number of patches low. I think our users would
also be happier with a less ambitious project that wouldn't break left
and right, instead of the current situation.

Let me know what you think.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

m?n 2009-01-05 klockan 22:18 +0100 skrev Peter Korsgaard:
> Hi, and happy new year everyone,
> 
> The end of the year is a moment to take a step back and take a bigger
> look at the situation. I have done that for buildroot, and as I see it
> the two biggest problems we have are:
> 
>  - Lack of an active maintainer. No hard feelings, but lets face it -
>    Erik hasn't really been active in buildroot development for quite
>    some time. This isn't a big deal for day to day development, but it
>    means that there's no one doing stuff like keeping the website
>    up to date, a central contact point for infrastruture issues (like
>    the recent break in), make decissions when there is disagreements
>    among developers (we already lost Bernhard because of that), and:
>  - Lack of releases. It has often been discussed, but nothing has come
>    of it.
> 
> I offer to do something about both: Take over maintainership and get
> atual stable releases out the door (if Erik and the other developers
> agree).
> 
> What is the plan? Getting the first release out is always the hardest,
> so I would on purpose aim low for the first release and get it out
> soon (February). The target is to get all architectures to build (and
> run where hw is available for test) using the default toolchain config
> and busybox, anything else is just a bonus. I will put out the first
> release candidate early next week, so from then on please don't add
> anything else than bugfixes until the release it out. I believe in
> time based releases, so any architectures that we cannot fix in time
> will simply be disabled in kconfig (E.G. depend on BROKEN).

This is a little bit too loose.
What is the "default toolchain config?".
I can see that this would affect the AVR32 where
the patches are still to be introduced into gcc and binutils.
(They are there in uClibc right now).

You have complained about size of patches, and 
that is why there is a prepatched toolchain for AVR32.
If that is not considered to be OK, then the several
MBytes of patches has to be introduced into the trunk.

If you by default toolchain config, means that each architecture
has its own toolchain versions, but the parameters like 
enabling WCHAR etc are standardized, then this is fine with me.

As I pointed out before, it is a source of problems
that the toolchain and the rootfs is build in a single make.
I think they should be separated.

I believe a distribution needs use a single version
of each package and we should focusing to get that to work for
as many architectures as possible.


The implementation needs to be discussed.
Instead of having a common "BROKEN" dependency, I think 
it would be good if each package depend on an <package>_ENABLE. 

This means that you can for a specific distribution
enable packages by architecture.

config	BR2_PACKAGES_arm
	bool
	depends on BR2_arm
	depends on BR2_VERSION_1_0
	default y
	?select BUSYBOX_ENABLE
	?select <package-1>_ENABLE if !BR2_MINIMAL_SYSTEM
	?select <package-2>_ENABLE? if !BR2_MINIMAL_SYSTEM
	
	...
	
	?select <package-1>_ENABLE? if !BR2_MINIMAL_SYSTEM


You would also want to enable everything,
if you do not have a distribution.
?config BR2_PACKAGES_ALL
	depends on !?BR2_VERSION_1_0
	default y
	select BUSYBOX_ENABLE
	select <package-1>_ENABLE if !BR2_MINIMAL_SYSTEM
	select <package-2>_ENABLE? if !BR2_MINIMAL_SYSTEM

	...

	select <package-1>_ENABLE? if !BR2_MINIMAL_SYSTEM

?If a user chooses to not use a distribution,
then Buildroot will be as free as it is now, to
build whatever

With this method we need to support a user file which 
allows users to extend the enables for testing purposes.

For Linux, there are two different ways of building it.
The simple and the advanced configuration.
I am fine with restricting kernel choices for the
simple configuration and to use that as a default.

The goal of the advanced linux configuration is to give 
freedom of selection to the user,so this should not contain
any restrictions on kernel versions/patches.

For this to work ; i think we need to support having
multiple makefiles for each package.
There needs to be a stable makefile for the distribution
but there needs to be a way to provide fixes that
is available to other developers as well.
If an ARCH is broken in the stable directory,
then it should be possible to commit changes 
to a separate directory for testing by others
on different architectures

I showed in a previous mail, how this can be done.

The distribution concept will not work, unless we mirror
packages on a server to avoid the build beeing broken
by disappearing packages.

> 
> After that I would like us to move to a regular release schedule every
> 3 months with 2 months of development and 1 month of stabilization.
> 
> The big issue with buildroot quality control is the mindblowing number
> of configuration combinations and specialized hardware needed to
> test. I am therefore convinced we need to leverage qemu and
> agressively deprecate legacy versions / packages + actively work with
> upstream to keep the number of patches low. I think our users would
> also be happier with a less ambitious project that wouldn't break left
> and right, instead of the current situation.

With the above method, you have fine-grained control
over what packages are buildable and what packages are not.



> Let me know what you think.
> 

I think we need to discuss the architecture on how things are to be done

BR
Ulf Samuelsson

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

> 
> 
> 
> > Let me know what you think.
> > 
> 
> I think we need to discuss the architecture on how things are to be done
> 
Maybe we should do this by documenting first what we want to do in the
Doc directory.

As an adder, I think we need to define which 
environment variables should be expected
to be generated by a Board Support Package

It would also make sense to document 
what files/directories are expected.


> BR
> Ulf Samuelsson
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 >> I think we need to discuss the architecture on how things are to be done
 >> 
 Ulf> Maybe we should do this by documenting first what we want to do in the
 Ulf> Doc directory.

Sure, more documentation is good - But let's first get to an agreement
on the list before writing stuff down.

Again, after the release please.

 Ulf> As an adder, I think we need to define which 
 Ulf> environment variables should be expected
 Ulf> to be generated by a Board Support Package

Environment variables? Board support package? I don't quite follow?

 Ulf> It would also make sense to document 
 Ulf> what files/directories are expected.

To add a new placeform under target/device you mean? Sure.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

tis 2009-01-06 klockan 13:55 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
>  >> I think we need to discuss the architecture on how things are to be done
>  >> 
>  Ulf> Maybe we should do this by documenting first what we want to do in the
>  Ulf> Doc directory.
> 
> Sure, more documentation is good - But let's first get to an agreement
> on the list before writing stuff down.
> 
> Again, after the release please.
> 

Personally, I find a working document better than a chain of emails.
Also I find writing a specification before doing the work
is better than trying to document the work afterwards.
Especially if we discover that the structure does not work.

It is not

>  Ulf> As an adder, I think we need to define which 
>  Ulf> environment variables should be expected
>  Ulf> to be generated by a Board Support Package
> 
> Environment variables? Board support package? I don't quite follow?

I use the term BSP for directories under "target/device/"
target/device/Atmel is a group of Board Support Packages

They define things like BOARD_NAME and BOARD_PATH
which for different reasons are hardwired and not
enabled through Config.in files.

We should document which environment variables
(if any) are mandatory, and which are optional.
The same with directories,and file names.

Currently you have linux config files called
linux26.config and this is really no good.
Assume you have linux-alpha.config and linux-beta.config,
and you do not supply info on which one to use?

The current copy script will (hopefully)
copy from <xxx>-linux-2.6.<minor>.<major>.config
up until, but not past the current kernel version.


>  Ulf> It would also make sense to document 
>  Ulf> what files/directories are expected.
> 
> To add a new placeform under target/device you mean? Sure.
> 

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 >> What is the plan? Getting the first release out is always the hardest,
 >> so I would on purpose aim low for the first release and get it out
 >> soon (February). The target is to get all architectures to build (and
 >> run where hw is available for test) using the default toolchain config
 >> and busybox, anything else is just a bonus. I will put out the first
 >> release candidate early next week, so from then on please don't add
 >> anything else than bugfixes until the release it out. I believe in
 >> time based releases, so any architectures that we cannot fix in time
 >> will simply be disabled in kconfig (E.G. depend on BROKEN).

 Ulf> This is a little bit too loose.
 Ulf> What is the "default toolchain config?".

The default one - E.G.:

rm .config; make menuconfig, select arch, save config, make

 Ulf> I can see that this would affect the AVR32 where
 Ulf> the patches are still to be introduced into gcc and binutils.
 Ulf> (They are there in uClibc right now).

Sorry, I don't know anything about avr32. It's my opinion that we have
too much special case handling for avr32/at91 in buildroot, and that
it's causing problems for the users + friction between developers
(E.G. see the recent openssl breakage)

But ok, that's the situation as it is today. My understanding is that
most of those patches are (slowly) progressing upstream.

Are you saying that the default config for avr32 doesn't build?

From talking with HcE on IRC, it seems like the Atmel fork of
buildroot is the recommended solution for avr32 users anyway.

 Ulf> You have complained about size of patches, and 
 Ulf> that is why there is a prepatched toolchain for AVR32.
 Ulf> If that is not considered to be OK, then the several
 Ulf> MBytes of patches has to be introduced into the trunk.

It's not the size in bytes as such, it's the special casing and
(effectively) black box patches. Even when you test your changes on
multiple archs there's a fairly big change that you break stuff for
avr32/at91, or that you guys break it for the other archs. The same
with moving packages to new versions or removing old versions, you
cannot expect other people to forward port those arch specific
patches.

 Ulf> If you by default toolchain config, means that each architecture
 Ulf> has its own toolchain versions, but the parameters like 
 Ulf> enabling WCHAR etc are standardized, then this is fine with me.

Whatever kconfig selects as default (which is Linux 2.6.28 / uclibc
0.9.30 / binutils 2.19 / gcc 4.2.4) for everything else than avr32 and
nios.

We should probably make gcc 4.3.2 default before the release.

 Ulf> As I pointed out before, it is a source of problems
 Ulf> that the toolchain and the rootfs is build in a single make.
 Ulf> I think they should be separated.

Ok, there's already some support for that - But that should NOT be a
showstopper for a release. We tried it before, if we go down that hole
then there won't be a release in the forseeable future.

 Ulf> I believe a distribution needs use a single version
 Ulf> of each package and we should focusing to get that to work for
 Ulf> as many architectures as possible.

Agree.

 Ulf> The implementation needs to be discussed.
 Ulf> Instead of having a common "BROKEN" dependency, I think 
 Ulf> it would be good if each package depend on an <package>_ENABLE. 

But why? That still leads to way too many combinations. Why not just
use the same package version for all archs?

 Ulf> For Linux, there are two different ways of building it.
 Ulf> The simple and the advanced configuration.
 Ulf> I am fine with restricting kernel choices for the
 Ulf> simple configuration and to use that as a default.

I'll leave all this discussion about distributions for after the
release, then we can bring it up again - OK?

 Ulf> The distribution concept will not work, unless we mirror
 Ulf> packages on a server to avoid the build beeing broken
 Ulf> by disappearing packages.

Yes, that's also on my todo list.

 >> Let me know what you think.
 >> 

 Ulf> I think we need to discuss the architecture on how things are to
 Ulf> be done

Sure, but after the release please.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

CC-ing Hans-Christian Egtvedt

Peter Korsgaard, 06.01.2009:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>  Ulf> I can see that this would affect the AVR32 where
>  Ulf> the patches are still to be introduced into gcc and binutils.
>  Ulf> (They are there in uClibc right now).
> 
> Sorry, I don't know anything about avr32. It's my opinion that we have
> too much special case handling for avr32/at91 in buildroot, and that
> it's causing problems for the users + friction between developers
> (E.G. see the recent openssl breakage)
> 
> But ok, that's the situation as it is today. My understanding is that
> most of those patches are (slowly) progressing upstream.
> 
> Are you saying that the default config for avr32 doesn't build?
> 
> >>From talking with HcE on IRC, it seems like the Atmel fork of
> buildroot is the recommended solution for avr32 users anyway.

I wonder, why many of the patches are also included in uClibc's
Buildroot then. Don't the avr32 users use Atmel's Buildroot? I'm an
avr32 user myself and only use Atmel's Buildroot for development. One
drawback is that I'm not up-to-date with uClibc, because these changes
are only seldom merged into the Atmel branches, only short before their
release candidates. So I end up working on another file base, which
doesn't ease integration of changes into uClibc's Buildroot. I could
merge myself, a branch "upstream" is available and is updated often, but
that doesn't make sense somehow. I haven't yet tried it, so I don't know
whether it will cause some hassle or not.

I haven't yet asked why this merge happens so rarely. Maybe lack of
time? OK, I'm already getting avr32-buildroot specific, but I think
updating the "devel" branch would be nice, even without testing
anything.  Currently the three branches "devel", "master" and
"atmel-2.3" are the same, pointing to the latest release.

>  Ulf> You have complained about size of patches, and 
>  Ulf> that is why there is a prepatched toolchain for AVR32.
>  Ulf> If that is not considered to be OK, then the several
>  Ulf> MBytes of patches has to be introduced into the trunk.
> 
> It's not the size in bytes as such, it's the special casing and
> (effectively) black box patches. Even when you test your changes on
> multiple archs there's a fairly big change that you break stuff for
> avr32/at91, or that you guys break it for the other archs. The same
> with moving packages to new versions or removing old versions, you
> cannot expect other people to forward port those arch specific
> patches.

Yes, mplayer for example is more than 2 years old and includes a huge
avr32 patch.

Markus

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

Hi,

 >> >>From talking with HcE on IRC, it seems like the Atmel fork of
 >> buildroot is the recommended solution for avr32 users anyway.

 Markus> I wonder, why many of the patches are also included in uClibc's
 Markus> Buildroot then.

Me too.

 Markus> Don't the avr32 users use Atmel's Buildroot? I'm an avr32
 Markus> user myself and only use Atmel's Buildroot for
 Markus> development. One drawback is that I'm not up-to-date with
 Markus> uClibc, because these changes are only seldom merged into the
 Markus> Atmel branches, only short before their release
 Markus> candidates. So I end up working on another file base, which
 Markus> doesn't ease integration of changes into uClibc's
 Markus> Buildroot. I could merge myself, a branch "upstream" is
 Markus> available and is updated often, but that doesn't make sense
 Markus> somehow. I haven't yet tried it, so I don't know whether it
 Markus> will cause some hassle or not.

I don't know anything about this Atmel fork (where is it?), but as
avr32 is maturing, long term I don't see why we cannot support it in
uclibc buildroot.

Right now things are kind of a mess as avr32 is lacking from most
upstream projects, so there's lots of big patches involved. As things
are now, I don't see missing avr32 as a showstopper for a first
release.

 Ulf> You have complained about size of patches, and 
 Ulf> that is why there is a prepatched toolchain for AVR32.
 Ulf> If that is not considered to be OK, then the several
 Ulf> MBytes of patches has to be introduced into the trunk.
 >> 
 >> It's not the size in bytes as such, it's the special casing and
 >> (effectively) black box patches. Even when you test your changes on
 >> multiple archs there's a fairly big change that you break stuff for
 >> avr32/at91, or that you guys break it for the other archs. The same
 >> with moving packages to new versions or removing old versions, you
 >> cannot expect other people to forward port those arch specific
 >> patches.

 Markus> Yes, mplayer for example is more than 2 years old and includes a huge
 Markus> avr32 patch.

Exactly. Who will redo this patch if I bump the mplayer version?

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

(resend with trimmed Cc line to please mailman)

Hi,

 >> >>From talking with HcE on IRC, it seems like the Atmel fork of
 >> buildroot is the recommended solution for avr32 users anyway.

 Markus> I wonder, why many of the patches are also included in uClibc's
 Markus> Buildroot then.

Me too.

 Markus> Don't the avr32 users use Atmel's Buildroot? I'm an avr32
 Markus> user myself and only use Atmel's Buildroot for
 Markus> development. One drawback is that I'm not up-to-date with
 Markus> uClibc, because these changes are only seldom merged into the
 Markus> Atmel branches, only short before their release
 Markus> candidates. So I end up working on another file base, which
 Markus> doesn't ease integration of changes into uClibc's
 Markus> Buildroot. I could merge myself, a branch "upstream" is
 Markus> available and is updated often, but that doesn't make sense
 Markus> somehow. I haven't yet tried it, so I don't know whether it
 Markus> will cause some hassle or not.

I don't know anything about this Atmel fork (where is it?), but as
avr32 is maturing, long term I don't see why we cannot support it in
uclibc buildroot.

Right now things are kind of a mess as avr32 is lacking from most
upstream projects, so there's lots of big patches involved. As things
are now, I don't see missing avr32 as a showstopper for a first
release.

 Ulf> You have complained about size of patches, and 
 Ulf> that is why there is a prepatched toolchain for AVR32.
 Ulf> If that is not considered to be OK, then the several
 Ulf> MBytes of patches has to be introduced into the trunk.
 >> 
 >> It's not the size in bytes as such, it's the special casing and
 >> (effectively) black box patches. Even when you test your changes on
 >> multiple archs there's a fairly big change that you break stuff for
 >> avr32/at91, or that you guys break it for the other archs. The same
 >> with moving packages to new versions or removing old versions, you
 >> cannot expect other people to forward port those arch specific
 >> patches.

 Markus> Yes, mplayer for example is more than 2 years old and includes a huge
 Markus> avr32 patch.

Exactly. Who will redo this patch if I bump the mplayer version?

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Nigel Kukard]

>  Ulf> You have complained about size of patches, and 
>  Ulf> that is why there is a prepatched toolchain for AVR32.
>  Ulf> If that is not considered to be OK, then the several
>  Ulf> MBytes of patches has to be introduced into the trunk.
>  >> 
>  >> It's not the size in bytes as such, it's the special casing and
>  >> (effectively) black box patches. Even when you test your changes on
>  >> multiple archs there's a fairly big change that you break stuff for
>  >> avr32/at91, or that you guys break it for the other archs. The same
>  >> with moving packages to new versions or removing old versions, you
>  >> cannot expect other people to forward port those arch specific
>  >> patches.
>
>  Markus> Yes, mplayer for example is more than 2 years old and includes a huge
>  Markus> avr32 patch.
>
> Exactly. Who will redo this patch if I bump the mplayer version
Perfect example why we need the MAINTAINERS file, ie. who is responsible
for keeping the $arch/target patches up to date?

-N

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

Peter Korsgaard, 07.01.2009:
> >>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:
> 
> (resend with trimmed Cc line to please mailman)

What was the problem with the former mail?
In my sent mail you, Ulf and HCE were on Cc, but when receiving my mail
from the list, only Ulf was on Cc, you and HCE were gone. Is this a
related problem? How to fix it?

> I don't know anything about this Atmel fork (where is it?), but as
> avr32 is maturing, long term I don't see why we cannot support it in
> uclibc buildroot.

You can find references to it on the AVR32 Linux site avr32linux.org
under "DevelopemtTools", there is also a link to
http://www.atmel.no/buildroot/
They also keep several packages on
http://www.atmel.no/buildroot/source/mirror/
It used to be just the packages missing on the upstream mirror but just
looking at it, it seems to be much more packages now, if not all
packages activated by default.
I don't remember where to find the git URL, but I did it somehow once:
git://www.atmel.no/~hcegtvedt/buildroot/avr32.git

> Right now things are kind of a mess as avr32 is lacking from most
> upstream projects, so there's lots of big patches involved. As things
> are now, I don't see missing avr32 as a showstopper for a first
> release.

Absolutely agreed. Especially given that there is this well-supported
AVR32 fork (which isn't really a fork I think, it rather sits on top of
uclibc-buildroot).

>  Markus> Yes, mplayer for example is more than 2 years old and includes a huge
>  Markus> avr32 patch.
> 
> Exactly. Who will redo this patch if I bump the mplayer version?

I tried it some weeks ago. I think it should have worked, but I got
a compile error that wasn't related to the patch as far as I remember
and judge. I had some time consuming toolchain rebuilds and then I
noticed that the new version wasn't really necessary, so I stopped
investigating further and stayed with the current version.

And even if it worked, this is not a solution. Someone should make it
ready and submit it upstream and it's definetly not me, I haven't
written the patch and cannot say anything about it's maturity.
If nobody involved in this patch has the time to do it, it should best
be thrown out of uclibc-buildroot and just be kept in HCE's repo.

Markus

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

Hi,

 >> (resend with trimmed Cc line to please mailman)

 Markus> What was the problem with the former mail?  In my sent mail
 Markus> you, Ulf and HCE were on Cc, but when receiving my mail from
 Markus> the list, only Ulf was on Cc, you and HCE were gone. Is this
 Markus> a related problem? How to fix it?

Mailman bounced the mail to the list because it didn't like the long
Cc list.

We might ask the osuosl.org people to tweak the config, but I'm still
waiting on them to fix the buildroot at busybox.net bounces.

 Markus> I don't remember where to find the git URL, but I did it somehow once:
 Markus> git://www.atmel.no/~hcegtvedt/buildroot/avr32.git

Thanks.

 >> Exactly. Who will redo this patch if I bump the mplayer version?

 Markus> I tried it some weeks ago. I think it should have worked, but I got
 Markus> a compile error that wasn't related to the patch as far as I remember
 Markus> and judge. I had some time consuming toolchain rebuilds and then I
 Markus> noticed that the new version wasn't really necessary, so I stopped
 Markus> investigating further and stayed with the current version.

Ok.

 Markus> And even if it worked, this is not a solution. Someone should make it
 Markus> ready and submit it upstream and it's definetly not me, I haven't
 Markus> written the patch and cannot say anything about it's maturity.

Probably HcE in the long run, but he seems quite busy at the moment.

 Markus> If nobody involved in this patch has the time to do it, it
 Markus> should best be thrown out of uclibc-buildroot and just be
 Markus> kept in HCE's repo.

Agreed.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thiago A. Corrêa]

This thread is getting too high traffic for me to follow, so I will
just pick some topics:

On Wed, Jan 7, 2009 at 10:19 AM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Peter Korsgaard, 07.01.2009:
>> Markus Heidelberg writes:
>
>> Right now things are kind of a mess as avr32 is lacking from most
>> upstream projects, so there's lots of big patches involved. As things
>> are now, I don't see missing avr32 as a showstopper for a first
>> release.
>
> Absolutely agreed. Especially given that there is this well-supported
> AVR32 fork (which isn't really a fork I think, it rather sits on top of
> uclibc-buildroot).
>

This is not really true. The Atmel fork have numerous issues, and I
can't do much about them, that's exactly why I looked up to this
project. I didn't even knew what buildroot was before being introduced
to Atmel's fork.
John and Amaur, certainly had their issues with Atmel's fork as well,
since they decided to contribute AVR32 specific changes here at some
point. That probably could be said about most AVR32 user around.

I guess HCE and others from Atmel will only point users to Atmel's
fork because of the quality issues we have here, and lack of release.
It really doesn't look good for the company to point it's customers
here and it sudenly doesn't even build today.
Having our quality issues and releases sorted out, it's likely that
their branch might just go away.

On Wed, Jan 7, 2009 at 9:28 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>  Ulf> That is why other systems like OpenEmbedded allow having more
>  Ulf> than one version of a package.
>  Ulf> A system that only allows a single version is really not useful.
>
> Sorry, I disagree. Most packages only have a single version and that
> works fine. Almost everything under packages builds just fine on any
[cut]

I agree with Peter. We should strive to keep single versions only.
There are cases like DirectFB and perhaps other libs that it's not
possible, because the lib changes it's API. But in general, having
several versions of the same package will add clutter and will be a
maintenance nightmare.
Ulf, I see your point. But suggesting to have versions for every
package is too much. Perhaps we could have multiple versions for one
very important package or another but every one doesn't make sense.

Kind Regards,
    Thiago A. Correa

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

Thiago A. Corr?a, 07.01.2009:
> On Wed, Jan 7, 2009 at 10:19 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Peter Korsgaard, 07.01.2009:
> >> Markus Heidelberg writes:
> >
> >> Right now things are kind of a mess as avr32 is lacking from most
> >> upstream projects, so there's lots of big patches involved. As things
> >> are now, I don't see missing avr32 as a showstopper for a first
> >> release.
> >
> > Absolutely agreed. Especially given that there is this well-supported
> > AVR32 fork (which isn't really a fork I think, it rather sits on top of
> > uclibc-buildroot).
> >
> 
> This is not really true. The Atmel fork have numerous issues, and I
> can't do much about them, that's exactly why I looked up to this
> project. I didn't even knew what buildroot was before being introduced
> to Atmel's fork.
> John and Amaur, certainly had their issues with Atmel's fork as well,
> since they decided to contribute AVR32 specific changes here at some
> point. That probably could be said about most AVR32 user around.

Given that there are numerous issues, can you at least show me a few of
them? I'm interested. Everybody is calling for stable releases, HCE
offers such for AVR32, but nobody is using them!?

> I guess HCE and others from Atmel will only point users to Atmel's
> fork because of the quality issues we have here, and lack of release.
> It really doesn't look good for the company to point it's customers
> here and it sudenly doesn't even build today.

Agreed.

> Having our quality issues and releases sorted out, it's likely that
> their branch might just go away.

I don't know, but I don't necessarily think so. 

> On Wed, Jan 7, 2009 at 9:28 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >  Ulf> That is why other systems like OpenEmbedded allow having more
> >  Ulf> than one version of a package.
> >  Ulf> A system that only allows a single version is really not useful.
> >
> > Sorry, I disagree. Most packages only have a single version and that
> > works fine. Almost everything under packages builds just fine on any
> [cut]
> 
> I agree with Peter. We should strive to keep single versions only.
> There are cases like DirectFB and perhaps other libs that it's not
> possible, because the lib changes it's API. But in general, having
> several versions of the same package will add clutter and will be a
> maintenance nightmare.
> Ulf, I see your point. But suggesting to have versions for every
> package is too much. Perhaps we could have multiple versions for one
> very important package or another but every one doesn't make sense.

The point is, when you have to be stable for delivered products, you
won't update any package without a reason, let alone u-boot or the
toolchain. During development you can update whenever you want to. So if
you really need some new versions, you can cherry-pick them from the
latest buildroot into your stable-branch. No need for multiple version
inside buildroot itself.

Markus

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

Thiago A. Corr?a, 07.01.2009:
> On Wed, Jan 7, 2009 at 10:19 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Peter Korsgaard, 07.01.2009:
> >> Markus Heidelberg writes:
> >
> >> Right now things are kind of a mess as avr32 is lacking from most
> >> upstream projects, so there's lots of big patches involved. As things
> >> are now, I don't see missing avr32 as a showstopper for a first
> >> release.
> >
> > Absolutely agreed. Especially given that there is this well-supported
> > AVR32 fork (which isn't really a fork I think, it rather sits on top of
> > uclibc-buildroot).

Yes, HCE regularily downloads the svn, adds his stuff on top.
and tests with one or more rc versions before release.

Therefore it makes sense to propagate any fixes to mainstream
because then the diff will be smaller and his job easier
and it contributes to mainstream with both generic
and AVR32 stuff.

>
> This is not really true. The Atmel fork have numerous issues, and I
> can't do much about them, that's exactly why I looked up to this
> project. I didn't even knew what buildroot was before being introduced
> to Atmel's fork.
> John and Amaur, certainly had their issues with Atmel's fork as well,
> since they decided to contribute AVR32 specific changes here at some
> point. That probably could be said about most AVR32 user around.

One of the key issues for an AVR32 developer is that they cannot
commit additions to the Atmel version, so every time
a new version is released, they have to port their stuff to the
Atmel version.

> Given that there are numerous issues, can you at least show me a few of
> them? I'm interested. Everybody is calling for stable releases, HCE
> offers such for AVR32, but nobody is using them!?

Why do you think that noone is using them, there are thousands
of AVR32 boards sold every year, and if the Atmel buildroot
is the recommended way of providing the Linux, that is the route
many will follow.

> I guess HCE and others from Atmel will only point users to Atmel's
> fork because of the quality issues we have here, and lack of release.
> It really doesn't look good for the company to point it's customers
> here and it sudenly doesn't even build today.

> Agreed.

> Having our quality issues and releases sorted out, it's likely that
> their branch might just go away.

> I don't know, but I don't necessarily think so.

It really does not matter. The Atmel branch fills one need,
and the AVR32 support in the main trunk fills another need.
The Atmel branch would have been much less useful
for AVR32 developers if people like John Voltz, Thiego & others
had not worked with the main trunk



> On Wed, Jan 7, 2009 at 9:28 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >  Ulf> That is why other systems like OpenEmbedded allow having more
> >  Ulf> than one version of a package.
> >  Ulf> A system that only allows a single version is really not useful.
> >
> > Sorry, I disagree. Most packages only have a single version and that
> > works fine. Almost everything under packages builds just fine on any
> [cut]



> I agree with Peter. We should strive to keep single versions only.
> There are cases like DirectFB and perhaps other libs that it's not
> possible, because the lib changes it's API. But in general, having
> several versions of the same package will add clutter and will be a
> maintenance nightmare.
> Ulf, I see your point. But suggesting to have versions for every
> package is too much. Perhaps we could have multiple versions for one
> very important package or another but every one doesn't make sense.

> The point is, when you have to be stable for delivered products, you
> won't update any package without a reason, let alone u-boot or the
> toolchain. During development you can update whenever you want to. So if
> you really need some new versions, you can cherry-pick them from the
> latest buildroot into your stable-branch. No need for multiple version
> inside buildroot itself.

My idea is based on that if buildroot works, then noone
should need to have a personal stable branch because
buildroot will contain the personal stable branch
without much addition.

Unfortunately people equates having several package versions inside 
buildroot
with having to test different permutations of those packages.

That just mean that either they have not read what I have written
or they have not understood so I repeat:

My proposal means that the test effort will only use ONE VERSION of each 
package.
The release will only support one version of each package.
It is in the development phase, where you get more versions,
and when you move to a new package version in a new distribution
you FREEZE the old versions, but you do not remove them
and you do not allow the casual user to select them through Kconfig.

You can however select to build an older distribution and then the older
versions will be used.
There is no immediate way to mix packages from  different distribution
suing Kconfig
A developer is free to select whatever package he wants by creating
his own distribution using overrides.








> Markus



Best Regards
Ulf Samuelsson

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

Ulf Samuelsson, 08.01.2009:
> 
> Thiago A. Corr?a, 07.01.2009:
> > On Wed, Jan 7, 2009 at 10:19 AM, Markus Heidelberg
> > <markus.heidelberg@web.de> wrote:
> > > Peter Korsgaard, 07.01.2009:
> > >> Markus Heidelberg writes:
> > >
> > >> Right now things are kind of a mess as avr32 is lacking from most
> > >> upstream projects, so there's lots of big patches involved. As things
> > >> are now, I don't see missing avr32 as a showstopper for a first
> > >> release.
> > >
> > > Absolutely agreed. Especially given that there is this well-supported
> > > AVR32 fork (which isn't really a fork I think, it rather sits on top of
> > > uclibc-buildroot).
> 
> Yes, HCE regularily downloads the svn, adds his stuff on top.
> and tests with one or more rc versions before release.
> 
> Therefore it makes sense to propagate any fixes to mainstream
> because then the diff will be smaller and his job easier
> and it contributes to mainstream with both generic
> and AVR32 stuff.

Pushing stuff into mainstream is always desirable.
I don't mean to have AVR32 specific things out of uclibc-buildroot. Of
course it should be supported there as well. But mplayer is just a good
example, where support for it is wrong and is a good reason for a
separate AVR32 repo, especially given that it's well supported by Atmel.

But when you already put so much stuff into uclibc-buildroot to fully
support AVR32, what's then remaining in HCE's tree and for what reason
this is not put into upstream? With your arguments, HCE doesn't need to
commit to his own repository at all, he could just commit everything
to upstream. The only purpose of his tree then would be having stable
and tested AVR32 releases for the customers.

> One of the key issues for an AVR32 developer is that they cannot
> commit additions to the Atmel version, so every time

What's wrong with that? What would they want to commit? You also cannot
commit directly to Haavards avr32-linux repo. Do you then ask Linus for
push access because of that? Is this also the reason why you put all the
U-Boot patches into buildroot, because you don't have commit access to
the u-boot repo but to uclibc-buildroot?

I think if you have AVR32 changes, that shouln't go into
uclibc-buildroot, then you could always send a patch to the
avr32-buildroot mailing list or HCE.

> a new version is released, they have to port their stuff to the
> Atmel version.

I don't get it. You can use the HCE's git repo and just pull the updates
or rebase against it. What has this to do with the fact that you cannot
commit to the public repo?

> > Given that there are numerous issues, can you at least show me a few of
> > them? I'm interested. Everybody is calling for stable releases, HCE
> > offers such for AVR32, but nobody is using them!?
> 
> Why do you think that noone is using them, there are thousands
> of AVR32 boards sold every year, and if the Atmel buildroot
> is the recommended way of providing the Linux, that is the route
> many will follow.

No, I don't think nobody is using them, that was just expressed
unluckily. But it seems as if the AVR32 users that are subscribed to
buildroot at uclibc.org aren't using it. At least I got that feeling while
following this mailing list.

> > The point is, when you have to be stable for delivered products, you
> > won't update any package without a reason, let alone u-boot or the
> > toolchain. During development you can update whenever you want to. So if
> > you really need some new versions, you can cherry-pick them from the
> > latest buildroot into your stable-branch. No need for multiple version
> > inside buildroot itself.
> 
> My idea is based on that if buildroot works, then noone
> should need to have a personal stable branch because
> buildroot will contain the personal stable branch
> without much addition.
> 
> [...]
> 
> My proposal means that the test effort will only use ONE VERSION of each 
> package.
> The release will only support one version of each package.
> It is in the development phase, where you get more versions,
> and when you move to a new package version in a new distribution
> you FREEZE the old versions, but you do not remove them
> and you do not allow the casual user to select them through Kconfig.

When I'm on stable, I definetly want to be on stable and only update/fix
packages that caused bugs. Consider a package that doesn't update its
version in buildroot (and also upstream maybe) during several months. It
will never FREEZE and always stay in development phase, because it's the
latest version, and it will probably get more patches.
So when merging the latest buildroot updates into my personal buildroot
repo for a board in development, I'd get changes behind my back also for
a released board in support phase.

So I will keep using branches in git instead of relying on buildroot to
include half a VCS functionality.

Markus

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

Ulf Samuelsson, 08.01.2009:
>
> Thiago A. Corr?a, 07.01.2009:
> > On Wed, Jan 7, 2009 at 10:19 AM, Markus Heidelberg
> > <markus.heidelberg@web.de> wrote:
> > > Peter Korsgaard, 07.01.2009:
> > >> Markus Heidelberg writes:
> > >
> > >> Right now things are kind of a mess as avr32 is lacking from most
> > >> upstream projects, so there's lots of big patches involved. As things
> > >> are now, I don't see missing avr32 as a showstopper for a first
> > >> release.
> > >
> > > Absolutely agreed. Especially given that there is this well-supported
> > > AVR32 fork (which isn't really a fork I think, it rather sits on top 
> > > of
> > > uclibc-buildroot).
>
> Yes, HCE regularily downloads the svn, adds his stuff on top.
> and tests with one or more rc versions before release.
>
> Therefore it makes sense to propagate any fixes to mainstream
> because then the diff will be smaller and his job easier
> and it contributes to mainstream with both generic
> and AVR32 stuff.

> Pushing stuff into mainstream is always desirable.
> I don't mean to have AVR32 specific things out of uclibc-buildroot. Of
> course it should be supported there as well. But mplayer is just a good
> example, where support for it is wrong and is a good reason for a
> separate AVR32 repo, especially given that it's well supported by Atmel.

> But when you already put so much stuff into uclibc-buildroot to fully
> support AVR32, what's then remaining in HCE's tree and for what reason
> this is not put into upstream? With your arguments, HCE doesn't need to
> commit to his own repository at all, he could just commit everything
> to upstream. The only purpose of his tree then would be having stable
> and tested AVR32 releases for the customers.

That is a very important reason for it to exist.


>> One of the key issues for an AVR32 developer is that they cannot
>> commit additions to the Atmel version, so every time

> What's wrong with that? What would they want to commit?

X-Windows for a start...
That was committed to Buildroot by John Voltz so he
could run X on his AVR32 board.
There are plenty of examples.

Since AVR32 is a fairly new architecture, support for it does not exist
in many packages, and maybe some developers want to put their
own effort into bringing more packages online with AVR32 support.

> You also cannot commit directly to Haavards avr32-linux repo.
> Do you then ask Linus for
> push access because of that? Is this also the reason why you put all the
> U-Boot patches into buildroot, because you don't have commit access to
> the u-boot repo but to uclibc-buildroot?

No, because noone basically got any patches committed for a long time
to the U-Boot project so the AT91 team did their own thing based on
U-Boot-1.1.5 and remained with U-Boot-1.1.5 for a long time.
I have updated the patches to newer versions until 1.2.0
and a prepatched U-Boot was added to buildroot some time ago
in target/device/Atmel/u-boot, maybe a year later someone
added the generic u-boot to target.
There has been some comments about having two ways of building
U-Boot, so I decided to merge, but that does not mean  that
I want to lost the extra functionality.
Everything I added to U-boot, except the sam9g20 support has been
there for 18 months minimum, just in a different way.
Before I added this, people could build u-boot-1.3.4.
They still can build 1.3.4 without any patches.
If you want to use 2009.01-rc-1, then I made that possible.



> I think if you have AVR32 changes, that shouln't go into
> uclibc-buildroot, then you could always send a patch to the
> avr32-buildroot mailing list or HCE.

I do not know of any AVR32 changes which I do not think
should go into uclibc-buildroot.

> a new version is released, they have to port their stuff to the
> Atmel version.

> I don't get it. You can use the HCE's git repo and just pull the updates
> or rebase against it. What has this to do with the fact that you cannot
> commit to the public repo?
> > Given that there are numerous issues, can you at least show me a few of
> > them? I'm interested. Everybody is calling for stable releases, HCE
> > offers such for AVR32, but nobody is using them!?
>
> Why do you think that noone is using them, there are thousands
> of AVR32 boards sold every year, and if the Atmel buildroot
> is the recommended way of providing the Linux, that is the route
> many will follow.

> No, I don't think nobody is using them, that was just expressed
> unluckily. But it seems as if the AVR32 users that are subscribed to
> buildroot at uclibc.org aren't using it. At least I got that feeling while
> following this mailing list.

I work with both.

> > The point is, when you have to be stable for delivered products, you
> > won't update any package without a reason, let alone u-boot or the
> > toolchain. During development you can update whenever you want to. So if
> > you really need some new versions, you can cherry-pick them from the
> > latest buildroot into your stable-branch. No need for multiple version
> > inside buildroot itself.
>
> My idea is based on that if buildroot works, then noone
> should need to have a personal stable branch because
> buildroot will contain the personal stable branch
> without much addition.
>
> [...]
>
> My proposal means that the test effort will only use ONE VERSION of each
> package.
> The release will only support one version of each package.
> It is in the development phase, where you get more versions,
> and when you move to a new package version in a new distribution
> you FREEZE the old versions, but you do not remove them
> and you do not allow the casual user to select them through Kconfig.

> When I'm on stable, I definetly want to be on stable and only update/fix
> packages that caused bugs. Consider a package that doesn't update its
> version in buildroot (and also upstream maybe) during several months. It
> will never FREEZE and always stay in development phase, because it's the
> latest version, and it will probably get more patches.

And in my point of view you do NOT commit a patch to the
distribution directory, because you risk fixing a minor issue
for one architecture, while potentially break the BUILD of ALL the others.

This behaviour should not be legal.
Instead you create a new directory, add your patch to that directory
and use that directory for your build.
Other people using other architectures can test your directory as
well, once buildroot enters a testing phase.
Once enough people has tested the new directory and found it good,
then it can be used in a new minor release of the distibution
and will replace the earlier directory (using the same source version)

Your approach (which is the current approach for most things)
is IMHO one of the major causes for problems in Buildroot.


> So when merging the latest buildroot updates into my personal buildroot
> repo for a board in development, I'd get changes behind my back also for
> a released board in support phase.

> So I will keep using branches in git instead of relying on buildroot to
> include half a VCS functionality.
> Markus

Best Regards
Ulf Samuelsson 

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

Ulf Samuelsson, 08.01.2009:
> > But when you already put so much stuff into uclibc-buildroot to fully
> > support AVR32, what's then remaining in HCE's tree and for what reason
> > this is not put into upstream? With your arguments, HCE doesn't need to
> > commit to his own repository at all, he could just commit everything
> > to upstream. The only purpose of his tree then would be having stable
> > and tested AVR32 releases for the customers.
> 
> That is a very important reason for it to exist.

Yes, it is. But I have the feeling, that in your opinion it is the only
reason.

> >> One of the key issues for an AVR32 developer is that they cannot
> >> commit additions to the Atmel version, so every time
> 
> > What's wrong with that? What would they want to commit?
> 
> X-Windows for a start...
> That was committed to Buildroot by John Voltz so he
> could run X on his AVR32 board.
> There are plenty of examples.

In package/x11r7/ there is only one little avr32 patch to support
xorg-server for this architecture. I think this is fine to be included
in uclibc-buildroot, as long as it is pushed upstream. I looked at
Xorg's git web interface and at least in the latest version it is
included.

So this is not a good example for a lack-of-commit-access issue with
HCE's repository.

I rather thought of examples like the big mplayer patch. This doesn't
belong into uclibc-buildroot, but into the AVR32 repo. And as I said
earlier: without commit access just send a patch to HCE. I'm sure he
would be glad to apply it to get more packages working with/optimized
for AVR32.

> Since AVR32 is a fairly new architecture, support for it does not exist
> in many packages, and maybe some developers want to put their
> own effort into bringing more packages online with AVR32 support.
> 
> > I think if you have AVR32 changes, that shouln't go into
> > uclibc-buildroot, then you could always send a patch to the
> > avr32-buildroot mailing list or HCE.
> 
> I do not know of any AVR32 changes which I do not think
> should go into uclibc-buildroot.

Then why is it a problem not to have commit access to HCE's repo?

Markus

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

tor 2009-01-08 klockan 23:06 +0100 skrev Markus Heidelberg:
> Ulf Samuelsson, 08.01.2009:
> > > But when you already put so much stuff into uclibc-buildroot to fully
> > > support AVR32, what's then remaining in HCE's tree and for what reason
> > > this is not put into upstream? With your arguments, HCE doesn't need to
> > > commit to his own repository at all, he could just commit everything
> > > to upstream. The only purpose of his tree then would be having stable
> > > and tested AVR32 releases for the customers.
> > 
> > That is a very important reason for it to exist.
> 
> Yes, it is. But I have the feeling, that in your opinion it is the only
> reason.
> 
> > >> One of the key issues for an AVR32 developer is that they cannot
> > >> commit additions to the Atmel version, so every time
> > 
> > > What's wrong with that? What would they want to commit?
> > 
> > X-Windows for a start...
> > That was committed to Buildroot by John Voltz so he
> > could run X on his AVR32 board.
> > There are plenty of examples.
> 
> In package/x11r7/ there is only one little avr32 patch to support
> xorg-server for this architecture. I think this is fine to be included
> in uclibc-buildroot, as long as it is pushed upstream. I looked at
> Xorg's git web interface and at least in the latest version it is
> included.
> 
> So this is not a good example for a lack-of-commit-access issue with
> HCE's repository.

You forget that  he created the build recipe,,,,,
and he is actually a VERY good example.


> I rather thought of examples like the big mplayer patch. This doesn't
> belong into uclibc-buildroot, but into the AVR32 repo. 


?I am sure you would think otherwise if you were an AVR32 user.
 
> And as I said
> earlier: without commit access just send a patch to HCE. I'm sure he
> would be glad to apply it to get more packages working with/optimized
> for AVR32.

The best way to have it upgraded, I guess is to 
update the mplayer version.
Then HCE will detect that mplayer will not build
and the patch will be have to be rebased on the new version.
You will of course see a new AVR32 patch quite soon in uclibc-buildroot.

It is also creating more work to do the same thing.




> > Since AVR32 is a fairly new architecture, support for it does not exist
> > in many packages, and maybe some developers want to put their
> > own effort into bringing more packages online with AVR32 support.
> > 
> > > I think if you have AVR32 changes, that shouln't go into
> > > uclibc-buildroot, then you could always send a patch to the
> > > avr32-buildroot mailing list or HCE.
> > 
> > I do not know of any AVR32 changes which I do not think
> > should go into uclibc-buildroot.
> 
> Then why is it a problem not to have commit access to HCE's repo?

If I or someone else have a AVR32 patch available that will enable 
a package to build for the AVR32, then I think it belongs in
uclibc-buildroot.




> Markus
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

Ulf Samuelsson, 08.01.2009:
> > > >> One of the key issues for an AVR32 developer is that they cannot
> > > >> commit additions to the Atmel version, so every time
> > > 
> > > > What's wrong with that? What would they want to commit?
> > > 
> > > X-Windows for a start...
> > > That was committed to Buildroot by John Voltz so he
> > > could run X on his AVR32 board.
> > > There are plenty of examples.
> > 
> > In package/x11r7/ there is only one little avr32 patch to support
> > xorg-server for this architecture. I think this is fine to be included
> > in uclibc-buildroot, as long as it is pushed upstream. I looked at
> > Xorg's git web interface and at least in the latest version it is
> > included.
> > 
> > So this is not a good example for a lack-of-commit-access issue with
> > HCE's repository.
> 
> You forget that  he created the build recipe,,,,,
> and he is actually a VERY good example.

I didn't understand this. Who is "he"? HCE? And which build recipe?

> > I rather thought of examples like the big mplayer patch. This doesn't
> > belong into uclibc-buildroot, but into the AVR32 repo. 
> 
> 
> I am sure you would think otherwise if you were an AVR32 user.

Eh, I am.

> > And as I said
> > earlier: without commit access just send a patch to HCE. I'm sure he
> > would be glad to apply it to get more packages working with/optimized
> > for AVR32.
> 
> The best way to have it upgraded, I guess is to 
> update the mplayer version.
> Then HCE will detect that mplayer will not build
> and the patch will be have to be rebased on the new version.

That's exactly the problem. We cannot update mplayer without breaking
anything. On the one hand you speak about creating releases, on the
other hand breaking packages is acceptable?

> You will of course see a new AVR32 patch quite soon in uclibc-buildroot.

If nobody has time to push the patch upstream, probably nobody will have
the time to update the patch to a newer mplayer version as well. And as
a result HCE will stay at the older version in his repository and
mplayer doesn't work for AVR32 with uclibc-buildroot.

But why not bump mplayer to 1.0rc2 and see what happens? It would be
interesting.

But if someone finds the time to update the patch, then I don't
understand why there won't be spent some more time to get it ready for
inclusion upstream. That's more effective than to always be behind and
having to adjust it to new a version.

> > > Since AVR32 is a fairly new architecture, support for it does not exist
> > > in many packages, and maybe some developers want to put their
> > > own effort into bringing more packages online with AVR32 support.
> > > 
> > > > I think if you have AVR32 changes, that shouln't go into
> > > > uclibc-buildroot, then you could always send a patch to the
> > > > avr32-buildroot mailing list or HCE.
> > > 
> > > I do not know of any AVR32 changes which I do not think
> > > should go into uclibc-buildroot.
> > 
> > Then why is it a problem not to have commit access to HCE's repo?
> 
> If I or someone else have a AVR32 patch available that will enable 
> a package to build for the AVR32, then I think it belongs in
> uclibc-buildroot.

I have never objected. But it depends on the type of the patch. A
simple patch that adds some architecture specific configurations
(endian or something) to get it working belongs to uclibc-buildroot. And
even there it can require some investigation to update the patch, if the
source code base has changed. And this investigation should be avoided
with pushing it upstream.

But a huge patch that adds lots of optimization code (mplayer) definetly
belongs to avr32-buildroot.

Markus

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

 Markus> I have never objected. But it depends on the type of the
 Markus> patch. A simple patch that adds some architecture specific
 Markus> configurations (endian or something) to get it working
 Markus> belongs to uclibc-buildroot. And even there it can require
 Markus> some investigation to update the patch, if the source code
 Markus> base has changed. And this investigation should be avoided
 Markus> with pushing it upstream.

 Markus> But a huge patch that adds lots of optimization code
 Markus> (mplayer) definetly belongs to avr32-buildroot.

I agree - Or atleast not in the buildroot I care about. Same with
feature patches, like the ones recently added to U-Boot. We really
need to keep patches to a minimum (and push them upstream) to stay
sane.

I repeat, Buildroot is not a dumping ground for random patches.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 >> I rather thought of examples like the big mplayer patch. This doesn't
 >> belong into uclibc-buildroot, but into the AVR32 repo. 

 Ulf> ?I am sure you would think otherwise if you were an AVR32 user.

Why? Wouldn't avr32 users use the atmel fork?

 >> Then why is it a problem not to have commit access to HCE's repo?

 Ulf> If I or someone else have a AVR32 patch available that will enable 
 Ulf> a package to build for the AVR32, then I think it belongs in
 Ulf> uclibc-buildroot.

This I cannot parse.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 04:09 +0100 skrev Markus Heidelberg:
> CC-ing Hans-Christian Egtvedt
> 
> Peter Korsgaard, 06.01.2009:
> > >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> >  Ulf> I can see that this would affect the AVR32 where
> >  Ulf> the patches are still to be introduced into gcc and binutils.
> >  Ulf> (They are there in uClibc right now).
> > 
> > Sorry, I don't know anything about avr32. It's my opinion that we have
> > too much special case handling for avr32/at91 in buildroot, and that
> > it's causing problems for the users + friction between developers
> > (E.G. see the recent openssl breakage)
> > 
> > But ok, that's the situation as it is today. My understanding is that
> > most of those patches are (slowly) progressing upstream.
> > 
> > Are you saying that the default config for avr32 doesn't build?

I managed to build the ngw100 yesterday,
but I had to disable SAMBA and STRACE and change to uCLibc-0.9.30
since 0.9.29 does not compile for anything I tried.

I giess a new version of STRACE has probably been introduced
and this broke the socat.XXX.patch.avr32 patches.
HCE has a new AVR32 patchset in the Atmel fork, which 
I hope to introduce soon.
With a new config, then the atngw100 should build again.

> > 
> > >>From talking with HcE on IRC, it seems like the Atmel fork of
> > buildroot is the recommended solution for avr32 users anyway.
> 
> I wonder, why many of the patches are also included in uClibc's
> Buildroot then. Don't the avr32 users use Atmel's Buildroot? I'm an
> avr32 user myself and only use Atmel's Buildroot for development. One
> drawback is that I'm not up-to-date with uClibc, because these changes
> are only seldom merged into the Atmel branches, only short before their
> release candidates. So I end up working on another file base, which
> doesn't ease integration of changes into uClibc's Buildroot. I could
> merge myself, a branch "upstream" is available and is updated often, but
> that doesn't make sense somehow. I haven't yet tried it, so I don't know
> whether it will cause some hassle or not.

I think it is desirable to have more people contributing
with testing and patches.


> 
> I haven't yet asked why this merge happens so rarely. Maybe lack of
> time? OK, I'm already getting avr32-buildroot specific, but I think
> updating the "devel" branch would be nice, even without testing
> anything.  Currently the three branches "devel", "master" and
> "atmel-2.3" are the same, pointing to the latest release.

Lack of time is the answer.
The way it works is that HCE is doing the Atmel Branch
and I am working on the main svn (even if HCE is providing
patches from time to time).

From time to time I am taking HCEs additions
from the Atmel branch and update the devel branch,
but I did really not have time to do anything
during most of the autumn.


> 
> >  Ulf> You have complained about size of patches, and 
> >  Ulf> that is why there is a prepatched toolchain for AVR32.
> >  Ulf> If that is not considered to be OK, then the several
> >  Ulf> MBytes of patches has to be introduced into the trunk.
> > 
> > It's not the size in bytes as such, it's the special casing and
> > (effectively) black box patches. Even when you test your changes on
> > multiple archs there's a fairly big change that you break stuff for
> > avr32/at91, or that you guys break it for the other archs. The same
> > with moving packages to new versions or removing old versions, you
> > cannot expect other people to forward port those arch specific
> > patches.

That is why other systems like OpenEmbedded allow having more
than one version of a package.
A system that only allows a single version is really not useful.
If new versions are introduced not because they are needed
or are tested, but because the tarball of the old version 
have disappeared, then we are going to have a mess.

A good system will allow buildroot to move to a 
newer version for some architectures, while not
breaking the build for other architectures.

* packages should depend on an enable variable
* This is set in a distribution file included by Kconfig
	which for each architecture defines 
	what is supported.
* Another distribution file ?can be included by Kconfig
	Contains enables for packages 
	which are *candidates* to be included
	in the distribution.
	This is not included for a stable build
?* Another distribution file is included, 
	This is empty, but the user can 
	put his own enables there if he wants
	to test other packages.
* Optional include of a file enabling ALL packages.

You have a similar set of files defining which versions
to be used for each package.
This is included inthe Makefile

You include a similar file for each architecture.
that can be used to override the value of the
first file.

An empty file is included, allowing the user to set 
his/her own value.

Each package has package/<package>/$(<package>_VERSION)
directories.
The distribution system includes a mechanism
that ensures that only the package with the
correct version is used,
We should probably support overriding
?package/<package>/$(<package>_VERSION)
with ?package/<package>/$(<package>_VERSION)-$(ARCH)
if available.

This approach will allow things to migrate 
from development to testing to stable without
upsetting a lot of users.
It will allow having multiple testing branches
and allow people to work on a single architecture without
having to test on other architectures,
but it will also allow to easily run a test
with a new version on a multitude of other 
architectures, once it is time to try
to get a new revision into the stable branch.

It will also allow us to freeze a distribution
allowing people to use buildroot for projects
which have a long lifetime.

I'd really like to get some feedback on this.


> Yes, mplayer for example is more than 2 years old and includes a huge
> avr32 patch.
> 
> Markus
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

 Ulf> but I had to disable SAMBA and STRACE and change to uCLibc-0.9.30
 Ulf> since 0.9.29 does not compile for anything I tried.

Ok, why would you use 0.9.29 now 0.9.30 is out? Anyway, I'll do a
0.9.29 test compile in a moment.

 Ulf> I giess a new version of STRACE has probably been introduced
 Ulf> and this broke the socat.XXX.patch.avr32 patches.

socat or strace?

It's probably caused by:

commit e3e68318e13e22e22c9619b24fc6dae1d8ac9e0a
Author: jacmet <jacmet@69ca8d6d-28ef-0310-b511-8ec308f3f277>
Date:   Mon Oct 20 09:04:49 2008 +0000

    strace: bump version
    
    Fixes build with 2.6.27 kernel headers

 Ulf> HCE has a new AVR32 patchset in the Atmel fork, which 
 Ulf> I hope to introduce soon.

Ok, but does it make sense when even HcE recommends people to use the
Atmel fork instead?

 >> I haven't yet asked why this merge happens so rarely. Maybe lack of
 >> time? OK, I'm already getting avr32-buildroot specific, but I think
 >> updating the "devel" branch would be nice, even without testing
 >> anything.  Currently the three branches "devel", "master" and
 >> "atmel-2.3" are the same, pointing to the latest release.

 Ulf> Lack of time is the answer.
 Ulf> The way it works is that HCE is doing the Atmel Branch
 Ulf> and I am working on the main svn (even if HCE is providing
 Ulf> patches from time to time).

With main svn you mean this tree? Maybe it would make more sense to
keep the Atmel stuff in your own fork?

 >> > It's not the size in bytes as such, it's the special casing and
 >> > (effectively) black box patches. Even when you test your changes on
 >> > multiple archs there's a fairly big change that you break stuff for
 >> > avr32/at91, or that you guys break it for the other archs. The same
 >> > with moving packages to new versions or removing old versions, you
 >> > cannot expect other people to forward port those arch specific
 >> > patches.

 Ulf> That is why other systems like OpenEmbedded allow having more
 Ulf> than one version of a package.
 Ulf> A system that only allows a single version is really not useful.

Sorry, I disagree. Most packages only have a single version and that
works fine. Almost everything under packages builds just fine on any
sane architecture. Look at huge distributions like Debian with 18K+
packages all building from the same sources on all archs.

 Ulf> A good system will allow buildroot to move to a 
 Ulf> newer version for some architectures, while not
 Ulf> breaking the build for other architectures.

I disagree. This is exactly what we SHOULDN'T do. We need to keep
close to upstream and only provide the latest stable version (except
for special situations) and work with upstream to fix problems if any.

Anything else is just too much work with too little improvements going
upstream.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 12:28 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  Ulf> but I had to disable SAMBA and STRACE and change to uCLibc-0.9.30
>  Ulf> since 0.9.29 does not compile for anything I tried.
> 
> Ok, why would you use 0.9.29 now 0.9.30 is out? Anyway, I'll do a
> 0.9.29 test compile in a moment.
> 
>  Ulf> I giess a new version of STRACE has probably been introduced
>  Ulf> and this broke the socat.XXX.patch.avr32 patches.
> 
> socat or strace?

sorry - strace.


> 
> It's probably caused by:
> 
> commit e3e68318e13e22e22c9619b24fc6dae1d8ac9e0a
> Author: jacmet <jacmet@69ca8d6d-28ef-0310-b511-8ec308f3f277>
> Date:   Mon Oct 20 09:04:49 2008 +0000
> 
>     strace: bump version
>     
>     Fixes build with 2.6.27 kernel headers
> 
>  Ulf> HCE has a new AVR32 patchset in the Atmel fork, which 
>  Ulf> I hope to introduce soon.
> 
> Ok, but does it make sense when even HcE recommends people to use the
> Atmel fork instead?

Atmel Norway has come to the conclusion that since 
Builkroot does not have stable distributions
Atmel cannot rely on the main trunk.

That is a problem known to everyone, and
if this is fixed, then I see no reason for Atmel to maintain
its own fork.

It is not fixed by a system which has stable distributions
which are removed and replaced with another stable
distribution which breaks support for a number of systems.
Then distributions might be stable, but the system as a whole
is totally unstable, and unacceptable for professional use.

>  >> I haven't yet asked why this merge happens so rarely. Maybe lack of
>  >> time? OK, I'm already getting avr32-buildroot specific, but I think
>  >> updating the "devel" branch would be nice, even without testing
>  >> anything.  Currently the three branches "devel", "master" and
>  >> "atmel-2.3" are the same, pointing to the latest release.
> 
>  Ulf> Lack of time is the answer.
>  Ulf> The way it works is that HCE is doing the Atmel Branch
>  Ulf> and I am working on the main svn (even if HCE is providing
>  Ulf> patches from time to time).
> 
> With main svn you mean this tree? Maybe it would make more sense to
> keep the Atmel stuff in your own fork?

That is not my own fork, it is Atmel Norways fork.



>  >> > It's not the size in bytes as such, it's the special casing and
>  >> > (effectively) black box patches. Even when you test your changes on
>  >> > multiple archs there's a fairly big change that you break stuff for
>  >> > avr32/at91, or that you guys break it for the other archs. The same
>  >> > with moving packages to new versions or removing old versions, you
>  >> > cannot expect other people to forward port those arch specific
>  >> > patches.
> 
>  Ulf> That is why other systems like OpenEmbedded allow having more
>  Ulf> than one version of a package.
>  Ulf> A system that only allows a single version is really not useful.
> 
> Sorry, I disagree. Most packages only have a single version and that
> works fine. Almost everything under packages builds just fine on any
> sane architecture. Look at huge distributions like Debian with 18K+
> packages all building from the same sources on all archs.
> 
>  Ulf> A good system will allow buildroot to move to a 
>  Ulf> newer version for some architectures, while not
>  Ulf> breaking the build for other architectures.
> 
> I disagree. This is exactly what we SHOULDN'T do. We need to keep
> close to upstream and only provide the latest stable version (except
> for special situations) and work with upstream to fix problems if any.

Which will break architectures continously, so it will not allow
the use of Buildroot as more than a toy to introduce Linux
until people find something that really works.
 

> Anything else is just too much work with too little improvements going
> upstream.
> 

I do not disagree that we need to ensure that patches are fed upstream,
but the current way does not support working as a team project.
It is a single user system.

Since we have opposing views, then I think the rest of the 
people interested in maintaining buildroot, needs to 
also show their desires before any drastic actions in either
direction is taken.



Best Regards
Ulf Samuelsson

[Buildroot] Buildroot maintainer and stable releases

[Nigel Kukard]

> Since we have opposing views, then I think the rest of the 
> people interested in maintaining buildroot, needs to 
> also show their desires before any drastic actions in either
> direction is taken.
>   
I for one am in agreement with Peter's views. I'm not going to type out
50 gazillion pages stating nearly exactly what he's stated in the past
few/many posts so I will keep it to one LOONG sentance.

We design and develop embedded i586/x86_64 software solutions covered by
SLAs, while I agree that changing one or two packages should not break
everyones build, that is why MAINTAINERS are required to ensure the
changes made do not break everything and if it does break something
unrelated the MAINTAINER of that must fix it and it should not become a
blocking factor to follow upstream closely.

-N

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 Ulf> but I had to disable SAMBA and STRACE and change to uCLibc-0.9.30
 Ulf> since 0.9.29 does not compile for anything I tried.
 >> 
 >> Ok, why would you use 0.9.29 now 0.9.30 is out? Anyway, I'll do a
 >> 0.9.29 test compile in a moment.

Builds ok here on armv4l with gcc 4.24 / 2.6.28 headers (breaks with
4.3.x with the limits.h error). I'm not interested in fixing up 0.9.29
to work with current compilers, but feel free to do so.

 Ulf> I giess a new version of STRACE has probably been introduced
 Ulf> and this broke the socat.XXX.patch.avr32 patches.
 >> 
 >> socat or strace?

 Ulf> sorry - strace.

Ok, HcE will afaik check in the updated avr32 patch once he gets the
connection sorted out.

 Ulf> It is not fixed by a system which has stable distributions
 Ulf> which are removed and replaced with another stable
 Ulf> distribution which breaks support for a number of systems.
 Ulf> Then distributions might be stable, but the system as a whole
 Ulf> is totally unstable, and unacceptable for professional use.

Breaks support? That shouldn't happen if the release candidates gets
enough testing. 100% safety is not realistic, if you want that, just
don't upgrade to the new version.

 >> With main svn you mean this tree? Maybe it would make more sense to
 >> keep the Atmel stuff in your own fork?

 Ulf> That is not my own fork, it is Atmel Norways fork.

Yes, but Ulf == Atmel.no, right?

 >> I disagree. This is exactly what we SHOULDN'T do. We need to keep
 >> close to upstream and only provide the latest stable version (except
 >> for special situations) and work with upstream to fix problems if any.

 Ulf> Which will break architectures continously, so it will not allow
 Ulf> the use of Buildroot as more than a toy to introduce Linux
 Ulf> until people find something that really works.

Why? Seems to work pretty well elsewhere.

 >> Anything else is just too much work with too little improvements
 >> going upstream.

 Ulf> I do not disagree that we need to ensure that patches are fed
 Ulf> upstream, but the current way does not support working as a team
 Ulf> project.  It is a single user system.

This I don't get - What do you mean?

 Ulf> Since we have opposing views, then I think the rest of the 
 Ulf> people interested in maintaining buildroot, needs to 
 Ulf> also show their desires before any drastic actions in either
 Ulf> direction is taken.

Sure, feel free to speak up.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Wed, Jan 07, 2009 at 01:10:38PM +0100, Ulf Samuelsson wrote:
> 
> It is not fixed by a system which has stable distributions
> which are removed and replaced with another stable
> distribution which breaks support for a number of systems.

Replaced? It's versioned (and tagged in the VCS) so it's not 
that an old version just ends up in /dev/null

The main issue regarding older releases is that the source packages might
not be available where they used to be. That's a different issue
that seems to be addressed anyway.



Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 19:13 +0100 skrev Thomas Lundquist:
> On Wed, Jan 07, 2009 at 01:10:38PM +0100, Ulf Samuelsson wrote:
> > 
> > It is not fixed by a system which has stable distributions
> > which are removed and replaced with another stable
> > distribution which breaks support for a number of systems.
> 
> Replaced? It's versioned (and tagged in the VCS) so it's not 
> that an old version just ends up in /dev/null
> 
> The main issue regarding older releases is that the source packages might
> not be available where they used to be. That's a different issue
> that seems to be addressed anyway.
> 

When we release a distribution, then all needed packages
in that distribution needs to be mirrored somewhere.

This was a key requirement when I pestered Atmel Norway 
to replace their build scripts with buildroot,
and I think HCE has implemented it.
There is a scripts/wget.sh which I will have a look at.


> 
> Thomas.
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 Ulf> When we release a distribution, then all needed packages
 Ulf> in that distribution needs to be mirrored somewhere.

Agreed (long term atleast).

 Ulf> This was a key requirement when I pestered Atmel Norway 
 Ulf> to replace their build scripts with buildroot,
 Ulf> and I think HCE has implemented it.
 Ulf> There is a scripts/wget.sh which I will have a look at.

From a quick look that script just seems to handle the backup mirror
thing like we have in Makefile.autotools.in.

For populating a mirror you can use make source instead (for all
possible configurations)

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Wed, Jan 07, 2009 at 08:16:48PM +0100, Ulf Samuelsson wrote:
> 
> When we release a distribution, then all needed packages
> in that distribution needs to be mirrored somewhere.

Maybe not just right then but later, yes. The Linux kernel and gcc 
does not have to be a part of this scheme since they are all available
at the source. I guess a few other packages might also be like that.

The other option is to always mirror and use one download source 
for all packages except the ones mentioned above.

This will require some disk space and bandwidth but not nessesarily 
that much since many of the biggest tarballs does not need 
to be mirrored.

> This was a key requirement when I pestered Atmel Norway 
> to replace their build scripts with buildroot,
> and I think HCE has implemented it.
> There is a scripts/wget.sh which I will have a look at.

make source might work but not tested.


Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:

Hi,

 >> When we release a distribution, then all needed packages
 >> in that distribution needs to be mirrored somewhere.

 Thomas> Maybe not just right then but later, yes. The Linux kernel and gcc 
 Thomas> does not have to be a part of this scheme since they are all available
 Thomas> at the source. I guess a few other packages might also be like that.

 Thomas> The other option is to always mirror and use one download source 
 Thomas> for all packages except the ones mentioned above.

I would prefer a backup system like what we have for
Makefile.autotools.in - E.G. try the upstream location first, and only
if that fails go to the mirror.

 Thomas> make source might work but not tested.

It does work, but it ofcourse only downloads the package(-versions)
you are using.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

Ulf Samuelsson, 07.01.2009:
> ons 2009-01-07 klockan 04:09 +0100 skrev Markus Heidelberg:
> > CC-ing Hans-Christian Egtvedt
> > 
> > Peter Korsgaard, 06.01.2009:
> > > >>From talking with HcE on IRC, it seems like the Atmel fork of
> > > buildroot is the recommended solution for avr32 users anyway.
> > 
> > I wonder, why many of the patches are also included in uClibc's
> > Buildroot then. Don't the avr32 users use Atmel's Buildroot? I'm an
> > avr32 user myself and only use Atmel's Buildroot for development. One
> > drawback is that I'm not up-to-date with uClibc, because these changes
> > are only seldom merged into the Atmel branches, only short before their
> > release candidates. So I end up working on another file base, which
> > doesn't ease integration of changes into uClibc's Buildroot. I could
> > merge myself, a branch "upstream" is available and is updated often, but
> > that doesn't make sense somehow. I haven't yet tried it, so I don't know
> > whether it will cause some hassle or not.
> 
> I think it is desirable to have more people contributing
> with testing and patches.

Then what's the purpose of buildroot-avr32, when you seem to say
uclibc-buildroot should be used for AVR32 development? A personal
playground for HCE and cherry-picking for you into uclibc-buildroot?
Surely not. This repository is well-tested for all of Atmel's AVR32
boards for every release and even during the release candidates.

> > I haven't yet asked why this merge happens so rarely. Maybe lack of
> > time? OK, I'm already getting avr32-buildroot specific, but I think
> > updating the "devel" branch would be nice, even without testing
> > anything.  Currently the three branches "devel", "master" and
> > "atmel-2.3" are the same, pointing to the latest release.
> 
> Lack of time is the answer.
> The way it works is that HCE is doing the Atmel Branch
> and I am working on the main svn (even if HCE is providing
> patches from time to time).
> 
> >>From time to time I am taking HCEs additions
> from the Atmel branch and update the devel branch,
> but I did really not have time to do anything
> during most of the autumn.

What is the devel branch you mentioned? Above I refered to the devel
branch from HCE, I don't think you work on his devel branch, I haven't
seen a commit from you there. Do you mean uclibc-buildroot?

See my comment above. Why picking commits from HCE, making his
repository more valueless, because everything is also in
uclibc-buildroot and at the same time risk breaking it or prevent
updating packages (mplayer for example)?

Markus

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

Hi,

 Markus> See my comment above. Why picking commits from HCE, making his
 Markus> repository more valueless, because everything is also in
 Markus> uclibc-buildroot and at the same time risk breaking it or prevent
 Markus> updating packages (mplayer for example)?

I would like to know that as well.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 12:54 +0100 skrev Peter Korsgaard:
> >>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:
> 
> Hi,
> 
>  Markus> See my comment above. Why picking commits from HCE, making his
>  Markus> repository more valueless, because everything is also in
>  Markus> uclibc-buildroot and at the same time risk breaking it or prevent
>  Markus> updating packages (mplayer for example)?
> 

I think I have shown that you can have the cookie and eat it as well.
With my proposal there will be

?* Very little need to declare an architecture broken
  by allowing limitations on each architectures.

* A single source version for a distribution

* Patches that are tested and verified for all 
  architectures, for which the package is available.

* possibilities to commit for development purposes,
?  without disrupting the stable or testing 
  distribution. This activity can be ongoing,
  and there is no need to stop the fixing
  of a package, due to release dates.
  Allowing patches for development purposes
  allows buildroot to become a team effort.

* Allow stable distribution to coexist with
  test distributions.

* Allow existence of multiple distributions

* Allow users to work with custom patches
  easily without commiting until proved correct.


Best Regards
Ulf Samuelsson
> I would like to know that as well.
> 

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Mon, Jan 05, 2009 at 10:18:01PM +0100, Peter Korsgaard wrote:
> 
> I offer to do something about both: Take over maintainership and get
> atual stable releases out the door (if Erik and the other developers
> agree).

The first question then is what kind of maintainer you mean. 

The One that makes releases or The One that maintains coherency and 
vetoes big changes?

> What is the plan? Getting the first release out is always the hardest,
> so I would on purpose aim low for the first release and get it out
> soon (February).

That *is* quick.

> The target is to get all architectures to build (and
> run where hw is available for test) using the default toolchain config
> and busybox, anything else is just a bonus.

Should we have some arch_testconfig as we have defconfigs? First start
with a simple config then add more.

> I will put out the first
> release candidate early next week, so from then on please don't add
> anything else than bugfixes until the release it out. I believe in
> time based releases, so any architectures that we cannot fix in time
> will simply be disabled in kconfig (E.G. depend on BROKEN).

BROKEN or ROTTEN or something that will alert future maintainer-wannabees.

> The big issue with buildroot quality control is the mindblowing number
> of configuration combinations and specialized hardware needed to
> test. 

This has to be handles by a defined set of test cases based on more 
or less generic HW, like evaluation kits. 

And also devices actively maintained by someone wanting it to be a 
part of the test collection.

The odd cases have to be taken care of by ordinary bug tickets.

(BTW; WCHAR and LOCALE OFF is NOT a special case, it should be default.
 In my view, also LARGEFILE.)

> I am therefore convinced we need to leverage qemu and
> agressively deprecate legacy versions / packages + actively work with
> upstream to keep the number of patches low. 

I am afraid we need more than one version of the kernel (Ulf wants is also) 
and I guess also of most of the toolchain but the packages/ is another story.

If we do releases we should be able to cut down on the amount of versions in
the toolchain aswell, since comppanies should freeze on a version if they plan
to use it for years as Ulf mentioned.

> I think our users would
> also be happier with a less ambitious project that wouldn't break left
> and right, instead of the current situation.

Agreed.

First thing I guess is to agree that we want this and 
then to make test criterias.

After that, lay down which big changes we want and distribute 
maintainer responsibilities.



Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:

Hi,

 Thomas> On Mon, Jan 05, 2009 at 10:18:01PM +0100, Peter Korsgaard wrote:
 >> 
 >> I offer to do something about both: Take over maintainership and get
 >> atual stable releases out the door (if Erik and the other developers
 >> agree).

 Thomas> The first question then is what kind of maintainer you mean. 

 Thomas> The One that makes releases or The One that maintains
 Thomas> coherency and vetoes big changes?

Primarily the first, but also the 2nd where needed. I think we have
done relatively good so far without a maintainer, so I expect the 2nd
part to be fairly infrequent.

 >> What is the plan? Getting the first release out is always the
 >> hardest, so I would on purpose aim low for the first release and
 >> get it out soon (February).

 Thomas> That *is* quick.

It is, but why delay it any longer? People are using current svn
anyway, so we might as well make a release of it.

 >> The target is to get all architectures to build (and
 >> run where hw is available for test) using the default toolchain config
 >> and busybox, anything else is just a bonus.

 Thomas> Should we have some arch_testconfig as we have defconfigs?
 Thomas> First start with a simple config then add more.

Maybe. I would just start with the rm .config; make menuconf, select
arch, save; make

 >> I will put out the first
 >> release candidate early next week, so from then on please don't add
 >> anything else than bugfixes until the release it out. I believe in
 >> time based releases, so any architectures that we cannot fix in time
 >> will simply be disabled in kconfig (E.G. depend on BROKEN).

 Thomas> BROKEN or ROTTEN or something that will alert future
 Thomas> maintainer-wannabees.

Exactly.

 >> The big issue with buildroot quality control is the mindblowing
 >> number of configuration combinations and specialized hardware
 >> needed to test.

 Thomas> This has to be handles by a defined set of test cases based
 Thomas> on more or less generic HW, like evaluation kits.

Or qemu.

 Thomas> And also devices actively maintained by someone wanting it to
 Thomas> be a part of the test collection.

 Thomas> The odd cases have to be taken care of by ordinary bug tickets.

 Thomas> (BTW; WCHAR and LOCALE OFF is NOT a special case, it should
 Thomas> be default.  In my view, also LARGEFILE.)

You mean default on? They currently default to off, simply because of
their size impact.

 >> I am therefore convinced we need to leverage qemu and
 >> agressively deprecate legacy versions / packages + actively work with
 >> upstream to keep the number of patches low. 

 Thomas> I am afraid we need more than one version of the kernel (Ulf
 Thomas> wants is also) and I guess also of most of the toolchain but
 Thomas> the packages/ is another story.

Maybe, but we can surely do better than todays' forest.


 Thomas> If we do releases we should be able to cut down on the amount
 Thomas> of versions in the toolchain aswell, since comppanies should
 Thomas> freeze on a version if they plan to use it for years as Ulf
 Thomas> mentioned.

Exactly.

 >> I think our users would
 >> also be happier with a less ambitious project that wouldn't break left
 >> and right, instead of the current situation.

 Thomas> Agreed.

 Thomas> First thing I guess is to agree that we want this and 
 Thomas> then to make test criterias.

 Thomas> After that, lay down which big changes we want and distribute 
 Thomas> maintainer responsibilities.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Tue, Jan 06, 2009 at 04:08:15PM +0100, Peter Korsgaard wrote:
> 
>  Thomas> Should we have some arch_testconfig as we have defconfigs?
>  Thomas> First start with a simple config then add more.
> 
> Maybe. I would just start with the rm .config; make menuconf, select
> arch, save; make

It's a start of course but is the resulting .config a good config or just 
more or less random?

>  Thomas> This has to be handles by a defined set of test cases based
>  Thomas> on more or less generic HW, like evaluation kits.
> 
> Or qemu.

True.

>  Thomas> (BTW; WCHAR and LOCALE OFF is NOT a special case, it should
>  Thomas> be default.  In my view, also LARGEFILE.)
> 
> You mean default on? They currently default to off, simply because of
> their size impact.

Default OFF. I haven't messed with g++ lately but it had a tendency 
to not work without WCHAR ON. It may be back in 3.X days though.

LARGEFILE set to off is another option I'd like to have as a test 
case but I have a slight feeling that will hinder a release 
for quite some time..


Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:

Hi,

 >> Maybe. I would just start with the rm .config; make menuconf, select
 >> arch, save; make

 Thomas> It's a start of course but is the resulting .config a good
 Thomas> config or just more or less random?

Hopefully good - It's the default config of everything, just like any
new user would see it. If anything is not sensible then we should
change the defaults.

 Thomas> (BTW; WCHAR and LOCALE OFF is NOT a special case, it should
 Thomas> be default.  In my view, also LARGEFILE.)
 >> 
 >> You mean default on? They currently default to off, simply because of
 >> their size impact.

 Thomas> Default OFF. I haven't messed with g++ lately but it had a tendency 
 Thomas> to not work without WCHAR ON. It may be back in 3.X days though.

It work for me here on PPC (gcc 4.2.x / 4.3.x).

 Thomas> LARGEFILE set to off is another option I'd like to have as a test 
 Thomas> case but I have a slight feeling that will hinder a release 
 Thomas> for quite some time..

WCHAR, LOCALE and LARGEFILE all defaults to off, so that's imho a
pretty well tested.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

tis 2009-01-06 klockan 19:52 +0100 skrev Peter Korsgaard:
> >>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:
> 
> Hi,
> 
>  >> Maybe. I would just start with the rm .config; make menuconf, select
>  >> arch, save; make
> 
>  Thomas> It's a start of course but is the resulting .config a good
>  Thomas> config or just more or less random?
> 
> Hopefully good - It's the default config of everything, just like any
> new user would see it. If anything is not sensible then we should
> change the defaults.
> 
>  Thomas> (BTW; WCHAR and LOCALE OFF is NOT a special case, it should
>  Thomas> be default.  In my view, also LARGEFILE.)
>  >> 
>  >> You mean default on? They currently default to off, simply because of
>  >> their size impact.
> 
>  Thomas> Default OFF. I haven't messed with g++ lately but it had a tendency 
>  Thomas> to not work without WCHAR ON. It may be back in 3.X days though.
> 
> It work for me here on PPC (gcc 4.2.x / 4.3.x).
> 
>  Thomas> LARGEFILE set to off is another option I'd like to have as a test 
>  Thomas> case but I have a slight feeling that will hinder a release 
>  Thomas> for quite some time..
> 
> WCHAR, LOCALE and LARGEFILE all defaults to off, so that's imho a
> pretty well tested.

I have been running with them on for a long time, since
when I last tried them OFF, there were a lot of packages
which did seemed to require at least WCHAR to build properly for ARM.

There are nice advantages if these packages could be made
to run without WHCAR of course.

A typical issue that pops up from time to time is that
people build the toolchain with a certain configuration
and then finds that they need a different configurtion
to build a package, and do not realize that they 
need to rebuild the toolchain for the changes to take effect.

It would be good to resolve this, and this is why I have
proposed to separate toolchain build.
With SYSROOT in gcc-4 there is really no reason 
to induce people to rebuild the toolchain,
and we might want to support downloading a binary toolchain as well.


Peter Korsgaard <jacmet@uclibc.org>,
BR
Ulf

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 >> WCHAR, LOCALE and LARGEFILE all defaults to off, so that's imho a
 >> pretty well tested.

 Ulf> I have been running with them on for a long time, since when I
 Ulf> last tried them OFF, there were a lot of packages which did
 Ulf> seemed to require at least WCHAR to build properly for ARM.

Don't know about ARM, but the ~10 PPC configs I regularly build all
have WCHAR off.

 Ulf> A typical issue that pops up from time to time is that
 Ulf> people build the toolchain with a certain configuration
 Ulf> and then finds that they need a different configurtion
 Ulf> to build a package, and do not realize that they 
 Ulf> need to rebuild the toolchain for the changes to take effect.

That's why those things depends on those toolchain features, instead
of select'ing them like what we do for libraries.

 Ulf> It would be good to resolve this, and this is why I have
 Ulf> proposed to separate toolchain build.
 Ulf> With SYSROOT in gcc-4 there is really no reason 
 Ulf> to induce people to rebuild the toolchain,
 Ulf> and we might want to support downloading a binary toolchain as well.

A binary toolchain sounds to me like a serious support headache, but
if you want to do it, feel free.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Tue, Jan 06, 2009 at 08:09:30PM +0100, Ulf Samuelsson wrote:
> 
> A typical issue that pops up from time to time is that
> people build the toolchain with a certain configuration
> and then finds that they need a different configurtion
> to build a package, and do not realize that they 
> need to rebuild the toolchain for the changes to take effect.

Which is why...

> It would be good to resolve this, and this is why I have
> proposed to separate toolchain build.

..This is a bad idea.

(Since the rebuild should be automagic if there are 
 changes in configurations that requires one.)

> With SYSROOT in gcc-4 there is really no reason 
> to induce people to rebuild the toolchain,
> and we might want to support downloading a binary toolchain as well.

The only way to support this should be through the "external toolchain" 
thingie. (And that should have it's own maintainer, one that uses this)


Thomas

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 19:43 +0100 skrev Thomas Lundquist:
> On Tue, Jan 06, 2009 at 08:09:30PM +0100, Ulf Samuelsson wrote:
> > 
> > A typical issue that pops up from time to time is that
> > people build the toolchain with a certain configuration
> > and then finds that they need a different configurtion
> > to build a package, and do not realize that they 
> > need to rebuild the toolchain for the changes to take effect.
> 
> Which is why...
> 
> > It would be good to resolve this, and this is why I have
> > proposed to separate toolchain build.
> 
> ..This is a bad idea.
> 
> (Since the rebuild should be automagic if there are 
>  changes in configurations that requires one.)

It doesn't rebuild automatically right now.

I think that this is the main reason why I think 
the toolchain should be separate.

When the toolchain has been build it should generate
Config.in files automatically, which is included
by the Buildroot Config.in.

You will then have access to the toolchain
parameters, but you will not have the ability
to add packages depending on non avaialble options.

You will have to go back and reconfigure the toolchain
when then will then be forced to be rebuilt.

gcctools:	toolchain/.config
		make -C toolchain 
		touch $@

and then the toolchain is automatically rebuilt
everytime the toolchain configuration is changed.

If you can change an option easily which forces the rebuild
of a toolchian, then you can also change an option by
mistake making you lose a couple of hours...

> 
> > With SYSROOT in gcc-4 there is really no reason 
> > to induce people to rebuild the toolchain,
> > and we might want to support downloading a binary toolchain as well.
> 
> The only way to support this should be through the "external toolchain" 
> thingie. (And that should have it's own maintainer, one that uses this)
> 

If you separate the build then (almost) everyone will build
then native toolchain and then use it as an external toolchain.

> 
> Thomas
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Wed, Jan 07, 2009 at 08:26:17PM +0100, Ulf Samuelsson wrote:
> 
> It doesn't rebuild automatically right now.
> 
> I think that this is the main reason why I think 
> the toolchain should be separate.

> When the toolchain has been build it should generate
> Config.in files automatically, which is included
> by the Buildroot Config.in.

With only the options working with that specific toochain? 

That will hide the users real options.

> You will then have access to the toolchain
> parameters, but you will not have the ability
> to add packages depending on non avaialble options.

If it is possible to know this, the opposite is possible too, and that is 
to keep the available options instead of hiding it but show / tell the 
user that this will result in a recompiled toolchain.

(One reason I am a bit recultant to do this automagically, that it turning on the 
 nessesary toolchain options is that options like WCHAR adds alot.)

> If you can change an option easily which forces the rebuild
> of a toolchian, then you can also change an option by
> mistake making you lose a couple of hours...

Figuring out that the one little thing you wanted would be available if 
you just turned on something in the toolchain takes alot longer and 
frustrates alot more. That is the *users* time wasted, not CPU time.

I'd rather have a warning of some sort.



Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:

 Thomas> If it is possible to know this, the opposite is possible too,
 Thomas> and that is to keep the available options instead of hiding
 Thomas> it but show / tell the user that this will result in a
 Thomas> recompiled toolchain.

We already have this several places under packages/

comment "xorg requires a toolchain with LOCALE and WCHAR support"
comment "iperf requires a toolchain with C++ support enabled"

And so on.

 >> If you can change an option easily which forces the rebuild
 >> of a toolchian, then you can also change an option by
 >> mistake making you lose a couple of hours...

No, as packages/* depends on toolchain settings, they don't select
them.

 Thomas> Figuring out that the one little thing you wanted would be
 Thomas> available if you just turned on something in the toolchain
 Thomas> takes alot longer and frustrates alot more. That is the
 Thomas> *users* time wasted, not CPU time.

Exactly, that's what the current comments are for.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Wed, Jan 07, 2009 at 09:31:10PM +0100, Peter Korsgaard wrote:
> 
> comment "xorg requires a toolchain with LOCALE and WCHAR support"
> comment "iperf requires a toolchain with C++ support enabled"
> 
> And so on.

That's a comment, maybe make it a bit more in-the-face?

(This is more like "finer details" and can be handled if we make the 
 metainfo-files I'd like to have.)


Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:

 Thomas> On Wed, Jan 07, 2009 at 09:31:10PM +0100, Peter Korsgaard wrote:
 >> 
 >> comment "xorg requires a toolchain with LOCALE and WCHAR support"
 >> comment "iperf requires a toolchain with C++ support enabled"
 >> 
 >> And so on.

 Thomas> That's a comment, maybe make it a bit more in-the-face?

The comment is displayed in menuconfig - E.G.

 [ ] ifplugd
 [ ] irda_utils  --->
     *** iperf requires a toolchain with C++ support enabled ***
 [ ] iproute2

I find that pretty clear.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Thu, Jan 08, 2009 at 10:12:17AM +0100, Peter Korsgaard wrote:
> 
>  [ ] ifplugd
>  [ ] irda_utils  --->
>      *** iperf requires a toolchain with C++ support enabled ***
>  [ ] iproute2
> 
> I find that pretty clear.

Hmm, ok then. It is :=)


Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 21:22 +0100 skrev Thomas Lundquist:
> On Wed, Jan 07, 2009 at 08:26:17PM +0100, Ulf Samuelsson wrote:
> > 
> > It doesn't rebuild automatically right now.
> > 
> > I think that this is the main reason why I think 
> > the toolchain should be separate.
> 
> > When the toolchain has been build it should generate
> > Config.in files automatically, which is included
> > by the Buildroot Config.in.
> 
> With only the options working with that specific toochain? 
> 
> That will hide the users real options.

If the user wants to know which options he has to build the
toolchain, then he will have to configre the toolchain.

It is the same with busybox, uClibc and linux. 
You can only configure  a few things from buildroot.

> 
> > You will then have access to the toolchain
> > parameters, but you will not have the ability
> > to add packages depending on non avaialble options.
> 
> If it is possible to know this, the opposite is possible too, and that is 
> to keep the available options instead of hiding it but show / tell the 
> user that this will result in a recompiled toolchain.

I think it could be harder to implement.
I do agree that you do not want a package to be totally
invisible, just because of an toolchain option.
I think that if a package IS disabled, then it could still be visible,
but the reason for it to be impossible to select is shown.


> (One reason I am a bit recultant to do this automagically, that it turning on the 
>  nessesary toolchain options is that options like WCHAR adds alot.)
> 
> > If you can change an option easily which forces the rebuild
> > of a toolchian, then you can also change an option by
> > mistake making you lose a couple of hours...
> 
> Figuring out that the one little thing you wanted would be available if 
> you just turned on something in the toolchain takes alot longer and 
> frustrates alot more. That is the *users* time wasted, not CPU time.

You need the information, but if you instead of:

[ ] socat

would get

--- socat -- needs toolchain with WCHAR

Would that be uncacceptable?

Maybe you could get an even better
description if each package had 
a menuconfig if the package cannot be
selected with the package name in CAPITALS.

[ ] NO SOCAT 

If cyou check the box you get
?
[*] NO SOCAT 
--- toolchain must be built with WCHAR enabled
--- socat requires pacakge <x>

You may have to set a global variable to enable 
the reason for hiding a package.

Will complicate the Config.in files a lot, but 
would sure be nice.
It is hard searching through the Config tree help



> I'd rather have a warning of some sort.
> 
> 
> 
> Thomas.
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 >> Figuring out that the one little thing you wanted would be
 >> available if you just turned on something in the toolchain takes
 >> alot longer and frustrates alot more. That is the *users* time
 >> wasted, not CPU time.

 Ulf> You need the information, but if you instead of:

 Ulf> [ ] socat

 Ulf> would get

 Ulf> --- socat -- needs toolchain with WCHAR

 Ulf> Would that be uncacceptable?

That's what we have already for a bunch of packages.

 Ulf> Maybe you could get an even better
 Ulf> description if each package had 
 Ulf> a menuconfig if the package cannot be
 Ulf> selected with the package name in CAPITALS.

 Ulf> [ ] NO SOCAT 

 Ulf> If cyou check the box you get
 Ulf> ?
 Ulf> [*] NO SOCAT 
 Ulf> --- toolchain must be built with WCHAR enabled
 Ulf> --- socat requires pacakge <x>

No, packages should just select their (library) dependencies, instead
of asking the user to hunt around for those dependencies.

So in short:
 - Depend on toolchain details (and display comment if not available)
 - Select package dependencies

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Nigel Kukard]

Hi,

> Hi, and happy new year everyone,
>   
Likewise.

> The end of the year is a moment to take a step back and take a bigger
> look at the situation. I have done that for buildroot, and as I see it
> the two biggest problems we have are:
>
>  - Lack of an active maintainer. No hard feelings, but lets face it -
>    Erik hasn't really been active in buildroot development for quite
>    some time. This isn't a big deal for day to day development, but it
>    means that there's no one doing stuff like keeping the website
>    up to date, a central contact point for infrastruture issues (like
>    the recent break in), make decissions when there is disagreements
>    among developers (we already lost Bernhard because of that), and:
>   
wrt central contacts and points of contacts ... we need that MAINTAINERS
file :)

>  - Lack of releases. It has often been discussed, but nothing has come
>    of it.
>
> I offer to do something about both: Take over maintainership and get
> atual stable releases out the door (if Erik and the other developers
> agree).
>   
Personally I like how you handle the project and try steer it with the
resources available, I would like to see you being the project maintainer.


> What is the plan? Getting the first release out is always the hardest,
> so I would on purpose aim low for the first release and get it out
> soon (February). The target is to get all architectures to build (and
> run where hw is available for test) using the default toolchain config
> and busybox, anything else is just a bonus. I will put out the first
> release candidate early next week, so from then on please don't add
> anything else than bugfixes until the release it out. I believe in
> time based releases, so any architectures that we cannot fix in time
> will simply be disabled in kconfig (E.G. depend on BROKEN).
>
> After that I would like us to move to a regular release schedule every
> 3 months with 2 months of development and 1 month of stabilization.
>   
And those components without maintainers scheduled to be dropped or
deprecated (using BROKEN, DEPRECATED, NEEDS_MAINTAINER or however the
finer detail may advise) after X number of releases if no maintainer
steps up, this would help with some of the more severe bitrot in
portions of buildroot.

> The big issue with buildroot quality control is the mindblowing number
> of configuration combinations and specialized hardware needed to
> test. I am therefore convinced we need to leverage qemu and
> agressively deprecate legacy versions / packages + actively work with
> upstream to keep the number of patches low. I think our users would
> also be happier with a less ambitious project that wouldn't break left
> and right, instead of the current situation.
>
>   
The other thing is possibly a mirror for buildroot releases so people at
least know those packages at those versions will always be available, or
at least available 6 months or so down the line?

-N

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Nigel" == Nigel Kukard <nkukard@lbsd.net> writes:

Hi,

 Nigel> wrt central contacts and points of contacts ... we need that
 Nigel> MAINTAINERS file :)

Yes ;)

 >> I offer to do something about both: Take over maintainership and get
 >> atual stable releases out the door (if Erik and the other developers
 >> agree).
 >> 

 Nigel> Personally I like how you handle the project and try steer it
 Nigel> with the resources available, I would like to see you being
 Nigel> the project maintainer.

Thanks.

 >> After that I would like us to move to a regular release schedule every
 >> 3 months with 2 months of development and 1 month of stabilization.
 >> 
 Nigel> And those components without maintainers scheduled to be dropped or
 Nigel> deprecated (using BROKEN, DEPRECATED, NEEDS_MAINTAINER or however the
 Nigel> finer detail may advise) after X number of releases if no maintainer
 Nigel> steps up, this would help with some of the more severe bitrot in
 Nigel> portions of buildroot.

Exactly.

 Nigel> The other thing is possibly a mirror for buildroot releases so
 Nigel> people at least know those packages at those versions will
 Nigel> always be available, or at least available 6 months or so down
 Nigel> the line?

Yes, I already got a server/bandwidth offer for it off list.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Markus Heidelberg]

Nigel Kukard, 06.01.2009:
> > I offer to do something about both: Take over maintainership and get
> > atual stable releases out the door (if Erik and the other developers
> > agree).
> >   
> Personally I like how you handle the project and try steer it with the
> resources available, I would like to see you being the project maintainer.

I agree in opinion and I think he is currently the only person suited
for this job. He has very constant presence, fixes many issues and
creates sensible commits.

Markus

[Buildroot] Buildroot maintainer and stable releases

[Thiago A. Corrêa]

Hi,

On Mon, Jan 5, 2009 at 7:18 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>
> I offer to do something about both: Take over maintainership and get
> atual stable releases out the door (if Erik and the other developers
> agree).

I for one welcome our new maintainer overlord.
Seriously, for what it's worth, you have my support.

> What is the plan? Getting the first release out is always the hardest,
> so I would on purpose aim low for the first release and get it out
> soon (February). The target is to get all architectures to build (and
> run where hw is available for test) using the default toolchain config
> and busybox, anything else is just a bonus.

AVR32 has been recently broken (again). I would much prefer that
changes were reverted (termporarily or not) and have AVR32 in this
"release" rather than deem it BROKEN.

> The big issue with buildroot quality control is the mindblowing number
> of configuration combinations and specialized hardware needed to
> test. I am therefore convinced we need to leverage qemu and
> agressively deprecate legacy versions / packages + actively work with
> upstream to keep the number of patches low. I think our users would
> also be happier with a less ambitious project that wouldn't break left
> and right, instead of the current situation.

Maybe we could get a buildbot going. Then we can let many of the
developers/uses here contribute cpu cycle to build tests.
The problem with qemu is that it will only cover some platforms that
it supports, and unfortunally for me, it doesn't support AVR32 :(

Kind Regards,
    Thiago A. Correa

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

 >> I offer to do something about both: Take over maintainership and get
 >> atual stable releases out the door (if Erik and the other developers
 >> agree).

 Thiago> I for one welcome our new maintainer overlord.
 Thiago> Seriously, for what it's worth, you have my support.

Great, thanks.

 Thiago> AVR32 has been recently broken (again). I would much prefer
 Thiago> that changes were reverted (termporarily or not) and have
 Thiago> AVR32 in this "release" rather than deem it BROKEN.

What changes are those exactly?

 Thiago> Maybe we could get a buildbot going. Then we can let many of the
 Thiago> developers/uses here contribute cpu cycle to build tests.

Yes, I have been pondering that as well. I have a buildbot running at
work for the platforms we're using with good results, but it's a
question about coming up with varying enough configs to get good test
coverage.

 Thiago> The problem with qemu is that it will only cover some
 Thiago> platforms that it supports, and unfortunally for me, it
 Thiago> doesn't support AVR32 :(

Sure, if you have access to suitable hw, then that's better than qemu,
but if not, then qemu is nice for the platforms it support.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thiago A. Corrêa]

Peter,

On Tue, Jan 6, 2009 at 4:33 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>  Thiago> AVR32 has been recently broken (again). I would much prefer
>  Thiago> that changes were reverted (termporarily or not) and have
>  Thiago> AVR32 in this "release" rather than deem it BROKEN.
>
> What changes are those exactly?

I didn't had the time to track it down to a commit yet. But it breaks
pretty early during toolchain compilation, so I guess some svn log in
toolchain should reveal the most likely candidates.
Will see if I can go back a few releases to pin point that.

>  Thiago> Maybe we could get a buildbot going. Then we can let many of the
>  Thiago> developers/uses here contribute cpu cycle to build tests.
>
> Yes, I have been pondering that as well. I have a buildbot running at
> work for the platforms we're using with good results, but it's a
> question about coming up with varying enough configs to get good test
> coverage.
>

Having just toolchain + libc + busybox and kernel build would already
go a long way compared to our current. At least for AVR32 which I
usually build for, most common breaks are in those packages. They are
also the trickiest ones. IMHO fixing a particular package is usually
easy compared to fixing the toolchain build.

Kind Regards,
   Thiago A. Correa

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

tis 2009-01-06 klockan 19:33 +0100 skrev Peter Korsgaard:
> >>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
> 
> Hi,
> 
>  >> I offer to do something about both: Take over maintainership and get
>  >> atual stable releases out the door (if Erik and the other developers
>  >> agree).
> 
>  Thiago> I for one welcome our new maintainer overlord.
>  Thiago> Seriously, for what it's worth, you have my support.
> 
> Great, thanks.
> 
>  Thiago> AVR32 has been recently broken (again). I would much prefer
>  Thiago> that changes were reverted (termporarily or not) and have
>  Thiago> AVR32 in this "release" rather than deem it BROKEN.
> 
> What changes are those exactly?

The DEPRECATION of Binutils 2-17 is one thing.
That is fixed.

uClibc-0.9.29 is broken for everything it tried
AVR32, ARM, PowerPC.

Thiago, pls check which toolchain you are using.
All the old defconfigs will not work, and
you need to use the latest 4.2.2 with uClibc-0.9.30.



>  Thiago> Maybe we could get a buildbot going. Then we can let many of the
>  Thiago> developers/uses here contribute cpu cycle to build tests.
> 
> Yes, I have been pondering that as well. I have a buildbot running at
> work for the platforms we're using with good results, but it's a
> question about coming up with varying enough configs to get good test
> coverage.
> 
>  Thiago> The problem with qemu is that it will only cover some
>  Thiago> platforms that it supports, and unfortunally for me, it
>  Thiago> doesn't support AVR32 :(
> 
> Sure, if you have access to suitable hw, then that's better than qemu,
> but if not, then qemu is nice for the platforms it support.
> 
> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

 >> What changes are those exactly?

 Ulf> The DEPRECATION of Binutils 2-17 is one thing.
 Ulf> That is fixed.

 Ulf> uClibc-0.9.29 is broken for everything it tried
 Ulf> AVR32, ARM, PowerPC.

I'm pretty sure I've recently done a successful uclibc 0.9.29 build
for arm / ppc.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

tis 2009-01-06 klockan 16:22 -0200 skrev Thiago A. Corr?a:
> Hi,
> 
> On Mon, Jan 5, 2009 at 7:18 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >
> > I offer to do something about both: Take over maintainership and get
> > atual stable releases out the door (if Erik and the other developers
> > agree).
> 
> I for one welcome our new maintainer overlord.
> Seriously, for what it's worth, you have my support.
> 
> > What is the plan? Getting the first release out is always the hardest,
> > so I would on purpose aim low for the first release and get it out
> > soon (February). The target is to get all architectures to build (and
> > run where hw is available for test) using the default toolchain config
> > and busybox, anything else is just a bonus.
> 

You have not said anything so far, on how you would like
to support distributions.

If you plan to take the current structure and just 
start to remove/deprecate and label with BROKEN
then I am afraid that this will cause a lot of problems.


We should also replacing svn with git.


> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 Ulf> You have not said anything so far, on how you would like
 Ulf> to support distributions.

Distributions? What kind of distributions?

 Ulf> If you plan to take the current structure and just 
 Ulf> start to remove/deprecate and label with BROKEN
 Ulf> then I am afraid that this will cause a lot of problems.

Why? More that the current situation?

 Ulf> We should also replacing svn with git.

One thing at the time. git infrastructure on uclibc.org has been
discussed in connection with the break in / reinstall. It probably
makes most sense to move buildroot to git when the other uclibc
projects do.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

tis 2009-01-06 klockan 20:16 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
>  Ulf> You have not said anything so far, on how you would like
>  Ulf> to support distributions.
> 
> Distributions? What kind of distributions?

Distributions = release.
> 
>  Ulf> If you plan to take the current structure and just 
>  Ulf> start to remove/deprecate and label with BROKEN
>  Ulf> then I am afraid that this will cause a lot of problems.
> 
> Why? More that the current situation?
> 

As I pointed out, the current structure really only
allows you to have one makefile fragment per package.

You need several for distributions (or releases) to work


You need the "stable" makefile
You need a "testing" makefile and you need
a "development" makefile

There is no support for indicating that a package works for one
architecture and is broken for another.

As I see it, you start with the minimum set of packages
in the stable distribution, and then you start
putting a set of packages in the testing part.

People should be able to test building the combined
stable + testing packages with *all* testing packages enabled.

When someone finds that a certain architecture
can build a set of packages, then this fact
can be commited to trunk by setting the enable for each
working package for that architecture.

We should maybe also have separate untested/broken
status for each package/architecture.
Some packages relies on H/W which never is going
to be present. Thinking of PCI etc,
and it we may want to separate broken (whgich theoretically
is fixable) from something that should *never* be tried.

This will allow anyone else to build the stable +
testing packages by including the file containing
the enables for that architecture/distribution combination.

Approaching the end of the testing period,
we will find some packages permanently broke for everything.
We then prune them from the testing set, 
Other packages will work for some architectures,
and they will have the architecture specific enable
removed, while the (hopefully many) packages
that build OK for everything, should have a global enable
set if the distribution is used.

With a system where you define which versions 
of each package you should use, with the possibility
for the user to override this, you get something
which is workable 

You can also allow people to have several versions
of the same package for different architectures. 

With the current structure you cannot work as a team.

-----
So what happens if we jst add BR2_BROKEN.
If you have one package like AVAHI, 
with might builds for 9 out of 10 architectures.
Are we going to mark this as broken, or are
we going to mark the 10th architecture as broken.

No good answer here.


I think our goal should be to help people to 
secure a working build for the things we choose to
support, but to allow them to improve and fix
problems without making it unneccessary hard to do so.

I do not think that we want to block people from
using other versions than the one supported
in the distribution.
They need to be able to test new things.

IMO, It is also important to allow people to
go back and rebuild a stable distribution
years later, but still be able to upgrade
the odd package.

You need to think carefully about the core architecture of
Buildroot, to ensure that this does not become a burden.



>  Ulf> We should also replacing svn with git.
> 
> One thing at the time. git infrastructure on uclibc.org has been
> discussed in connection with the break in / reinstall. It probably
> makes most sense to move buildroot to git when the other uclibc
> projects do.
> 

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 Ulf> As I pointed out, the current structure really only
 Ulf> allows you to have one makefile fragment per package.

 Ulf> You need several for distributions (or releases) to work

Why? If big distributions like Debian can use the same sources for all
it's archs, why can't we?

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 12:29 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
>  Ulf> As I pointed out, the current structure really only
>  Ulf> allows you to have one makefile fragment per package.
> 
>  Ulf> You need several for distributions (or releases) to work
> 
> Why? If big distributions like Debian can use the same sources for all
> it's archs, why can't we?

We need to differentiate between testing and releases.
I have already made the comment, that I believe 
a distribution should use a single version of the source
(with patches).

I am talking about the process of getting a package
into the stable distribution, and currently there
is no process of doing this.
Either you commit a patch or not.
As you pointed out, we do not have the resources
to do every test for every architecture.

That is why we need to be able to bring up architecture
support in an incremental fashion.

Unless we can commit patches to a development section
without breaking the distribution we cannot work 
as a team.

Your goal of a single source package that will not break
for any supported architecture will thus be met by the 
packages IN the distribution. Packages outside
the distribution are not supported.

It will also allow people to build old distributions.

Anyone wanting to build a system adding package-versions
to their own build of the distribution, cam do so without 
disrupting the build.
That means that when we plan to create a new distribution,
a lot of the work, may already be done.
Allowing a commit, will allow other people to 
test on other architectures as well.

When it is time to look at a new release, then
it is easy to check what has been introduced
since the last distribution, and create 
the version file for the new testing phase.

People can then try to build the test distribution
for different architectures, using the "enable all"
file, and if it builds, then the enable is set for
that architecture.

If it does not build, then it is set to broken
for that architecture.

If the problem can be fixed with a patch, then
a new directory is created with the patch.

The architecture specific distribution file
is set to use that directory, instead of the 
testing directory.

You can periodically during the testing phase 
generate a release candidate enabling all
working packages for a specific architecture.

During next phase, you provide a version file 
allowing you to build all architecures using
directories with the new patches.

Hopefully the patch will not break any architectures,
and then it can be accepted into next release
candidate.

If the patch fixes the problem in some
architectures, but breaks others, then
it becomes an architecture specific patch.
*.patch.$ARCH)

This approach gives us a possibility to work
as a team to bring up the distribution
and will significantly reduce the workload
because you can concentrate on a few architecture
and new patches will not break anything else.



Best Regards

Ulf Samuelsson

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

 Ulf> You need several for distributions (or releases) to work
 >> 
 >> Why? If big distributions like Debian can use the same sources for all
 >> it's archs, why can't we?

 Ulf> We need to differentiate between testing and releases.
 Ulf> I have already made the comment, that I believe 
 Ulf> a distribution should use a single version of the source
 Ulf> (with patches).

 Ulf> I am talking about the process of getting a package
 Ulf> into the stable distribution, and currently there
 Ulf> is no process of doing this.
 Ulf> Either you commit a patch or not.
 Ulf> As you pointed out, we do not have the resources
 Ulf> to do every test for every architecture.

That's what the releases are for. We do development for some time,
then move into a stabilization phase (release candidates) and finally
we do a release. Then the cyclus starts again.

 Ulf> Unless we can commit patches to a development section
 Ulf> without breaking the distribution we cannot work 
 Ulf> as a team.

Why not? It seems to work elsewhere, and obviously seems to have
worked here pretty ok as well.

 Ulf> Your goal of a single source package that will not break
 Ulf> for any supported architecture will thus be met by the 
 Ulf> packages IN the distribution. Packages outside
 Ulf> the distribution are not supported.

packages outside the distribution? What are those?

 Ulf> It will also allow people to build old distributions.

They always can do that, just use an old release.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Wed, Jan 07, 2009 at 01:34:23PM +0100, Ulf Samuelsson wrote:
> 
> We need to differentiate between testing and releases.
> I have already made the comment, that I believe 
> a distribution should use a single version of the source
> (with patches).

That's what tags, branches and releases are for. 
Having separate makefiles sounds messy.

> I am talking about the process of getting a package
> into the stable distribution, and currently there
> is no process of doing this.

You could tag each package in Config.in or something 
with "UNTESTED" "TESTING" or whatever aswell, then change or remove when
we know it works.

(Or just use EXPERIMENTAL as other projects does)

> Your goal of a single source package that will not break
> for any supported architecture will thus be met by the 
> packages IN the distribution. Packages outside
> the distribution are not supported.

This is another story, maybe we should support contrib/*.* like you 
once had with local/ for out-of-tree packages and boards.

> It will also allow people to build old distributions.

That's why we have version control. Just check out an earlier
revision.

> When it is time to look at a new release, then
> it is easy to check what has been introduced
> since the last distribution, and create 
> the version file for the new testing phase.

NEW (and oldconfig)

> If it does not build, then it is set to broken
> for that architecture.

What you are suggesting here is a package-tagging about the status 
of the package per ARCH.

This would suggest a new file per package with metainfo (Which could be used
to make Config.in since we'd rather not duplicate information.)

> If the problem can be fixed with a patch, then
> a new directory is created with the patch.

As long as we keep having only one version of each package we won't need
to do this.



Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 19:02 +0100 skrev Thomas Lundquist:
> On Wed, Jan 07, 2009 at 01:34:23PM +0100, Ulf Samuelsson wrote:
> > 
> > We need to differentiate between testing and releases.
> > I have already made the comment, that I believe 
> > a distribution should use a single version of the source
> > (with patches).
> 
> That's what tags, branches and releases are for. 
> Having separate makefiles sounds messy.

I am not an expert in Source Code Management,
but do you have this capability in Subversion?
I know you have it in git, but using git
is apparently not an option.

I do not see it as too messy to use directories.

Go to the package/<package> directory and create a new
directory, copy the files but not the svn info 
from the old distribution directory X.Y.Z. 
Call the new directory X1.X2.X3.

Add 

"<package>_VERSION=Z1.Y1.Z1"

to a file, and and

?select BR2_PACKAGE_<package>

to another, and your are ready to go.

ONce you ahve added a patch, then it will be easy
for other people to test this by adding 
?
"<package>_VERSION=Z1.Y1.Z1"
?select BR2_PACKAGE_<package>

to their private override files.

For testing you provide a list of overrides.
??If a package build, then you commit
	select BR2_PACKAGE_<package>
to the architecture enable file.

Once the "enable" file for all architectures contain this select
then the package can be considered to be validated,
and can be released.

Then again, my requirement is not that it needs
to be implemented in a certain way, just
that the functionality of beeing able to 
start with a distribution, 
and work on that distibrution + own changes,
and commit those changes for review by others
without breaking the build would be good.

You can review changes by code reading,
and you can build to check that it compiles
but if you want to check that it actually
runs then someone with the right H/W needs
to build and run the code.


> > I am talking about the process of getting a package
> > into the stable distribution, and currently there
> > is no process of doing this.
>
> You could tag each package in Config.in or something 
> with "UNTESTED" "TESTING" or whatever aswell, then change or remove when
> we know it works.
> 
> (Or just use EXPERIMENTAL as other projects does)
> 

If you can accomplish what I want, then I do not
mind using an SCM.

> > Your goal of a single source package that will not break
> > for any supported architecture will thus be met by the 
> > packages IN the distribution. Packages outside
> > the distribution are not supported.
> 
> This is another story, maybe we should support contrib/*.* like you 
> once had with local/ for out-of-tree packages and boards.
> 

That is important as well, but I am rather thinking
distribution X supports package 1,2,3 but not 4.
You wamt tp develop package 4 support for your arch,
and want to submit patches for others to test.

So you commit a new directory.
Anyone can then take the standard distribution
and then replace this with thier own version.

This is how openembedded works, you have a base distribution
which defines what versions to use, but anyone
can override the package version in their local.conf file.

Anyone (with write access) can introduce and test a new package version
without breaking anyone elses build.


> > It will also allow people to build old distributions.
> 
> That's why we have version control. Just check out an earlier
> revision.
> 
> > When it is time to look at a new release, then
> > it is easy to check what has been introduced
> > since the last distribution, and create 
> > the version file for the new testing phase.
> 
> NEW (and oldconfig)
> 
> > If it does not build, then it is set to broken
> > for that architecture.
> 
> What you are suggesting here is a package-tagging about the status 
> of the package per ARCH.

Yes. But in addition, I would like each architecture
to have access to packages from earlier distributions as well.
In order to avoid support nightmares, updates of
packages belonging to previous packages should not be
permitted, when work is starting on a new revision.

Use of old packages together with the current
distribution is not neccessarily a supported
activity.

If an old package breaks because it is incompatible
with other packages this does not allow the old package
to be updated, then it is simply broken for that architecture

> 
> This would suggest a new file per package with metainfo (Which could be used
> to make Config.in since we'd rather not duplicate information.)
> 
> > If the problem can be fixed with a patch, then
> > a new directory is created with the patch.
> 
> As long as we keep having only one version of each package we won't need
> to do this.
> 



> 
> Thomas.
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

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

Hi,

 >> That's what tags, branches and releases are for. 
 >> Having separate makefiles sounds messy.

 Ulf> I am not an expert in Source Code Management,
 Ulf> but do you have this capability in Subversion?
 Ulf> I know you have it in git, but using git
 Ulf> is apparently not an option.

Yes, ofcourse you can do it in svn, and as I said, git is coming.

 Ulf> I do not see it as too messy to use directories.

I do - But more importantly, it would just keep on growing, making it
harder and harder to test everything.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Joe George]

On Wed, Jan 7, 2009 at 12:36 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>
> Yes, ofcourse you can do it in svn, and as I said, git is coming.
>

When is git coming?  It seems it would make sense to change now before
the release.

Thanks,
Joe

[Buildroot] Buildroot maintainer and stable releases

[Peter Korsgaard]

>>>>> "Joe" == Joe George <ccjoegml@gmail.com> writes:

 >> Yes, ofcourse you can do it in svn, and as I said, git is coming.

 Joe> When is git coming?  It seems it would make sense to change now
 Joe> before the release.

Some time after the bugtracker gets installed and the issues with the
mailing list get fixed, so realisticly seen not within the timeframe I
set up for the first release (February)

But it's no big deal to do the release in svn.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot maintainer and stable releases

[Ulf Samuelsson]

ons 2009-01-07 klockan 20:36 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
>  >> That's what tags, branches and releases are for. 
>  >> Having separate makefiles sounds messy.
> 
>  Ulf> I am not an expert in Source Code Management,
>  Ulf> but do you have this capability in Subversion?
>  Ulf> I know you have it in git, but using git
>  Ulf> is apparently not an option.
> 
> Yes, ofcourse you can do it in svn, and as I said, git is coming.
> 
>  Ulf> I do not see it as too messy to use directories.
> 
> I do - But more importantly, it would just keep on growing, making it
> harder and harder to test everything.

That is not my intention.
Let me provide an example:

assume we work with the dbus package.

dbus
	1.1.1
		strace.mk
		Config.in

the file ".distribution" contains
DBUS_VERSION=1.1.1

-------
Ok, so I want to update to dbus-1.1.2
I copy the directory 1.1.1 to 1.1.2-arm and add a patch

?dbus
	1.1.1
		dbus.mk
		Config.in
	1.1.2-arm
		dbus.mk
		Config.in
		dbus-xx.patch


?the file ".distribution-1.0" still contains
DBUS_VERSION=1.1.1
	
but I add 
?DBUS_VERSION=1.1.2-arm
in ".distribution.local"

so now whenever I build, I will use my own version,
and if someone adds a powerpc version with another fix
and we get.

?dbus
	1.1.1
		dbus.mk
		Config.in
	1.1.2-arm
		dbus.mk
		Config.in
		dbus-xx.patch
	?1.1.2-powerpc
		dbus.mk
		Config.in
		?dbus-yy.patch

?When we enter the test phase we create a merged testing directory
dbus
	1.1.1
		dbus.mk
		Config.in
	1.1.2-arm
		dbus.mk
		Config.in
		dbus-xx.patch
	?1.1.2-powerpc
		dbus-modified.mk
		Config.in
		?dbus-yy.patch
	?1.1.2-testing
		dbus-modified.mk
		Config.in
		dbus-xx.patch
		dbus-yy.patch


??DBUS_VERSION=1.1.2-testing
is added to ".distribution-2.0.testing"

Once all the packages selected by the merge of
".distribution-1.0" and ".distribution-2.0-testing"
can be built with the ARM architecture
you can commit the following addition to the 
"distributions/2.0/Config.in.arm"

config	BR2_DISTRIBUTION_2_0_ARM
	...
	select	BR2_PACKAGE_SELECT

You then prune the directory structure to get:

?dbus
	1.1.1
		dbus.mk
		Config.in
	?1.1.2
		dbus-modified.mk
		Config.in
		dbus-xx.patch
		dbus-yy.patch

At that point you also freeze "1.1.1"
No more changes are allowed so there will be 
little and no more support.
This is a VERY important thing, because 
otherwise we end up in the support nightmare
that you rightfully are scared of.

Assume that we do 5 distribution and one
poor package gets a new version every time
so you have 5 version directories

I do not suggest that we use KConfig to
allow the user to select which of the 5
versions he/she  wants to use.
Again that will end up in a support nightmare
since packages mightr depend on that other packages
have a certain version.

The user will only use Kconfig to select
which *package* and not which *version*.

Either the user selects a distribution
and then he will be limited by which
packages are tested for that distribution
and might also be limited by the architecture.

Or he disables the distribution system
and can build anything he wants, but
then this is not a supported activity.
He STILL cannot select the version with Kconfig.

If the move from dbus-1.1.1 would break the powerpc
architecture, you would be able
to have ".distribution-2.0-powerpc"
which defines 

DBUS_VERSION=1.1.1

This file might be created at the release of distribution-2.0
but can be overridden by a new
?
DBUS_VERSION=1.1.2-powerpc

in local files by developers so they can continue
working on the powerpc versions all the time
and do not have to care about release cycles.

Eventually dbus-1.1.2 is working for the powerpc
and ".distribution-3.0" could contain.
?DBUS_VERSION=1.1.2

and ?".distribution-3.0-powerpc" could be empty.

If the distribution does not change package versions
then of course there will be no added directory.

If you want to test if a certain distribution works
for an architecture, you will only have one version
of each package to test.

If you are doing development for a new distribution
you again will only have one package version to test.

Even if we eventually end up with multiple versions
for each and every package, the distribution mechanism
will only support one version per package per 
distribution/architecture.

I do not think that it is a good idea to check
in two or more versions when we create a new distribution
The distribution will allow max one added version per package
but it should be OK to allow an architecture to keep
an old revision of a package, if the new version breaks,
but the old CAN NOT be modified, even for bug fixes.


A developer avoiding or overridign the distribution
mechanism can using override files use each an any
apcakage in whatever version they want,
including test versions, but we need to prune
aggressively after a new release.

We should document the last revision before pruning begins
so that people can retrieve the work on a non-completed
package which did not make it into the new distribution
and create new testing directories preparing for
the next distribution.

I really think this would work
and would be better than just tarballing
the tree and then put it on a webpage.

If we can achieve the same functionality
with a SCM, then I am fine with this.

I am not convinced yet though.
Parts can be done with the SCM, I am sure,
but can you get the flexibility?

Automatically adding/creating the config enables
and the distribition files would be good.

Best Regards
Ulf Samuelsson

[Buildroot] Buildroot maintainer and stable releases

[Thomas Lundquist]

On Wed, Jan 07, 2009 at 08:13:44PM +0100, Ulf Samuelsson wrote:

> > That's what tags, branches and releases are for. 
> > Having separate makefiles sounds messy.
> 
> I am not an expert in Source Code Management,
> but do you have this capability in Subversion?

Of course.

> I know you have it in git, but using git
> is apparently not an option.

Maybe not as cool as git but still tags and branches.

> I do not see it as too messy to use directories.
> 
> Go to the package/<package> directory and create a new
> directory, copy the files but not the svn info 
> from the old distribution directory X.Y.Z. 
> Call the new directory X1.X2.X3.
> 
> Add 
> 
> "<package>_VERSION=Z1.Y1.Z1"
> 
> to a file, and and
> 
> ???select BR2_PACKAGE_<package>
> 
> to another, and your are ready to go.
> 
> ONce you ahve added a patch, then it will be easy
> for other people to test this by adding 
> ???
> "<package>_VERSION=Z1.Y1.Z1"
> ???select BR2_PACKAGE_<package>
> 
> to their private override files.

This will be hell to maintain. Who / when to deprecate older versions 
that does not compile with anything new? Shall it be kept for 
ten years like you seem to suggest?

Bit rot tends to start showing up in less than a year.

> Once the "enable" file for all architectures contain this select
> then the package can be considered to be validated,
> and can be released.

for *that* particular version and patch set. 

> Then again, my requirement is not that it needs
> to be implemented in a certain way, just
> that the functionality of beeing able to 
> start with a distribution, 

That is tags and releases. No need to have more than one version 
of the packages for that.

> You can review changes by code reading,
> and you can build to check that it compiles
> but if you want to check that it actually
> runs then someone with the right H/W needs
> to build and run the code.

Yes.

> That is important as well, but I am rather thinking
> distribution X supports package 1,2,3 but not 4.

distribution or arch?

> You wamt tp develop package 4 support for your arch,
> and want to submit patches for others to test.

Then you add that package (or do you mean version? then you bump it and make 
sure it goes through the test runs) and then add your specific patches 
if it's nessesary.

> This is how openembedded works, you have a base distribution
> which defines what versions to use, but anyone
> can override the package version in their local.conf file.

it can be overridden in the .mk file and then tagged with ignore in 
the SCM so it won't be overwritten by the next update.

> Anyone (with write access) can introduce and test a new package version
> without breaking anyone elses build.

And then we end up with so many versions it'll hurt, alot.

> Yes. But in addition, I would like each architecture
> to have access to packages from earlier distributions as well.

As mentioned; Debian manages without and doing this will complicate
way too much.

> In order to avoid support nightmares, updates of
> packages belonging to previous packages should not be
> permitted, when work is starting on a new revision.

This didn't make sense. Previous versions of a package 
or "distribution"?

> Use of old packages together with the current
> distribution is not neccessarily a supported
> activity.

Whitch is exactly why we don't need this.


Thomas.

[Buildroot] Buildroot maintainer and stable releases

[Steve Calfee]

----- Original Message ----
> From: Peter Korsgaard <jacmet@uclibc.org>
> To: buildroot at uclibc.org; andersen at codepoet.org
> Sent: Monday, January 5, 2009 1:18:01 PM
> 
> I offer to do something about both: Take over maintainership and get
> atual stable releases out the door (if Erik and the other developers
> agree).
> 
> What is the plan? Getting the first release out is always the hardest,
> so I would on purpose aim low for the first release and get it out
> soon (February). The target is to get all architectures to build (and
> run where hw is available for test) using the default toolchain config
> and busybox, anything else is just a bonus. I will put out the first
> release candidate early next week, so from then on please don't add
> anything else than bugfixes until the release it out. I believe in
> time based releases, so any architectures that we cannot fix in time
> will simply be disabled in kconfig (E.G. depend on BROKEN).
> 
> After that I would like us to move to a regular release schedule every
> 3 months with 2 months of development and 1 month of stabilization.
> 
> The big issue with buildroot quality control is the mindblowing number
> of configuration combinations and specialized hardware needed to
> test. I am therefore convinced we need to leverage qemu and
> agressively deprecate legacy versions / packages + actively work with
> upstream to keep the number of patches low. I think our users would
> also be happier with a less ambitious project that wouldn't break left
> and right, instead of the current situation.
> 
> Let me know what you think.
> 

Hi All,

I think this is a great plan.

I am a computer consultant and jump around to many jobs, most on Linux. I used buildroot sometime in 2004 or so, and someone else had already done the heavy lifting and had a released product. I needed to upgrade the kernel to something like 2.6.12 to get better USB support. I was completely blown away by the completeness of the buildroot concept. Everything is built including the compiler! Upgrading the BSP for the client and even adding a few apps/packages was great.

Recently I was talking with another potential client about doing a new product. I thought of trying buildroot again. I first tried to build a system based on some old motorola 823 hardware I had around. I couldn't even get the compiler to build without obscure missing files etc. So then I thought probably no one was using that processor so I decided to try what I thought was a well supported hardware, one of the Atmel at91.. arm systems. I could then build the toolchain, but the busybox/packages in the standard config would not build, so I gave up.

When starting a new embedded system it is very nice to be able to get a minimal system up and running and then add packages and features. Just getting Linux, Busybox and a file system working is an incredible hurdle. Having a release that is known to build and run is incredibly valuable. There are so many build environment gotcha's (ubuntu dash vs bash was one I remember), that knowing something should work really helps in finding the issues and fixing them.

Better docs would help. Even a buildroot newby wiki would help greatly.

So anyway Peter, if you are willing to take this huge effort on, great. Thank you.

Steve