[Buildroot] [GIT PULL] avr32 updates

[Buildroot] [GIT PULL] avr32 updates

[Thiago A. Corrêa]

Hi Peter,

    I'm newbie with this git thing, so please bear with me...

    Please pull git clone git://git.buildroot.net/~correa/git/buildroot.git for:

 * Update Linux Advanced to 2.6.29.2 - this fixes iptables compile
 * Add dl folder to gitignore
 * Update atngw100_defconfig

Kind Regards,
   Thiago A. Correa

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

 Thiago> Hi Peter,
 Thiago>     I'm newbie with this git thing, so please bear with me...

 Thiago>     Please pull git clone git://git.buildroot.net/~correa/git/buildroot.git for:

 Thiago>  * Update Linux Advanced to 2.6.29.2 - this fixes iptables compile
 Thiago>  * Add dl folder to gitignore
 Thiago>  * Update atngw100_defconfig

I had a quick look, and it basically looks good, but there's a few
things I would like you to fix:

- Please sign off on your fixes (git commit -s)
- Don't commit unrelated things together (Linux advanced together with
  atngw100 defconfig)
- What do you mean with 'this fixes iptables compile'? What does the
  kernel has to do with iptables compilation?

You are welcome to put the fixes for 2009.05 in a seperate branch
(upstream, stable or whatever) if that's easier for you to keep it
seperate for new feature development while we're stabilizing for the
release. I might create a 'next' branch for new stuff.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Thiago A. Corrêa]

Hi,

On Fri, May 8, 2009 at 4:13 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>
> ?Thiago> Hi Peter,
> ?Thiago> ? ? I'm newbie with this git thing, so please bear with me...
>
> ?Thiago> ? ? Please pull git clone git://git.buildroot.net/~correa/git/buildroot.git for:
>
> ?Thiago> ?* Update Linux Advanced to 2.6.29.2 - this fixes iptables compile
> ?Thiago> ?* Add dl folder to gitignore
> ?Thiago> ?* Update atngw100_defconfig
>
> I had a quick look, and it basically looks good, but there's a few
> things I would like you to fix:
>
> - Please sign off on your fixes (git commit -s)

Can this be done easily after it has been commited? Since I had setup
my name and address, I had hopes that it would do it automagically.

> - Don't commit unrelated things together (Linux advanced together with
> ?atngw100 defconfig)

Ok.

> - What do you mean with 'this fixes iptables compile'? What does the
> ?kernel has to do with iptables compilation?

Something is wrong in the kernel headers in previous versions.
Something in byteorder.h prevended it from building earlier.

> You are welcome to put the fixes for 2009.05 in a seperate branch
> (upstream, stable or whatever) if that's easier for you to keep it
> seperate for new feature development while we're stabilizing for the
> release. I might create a 'next' branch for new stuff.
>

I thought of using master for current and 2009.07 for next. But I
could use a suggestion anyway.

About the .gitignore, I didn't base it from a patch, I actually added
it myself because git was always complaining about it and I had to do
git commit -m "" -a
But feel free to apply a previous patch that does the same. I still
haven't figured out how to do git am stuff :D

Btw, how does one get those nice summaries like this ?
http://lkml.org/lkml/2009/4/4/40


Kind Regards,
   Thiago A. Correa

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

 >> - Please sign off on your fixes (git commit -s)

 Thiago> Can this be done easily after it has been commited? Since I had setup
 Thiago> my name and address, I had hopes that it would do it automagically.

You can rebase your commits and edit the descriptions - Something
like:

git rebase -i master (or the git rev you started from if you did it in
the same branch)
change all the lines to edit
run git commit -s --amend; git rebase --continue until you're done.

Normally you shouldn't rebase something that you have pushed, but OK
..

 >> - What do you mean with 'this fixes iptables compile'? What does the
 >> ?kernel has to do with iptables compilation?

 Thiago> Something is wrong in the kernel headers in previous versions.
 Thiago> Something in byteorder.h prevended it from building earlier.

But the Linux.advanced stuff doesn't have anything to do with kernel
headers, right?

 >> You are welcome to put the fixes for 2009.05 in a seperate branch
 >> (upstream, stable or whatever) if that's easier for you to keep it
 >> seperate for new feature development while we're stabilizing for the
 >> release. I might create a 'next' branch for new stuff.
 >> 

 Thiago> I thought of using master for current and 2009.07 for next. But I
 Thiago> could use a suggestion anyway.

