[Buildroot] [GIT PULL] For 2009.05-rc2

[Buildroot] [GIT PULL] For 2009.05-rc2

[Thiago A. Corrêa]

Peter,

The following changes since commit b124f62e23c3dc35ed0a74e68c2c596b30ea3d7c:
  Peter Korsgaard (1):
        Merge branch 'master' of
git://git.buildroot.net/~correa/git/buildroot into test

are available in the git repository at:

  git://git.buildroot.net/~correa/git/buildroot 2009.05

Olaf Rempel (1):
      rsync: fix build with config cache

Thiago A. Correa (11):
      Update atngw100-extended_defconfig
      Fix avahi build
      Update atngw100-base_defconfig
      CUPS requires stack protection support
      Update i686_defconfig
      Remove unused busybox.config
      Update i386_defconfig
      Update default linux config for x86
      Remove unused busybox config
      Update kernel config for atngw100_defconfig
      Remove unused kernel configs

 package/avahi/avahi.mk                             |    1 +
 package/cups/Config.in                             |    4 +
 package/rsync/rsync.mk                             |    1 +
 .../Atmel/atngw100-base/atngw100-base_defconfig    |  550 ++++--
 .../atngw100-expanded/atngw100-expanded_defconfig  |  634 ++----
 .../Atmel/atngw100/atngw100-linux-2.6.22.10.config | 1170 -----------
 ....6.24.config => atngw100-linux-2.6.29.2.config} |  495 ++++--
 target/device/Atmel/atngw100/atngw100_defconfig    |   19 +-
 target/device/Atmel/atngw100/busybox-1.9.1.config  |  767 -------
 target/device/x86/i686/busybox.config              |  719 -------
 target/device/x86/i686/i386_defconfig              |  139 +-
 target/device/x86/i686/i686_defconfig              |   42 +-
 target/device/x86/i686/linux-2.6.29.2.config       | 2157 ++++++++++++++++++++
 13 files changed, 3218 insertions(+), 3480 deletions(-)
 delete mode 100644 target/device/Atmel/atngw100/atngw100-linux-2.6.22.10.config
 rename target/device/Atmel/atngw100/{atngw100-linux-2.6.24.config =>
atngw100-linux-2.6.29.2.config} (77%)
 delete mode 100644 target/device/Atmel/atngw100/busybox-1.9.1.config
 delete mode 100644 target/device/x86/i686/busybox.config
 create mode 100644 target/device/x86/i686/linux-2.6.29.2.config

Kind Regards,
    Thiago A. Correa

[Buildroot] [GIT PULL] For 2009.05-rc2

[Peter Korsgaard]

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

 Thiago> Peter,
 Thiago> The following changes since commit b124f62e23c3dc35ed0a74e68c2c596b30ea3d7c:
 Thiago>   Peter Korsgaard (1):
 Thiago>         Merge branch 'master' of
 Thiago> git://git.buildroot.net/~correa/git/buildroot into test

 Thiago> are available in the git repository at:

 Thiago>   git://git.buildroot.net/~correa/git/buildroot 2009.05

Could you also please send (your own atleast) patches to the mailing
list for easy review?

Use something like:

git format-patch master
git send-email --to buildroot at uclibc.org 00*.patch

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] For 2009.05-rc2

[Thiago A. Corrêa]

Hi Peter,

On Wed, May 13, 2009 at 5:20 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
> Could you also please send (your own atleast) patches to the mailing
> list for easy review?
>
> Use something like:
>
> git format-patch master
> git send-email --to buildroot at uclibc.org 00*.patch
>

Is there some way that we could stream line this? So far this git move
have done nothing than double or triple the amount of work I need to
do to submit.
After that I still need to do the work that will actually bring the
food on the table.

