linux-next: manual merge of the kconfig tree with the kbuild tree

linux-next: manual merge of the kconfig tree with the kbuild tree

[Stephen Rothwell]

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

Hi Steven,

Today's linux-next merge of the kconfig tree got conflicts in
scripts/extract-ikconfig between commit
692d21e03cfc740684639b019ce9ad708930eb47 ("kconfig: simplification of
scripts/extract-ikconfig") from the kbuild tree and commits
fd3132d5815bf72aeec7d5ad87161b4831f8e48c ("kconfig: add check if end
exists in extract-ikconfig") and 6be51ffc1791b72d11cef9bb0a578fe8c5d64c6a
("kconfig: have extract-ikconfig read ELF files") from the kconfig tree.

It looks like the kbuild patch obsoletes the first of the kconfig patches
and may obsolete the second.  I used the kbuild version for now, but
invite advice.

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

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

Re: linux-next: manual merge of the kconfig tree with the kbuild tree

[Dick Streefland]

On Monday 2009-08-24 11:32, Stephen Rothwell wrote:
| Today's linux-next merge of the kconfig tree got conflicts in
| scripts/extract-ikconfig between commit
| 692d21e03cfc740684639b019ce9ad708930eb47 ("kconfig: simplification of
| scripts/extract-ikconfig") from the kbuild tree and commits
| fd3132d5815bf72aeec7d5ad87161b4831f8e48c ("kconfig: add check if end
| exists in extract-ikconfig") and 6be51ffc1791b72d11cef9bb0a578fe8c5d64c6a
| ("kconfig: have extract-ikconfig read ELF files") from the kconfig tree.
| 
| It looks like the kbuild patch obsoletes the first of the kconfig patches
| and may obsolete the second.  I used the kbuild version for now, but
| invite advice.

My simplified script that you merged from the kbuild tree will also
extract config information from ELF files. So both patches from the
kconfig tree are not needed anymore.

-- 
Dick

Re: linux-next: manual merge of the kconfig tree with the kbuild tree

[Steven Rostedt]

On Mon, 24 Aug 2009, Dick Streefland wrote:

> On Monday 2009-08-24 11:32, Stephen Rothwell wrote:
> | Today's linux-next merge of the kconfig tree got conflicts in
> | scripts/extract-ikconfig between commit
> | 692d21e03cfc740684639b019ce9ad708930eb47 ("kconfig: simplification of
> | scripts/extract-ikconfig") from the kbuild tree and commits
> | fd3132d5815bf72aeec7d5ad87161b4831f8e48c ("kconfig: add check if end
> | exists in extract-ikconfig") and 6be51ffc1791b72d11cef9bb0a578fe8c5d64c6a
> | ("kconfig: have extract-ikconfig read ELF files") from the kconfig tree.
> | 
> | It looks like the kbuild patch obsoletes the first of the kconfig patches
> | and may obsolete the second.  I used the kbuild version for now, but
> | invite advice.
> 
> My simplified script that you merged from the kbuild tree will also
> extract config information from ELF files. So both patches from the
> kconfig tree are not needed anymore.

OK what is the proper way to resolve this, before sending anything off to 
Linus?  Should I pull in Dick's tree and resolve the conficts myself, and 
let you repull? Or is something else recommended?

Thanks,

-- Steve

Build failure on linux-next master branch

[Steven Rostedt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 284 bytes --]


With latest next master branch I got this failure in my build system.

  Building modules, stage 2.
Kernel: arch/x86/boot/bzImage is ready  (#1801)
  MODPOST 96 modules
ERROR: "crc16" [net/bluetooth/l2cap.ko] undefined!
make[1]: *** [__modpost] Error 1


Config attached.

-- Steve


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2564 bytes --]

Re: linux-next: manual merge of the kconfig tree with the kbuild tree

[Stephen Rothwell]

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

Hi Steve,

On Mon, 24 Aug 2009 10:54:04 -0400 (EDT) Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 24 Aug 2009, Dick Streefland wrote:
> 
> > My simplified script that you merged from the kbuild tree will also
> > extract config information from ELF files. So both patches from the
> > kconfig tree are not needed anymore.
> 
> OK what is the proper way to resolve this, before sending anything off to 
> Linus?  Should I pull in Dick's tree and resolve the conficts myself, and 
> let you repull? Or is something else recommended?

You could cherry-pick Dick's commit into your tree (and remove your
conflicting commits by rebasing). Or you could rebase your work on top of
Sam's kbuild tree (or merge Sam's tree) (but that would require Sam to
guarantee that his tree won't be rebased). Or you could do the rebase and
then just submit your tree to Sam for inclusion (instead of, or as well
as, it being included in linux-next directly).  Or you could keep going
the way you are and resolve the conflict once one of the trees has been
merged into Linus' tree.

For the moment, I can keep resolving the conflict.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the kconfig tree with the kbuild tree

[Steven Rostedt]

On Tue, 25 Aug 2009, Stephen Rothwell wrote:

> Hi Steve,
> 
> On Mon, 24 Aug 2009 10:54:04 -0400 (EDT) Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Mon, 24 Aug 2009, Dick Streefland wrote:
> > 
> > > My simplified script that you merged from the kbuild tree will also
> > > extract config information from ELF files. So both patches from the
> > > kconfig tree are not needed anymore.
> > 
> > OK what is the proper way to resolve this, before sending anything off to 
> > Linus?  Should I pull in Dick's tree and resolve the conficts myself, and 
> > let you repull? Or is something else recommended?
> 
> You could cherry-pick Dick's commit into your tree (and remove your
> conflicting commits by rebasing). Or you could rebase your work on top of
> Sam's kbuild tree (or merge Sam's tree) (but that would require Sam to
> guarantee that his tree won't be rebased). Or you could do the rebase and
> then just submit your tree to Sam for inclusion (instead of, or as well
> as, it being included in linux-next directly).  Or you could keep going
> the way you are and resolve the conflict once one of the trees has been
> merged into Linus' tree.
> 
> For the moment, I can keep resolving the conflict.

Yeah, lets just keep it as is for the moment. When Sam's is accepted into 
Linus's I'll rebase off of that. Assuming that Sam's will be accepted 
rather quickly ;-)

-- Steve