I would think it would be easier to leave master alone so you easily
pull new changes in the main repo and rebase your commits on it.

 Thiago> About the .gitignore, I didn't base it from a patch, I actually added
 Thiago> it myself because git was always complaining about it and I had to do
 Thiago> git commit -m "" -a
 Thiago> But feel free to apply a previous patch that does the same. I still
 Thiago> haven't figured out how to do git am stuff :D

Ok. git am is easy - Simply save the mail and run git am -s <file>

 Thiago> Btw, how does one get those nice summaries like this ?
 Thiago> http://lkml.org/lkml/2009/4/4/40

with git shortlog. E.G. to see the log since the previous release you
would do:

git shortlog 2009.02...

For sending a git pull request you can use git request-pull, E.G. if
you do your work in a 'upstream' branch you could do:

git request-pull master git://git.buildroot.net/~correa/git/buildroot.git

Which would spit out something like (well, different - but same format):

The following changes since commit cf92bc23e9708881c7e982d20eeeb236c6427dfb:
  Peter Korsgaard (1):
        Update for 2009.05-rc1, add CHANGES

are available in the git repository at:

  git://git.buildroot.net/buildroot master

Peter Korsgaard (5):
      news: announce 2009.05-rc1
      download.html: fix browse source URL
      metacity: bump version and convert to Makefile.autotools.in format
      dmraid: broken with parallel make (lib + tools race)
      clarify license and fix website license link

 CHANGES                              |    6 +
 COPYING                              |  339 ++++++++++++++++++++++++++++++++++
 docs/about.html                      |    3 +-
 docs/download.html                   |    2 +-
 docs/news.html                       |   13 ++
 package/dmraid/dmraid.mk             |    2 +
 package/metacity/metacity-nopo.patch |   24 ++-
 package/metacity/metacity.mk         |  156 ++--------------
 8 files changed, 394 insertions(+), 151 deletions(-)
 create mode 100644 COPYING

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Thiago A. Corrêa]

Hi,

On Fri, May 8, 2009 at 5:29 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>
> ?>> - Please sign off on your fixes (git commit -s)
>
> ?Thiago> Can this be done easily after it has been commited? Since I had setup
> ?Thiago> my name and address, I had hopes that it would do it automagically.
>
> You can rebase your commits and edit the descriptions - Something
> like:
>

Ok, after an hour of wrestling with git and it's man pages, I think I
got it right :)
I was even able to split the kernel update commit.

> ?>> - What do you mean with 'this fixes iptables compile'? What does the
> ?>> ?kernel has to do with iptables compilation?
>
> ?Thiago> Something is wrong in the kernel headers in previous versions.
> ?Thiago> Something in byteorder.h prevended it from building earlier.
>
> But the Linux.advanced stuff doesn't have anything to do with kernel
> headers, right?

Unfortunally, it doesn't look like it. Even if I select 2.6.29 for the
linux headers (toolchain), the build fails. Unless I actually update
the kernel on the target, it fails to build for avr32. According to
the avr32-linux mailling list, there was a byteorder.h restructuring a
while back, so I guess some versions of the headers are not what
iptables expects.

> ?Thiago> I thought of using master for current and 2009.07 for next. But I
> ?Thiago> could use a suggestion anyway.
>
> I would think it would be easier to leave master alone so you easily
> pull new changes in the main repo and rebase your commits on it.

Yeah, after all this rebase thing I see your point. I guess I will do
that once those changes are merged.

> ?Thiago> But feel free to apply a previous patch that does the same. I still
> ?Thiago> haven't figured out how to do git am stuff :D
>
> Ok. git am is easy - Simply save the mail and run git am -s <file>
>

A bit easier said than done *smile*.
I do all of my buildroot development over ssh. Anyway, what happens if
I apply a patch and then you apply it a while later before pulling
from my tree? I guess we will conflict right?

my git pull-request: (thanks for the tip)

The following changes since commit 30b9a6ae5b1d770d9b8eae9e9bafc316a4923762:
  Peter Korsgaard (1):
        dmraid: broken with parallel make (lib + tools race)

are available in the git repository at:

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

Thiago A. Correa (4):
      Update atngw100_defconfig
      Add dl folder to gitignore
      Update Linux Advanced to 2.6.29.2
      Update atngw100_defconfig to kernel 2.6.29.2

 .gitignore                                      |    1 +
 target/device/Atmel/atngw100/atngw100_defconfig |   38 +++++++++-------------
 target/linux/Config.in.advanced                 |   17 +++++-----
 target/linux/Config.in.versions                 |   10 ++++--
 4 files changed, 33 insertions(+), 33 deletions(-)

