[Nut-upsdev] NUT and Buildbot (was Re: New Mustek UPS model working)

[Charles Lepple]

On Wed, Feb 11, 2009 at 11:30 AM, Fr3ddie <fr3ddie at fr3ddie.it> wrote:
> Charles Lepple wrote:
>> When something gets updated, you would then run 'svn update' to pull
>> the latest changes in.
>
> Ok.
>
>> The dependencies are set up such that if only one driver is changed
>> during the SVN update, running 'make' on that directory should
>> recompile the minimum number of files. (You will also want to add
>> "--enable-maintainer-mode" to the ./configure command line.)
>> Also, you can add a few --with-whatever=no arguments to ./configure in
>> case that is taking too long.
>
> Ok, are these addresses correct to retrieve nut's documentation about
> ./configure parameters?
> http://www.networkupstools.org/doc/2.2.0/INSTALL.html
> http://www.networkupstools.org/doc/2.2.0/configure.html

Those are good for an overview of the process, but you can always get
the latest help by running "./configure --help".

> Should I place my parameters inside ./configure as variables, or I
> should pass those parameters to ./configure (so what buildbot does, just
> "make")?

I meant that you can run "./configure --with-whatever
--without-something-else --enable-maintainer-mode". You don't need to
edit the configure script directly - it gets rebuilt with autoreconf.

You can see the commands that will be run by looking at the buildbot logs, e.g.

   http://buildbot.ghz.cc/public/nut/Debian-etch-x86/builds/682/step-configure/0

and

   http://buildbot.ghz.cc/public/nut/Debian-etch-x86/builds/682/step-compile/0

(first blue line in each link)

Please take some time to run things by hand a few more times to
familiarize yourself with the build process.

>> Here is a conceptual diagram:
>> http://buildbot.net/repos/release/docs/buildbot.html#System-Architecture
>
> Red, thanks.
>
>> and here is the NUT Buildbot master status page:
>> http://buildbot.ghz.cc/public/nut/
>
> Ok, but I need the parameters to create the slave appropriately: I tried
> with:
>
> buildbot create-slave /home/nut/ buildbot.ghz.cc/public/nut:8007 nut nut
>
> but... herr... I miss something, maybe the correct address and user/pass :)

Yes, we try not to mention the slave address and passwords on the
mailing list :-)

>
> I'm sorry but I need some information (a "man buildbot" doesn't exists
> and I anyway need correct parameters for nut...).
>
> - Is the creation process I tryed correct?
> - After creation process I only need to run:
>        buildbot start /home/nut/

Yes, buildbot will check out its own copy of the source code.

>  or I need to run a svn update *before*?
> - The SVN address is:
>        svn co svn://svn.debian.org/nut/trunk
>  or is the one stated at http://buildbot.ghz.cc/public/nut/changes:
>        svn co svn://svn.debian.org/nut
>  ?
> - Can I run all the above commands as an unprivileged user or I need to
> be r00t?

Buildbot doesn't need to be root, you just need to make sure it has
write permission to its working directory.

> - After buildbot build/test where will be placed the NUT binaries? In
> the same buildbot directory, so I should install by the classic "sudo
> make install" (or, maybe, "sudo checkinstall")?
>
> I'm a little confused about buildbot capabilities and a compiling-newbie :)

I think I jumped into the original conversation late. I thought you
just wanted to test compilation on another platform. Right now, we
don't have a good functional test for NUT, although Arnaud has been
working on a test with dummyups against upsd.

If you want to actually test the drivers, Buildbot isn't as helpful
right now, since we don't force the system to use the newly-built
drivers. In fact, "make distcheck" only tests that all needed files
will be present in a distribution tarball, and that they all compile.

I suppose you could do a "make install" from the buildbot directory
afterwards, but I personally like having a little more control over
the build process when I am installing new drivers. You can still
manually run "svn update" then run "make && sudo make install" to test
a new revision of a driver.

-- 
- Charles Lepple