linux-kbuild.git

linux-kbuild.git

[Michal Marek]

Hi Stephen,

I went through the patches posted to linux-kbuild and picked those that
were easy enough to review, looked safe and worked for me. I also took
Sam's series from kbuild-next.git, but I didn't really review it yet, so
there is no signoff from me (TBD). The repo is at

  git://repo.or.cz/linux-kbuild.git for-next

Please ignore the other branches. The shortlog is

Jie Zhang (1):
      net: add net_tstamp.h to headers_install

Jonathan Nieder (2):
      scripts/package: add KBUILD_PKG_ROOTCMD variable
      scripts/package: deb-pkg: use fakeroot if available

Michael Tokarev (1):
      kbuild: fix bzImage build for x86

Michal Marek (2):
      scripts/package: tar-pkg: use tar --owner=root
      kbuild: create include/generated in silentoldconfig

Sam Ravnborg (14):
      kbuild: search arch/$ARCH/include before include/
      dontdiff: add generated
      kbuild: move bounds.h to include/generated
      kbuild: move asm-offsets.h to include/generated
      ia64: move nr-irqs.h to include/generated
      arm: move mach-types to include/generated
      sh: move machtypes.h to include/generated
      kbuild: drop include2/ used for O=... builds
      kbuild: do not check for include/asm-$ARCH
      kbuild: drop include/asm
      kbuild: move compile.h to include/generated
      drop explicit include of autoconf.h
      kbuild: move autoconf.h to include/generated
      kbuild: move utsrelease.h to include/generated

Wenji Huang (2):
      Kbuild: clear marker out of modpost
      Kbuild: clean up marker

There are some more patches on the mailing list and in -mm, which I'm
going to look at, but I think this should be a good start. What do you
think? Could this be added to linux-next?

Michal

Re: linux-kbuild.git

[Sam Ravnborg]

On Thu, Nov 26, 2009 at 01:26:09PM +0100, Michal Marek wrote:
> Hi Stephen,
> 
> I went through the patches posted to linux-kbuild and picked those that
> were easy enough to review, looked safe and worked for me. I also took
> Sam's series from kbuild-next.git, but I didn't really review it yet, so
> there is no signoff from me (TBD). The repo is at
> 
>   git://repo.or.cz/linux-kbuild.git for-next
> 
> Please ignore the other branches. The shortlog is
> 
> Jie Zhang (1):
>       net: add net_tstamp.h to headers_install
> 
> Jonathan Nieder (2):
>       scripts/package: add KBUILD_PKG_ROOTCMD variable
>       scripts/package: deb-pkg: use fakeroot if available
> 
> Michael Tokarev (1):
>       kbuild: fix bzImage build for x86
> 
> Michal Marek (2):
>       scripts/package: tar-pkg: use tar --owner=root
>       kbuild: create include/generated in silentoldconfig
> 
> Sam Ravnborg (14):
>       kbuild: search arch/$ARCH/include before include/
>       dontdiff: add generated
>       kbuild: move bounds.h to include/generated
>       kbuild: move asm-offsets.h to include/generated
>       ia64: move nr-irqs.h to include/generated
>       arm: move mach-types to include/generated
>       sh: move machtypes.h to include/generated
>       kbuild: drop include2/ used for O=... builds
>       kbuild: do not check for include/asm-$ARCH
>       kbuild: drop include/asm
>       kbuild: move compile.h to include/generated
>       drop explicit include of autoconf.h
>       kbuild: move autoconf.h to include/generated
>       kbuild: move utsrelease.h to include/generated
> 
> Wenji Huang (2):
>       Kbuild: clear marker out of modpost
>       Kbuild: clean up marker
> 
> There are some more patches on the mailing list and in -mm, which I'm
> going to look at, but I think this should be a good start. What do you
> think? Could this be added to linux-next?

Looks good.
Good to see you picked up some of the patches that were pending.

Stephen - please replace my kbuild trees with this.

	Sam

Re: linux-kbuild.git

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

Hi Michal,

On Thu, 26 Nov 2009 20:37:50 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> On Thu, Nov 26, 2009 at 01:26:09PM +0100, Michal Marek wrote:
> > 
> > I went through the patches posted to linux-kbuild and picked those that
> > were easy enough to review, looked safe and worked for me. I also took
> > Sam's series from kbuild-next.git, but I didn't really review it yet, so
> > there is no signoff from me (TBD). The repo is at
> > 
> >   git://repo.or.cz/linux-kbuild.git for-next
> 
> Looks good.
> Good to see you picked up some of the patches that were pending.
> 
> Stephen - please replace my kbuild trees with this.

