[openib-general] Latest build test results

[Nishanth Aravamudan]

On 11.10.2005 [23:15:27 -0400], Hal Rosenstock wrote:
> Hi again Nish,
> 
> On Tue, 2005-10-11 at 21:39, Nishanth Aravamudan wrote:
> > > > > Update arp_recv functions to latest 2.6.14 netdevice.h API for struct
> > > > > packet_type
> > > > 
> > > > Sorry for the delay, I haven't yet had time to test the patches :/ I'll
> > > > try to get to it tonight or tomorrow.
> > > > 
> > > > Is there anyway you can send me patches against the kernel tree as
> > > > opposed to the svn repo? It makes my side of things *a lot* easier, as
> > > > right now I have to take your patch against svn and either hand-edit or
> > > > patch my checkout and then diff against the current kernel tree.
> > > 
> > > Since you were reporting iSER, AT, and SDP compile warnings/errors,
> > > aren't you using the latest OpenIB svn tree with 2.6.14-rc3 ?
> > 
> > Yes; but you have to understand that the automated build system I have
> > access to 1) does not have external internet access (i.e., to the svn
> > tree) and 2) only builds kernels unless I manually send commands to the
> > terminal.
> > 
> > So, the way I'm doing things is:
> > 
> > Send in 4 jobs for mainline (x86 and ppc64 with =y and =m) and then
> > generate a patch of the latest svn tree against the current -git release
> > (a patch to the kernel) and send it in as a parameter to my builds to
> > test the latest svn tree. This leads to another 4 jobs (x86 and ppc64
> > with =y and =m).
> > 
> > I'm *only* doing kernel build testing right now.
> > 
> > > Which patches are you referring to ? Was it the fib_frontend.c one ?
> > > Not sure why they would need any manual fixup. At least that one was
> > > pretty straightforward.
> > 
> > In the sense that I have to edit them to kernel relative paths, not in
> > the content of the patch. To test any patch in the system I have access
> > to, it needs to be a normal kernel patch (-p1 applicable to the base
> > tree).
> > 
> > Going through and manually applying patches to the svn tree and then
> > regenerating the diff completely defeats the purpose of automated
> > compilation testing.
> 
> OK. Do you need any patches regenerated or is this more for the future ?

If you could regen the patches, that would definitely speed things up
for me, but I can handle these few, it's not a big deal. Definitely, in
the future, it makes it an almost instantaneous build test if I have the
kernel-relative patch.

Thanks,
Nish