[Buildroot] Hi There

[Buildroot] Hi There

[Michel]

I've been using buildroot via atmel's AVR32 git tree for some time, and I 
started to fix problems. It's been suggested that I push my 'general' patches 
to you guys so they will come back down the feeding chain to us :-)

First a question : is there an official git repositiory somewhere ? I've 
quickly grown to rely on git, and it would make things easier for me...

Alternatively, should I push patch emails directly to this list ? I do try to 
make them as small as possible.

What I have to push right now is :
+ NCURSES: Fixed GNU URL pathname for ncurses
+ SCREEN: Added support for GNU screen
+ NCURSES: ncurses install procedure now also copies the 'extra' libraries 
like libpanel.so into the target. This allows tools like 'iptraf' to work
+ IPTRAF: Added support for 'iptraf' curses based traffic monitor
+ U-BOOT: A patch to fix the fw_printenv compilation
+ U-BOOT: Added support for linux userland environmnet access
+ U-BOOT: Documented that the fw_setenv will only work if the MTD partition is 
R/W

Please advise.
Michel

[Buildroot] Hi There

[Peter Korsgaard]

>>>>> "Michel" == Michel (BusError) <buildroot.atmel.com@pollet.net> writes:

 Michel> I've been using buildroot via atmel's AVR32 git tree for some
 Michel> time, and I started to fix problems. It's been suggested that
 Michel> I push my 'general' patches to you guys so they will come
 Michel> back down the feeding chain to us :-)

Sounds good!

 Michel> First a question : is there an official git repositiory
 Michel> somewhere ? I've quickly grown to rely on git, and it would
 Michel> make things easier for me...

Well, you can always use git-svn like I do.

 Michel> Alternatively, should I push patch emails directly to this
 Michel> list ? I do try to make them as small as possible.

Yes please, that's the easiest for review.

 Michel> What I have to push right now is :
 Michel> + NCURSES: Fixed GNU URL pathname for ncurses

Hmm, from a quick look the URL seems correct - Are you uptodate with
trunk?

 Michel> + SCREEN: Added support for GNU screen
 Michel> + NCURSES: ncurses install procedure now also copies the
 Michel> + 'extra' libraries like libpanel.so into the target. This
 Michel> + allows tools like 'iptraf' to work

Ok, how big is libpanel? Does it make sense to make a specific CONFIG_
setting for that?

 Michel> + IPTRAF: Added support for 'iptraf' curses based traffic monitor
 Michel> + U-BOOT: A patch to fix the fw_printenv compilation
 Michel> + U-BOOT: Added support for linux userland environmnet access
 Michel> + U-BOOT: Documented that the fw_setenv will only work if the
 Michel> + MTD partition is R/W

Sounds good, looking forward to seeing the patches.

-- 
Bye, Peter Korsgaard

[Buildroot] Hi There

[Michel]

On Tuesday 08 April 2008, Peter Korsgaard wrote:
> >>>>> "Michel" == Michel (BusError) <buildroot.atmel.com@pollet.net>
> >>>>> writes:
>  Michel> First a question : is there an official git repositiory
>  Michel> somewhere ? I've quickly grown to rely on git, and it would
>  Michel> make things easier for me...
>
> Well, you can always use git-svn like I do.

Good point I'll investigate the git-svn bridge.. It seemd to be getting 
popular...
 
>  Michel> Alternatively, should I push patch emails directly to this
>  Michel> list ? I do try to make them as small as possible.
>
> Yes please, that's the easiest for review.

Ok I'll use git-send-email then :-)

>  Michel> What I have to push right now is :
>  Michel> + NCURSES: Fixed GNU URL pathname for ncurses
>
> Hmm, from a quick look the URL seems correct - Are you uptodate with
> trunk?
It seems that it was fixed in my latest merge this afternoon, so this one no 
longer applies :-)

>  Michel> + SCREEN: Added support for GNU screen
>  Michel> + NCURSES: ncurses install procedure now also copies the
>  Michel> + 'extra' libraries like libpanel.so into the target. This
>  Michel> + allows tools like 'iptraf' to work
>
> Ok, how big is libpanel? Does it make sense to make a specific CONFIG_
> setting for that?

Good point about the size; it's a tiny lib (5KB on avr32)  but I reworked the 
patch to allow to add them selectively via the config file...

>
>  Michel> + IPTRAF: Added support for 'iptraf' curses based traffic monitor
>  Michel> + U-BOOT: A patch to fix the fw_printenv compilation
>  Michel> + U-BOOT: Added support for linux userland environmnet access
>  Michel> + U-BOOT: Documented that the fw_setenv will only work if the
>  Michel> + MTD partition is R/W
>
> Sounds good, looking forward to seeing the patches.

Thanks, I'll post that a bit later..

Michel

[Buildroot] Hi There

[Ulf Samuelsson]

>>>>>> "Michel" == Michel (BusError) <buildroot.atmel.com@pollet.net> writes:
> 
> Michel> I've been using buildroot via atmel's AVR32 git tree for some
> Michel> time, and I started to fix problems. It's been suggested that
> Michel> I push my 'general' patches to you guys so they will come
> Michel> back down the feeding chain to us :-)
> 
> Sounds good!
> 
> Michel> First a question : is there an official git repositiory
> Michel> somewhere ? I've quickly grown to rely on git, and it would
> Michel> make things easier for me...
> 
> Well, you can always use git-svn like I do.
> 
> Michel> Alternatively, should I push patch emails directly to this
> Michel> list ? I do try to make them as small as possible.
> 
> Yes please, that's the easiest for review.
> 


