LTP Nightly BK Test Failure

LTP Nightly BK Test Failure

[Paul Larson]

The nightly bk testing last night found a build error that I don't
believe showed up in the stock 2.5.32.

This bk tree covered up to cset 1.523.1.3 and there were several e100
driver updates immediately following the 2.5.32 tag that are probably
the likely suspects.  Here's the end of the compile log:

  ld -m elf_i386 -T arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/
i386/kernel/init_task.o init/init.o --start-group
arch/i386/kernel/kernel.o arch
/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o
security/built-in.o /ker
nel/bk/linux-2.5/arch/i386/lib/lib.a lib/lib.a
/kernel/bk/linux-2.5/arch/i386/li
b/lib.a drivers/built-in.o sound/sound.o arch/i386/pci/pci.o
net/network.o --end
-group -o vmlinux
drivers/built-in.o: In function `e100_diag_config_loopback':
drivers/built-in.o(.text+0x49393): undefined reference to
`e100_force_speed_dupl
ex'
make[1]: *** [vmlinux] Error 1
make[1]: Leaving directory `/kernel/bk/linux-2.5'
make: *** [bzImage] Error 2


Thanks,
Paul Larson

Re: LTP Nightly BK Test Failure

[Larry McVoy]

On Wed, Aug 28, 2002 at 09:40:03AM -0500, Paul Larson wrote:
> This bk tree covered up to cset 1.523.1.3 and there were several e100

Because revisions in BK change if there is parallel development, it's
far more effective if you list a changeset as either

	bk changes -r1.523.1.3
i.e.,
	ChangeSet@1.523.1.3, 2002-08-27 18:29:55-07:00, fdavis@si.rr.com
	  [PATCH] drivers/media/video/bt819.c
	    
	  Here's the bt819 i2c-old --> i2c patch.

or as the revision and the key, 
	
	bk prs -hr1.523.1.3 -nd':I: (:KEY:)'
i.e.,
	1.523.1.3 (fdavis@si.rr.com|ChangeSet|20020828012955|42356)

You can use the key any place you can use the revision, like so

	bk changes -r'fdavis@si.rr.com|ChangeSet|20020828012955|42356'
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: LTP Nightly BK Test Failure

[Paul Larson]

On Wed, 2002-08-28 at 10:10, Larry McVoy wrote:
> On Wed, Aug 28, 2002 at 09:40:03AM -0500, Paul Larson wrote:
> > This bk tree covered up to cset 1.523.1.3 and there were several e100
> 
> Because revisions in BK change if there is parallel development, it's
> far more effective if you list a changeset as either
...
I didn't think about that, thanks for the tip.  I'll make sure to do it
like that in future reports.  Of course if there's any confusion, the
cset numbers I've been giving can be looked up on the linux-2.5 tree at
bkbits since I test against an unmodified pull from that tree.

Thanks,
Paul Larson

Re: LTP Nightly BK Test Failure

[Matthias Urlichs]

Paul Larson:
>  I didn't think about that, thanks for the tip.  I'll make sure to do it
>  like that in future reports.  Of course if there's any confusion, the
>  cset numbers I've been giving can be looked up on the linux-2.5 tree at
>  bkbits since I test against an unmodified pull from that tree.
>
That doen't work if the tree changes after you pulled ...

-- 
Matthias Urlichs