tarballs of patchsets?

tarballs of patchsets?

[Christian]

hi,

i am trying to chase some bug and i know, it must be somewhere between 2.6.4 and 
2.6.5. the 2.6.5 patch is 7.0 MB (unpacked). although i am pretty sure the lines 
starting with "diff -Nru a/Documentation" do seem to be involved with the issue, 
i am not a programmer and often have to use brute-force methods as described in 
"BUG-HUNTING". that said, i'd like to know, if there is a possibility to find 
out the different sets that generated this "patch-2.6.5.bz2".

correct me if i'm wrong, but isn't it like:
   - $scsi-maintainer sent in these patches
   - $ppc_maintainer sent in those patches
   - fix from author_x
   - more fixes from author_y

and then this whole thing is cat'ed altogether to the very patch-file.bz2?
could one compile a tar.[bz2|gz] from the patch-sets, before putting it into one 
large patch-file?

hm, maybe it's done in another way.
the thing is: even when i say: "hm, this is a ppc issue, so i'll cut out all 
diff's touching arch/ppc/ (i.e. from "$ppc_maintainer") -> the kernel might not 
compile then, and i have to wait until compilation is almost finished, just to 
find out that something under drivers/char was referencing a change in arch/ppc.

when i could know "oh, the guy who changed arch/ppc also touched drivers/char", 
i would cut out _both_ and the kernel would at least compile.

perhaps the whole process of releasing a patch is way more complex than i think 
here, but perhaps someone has some thoughts on it. just now compilation of 
2.5.6-rc1 failed. i hoped it would at least compile, because it's "only" 4MB to 
search for the bug then.

Thank you,
Christian.
-- 
BOFH excuse #9:

doppler effect

Re: tarballs of patchsets?

[Christian]

Christian wrote:
> hi,
> 
> i am trying to chase some bug and i know, it must be somewhere between 
> 2.6.4 and 2.6.5. the 2.6.5 patch is 7.0 MB (unpacked). although i am 
> pretty sure the lines starting with "diff -Nru a/Documentation" do seem 
> to be involved with the issue, i am not a programmer and often have to 

s/do seem to be involved/do _not_ seem to be involved/

-- 
BOFH excuse #377:

Someone hooked the twisted pair wires into the answering machine.

Re: tarballs of patchsets?

[Andrew Morton]

Christian <evil@g-house.de> wrote:
>
> i am trying to chase some bug and i know, it must be somewhere between 2.6.4 and 
>  2.6.5.

The most practical way of doing this would be to download bitkeeper and do
a binary search.


 1: Do `bk changes > foo'.

    This generates a monster changelog file which is your
    bisection-searching guide.  It has stuff like:

 ChangeSet@1.1734, 2004-05-21 22:59:48+01:00, tony@com.rmk.(none)
   [ARM PATCH] 1887/1: Update OMAP low level debug functions again
   
   Patch from Tony Lindgren
   
   This patch makes the low level debug functions work when support is
   compiled in for multiple OMAPs. The patch also removes now unnecessary
   include, incorrect comment, and SERIAL_REG_SHIFT ifdefs.


 2: Do

 	bl clone -ql -r1.1734 ref-repo test-repo

    and you have a tree up to and including 1.1734.

 3: cd test-repo ; bk -r get

 4: build, test, choose new revision, goto step 1.


It's probably possible to do the same with the CVS tree - I haven't tried.

Re: tarballs of patchsets?

[Christian]

Andrew Morton wrote:
> The most practical way of doing this would be to download bitkeeper and do
> a binary search.

ok, i'll go with bk then.

[...]
> It's probably possible to do the same with the CVS tree - I haven't tried.

thank you for your precious time for giving me live examples. i'm not very used 
to bk stuff but this will hoepfully help.

kind regards,
Christian.
-- 
BOFH excuse #138:

BNC (brain not connected)

Re: tarballs of patchsets?

[Andy Isaacson]

On Mon, May 24, 2004 at 10:55:52AM -0700, Andrew Morton wrote:
> Christian <evil@g-house.de> wrote:
> > i am trying to chase some bug and i know, it must be somewhere
> > between 2.6.4 and 2.6.5.
> 
> The most practical way of doing this would be to download bitkeeper and do
> a binary search.
> 
>  1: Do `bk changes > foo'.
[snip]
>  2: Do
>  	bl clone -ql -r1.1734 ref-repo test-repo
[snip]
>  3: cd test-repo ; bk -r get
>  4: build, test, choose new revision, goto step 1.

FWIW, we're batting around the idea of automating this -- it would be
cool (and quite trivial) to have a "bk-findbug.sh" script that takes
 - a repo
 - "I know the bug wasn't present in 1.1562"
 - "the bug is present in 1.1699"
 - a shell fragment that exits 1 if the bug exists, 0 if the bug is squashed

and tells you which cset causes the bug to appear.

But, applying this to the kernel is more problematic; you have to
reboot, or run under vmware/UML/Xen/whatever.

-andy