[Nut-upsuser] Re: FreeBSD 6.1, MGE Ellipse ASR600USBS, newhidups & upsd

[Eric Masson]

Arjen de Korte a écrit :

Hello Arjen,

> This is a different problem, your driver is not answering at all and it
> looks like the dumpall command is not processed. Upgrading to the latest
> development version would be a good idea now, since a few things have
> changed in the newhidups driver lately.

Ok, I've pulled rev 584.

Now, the problems ;), automake, autoconf and libtool have been installed 
  via ports but the following happens :

- autoconf 2.59 barfs with

emss at box:~/nut/trunk> /usr/local/gnu-autotools/bin/autoconf
configure.in:11: error: possibly undefined macro: AM_INIT_AUTOMAKE
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.
configure.in:50: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.in:327: error: possibly undefined macro: AM_CONDITIONAL

- If i try to use the generated configure script, it fails with

emss at srvbsdnanssv:~/nut/trunk> ./configure
checking build system type... i386-unknown-freebsd6.1
checking host system type... i386-unknown-freebsd6.1
checking target system type... i386-unknown-freebsd6.1
./configure: line 1454: AM_INIT_AUTOMAKE: command not found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for egrep... grep -E
checking for ar... /usr/bin/ar
checking for ranlib... ranlib
./configure: line 2861: AC_PROG_LIBTOOL: command not found
checking for inline... inline
checking for flock... yes
checking for lockf... yes
checking for fcvt... no
checking for fcvtl... no
checking for cfsetispeed... yes
checking for tcsendbreak... yes
checking for seteuid... yes
checking for setsid... yes
checking for getpassphrase... no
checking for on_exit... no
checking for vsnprintf... yes
checking for snprintf... yes
checking for setenv... yes
checking for inet_aton... yes
checking for strerror... yes
checking for atexit... yes
checking whether byte ordering is bigendian... no
checking for getopt declarations... in unistd.h
checking whether to use uu_lock... yes
checking for connect... yes
checking sys/modem.h usability... no
checking sys/modem.h presence... no
checking for sys/modem.h... no
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking varargs.h usability... no
checking varargs.h presence... no
checking for varargs.h... no
checking sys/termios.h usability... yes
checking sys/termios.h presence... yes
checking for sys/termios.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
./configure: line 4932: TYPE_SOCKLEN_T: command not found
./configure: line 4933: TYPE_UINT16_T: command not found
./configure: line 4934: TYPE_UINT8_T: command not found
checking for SSL library availability... yes
checking whether to enable SSL development code... no
checking for gd version via gdlib-config... not found
checking for gd include flags... using defaults
checking for gd library flags... using defaults
checking gd.h usability... no
checking gd.h presence... no
checking for gd.h... no
checking for gdImagePng in -lgd... no
checking for --with-all... no
checking whether to build CGI programs... no
./configure: line 5517: syntax error near unexpected token `WITH_CGI,'
./configure: line 5517: `AM_CONDITIONAL(WITH_CGI, test "${nut_with_cgi}" 
= "yes")'

Seems I'll have to wait for a new release...

> I will make this value configurable later today in the (development)
> trunk. It will basically have the same default value, which can be
> overridden by specifying INITIALWAITMAX in upsd.conf, but again I really
> doubt this is your problem.

Ok.

> Please note that you don't want to overdo this. All the time you spend
> in the initial waiting, upsmon isn't running (yet), so you're basically
> blind to any changes in power/battery state.
> Which may be a problem if you loose power repeatedly without the batteries
> fully recharged again in the mean time.

Yes, I understand the point.

Regards

éric