I have replaced this from today.  Do you intend to run the equivalent of
the kbuild-current tree (bug fixes for the current release while they are
waiting to go to Linus)?  I have removed the kbuild-current tree for now
since the only commit in it is in the new kbuild tree.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-kbuild.git

[Michal Marek]

On 27.11.2009 05:22, Stephen Rothwell wrote:
> Hi Michal,
> 
> On Thu, 26 Nov 2009 20:37:50 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>>
>> On Thu, Nov 26, 2009 at 01:26:09PM +0100, Michal Marek wrote:
>>>
>>> I went through the patches posted to linux-kbuild and picked those that
>>> were easy enough to review, looked safe and worked for me. I also took
>>> Sam's series from kbuild-next.git, but I didn't really review it yet, so
>>> there is no signoff from me (TBD). The repo is at
>>>
>>>   git://repo.or.cz/linux-kbuild.git for-next
>>
>> Looks good.
>> Good to see you picked up some of the patches that were pending.
>>
>> Stephen - please replace my kbuild trees with this.
> 
> I have replaced this from today.

Thanks!


>  Do you intend to run the equivalent of
> the kbuild-current tree (bug fixes for the current release while they are
> waiting to go to Linus)?  I have removed the kbuild-current tree for now
> since the only commit in it is in the new kbuild tree.

I plan to maintain such a branch, but I thought I would base the
for-next branch on top of it, so that you get everything in one pack. Or
would you still prefer to have two kbuild branches in linux-next, so
that you can remove the for-next branch if necessary and keep the
for-current branch? Just tell me what fits you best.



> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgment of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window. 
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>      * submitted under GPL v2 (or later) and include the Contributor's
> 	Signed-off-by,
>      * posted to the relevant mailing list,
>      * reviewed by you (or another maintainer of your subsystem tree),
>      * successfully unit tested, and 
>      * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.

OK, will keep that in mind.

Michal

Re: linux-kbuild.git

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

Hi Michal,

On Fri, 27 Nov 2009 10:42:37 +0100 Michal Marek <mmarek@suse.cz> wrote:
>
> >  Do you intend to run the equivalent of
> > the kbuild-current tree (bug fixes for the current release while they are
> > waiting to go to Linus)?  I have removed the kbuild-current tree for now
> > since the only commit in it is in the new kbuild tree.
> 
> I plan to maintain such a branch, but I thought I would base the
> for-next branch on top of it, so that you get everything in one pack. Or
> would you still prefer to have two kbuild branches in linux-next, so
> that you can remove the for-next branch if necessary and keep the
> for-current branch? Just tell me what fits you best.

Running a for-current branch allows you to queue up urgent fixes without
disrupting your for-next branch.  I will merge such a branch early on
(actually before I do my first build) so that I don't have to worry about
problems that are already have fixes pending for to be merged by Linus in
his current tree.  Also, as you say, if I have problems with your
for-next branch, it does not affect the more urgent patches.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-kbuild.git

[Michal Marek]

On 29.11.2009 22:57, Stephen Rothwell wrote:
> On Fri, 27 Nov 2009 10:42:37 +0100 Michal Marek <mmarek@suse.cz> wrote:
>> I plan to maintain such a branch, but I thought I would base the
>> for-next branch on top of it, so that you get everything in one pack. Or
>> would you still prefer to have two kbuild branches in linux-next, so
>> that you can remove the for-next branch if necessary and keep the
>> for-current branch? Just tell me what fits you best.
> 
> Running a for-current branch allows you to queue up urgent fixes without
> disrupting your for-next branch.  I will merge such a branch early on
> (actually before I do my first build) so that I don't have to worry about
> problems that are already have fixes pending for to be merged by Linus in
> his current tree.  Also, as you say, if I have problems with your
> for-next branch, it does not affect the more urgent patches.

OK, I created a for-linus branch in git://repo.or.cz/linux-kbuild.git.
Currently it's empty, as there are no urgent kbuild fixes for 2.6.32.

Michal

Re: linux-kbuild.git

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

Hi Michal,

On Mon, 30 Nov 2009 11:36:05 +0100 Michal Marek <mmarek@suse.cz> wrote:
>
> OK, I created a for-linus branch in git://repo.or.cz/linux-kbuild.git.
> Currently it's empty, as there are no urgent kbuild fixes for 2.6.32.

OK, it will be included from tomorrow in case you find anything urgent.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]