[Buildroot] Huge update

[Buildroot] Huge update

[John Voltz]

Well, the huge update from my Google svn is now merged into buildroot's svn.
As of this moment, they are both identical. I'll keep my Google svn open as
a testing/play ground and only merge the solid changes upstream.

John Voltz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080306/ed26ef5e/attachment.htm 

[Buildroot] Huge update

[Erik Andersen]

On Thu Mar 06, 2008 at 02:16:11PM -0500, John Voltz wrote:
> Well, the huge update from my Google svn is now merged into buildroot's svn.
> As of this moment, they are both identical. I'll keep my Google svn open as
> a testing/play ground and only merge the solid changes upstream.

Excellent, thanks!  I'll have to get the new bits a go.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

[Buildroot] Huge update

[JS]

On Thu, 2008-03-06 at 14:16 -0500, John Voltz wrote:
> Well, the huge update from my Google svn is now merged into
> buildroot's svn. As of this moment, they are both identical. I'll keep
> my Google svn open as a testing/play ground and only merge the solid
> changes upstream.

That was like.. a whole bunch :)

-- 
HiPro Solutions
http://hipro.co.in/

[Buildroot] Huge update

[Ulf Samuelsson]

----- Original Message ----- 
From: "John Voltz" <john.voltz@gmail.com>
To: "Buildroot List" <buildroot@uclibc.org>
Sent: Thursday, March 06, 2008 8:16 PM
Subject: [Buildroot] Huge update


> Well, the huge update from my Google svn is now merged into buildroot's svn.
> As of this moment, they are both identical. I'll keep my Google svn open as
> a testing/play ground and only merge the solid changes upstream.
> 
> John Voltz
>

This must be some kind of a record :-)


Best Regards
Ulf Samuelsson

[Buildroot] Huge update

[Hans-Christian Egtvedt]

On Thu, 2008-03-06 at 14:16 -0500, John Voltz wrote:
> Well, the huge update from my Google svn is now merged into
> buildroot's svn. As of this moment, they are both identical. I'll keep
> my Google svn open as a testing/play ground and only merge the solid
> changes upstream.
> 

You could also make your own branch in buildroot SVN for testing out new
stuff before you commit them as well ;)

Thanks for the major update.

-- 
With kind regards,
Hans-Christian Egtvedt, Applications Engineer

[Buildroot] Huge update

[John Voltz]

ninevoltz> added and removed uclibc patches

Why?
There were some redundant patches from Atmel, they were rolled into a larger
patch.

 ninevoltz> Added:
 ninevoltz>    trunk/buildroot/toolchain
/uClibc/Glibc_vs_uClibc_Differences.txt

Who is this for? Why here?
For convenience. Anyone developing or adding packages for use with uClibc
would probably like to know the differences. In hind sight it should
probably go into docs.

ninevoltz> +     http://avr32linux.org/twiki/pub/Main/XStroke

Is that the official upstream nowadays? Didn't it used to live on
handhelds.org?

It hasn't been touched on handhelds.org in over three years. A new site,
xstroke.org was created and then disappeared. I fear for it's continued
existence anywhere, so there it is.

 ninevoltz>    trunk/buildroot/scripts/
 ninevoltz>    trunk/buildroot/scripts/add_new_package.wizard
 ninevoltz>    trunk/buildroot/scripts/build-ext3-img
 ninevoltz>    trunk/buildroot/scripts/create_ipkgs

Adding something in docs/ about this would be nice.

Will do. The build-ext3-img and create_ipkgs scripts are a bit rough around
the edges. I hope to do more with them soon.

I knew I would probably ruffle some feathers with such a huge addition, but
hopefully we can fix it all up into something good.

John Voltz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080306/34b41ace/attachment.htm 

[Buildroot] Huge update

[Hamish Moffatt]

On Thu, Mar 06, 2008 at 07:04:03PM -0500, John Voltz wrote:
> ninevoltz> added and removed uclibc patches
> 
> Why?
> There were some redundant patches from Atmel, they were rolled into a larger
> patch.

