[Buildroot] Buildroot maintainer and stable releases
jacmet at uclibc.org
Tue Jan 6 12:44:55 UTC 2009
>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson at atmel.com> writes:
>> 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
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
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.
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
More information about the buildroot