The structured alternative is to report into the bug-tracking system
at buildroot.uclibc.org.

This makes sure that the patch is available for anyone even
if they joined the list after you sent the mail.

Personally, I let you decided what you prefer.


On the U-Boot patch, pls try to push the patch at the u-boot mailing list.
After spending years in Limbo, the patching process of U-Boot is
progressing at a a rapid pace and if the patch is OK, you
should get it into U-boot in notime..



Best Regards
Ulf Samuelsson

[Buildroot] Hi There

[Peter Korsgaard]

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

 Ulf> On the U-Boot patch, pls try to push the patch at the u-boot mailing list.
 Ulf> After spending years in Limbo, the patching process of U-Boot is
 Ulf> progressing at a a rapid pace and if the patch is OK, you
 Ulf> should get it into U-boot in notime..

Talking about u-boot, what's the status of the avr32 patch? Can we
bump the u-boot version to 1.3.2?

-- 
Bye, Peter Korsgaard

[Buildroot] Hi There

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Ulf> On the U-Boot patch, pls try to push the patch at the u-boot mailing list.
> Ulf> After spending years in Limbo, the patching process of U-Boot is
> Ulf> progressing at a a rapid pace and if the patch is OK, you
> Ulf> should get it into U-boot in notime..
> 
> Talking about u-boot, what's the status of the avr32 patch? Can we
> bump the u-boot version to 1.3.2?
> 


The AVR32 has been fully integrated into U-Boot for quite some time
and I think there should be no reason to give any special consideration
when bumping versions.

It might be good to allow for several versions of U-Boot though,
if some release do break a board or architecture.

The reason for providing prepatched U-boot in the Atmel directory is the AT91.
The AT91 team failed to get even a reply when they submitted  patches, 
so they basically gave up.

Now, the U-Boot project has changed strategy and there is a significant number 
of "Custodians" and the AT91 team has been working with third parties which
are subitting patches to the Custodians on almost daily basis.

I hope the situation will stabilize and that the AT91 stuff can be merged in 
mainstream buildroot during the summer.


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

[Buildroot] Hi There

[Peter Korsgaard]

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

Hi,

 >> Talking about u-boot, what's the status of the avr32 patch? Can we
 >> bump the u-boot version to 1.3.2?

 Ulf> The AVR32 has been fully integrated into U-Boot for quite some time
 Ulf> and I think there should be no reason to give any special consideration
 Ulf> when bumping versions.

So we can get rid of
target/u-boot/u-boot-1.3.0-avr32-100-atmel.2.patch ? Great!

 Ulf> It might be good to allow for several versions of U-Boot though,
 Ulf> if some release do break a board or architecture.

Sure, to a certain limit.

 Ulf> I hope the situation will stabilize and that the AT91 stuff can
 Ulf> be merged in mainstream buildroot during the summer.

Good to hear.

-- 
Bye, Peter Korsgaard

[Buildroot] Hi There

[Hans-Christian Egtvedt]

On Wed, 2008-04-09 at 08:49 +0200, Peter Korsgaard wrote:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>  >> Talking about u-boot, what's the status of the avr32 patch? Can we
>  >> bump the u-boot version to 1.3.2?
> 
>  Ulf> The AVR32 has been fully integrated into U-Boot for quite some time
>  Ulf> and I think there should be no reason to give any special consideration
>  Ulf> when bumping versions.
> 
> So we can get rid of
> target/u-boot/u-boot-1.3.0-avr32-100-atmel.2.patch ? Great!
> 

Yes, upstream version 1.3.2 got all those changes and a couple of other
fixes as well.

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

[Buildroot] Hi There

[Peter Korsgaard]

>>>>> "Hans-Christian" == Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> writes:

Hi,

 Hans-Christian> Yes, upstream version 1.3.2 got all those changes and
 Hans-Christian> a couple of other fixes as well.

Great - Thanks!

-- 
Bye, Peter Korsgaard

[Buildroot] Hi There

[Michel]

On Tuesday 08 April 2008, Ulf Samuelsson wrote:
>
> On the U-Boot patch, pls try to push the patch at the u-boot mailing list.
> After spending years in Limbo, the patching process of U-Boot is
> progressing at a a rapid pace and if the patch is OK, you
> should get it into U-boot in notime..

Well for me this stuff is a mean to an end : getting a distribution for my 
project. I don't necessarily want to subscribe to a 'developer' mailing list 
everytime I have a oneliner on projects where /i'm not a developer/ -- I'm 
not really a developer even on buildroot, just trying to do something with 
it :-)

So I'm trying to do the 'right thing' by pushing patches up, but I can't 
possibly follow thru all the ramifications. If these patches posted here are 
to be up in limbo with a "wrong address" tag, please tell me and I can keep 
them in my git tree, and forget about them.

My assumption was that there was a system of 'layers' like with the kernel, 
were separate branches had 'sergeants' and were collating and pushing 
relevant patchsets to top maintainers. It seems this is not the case.

Cheers,
Michel