similar to: NUT-NG (was: ideas for a new UPS infrastructure)

Stanislav Brabec wrote: > Please note that 2.2.2-pre3 installs hald addons by default to / on > openSUSE 11.0 beta 2 x86_64. Not a big problem. Here is a patch, which fixes openSUSE 11.0 beta 2 x86_64: --- m4/nut_check_libhal.m4 +++ m4/nut_check_libhal.m4 @@ -63,7 +63,7 @@ dnl As per HAL spec, ?5 Callouts and ?2 Device Information Files dnl - addon install path: $libdir/hal

Stan, I'm very pleased to see you back to work with us on enhancing nut in that many areas ;-) 2008/4/30 Stanislav Brabec <sbrabec at suse.cz>: > Stanislav Brabec wrote: > > > Please note that 2.2.2-pre3 installs hald addons by default to / on > > openSUSE 11.0 beta 2 x86_64. Not a big problem. > > Here is a patch, which fixes openSUSE 11.0 beta 2 x86_64:

Hi David and fellows, I'm reviving this important thread about a common power management. To sum up, the first aim is to allow a better user experience on Linux by bridging NUT with Linux HAL, and Gnome Power Management / any PM GUI. But it also initiate a bigger investigation about how to integrate NUT support for UPSs into the native OS Power Management infrastructure for all supported

Citeren Charles Lepple <clepple at gmail.com>: >> Another thing, loosely related to this, is how we are going to deal with the >> 'generic' VID:PID combinations in some of the USB drivers, for example the >> megatec_usb and (new) blazer_usb drivers. At present, in the megatec_usb >> driver we have several VID:PID combinations for USB-to-serial converters

On Wed, Dec 3, 2008 at 4:05 PM, Arjen de Korte <nut+devel at de-korte.org> wrote: > Citeren Charles Lepple <clepple at gmail.com>: > >> Note that this is the same VID/PID as on this example on the Lakeview >> Research home page: >> >> http://www.lvr.com/usb_on_a_budget.htm >> >> We can include the name "Lakeview Research" in the

nut hardcodes systemdsystemshutdowndir to ${libdir}/systemd/system-shutdown. This is not valid: - Executable helpers are installed to ${libexecdir}, which is different from ${libdir} on bi-arch systems. - Even if nut will use ${libexecdir}, it could be different from systemd libexecdir. That is why it is better to check systemd.pc for the correct path. That path is stored as systemdutildir.

Ladies and Gentlemen, I have been playing around with Arnaud's new HAL stuff a bit, and have some questions and observations. First my configuration: my UPS (Peter may remember): ups.mfr: APC ups.model: Back-UPS ES 650 ups.productid: 0002 ups.firmware: 818.w1.D ups.firmware.aux: w1 kernel: 2.6.18-92.1.6.el5 hal-0.5.8.1-35.el5, nut based on nut-2.2.2.tar.gz, small changes to

Hi, I was fooling around with the bcmxcp driver and enabling the alarm functions. I hade tested this on some of the ups'es so I was planning to submit it to the svn trunk. But, as the bcmxcp is shared code for serial and usb I got a problem. When enabling --with-hal it halt on the build of hald-addon-bcmxcp_usb. -------------------------------------------------------------- gcc

On Feb 1, 2008 6:11 PM, Arnaud Quette <aquette at alioth.debian.org> wrote: > Author: aquette > Date: Fri Feb 1 23:11:33 2008 > New Revision: 1264 > > Log: > fix HAL support installation [Alioth Bug #304156] Arnaud, I tried to fix some of the errors that I was seeing in buildbot, but I still get the following error on "make distcheck", and I don't know how

On 5/23/07, Kjell Claesson <keyson-guest at alioth.debian.org> wrote: > Author: keyson-guest > Date: Wed May 23 21:12:51 2007 > New Revision: 915 > > Log: > - Enabled requested Alarm function in bcmxcp.c > > Modified: > trunk/ChangeLog > trunk/drivers/bcmxcp.c Looks like this breaks when HAL is enabled. At the end of:

Hi fellows, I'm really pleased to announce that a first stage of NUT and HAL [1] integration has been reached: NUT drivers (in fact, only newhidups, tripplite_usb and bcmxcp_usb for the moment) can feed HAL data. It's a "quick and dirty" hack, as a proof of concept, and there is still lots of things to be done, both on NUT and HAL sides. But it's a good base, and very

Hi Jordi, 2008/7/7 Jordi Mallach <jordi at debian.org>: > Package: nut > Version: 2.2.2-3 > Severity: important > > Hi Arnaud, > > I just tried backporting nut 2.2.2 to etch, and found the build fails > with: > > x86_64-linux-gnu-gcc -I../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include

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

I bought a new CyberPower CP850AVRLCD ups, connected it to a usb port and I'm trying to use it with hal. I installed [root at phoenix ~]# rpm -q nut nut-client nut-2.2.0-6.1.fc8 nut-client-2.2.0-6.1.fc8 lsusb sees it: [root at phoenix docs]# lsusb Bus 001 Device 001: ID 0000:0000 Bus 005 Device 002: ID 0c45:1050 Microdia Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000

On Nov 11, 2016, at 1:01 PM, Stuart Gathman wrote: > > I've tried several recipes found with google, but hal likes to grab the > USB ups before nut can get it. > There are a number of klugey workarounds, like turn off port power until > ready to start nut (so that hal doesn't see the UPS). Or > killall hal-addon-hid-ups before starting nut. Minor nit, but for anyone

Hi, today I updated the glibc packages on some CentOS machines. After the Update I checked which services/processes I have to restart "yum -C ps" or "needs-restarting" At the most machines I get no information about necessary restarts, but at two machines a long listing : 1 : /sbin/init 386 : /sbin/udevd-d 659 : /sbin/udevd-d 999 : /usr/sbin/vmtoolsd 1103 : auditd 1128 :

Hallo. Here is a simplification of the automake stuff for nut 2.2.2. The idea is simple: libcommon.a contains stuff for the binaries libparseconf.la contains stuff for binaries and shared library Both are NOINST, automake understands perfectly our intentions. The rest is only a removal of the implicitly defined stuff. On top of the parallel build patch I got build success on all platforms

Hi fellows, As the NUT-NG draft will take me more time than I currently have (I found myself too optimistic since I got a baby ;-), below is the beginning of an answer to the "Common Power Management with UPS support" problem... First, NUT is pure userspace code, for portability issue, and will remain. USB is through libusb, snmp through net-snmp and serial through standard read/write.

I have Cent OS 5.1 I also have http://phpsysinfo.sourceforge.net/ I have asterisk running . Now when I look at System Information , I see that "Physical Memory" keep increasing and at one point it reaches 96%. Then my sever get hang and then I have to restart it. I have 4 GB RAM. Processors 2 Model Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz CPU Speed 2.53 GHz Cache Size 3.00 MB

Hi All, I've been trying to trace the cause of a hang on a 5.6 i386 system. After running for almost a year, it hung last week, when I plugged in a screen it was blank, machine was unresponsive to the keyboard, over the network ssh and other daemons didn't respond but the thing has two network cards and routing from one to the other was still working. So the kernel was up and I