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

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

Charles Lepple ha scritto:
>> 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".
Ok, thanks for this, I haven't ever known about a "--help"
parameter for
configure scripts! ;)
> 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.
Do I have to launch autoreconf before or after my personal ./configure line?
> 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)
Looking at...
> Please take some time to run things by hand a few more times to
> familiarize yourself with the build process.
Sure. I definitively need to. ;)
I'll make some try then I'll be back to report.
> Yes, we try not to mention the slave address and passwords on the
> mailing list :-)
LOL, understood :)
>> - 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
>>  ?
About this? I think I should use the "trunk" subdirectory only to test
the latest testing, is it correct?
> 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.
Ok so the best, for now, is if I understand alone how to "manually"
compile&run the nut's testing version. Then, if you need it, I'll
try
using buildbot.
Thank you very much for your help and I'll be back soon :)

-- 
Fr3ddie
fr3ddie at fr3ddie.it
Home Page: http://www.fr3ddie.it
OpenPGP Public Key available on my website

The only good Windows is an uninstalled Windows