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
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.,
[email protected], 2002-08-27 18:29:55-07:00, [email protected]
[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 ([email protected]|ChangeSet|20020828012955|42356)
You can use the key any place you can use the revision, like so
bk changes -r'[email protected]|ChangeSet|20020828012955|42356'
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
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