Network UPS Tools version 2.4.3 has been released. http://www.networkupstools.org/ Note: this is only a bugfix release that only solves the regression on IPv6 activation. Direct access: - Download: http://www.networkupstools.org/source/2.4/nut-2.4.3.tar.gz - News: http://www.networkupstools.org/source/2.4/new-2.4.3.txt - ChangeLog: http://www.networkupstools.org/source/2.4/ChangeLog the NUT team
Hi! Please find a trivial documentation patch attached. -- Sincerely yours, Yury V. Zaytsev On Tue, 2010-02-23 at 11:47 +0100, Arnaud Quette wrote:> Network UPS Tools version 2.4.3 has been released. > > http://www.networkupstools.org/ > > Note: this is only a bugfix release that only solves the regression on > IPv6 activation. > > Direct access: > - Download: http://www.networkupstools.org/source/2.4/nut-2.4.3.tar.gz > - News: http://www.networkupstools.org/source/2.4/new-2.4.3.txt > - ChangeLog: http://www.networkupstools.org/source/2.4/ChangeLog > > the NUT team > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser-------------- next part -------------- A non-text attachment was scrubbed... Name: nut-2.4.3-docs.patch Type: text/x-patch Size: 343 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20100225/619cf3ec/attachment.bin>
Yury V. Zaytsev
2010-Feb-25 13:11 UTC
[Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi guys! I'm desperately trying to update the package we ship at RPMForge and bump NUT from v2.4.1 to v2.4.3. Unfortunately, it does not seem to be an easy task by any means. I was first trying to use ./configure which is bundled with NUT. It didn't work, because the following check was introduced in nut-2.4.3/m4/nut_check_libgd.m4 for some reason: AC_SEARCH_LIBS(gdImagePng, gd, [], [nut_have_libgd=no]) and it always fail no matter whether GD is installed or not (in fact, it is installed and previous checks report that the headers are there and usable). I removed this check and did autoreconf -vfi but it needs newer autoconf that comes with RHEL. Fine, I did it with 2.63 installed in /usr/local. Now ./configure works fine, but if fails to compile on the clean machine with the following message: if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --para then mv -f ".deps/common.Tpo" ".deps/common.Po"; else rm -f ".deps/common.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --para then mv -f ".deps/state.Tpo" ".deps/state.Po"; else rm -f ".deps/state.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --para then mv -f ".deps/upsconf.Tpo" ".deps/upsconf.Po"; else rm -f ".deps/upsconf.Tpo"; exit 1; fi if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOU then mv -f ".deps/parseconf.Tpo" ".deps/parseconf.Plo"; else rm -f ".deps/parseconf.Tpo"; exit 1; fi ../libtool: line 813: X--tag=CC: command not found ../libtool: line 846: libtool: ignoring unknown tag : command not found ../libtool: line 813: X--mode=compile: command not found ../libtool: line 979: *** Warning: inferring the mode of operation is deprecated.: command not found ../libtool: line 980: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../libtool: line 1123: Xgcc: command not found ../libtool: line 1123: X-DHAVE_CONFIG_H: command not found ../libtool: line 1123: X-I.: command not found ../libtool: line 1123: X-I.: command not found ../libtool: line 1123: X-I../include: No such file or directory ../libtool: line 1123: X-I../include: No such file or directory ../libtool: line 1123: X-O2: command not found ../libtool: line 1123: X-g: command not found ../libtool: line 1123: X-pipe: command not found ../libtool: line 1123: X-Wall: command not found ../libtool: line 1123: X-Wp,-D_FORTIFY_SOURCE=2: command not found ../libtool: line 1123: X-fexceptions: command not found ../libtool: line 1123: X-fstack-protector: command not found OK, it seems that it needs re-libtoolizing with native libtool, because libtool is to old: [zyv at servinet nut-2.4.3]$ libtoolize --force --copy You should update your `aclocal.m4' by running aclocal. Fine, I run aclocal and relibtoolize. This time is says nothing, but compilation gives the same error as above. Now I'm stuck! Please help. P.S. Also, I'm getting the following warning: configure: WARNING: unrecognized options: --with-linux-hiddev Does anybody have a clue what happened to this option? Thanks! -- Sincerely yours, Yury V. Zaytsev
Yury V. Zaytsev
2010-Feb-26 08:50 UTC
[Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
On Fri, 2010-02-26 at 09:26 +0300, Anton Gorlov wrote:> > As surprising as it might seem, I did read ./configure --help, which > > says this to be exact: > > --with-gd-libs=LDFLAGS linker flags for the gd library > > ${LDFLAGS} != ${LIBS}Would you please elaborate? Thanks! -- Sincerely yours, Yury V. Zaytsev
Yury V. Zaytsev
2010-Feb-26 09:52 UTC
[Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi! It seems that the previous RHEL / Fedora maintainers just wiped out nut_check_libhal.m4 completely to replace it with HAL_CALLOUTS_PATH="${libexecdir}" HAL_FDI_PATH="${datadir}/hal/fdi/information/20thirdparty" and did autoreconf in the SPEC. We can no longer do this, because autoconf that it shipped with RHEL is too old. The options are to find out the reason why it fails, do autoreconf on another machine to make a patch or move files manually in the SPEC. On my host [buildbot at servinet libexec]$ pkg-config --silence-errors --variable=libexecdir hal returns nothing, but [zyv at servinet ~]$ if (test -d "/usr/lib64/hal"); then echo 1; fi 1 [zyv at servinet ~]$ if (test -d "/usr/libexec"); then echo 1; fi 1 So apparently Debian line takes precedence over the Redhat line (which turns out to be useless). The next test for OpenSuse, by the way, will only work on 32-bit platforms, because the lib path is hardcoded and apparently will fail anyway, because they do have /usr/libexec. Therefore, I suspect that the detection logic in nut_check_libhal.m4 is broken. Is it indeed the case or I have to read some magic files for enlightenment? I would suggest to swap the order of Debian and Redhat lines and for Redhat check against the existence of /etc/redhat-release which is guaranteed to be there on all RH distributions. I am no Suse or Debian expert. -- Sincerely yours, Yury V. Zaytsev On Thu, 2010-02-25 at 19:18 +0100, Yury V. Zaytsev wrote:> Hi! > > Is there any particular reason why NUT installs hal addons to > > /usr/lib64/hal/hald-addon-bcmxcp_usb > /usr/lib64/hal/hald-addon-megatec_usb > /usr/lib64/hal/hald-addon-tripplite_usb > /usr/lib64/hal/hald-addon-usbhid-ups > > Instead of /usr/libexec/hald-addon-* where they should actually be > placed on RHEL systems? > > Is there a way to change this behavior with a ./configure option? >
Yury V. Zaytsev
2010-Feb-26 13:24 UTC
[Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi! This is the expanded configure line as set by the %configure script: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-user=nut --with-group=uucp --with-statepath=/var/run/nut --with-pidpath=/var/run/nut --with-altpidpath=/var/run/nut --sysconfdir=/etc/ups --with-cgipath=/var/www/nut-cgi-bin --with-drvpath=/sbin --with-all --with-ipv6 --with-pkgconfig-dir=/usr/lib64/pkgconfig --disable-static As you can see, I am doing it exactly the correct way around: --libdir=/usr/lib64 --libexecdir=/usr/libexec How is this possible, assuming your messages are correct? config.log: http://paste.ubuntu.com/384374/ Note this: configure:7803: checking for libhal Callouts path configure:7814: result: /usr/lib64/hal Shockingly, line 7814 is <------><------><------><------># For Debian <------><------><------><------>HAL_CALLOUTS_PATH="${libdir}/hal" <------><------><------><------>{ $as_echo "$as_me:${as_lineno-$LINENO}: result: ${HAL_CALLOUTS_PATH}" >&5 $as_echo "${HAL_CALLOUTS_PATH}" >&6; } Nonsense? -- Sincerely yours, Yury V. Zaytsev
On Thu, Feb 25, 2010 at 7:44 AM, Yury V. Zaytsev <yury at shurup.com> wrote:> Hi! > > Please find a trivial documentation patch attached.Commited as r2395. Thanks for pointing this out! -- - Charles Lepple