First one has to figure out git, then he has to setup sendmail or
ssmtp or procmail, whatever. Personally I don't really like to leave
my password in plain text in any /etc/*.conf

I think we should find a model that is easy and works for us, not for
the linux kernel with countless people, lots of mailling lists and
several subsystems with maintainers for each.

Thanks,
    Thiago A. Correa

[Buildroot] [GIT PULL] For 2009.05-rc2

[Thiago A. Corrêa]

By the way, one or more of my patches got stuck in the mailling list
and is waiting approval because of it's size. I guess it further
illustrates that perhaps we should work differently.

2009/5/13 Thiago A. Corr?a <thiago.correa@gmail.com>:
> Hi Peter,
>
> On Wed, May 13, 2009 at 5:20 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>> Could you also please send (your own atleast) patches to the mailing
>> list for easy review?
>>
>> Use something like:
>>
>> git format-patch master
>> git send-email --to buildroot at uclibc.org 00*.patch
>>
>
> Is there some way that we could stream line this? So far this git move
> have done nothing than double or triple the amount of work I need to
> do to submit.
> After that I still need to do the work that will actually bring the
> food on the table.
>
> First one has to figure out git, then he has to setup sendmail or
> ssmtp or procmail, whatever. Personally I don't really like to leave
> my password in plain text in any /etc/*.conf
>
> I think we should find a model that is easy and works for us, not for
> the linux kernel with countless people, lots of mailling lists and
> several subsystems with maintainers for each.
>
> Thanks,
> ? ?Thiago A. Correa
>

[Buildroot] [GIT PULL] For 2009.05-rc2

[Peter Korsgaard]

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

Hi,

 Thiago> By the way, one or more of my patches got stuck in the
 Thiago> mailling list and is waiting approval because of it's size. I
 Thiago> guess it further illustrates that perhaps we should work
 Thiago> differently.

Yes, we have a max limit of 40kb on the list. I have approved your
mail and bumped the limit to 100kb.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] For 2009.05-rc2

[Thiago A. Corrêa]

Hi Peter,

   Could you please cherypick the commits, from the tree or from the
patches and commit what you feel is important?
   Please make sure to get the rsync one, that's important, and I've
tested it, it's clean and I can assure the problem is there and the
fix resolves it.

   I am too frustrated with not being able to send changes as before.
I will just refrain for a while from sending anything, at least until
past the next release. I will have travel next week to see clients
anyway, so I don't think I will have the time to follow up anyway. I'm
not giving up on buildroot just yet.

Thanks,
    Thiago A. Correa

On Thu, May 14, 2009 at 4:59 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>
> Hi,
>
> ?Thiago> By the way, one or more of my patches got stuck in the
> ?Thiago> mailling list and is waiting approval because of it's size. I
> ?Thiago> guess it further illustrates that perhaps we should work
> ?Thiago> differently.
>
> Yes, we have a max limit of 40kb on the list. I have approved your
> mail and bumped the limit to 100kb.
>
> --
> Bye, Peter Korsgaard
>

[Buildroot] [GIT PULL] For 2009.05-rc2

[Peter Korsgaard]

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

Hi,

 Thiago> Is there some way that we could stream line this? So far this
 Thiago> git move have done nothing than double or triple the amount
 Thiago> of work I need to do to submit.  After that I still need to
 Thiago> do the work that will actually bring the food on the table.

Well, it's a matter of viewpoint ofcourse - But to me it has made it
easier to work with. The extra review before commits are imho a good
thing.

You could enable the post-receive hook on your repo to get it to
automatically send patches to the list when you push changes to it
(see .git/hooks/post-receive.sample).

 Thiago> First one has to figure out git, then he has to setup
 Thiago> sendmail or ssmtp or procmail, whatever. Personally I don't
 Thiago> really like to leave my password in plain text in any
 Thiago> /etc/*.conf

True, all tools require some setup. I would expect most developer
machines to be able to send mail and/or have git installed already
though as lots of projects use it.

 Thiago> I think we should find a model that is easy and works for us,
 Thiago> not for the linux kernel with countless people, lots of
 Thiago> mailling lists and several subsystems with maintainers for
 Thiago> each.

What exactly isn't working for you? I can understand that it takes a
bit of time to learn git if you haven't used it before, but other than
that?

-- 
Bye, Peter Korsgaard