similar to: Bug#439986: Renaming `UPSCONN' to `UPSCONN_t' causes problems when upgrading.

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

Tags: patch, upstream Hi, when configuring nut 2.2.0 the variable/symbol `@SSL_LDFLAGS@' is not resolved by the libupsclient-config script. The attached patch changes `@SSL_CFLAGS@' to `@LIBSSL_CFLAGS@' `@SSL_LDFLAGS@' to `@LIBSSL_LDFLAGS@' which should solve this issue. Regards, -octo -- Florian octo Forster Hacker in training GnuPG: 0x91523C3D http://verplant.org/

On Tue, Nov 13, 2018 at 10:04:33AM +0000, Daniel P. Berrangé wrote: > On Fri, Nov 09, 2018 at 12:19:30PM +0000, Richard W.M. Jones wrote: > > Peter Dimitrov and myself were debugging a very peculiar bug when > > libguestfs is run as a plugin from collectd: > > > > https://www.redhat.com/archives/libguestfs/2018-November/thread.html#00023 > > > > The long

[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

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, I've stumbled upon a problem which I can't solve easily with the available options in tinc - at least as far as I see. If enlightenment is all I need, I'll happily accept pointers ;) I try to establish a connection between two hosts. Each host has multiple addresses assigned to it's internet interface. A stripped down list would be: Host 1: 2001:780:0:1e::1

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

Hi, thank you very much for reporting this! Sounds like a bug in the exec plugin – it never ceases to amaze me how many issues a single plugin can have ;) > > > This means that any plugin that does the usual pattern of: > > > > > > pid = fork (); Note that the exec plugin is the *only* plugin that does this. All other plugins are forbidden to fork(), popen() or

If running without `--net', the (global) variable `netname' is NULL. This creates a segmentation fault because this NULL-pointer is passed to strdup: Program terminated with signal 11, Segmentation fault. #0 0xb7d30463 in strlen () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7d30463 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d30175 in strdup () from

Dear LLVMer ; i'm trying to use LLVM for a specific target, using different memory banks. I have written the frontend to generate a valid IR and want to use the existing passes (as defined in tool opt) to optimize the code. The target has specific instructions, so following advices given in documentation, I created an intrinsic function, with attribute [IntrReadArgMem]. My test case is

I use the NUT RPM package for CentOS 6.7, which is version 2.6.5-2. I am testing implementation of NUT features with APC and Tripp-Lite USB UPS interfaces. Things are going reasonably well. However, I'm seeing many more messages than I would like in /var/log/messages when I boot the system without the UPS connected. I have configured NOCOMMWARNTIME 3600, which takes care to only broadcast

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'

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'

The downsides of an additional project are small. I can see: 1) It's not possible to do pull requests from there, because GitHub won't treat it as a fork. 2) It's still visible to people ( http://lists.llvm.org/pipermail/llvm-dev/2020-June/142559.html) In the end I don't have a strong opinion on whether this is a branch or a repository, as long as we move ahead soon. On Thu, Jul

As noted in the other thread, making a new repository under the same user, which therefore must be unrelated to the original, seems to have downsides as far as commit duplication on github. Probably the downsides of that are non-critical (and less bad than a bunch of email spam), but it's still unfortunate. It still very much feels to me that the best answer should be to do none of the above,

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

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

On Thu, Dec 4, 2008 at 7:38 AM, Julien Schmitt <jschmitt at dibcom.fr> wrote: > Dear LLVMer ; > > i'm trying to use LLVM for a specific target, using different memory banks. > I have written the frontend to generate a valid IR and want to use the > existing passes (as defined in tool opt) to optimize the code. > > The target has specific instructions, so following

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