But you renamed the rest of the patches as well... ?

> I knew I would probably ruffle some feathers with such a huge addition, but
> hopefully we can fix it all up into something good.

I think it is good to discuss large changes before committing them. I
have posted diffs here for review recently even though I have commit
access.

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

[Buildroot] Huge update

[John Voltz]

 > --- trunk/buildroot/scripts/build-ext3-img
 (rev 0)
> +++ trunk/buildroot/scripts/build-ext3-img    2008-03-06 17:52:37 UTC (rev
21176)

Why isn't this just a normal target? Or an option to the current ext2
target?

I would like to do that once I find a good way to do it. It will create a
bootable ext3 image with grub that can be run directly with qemu or vmware.
I've been trying to get this to work with minimal success. I don't think
anyone has built a buildroot image for x86 since uClibc 0.9.27 was around,
it doesn't seem to work.

The move to /usr/lib was partly because a few embedded systems have the root
file system stored in a smallish flash device on the main board, sufficient
to boot the kernel, start networking, and get into a shell. The /usr
directory can be mounted with a removable device such as an SD card and hold
more enormous contents. Also, a lot of regular packages expect to find most
of these libraries in /usr/lib, from what I've experienced.

> Added:
>    trunk/buildroot/package/editors/

Why add hierarchy into the package directory?

It's getting a bit crowded in there I think. But this wasn't my work, it was
Arnar Mar Sigurdsson from Valka Ehf.

> fixed jpeg makefile

(Moved from /lib to /usr/lib.)

What does this fix?

I forgot now. Some other package, probably glib or gtk, placed it in it's
package config flags as /usr/lib and then other packages couldn't find it.
Hard coded paths are the bestest.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080306/9568a53c/attachment.htm 

[Buildroot] Huge update

[Hamish Moffatt]

On Thu, Mar 06, 2008 at 08:10:41PM -0500, John Voltz wrote:
>  > --- trunk/buildroot/scripts/build-ext3-img
>  (rev 0)
> > +++ trunk/buildroot/scripts/build-ext3-img    2008-03-06 17:52:37 UTC (rev
> 21176)
> 
> Why isn't this just a normal target? Or an option to the current ext2
> target?
> 
> I would like to do that once I find a good way to do it. It will create a
> bootable ext3 image with grub that can be run directly with qemu or vmware.

Right, I see that it's building a whole hard disk image rather than just
an ext3 file system image.

> The move to /usr/lib was partly because a few embedded systems have the root
> file system stored in a smallish flash device on the main board, sufficient

OK. I'm a bit concerned that we might have some binaries installed in
/bin or /sbin which need those libraries that moved.

Also we don't any targets (image generators) capable of generating
separate root and /usr images afaik. But they can be developed later.


Thanks for all your patches by the way. I don't mean to be a harsh
critic.


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

[Buildroot] Huge update

[Ulf Samuelsson]

Hi John.
Your U-Boot patches unfortunately breaks the AT91 build.
AT91 is not well supported in the main U-Boot trunk.
The U-Boot build in target/device/Atmel/u-boot will therefore download
a prepatched version of u-boot (instead of adding 100s of kB in form
of patches).

Upgrading to mainstream u-boot will therefore ensure that almost
none of the AT91 processors will build.
Also the configuration items for u-boot are irrelevant for mainstream.

I have disabled your u-boot, but the files remain.
Please create a separate u-boot directory outside the Atmel directory and

1) ensure that you do not have any conflicts with the prepatched version
2) AT91 u-boot can selected inside the AT91 target configuration.
3) AVR32 should use the generic u-boot.

once fixed, resubmit.


It will be more complex in the future, since the AT91CAP9
will probably have good u-boot support in the near future,
so ideally the user should have a choice between
building the generic and the prepatched version.

Personally I think that putting the bootloader configuration
inside the root fs build is wrong.
Makes more sense to me to have it in the target.

Don't be dismayed by this, keep the patches coming.

Best Regards
Ulf Samuelsson