Wireshark · Wireshark-dev: Re: [Wireshark-dev] Buildbots

[Gerald Combs <gerald@xxxxxxxxxxxxx>]

Maynard, Chris wrote:
> I was looking at the Windows buildbot status to see if the compiling step would fail at the same place as it fails for me, namely here:
>  
> 
> 		Generating Code...
> 		Linking dumpcap.exe
> 		        link @C:\DOCUME~1\cmaynard\LOCALS~1\Temp\nmi02488.
> 		CVPACK : fatal error CK1024: ringbuffer.obj cannot use program database c:\svn\wireshark\vc60.pdb : signatures do not match
> 		LINK : warning LNK4027: CVPACK error
> 		NMAKE : fatal error U1077: 'link' : return code '0x1'
> 		Stop.
> 
> Well, it didn't fail, so I'm not sure why that's happening for me.  At least it seems to successfully compile if I simply retry.  Strange though ... and annoying.  Regardless, I did notice a few other things with the buildbots that I thought I would mention:

I'm seeing the same behavior here.

> 1) The Windows buildbot is red due to the tshark test failing.  I looked at the Solaris and Ubuntu buildbots and perhaps the only reason why they're not also red is because the Solaris buildbot doesn't seem to run any tests and the Ubuntu buildbot skips almost all of the tshark tests.  Perhaps those tests should not be skipped?

The Ubuntu builder would need elevated privileges to run capture tests, so I'm
not sure if that's an option.  It might be on the Solaris builder.

> 2) The Windows buildbot does not report any warnings when creating an installer, whereas I get the following two warnings:
>   LangString "MUI_UNTEXT_COMPONENTS_TITLE" is not set in language table of language English
>   LangString "MUI_UNTEXT_COMPONENTS_SUBTITLE" is not set in language table of language English
> 
> I believe the reason I get the warnings and the Windows buildbot doesn't is because I'm using the latest version of NSIS, namely version 2.30 whereas the Windows buildbot is using version 2.17.  Perhaps it's time for an NSIS upgrade on the buildbot?  And then a fix of the two warnings above too.

It doesn't look like anything is broken in 2.30, so I'll go ahead and upgrade.

> 3) The Solaris buildbot doesn't test all options.  Perhaps it should?  For example:
>                      Install setuid : no
>                    Build lua plugin : no
>                    Build rtp_player : no
>                         Use threads : no
>              Build profile binaries : no
>                Use GNU ADNS library : no
>                Use SMI SNMP library : no
> 
> 4) The Ubuntu buildbot doesn't test all options.  Perhaps it should?  For example:
>                      Install setuid : no
>                    Build lua plugin : no
>                    Build rtp_player : no
>                         Use threads : no
>              Build profile binaries : no
>              Use SSL crypto library : no

I'm not sure this would be a good idea.  Most of the options above switch
different sections of code on and off.  Having the same options enabled
everywhere would mean that significant amounts of code wouldn't get any
compile-time checking.  (Whether the options we have in place are optimal is a
different question.)

> 5) Neither the Solaris not the Ubuntu buildbots test creating an rpm (via make rpm-package) or test creating a source rpm (via make srpm-package).  Perhaps they should?  I create both Windows installers and Linux rpm's and I have run into problems with creating rpms in the past, so personally, I would be in favor of having those tests added to the suite.

We should probably have a Red Hat and/or SuSE builder for that purpose.  (...and
the Ubuntu builder should probably build Debian packages, and the Solaris
builder should probably build Solaris/SVR4 packages).

> 7) The OSX buildbot doesn't appear to build whatever equivalent installer and/or rpm would be needed to install on a MAC.  (Sorry, I don't know much about the MAC so I have no idea what to call it.)  Anyway, it'd probably be a good idea for it to do so as well, wouldn't it?

That's because it doesn't exist (which is ironic, since there appear to be a
gaggle of Wireshark developers running OS X).  The current OS X packages are
hand-built by Andreas Fink.  Inkscape does a pretty good job of OS X packaging:

http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/packaging/macosx/

Maybe we should steal^W use them for inspiration.