Kind Regards,
   Thiago A. Correa

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

Hi,

 Thiago> Ok, after an hour of wrestling with git and it's man pages, I
 Thiago> think I got it right :) I was even able to split the kernel
 Thiago> update commit.

Heh, was git rebase -i that bad?

 >> ?Thiago> Something is wrong in the kernel headers in previous versions.
 >> ?Thiago> Something in byteorder.h prevended it from building earlier.
 >> 
 >> But the Linux.advanced stuff doesn't have anything to do with kernel
 >> headers, right?

 Thiago> Unfortunally, it doesn't look like it. Even if I select
 Thiago> 2.6.29 for the linux headers (toolchain), the build
 Thiago> fails. Unless I actually update the kernel on the target, it
 Thiago> fails to build for avr32. According to the avr32-linux
 Thiago> mailling list, there was a byteorder.h restructuring a while
 Thiago> back, so I guess some versions of the headers are not what
 Thiago> iptables expects.

I still don't get it - I've never used the Linux.advanced stuff, but
it's just used to build a kernel for the target and doesn't have
anything to do with the rootfs, right? How can it then influence the
iptables build?

 >> Ok. git am is easy - Simply save the mail and run git am -s <file>

 Thiago> A bit easier said than done *smile*.

 Thiago> I do all of my buildroot development over ssh.

And? Do you mean that your desktop machine is running Windows?

 Thiago> Anyway, what happens if I apply a patch and then you apply it
 Thiago> a while later before pulling from my tree? I guess we will
 Thiago> conflict right?

No, if none of us modify the patch then the git sha1 id will be the
same and the commit just ignored (if one of us modifies it you will
most likely get a merge conflict that you'll have to resolve when you
rebase your changes against me).

 Thiago> my git pull-request: (thanks for the tip)

pulled and pushed.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

 Thiago> my git pull-request: (thanks for the tip)

 Peter> pulled and pushed.

Sorry, pulled but not pushed yet as Mike's pre-receive git hook is a
bit too restrictive:

Refusing to update refs/heads/master:
Missing committer's Signed-off-by tag

When I pull from other developers and push their changes then git
doesn't add my s-o-b (and afaik shouldn't).

I've sent a mail to Mike to get it fixed.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

 Peter> When I pull from other developers and push their changes then git
 Peter> doesn't add my s-o-b (and afaik shouldn't).

To be more clear - When git creates a merge commit, then it doesn't
add my s-o-b, which causes the pre-receive hook to fail. I can fix
that by rebasing your changes, but then I become the committer (which
is wrong) and as the commits don't have my s-o-b's on them the
pre-receive hook fails.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Thiago A. Corrêa]

On Fri, May 8, 2009 at 6:48 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
> ?Thiago> Ok, after an hour of wrestling with git and it's man pages, I
> ?Thiago> think I got it right :) I was even able to split the kernel
> ?Thiago> update commit.
>
> Heh, was git rebase -i that bad?

Just adding the signoff was easy... commit --amend -s did the trick,
the problem was me trying to split the other commit. I somehow managed
to completely trash my local tree and had to clone it again from the
remote. I really miss svn revert... If I remove some file from the
local tree, I can't bring it back with git fetch, git checkout or git
reset.

> ?>> ?Thiago> Something is wrong in the kernel headers in previous versions.
> ?>> ?Thiago> Something in byteorder.h prevended it from building earlier.
> ?>>
> ?>> But the Linux.advanced stuff doesn't have anything to do with kernel
> ?>> headers, right?
>
> ?Thiago> Unfortunally, it doesn't look like it. Even if I select
> ?Thiago> 2.6.29 for the linux headers (toolchain), the build
> ?Thiago> fails. Unless I actually update the kernel on the target, it
> ?Thiago> fails to build for avr32. According to the avr32-linux
> ?Thiago> mailling list, there was a byteorder.h restructuring a while
> ?Thiago> back, so I guess some versions of the headers are not what
> ?Thiago> iptables expects.
>
> I still don't get it - I've never used the Linux.advanced stuff, but
> it's just used to build a kernel for the target and doesn't have
> anything to do with the rootfs, right? How can it then influence the
> iptables build?

Perhaps it's how it touches all the LINUX26* variables. I have no idea
either. I just tried to update and it worked. I might just be loosing
my mind and tested it wrong, could have forgot to run a toolchain with
2.6.29 and kernel 2.6.28 test and thought that I had. I've been awake
for 36 hours already and still have to study for German test tomorrow
(as second foreign language).

