similar to: Testing recommend, make Install error Digest, Vol 116, Issue 10

Hi Charles, I forgot add attaches.[?] I try to do from a new clean installations after reset my server (some changes need it), and now the make install seems to works. Now i going to configure and test it. I attached the logs files from the last run. If i have any other problem I write to the list. Thanks a lot for your help. Have a good day. 2015-02-13 17:45 GMT-06:00 Charles Lepple

Hi, Thanks for help. - I download the last version of NUT, 2.7.2.6 - I install library: nss-devel gcc-c++ So now I didn't get last errors on make. But I get a new one when I try to do - make install --------------------------- *[root at artesano nut-2.7.2.6]# make install* Making install in include make[1]: Entering directory `/home/artesano/Downloads/nut-2.7.2.6/include'

I upgraded an operating system to openSUSE 42.2, kernel 4.4 and recompiled nut 2.7.4. ./configure, make clean and make went well, but make install failed. Make reports Making install in clients make[1]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' make[2]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' /usr/bin/mkdir -p '/usr/lib64'

On 04/04/17 15.19, Arnaud Quette wrote: > > > 2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendtsen at jonix.dk > <mailto:jon.bendtsen at jonix.dk>>: [cuuuuut] > > there is a Github issue: https://github.com/networkupstools/nut/issues/415 > + a branch with the implementation: > https://github.com/networkupstools/nut/tree/upsmon_alarm > > For now: > -

2015-07-06 10:40 GMT+02:00 Sergey Talchuk <tals1975 at gmail.com>: > Dear developers, > > libnutclient has been added as a C++ alternative to libupsclient in 2.7.1. > As a result I can't compile nut 2.7.3 with gcc-3.3.6. There wasn't such a > problem with nut-2.6.5. > > Is it possible to add a configuration parameter like > '-without-libnutclient' to

On Jul 6, 2015, at 4:40 AM, Sergey Talchuk wrote: > Dear developers, > > libnutclient has been added as a C++ alternative to libupsclient in 2.7.1. As a result I can't compile nut 2.7.3 with gcc-3.3.6. What does the error message look like? Does the configure script fail when checking for the C++ compiler, or later on? > There wasn't such a problem with nut-2.6.5. > >

Dear developers, libnutclient has been added as a C++ alternative to libupsclient in 2.7.1. As a result I can't compile nut 2.7.3 with gcc-3.3.6. There wasn't such a problem with nut-2.6.5. Is it possible to add a configuration parameter like '-without-libnutclient' to provide better compatibility with older gcc versions please (since libnutclient is an alternative to

Dear developers, libnutclient has been added as a C++ alternative to libupsclient in 2.7.1. As a result I can't compile nut 2.7.3 with gcc-3.3.6. There wasn't such a problem with nut-2.6.5. Is it possible to add a configuration parameter like '-without-libnutclient' to provide better compatibility with older gcc versions please (since libnutclient is an alternative to

Hi Charles, Thanks for the prompt reply! Errors occur when execute make: /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF $depbase.Tpo -c -o nutclient.lo nutclient.cpp &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF .deps/nutclient.Tpo -c

Hello all, I come back to request comments (and merge) on my pull request of the libnutclient. https://github.com/clepple/nut/pull/2 All previous comments have been addressed (some fixes and documentation). For memory, the libnutclient is an high-level C++ and C client library allowing to dialog with upsd. The addressed model is oriented around devices, variables and commands; unlike

[I took the liberty of replying on nut-upsdev - not many people are using github yet since the NUT repository native format is still SVN.] On Sep 4, 2012, at 10:17 AM, Emilien Kia wrote: > This is a proposal for a new client library which scopes an higher level than the existing libupsclient. > > It needs less dependencies to be compiled than the libupsclient and can be easier to

Hi, I need help because I can't install Nut in RedHat EL 6.6 The version of Nut in repository ot RHEL is 2.6.5-2, but doesn't suppor my UPS, Liebert GXT3-200RT. I read that it is supported using Nut version 2.7.2, but I looking all around the web how to install it in my RedHat but I didn't find answers. Follow the guide, I can downlad lasted version stable on web: 2.7.2 Here the

2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendtsen at jonix.dk>: > On 04/04/17 14.10, Roger Price wrote: > >> On Tue, 4 Apr 2017, Arnaud Quette wrote: >> >> > [cuuuuut] > > Hi Arnaud, It seems to me that, looking out into the future, there are >> three >> things upsmon needs: >> >> 1. A fall-through <notify type> of

?Hello everybody, just a few notes to the doxygen X man issue: 1/ AFAIK doxygen can generate man pages, so why don't we just generate them and decide then whether they are ill fitted or usable... 2/ I'd definitely use doxygen when possible; I mean I don't know any alternative that's able to do (at least partial) validation of the documentation with the source 3/ I

Hi, when building with the WITH_DEV conditional, either `libupsclient.pc' *or* `libupsclient-config' is installed. This is annoying when linking with libupsclient, because you basically have to do the check twice, once using `pkg-config' and once using `libupsclient-config'. Please consider the attached patch, which changes the behavior of `lib/Makefile.am' to install

Dear Stanislav, thanks for your patch. The problem with your "recommended" pkgconfigdir is that in many cases, it does not work. Namely, when ${prefix} is not one of the standard places such as /usr. As I understand it, the whole point of a tool like pkgconfig is to allow other software to automatically detect the install location of NUT, especially when that location is not one of

Hi, Made a test build of the Testing branch. The problem is that upsmon and upsc is not respecting the revision change of libupsclient.so. It is now libupsclient.so.1, but i get this. /usr/sbin/upsmon: error while loading shared libraries: libupsclient.so.0: cannot open shared object file: No such file or directory and: upsc: error while loading shared libraries: libupsclient.so.0: cannot

Hi Charles, Yes, it looks like my g++ does contain STL library which might be just my specific case... However, as a temporary solution I disabled nutclient in Makefile (please find the file attached). And nut-2.7.3 can be compiled now. Thanks, Sergey On Wed, Jul 8, 2015 at 4:13 AM, Charles Lepple <clepple at gmail.com> wrote: > On Jul 6, 2015, at 10:32 AM, Sergey Talchuk

I have been trying to get Nut working on a system with Fedora 8 i86_64 installed and an APC Smart-UPS USB. The 2.2.0 rpm does not seem to like the USB on this UPS. I have tried compiling the 2.2.2 version, from source, but am getting warnings. I have tried building it on my i386 system (f8 as well) and I get no warnings also the 2.2.0 works fine on that one with a TrippLite Omni 900 LCD via

Arnaud, We've stumbled on a regression in nut-2.2.1 (also in nut-2.2.2-pre2) with regards to Tripplite USB devices. It turns out these devices will always indicate they have data available on the interrupt pipeline, no matter what. So we must limit the number of input reports we process to a single one in upsdrv_updateinfo() and leave any remaining ones to the next call in order to prevent