I will leave this building with toolchain kernel headers 2.26.9 and
advanced linux 2.26.7 and see if iptables fails to compile again.

> ?>> Ok. git am is easy - Simply save the mail and run git am -s <file>
>
> ?Thiago> A bit easier said than done *smile*.
> ?Thiago> I do all of my buildroot development over ssh.
>
> And? Do you mean that your desktop machine is running Windows?

Yes, my gentoo build environment runs inside vmware in a quad core.

> ?Thiago> Anyway, what happens if I apply a patch and then you apply it
> ?Thiago> a while later before pulling from my tree? I guess we will
> ?Thiago> conflict right?
>
> No, if none of us modify the patch then the git sha1 id will be the
> same and the commit just ignored (if one of us modifies it you will
> most likely get a merge conflict that you'll have to resolve when you
> rebase your changes against me).

Nice. Then I don't need to skip all patches :)

> ?Thiago> my git pull-request: (thanks for the tip)
>
> pulled and pushed.
>

Thanks.

[Buildroot] [GIT PULL] avr32 updates

[Daniel Mack]

On Fri, May 08, 2009 at 07:56:25AM -0300, Thiago A. Corr?a wrote:
> On Fri, May 8, 2009 at 6:48 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
> > ?Thiago> Ok, after an hour of wrestling with git and it's man pages, I
> > ?Thiago> think I got it right :) I was even able to split the kernel
> > ?Thiago> update commit.
> >
> > Heh, was git rebase -i that bad?
> 
> Just adding the signoff was easy... commit --amend -s did the trick,
> the problem was me trying to split the other commit. 

That's exactly what git rebase -i is for. Mark the commit you like to
split as 'edit' (instead of 'pick') and quit the editor. git will stop
the rebase at this point and let you do more commits. When you're done
splitting things up, run git rebase --continue.

There's a nice video cast about that here:

  http://gitcasts.com/posts/rebasing

Daniel

[Buildroot] [GIT PULL] avr32 updates

[Thiago A. Corrêa]

Hi,

2009/5/8 Thiago A. Corr?a <thiago.correa@gmail.com>:
>> ?Thiago> Unfortunally, it doesn't look like it. Even if I select
>> ?Thiago> 2.6.29 for the linux headers (toolchain), the build
>> ?Thiago> fails. Unless I actually update the kernel on the target, it
>> ?Thiago> fails to build for avr32. According to the avr32-linux
>> ?Thiago> mailling list, there was a byteorder.h restructuring a while
>> ?Thiago> back, so I guess some versions of the headers are not what
>> ?Thiago> iptables expects.
>>
>> I still don't get it - I've never used the Linux.advanced stuff, but
>> it's just used to build a kernel for the target and doesn't have
>> anything to do with the rootfs, right? How can it then influence the
>> iptables build?
>
> Perhaps it's how it touches all the LINUX26* variables. I have no idea
> either. I just tried to update and it worked. I might just be loosing
> my mind and tested it wrong, could have forgot to run a toolchain with
> 2.6.29 and kernel 2.6.28 test and thought that I had. I've been awake
> for 36 hours already and still have to study for German test tomorrow
> (as second foreign language).
>
> I will leave this building with toolchain kernel headers 2.26.9 and
> advanced linux 2.26.7 and see if iptables fails to compile again.
>

It turns out I was a bit too tired and thought I tested it with 2.6.29
kernel headers and < 2.6.29 kernel.

iptables can't build with toolchain kernel headers earlier than 2.6.29
under avr32, what actually fixed the build was the atngw100_defconfig
update. Good thing I removed that "fix iptables" bit from the logs :D

Cheers,
   Thiago A. Correa

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

 Thiago> It turns out I was a bit too tired and thought I tested it
 Thiago> with 2.6.29 kernel headers and < 2.6.29 kernel.

;)

 Thiago> iptables can't build with toolchain kernel headers earlier
 Thiago> than 2.6.29 under avr32, what actually fixed the build was
 Thiago> the atngw100_defconfig update. Good thing I removed that "fix
 Thiago> iptables" bit from the logs :D

Ok, that makes a bit more sense ;)

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Markus Heidelberg]

Thiago A. Corr?a, 08.05.2009:
> I somehow managed
> to completely trash my local tree and had to clone it again from the
> remote.

You shouldn't ever need to do a complete clone again, unless you did
something really strange. If you messed you local branches, then you can
recreate them from the remote branches or from the reflog which also
contains local changes. If you removed remote branches, you can simply
do "git fetch".

> I really miss svn revert... If I remove some file from the
> local tree, I can't bring it back with git fetch, git checkout or git
> reset.

Yes, you can, with checkout/reset. But it's be a bit different compared
to svn because of git's index. "git status" gives you hints what to do.
To prevent confusion: if you want to revert a particular file, that is
currently in the index, you need to invoke 2 commands: reset && checkout

Markus

[Buildroot] [GIT PULL] avr32 updates

[Markus Heidelberg]

Peter Korsgaard, 08.05.2009:
> >>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>  Thiago> Anyway, what happens if I apply a patch and then you apply it
>  Thiago> a while later before pulling from my tree? I guess we will
>  Thiago> conflict right?
> 
> No, if none of us modify the patch then the git sha1 id will be the
> same

No, it will be different because of the different committer identity.

> and the commit just ignored (if one of us modifies it you will
> most likely get a merge conflict that you'll have to resolve when you
> rebase your changes against me).

If the changes are the same, there will be no merge conflict, it will be
resolved automatically. But it won't ignore a commit, it will leave 2
commits with the same change in the repository, which may be confusing
when browsing the history.

Markus

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

Hi,

 >> No, if none of us modify the patch then the git sha1 id will be the
 >> same

 Markus> No, it will be different because of the different committer identity.

Yes ofcourse. I meant that the file (blob) id would be identical.

 Markus> If the changes are the same, there will be no merge conflict,
 Markus> it will be resolved automatically. But it won't ignore a
 Markus> commit, it will leave 2 commits with the same change in the
 Markus> repository, which may be confusing when browsing the history.

Yeah, but if people reply to the patches with a simple "applied to my
tree, thanks" - Then that shouldn't happen often ..

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Thiago A. Corrêa]

HI,

On Tue, May 12, 2009 at 7:30 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:
> ?>> No, if none of us modify the patch then the git sha1 id will be the
> ?>> same
>
> ?Markus> No, it will be different because of the different committer identity.
>
> Yes ofcourse. I meant that the file (blob) id would be identical.
>

I actually applied the rsync patch with git commit --author="name
<email>". And the log looks just like he commited directly.
If we apply patches like that, both you and those with personal trees,
shouldn't pulls figure out and apply it properly?

Thanks,
    Thiago A. Correa

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

Hi,

 Thiago> I actually applied the rsync patch with git commit --author="name
 Thiago> <email>". And the log looks just like he commited directly.
 Thiago> If we apply patches like that, both you and those with personal trees,
 Thiago> shouldn't pulls figure out and apply it properly?

The author will be the same, but the committer will still be
different. Taking about that rsync patch, will you send a pull request
soonish or should I apply it myself? I would like to include it and
release a -rc2 soon.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Thiago A. Corrêa]

Hi,

On Tue, May 12, 2009 at 4:46 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>
> Hi,
>
> ?Thiago> I actually applied the rsync patch with git commit --author="name
> ?Thiago> <email>". And the log looks just like he commited directly.
> ?Thiago> If we apply patches like that, both you and those with personal trees,
> ?Thiago> shouldn't pulls figure out and apply it properly?
>
> The author will be the same, but the committer will still be
> different. Taking about that rsync patch, will you send a pull request
> soonish or should I apply it myself? I would like to include it and
> release a -rc2 soon.

Yeah, I was trying to squeeze a cups fix too before adding
atngw100-extended_defconfig update and requesting a pull.
But it appears the cups problem is beyond my skills, so I guess I will
just disable it from the defconfig for now and add a bug report.

Do you have a cut date for pull requests?

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

Hi,

 Thiago> Do you have a cut date for pull requests?

Not really, but definately this week.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Peter Korsgaard]

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

 Thiago> Hi Peter,
 Thiago>     I'm newbie with this git thing, so please bear with me...

 Thiago>  * Add dl folder to gitignore

On more thing - Isn't this based on Michael Roth's patch? Please keep
his authorship then.

-- 
Bye, Peter Korsgaard

[Buildroot] [GIT PULL] avr32 updates

[Daniel Mack]

On Fri, May 08, 2009 at 01:52:27AM -0300, Thiago A. Corr?a wrote:
>     I'm newbie with this git thing, so please bear with me...

Btw - a more convenient way of providing such summaries is 
'git request-pull'.

Daniel