similar to: r1515 - branches/trunk-make-package: anybody interested in taking over?

> ---------- Forwarded message ---------- > From: Arjen de Korte > To: nut-commits at lists.alioth.debian.org > Date: Mon, 27 Aug 2007 18:33:00 +0000 > Subject: svn commit r1076 - in trunk: . drivers > Author: adkorte-guest > Date: Mon Aug 27 18:33:00 2007 > New Revision: 1076 > > Log: > * drivers/libhid.[ch],libshut.[ch],libusb.[ch]: > - Cut the libshut and

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

Arnaud, this commit refers to files called libshut.c and libshut.h, yet no such file has been added to SVN. Perhaps take this opportunity to run "svn status" and check for other files that might be missing from SVN. -- Peter > ---------- Forwarded message ---------- > From: Arnaud Quette > To: nut-commits@lists.alioth.debian.org > Date: Fri, 16 Jun 2006 13:40:59 +0000

Citeren clepple+buildbot op ghz.cc: > The Buildbot has detected a new failure of FreeBSD-i686. > Full details are available at: > http://buildbot.ghz.cc/public/nut/FreeBSD-i686/builds/35 Charles, It seems that m4/nut_check_libhal.m4 fails to detect the proper path where to install the .fdi files. I have no idea where these files live on FreeBSD, so could you please find out what

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:

Description: Fix warning: variable set but not used [-Wunused-but-set-variable]. bugs.debian.org/633756. Related drivers were not tested. Last-Update: Sat, 13 Aug 2011 14:04:48 +0300 Index: b/drivers/belkinunv.c =================================================================== --- a/drivers/belkinunv.c 2011-05-31 13:36:49.000000000 +0300 +++ b/drivers/belkinunv.c

Hello Panagiotis 2015-04-01 16:28 GMT+02:00 Panagiotis Kritikakos < panagiotis.kritikakos at nikitec.gr>: > Hello all, > > OS name: FreeNAS 9.3 > NUT version: 2.7.2 > NUT installed method: Bundled with FreenNAS 9.3 > Device: EATON 5SC 1000 (http://powerquality.eaton. > com/Products-services/Backup-Power-UPS/5SC.aspx?cx=5& >

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

Hello Arno, Thanks for the quick reply. FreeNAS is FreeBSD-based. Yes, I could test a patch. As I have mentioned, this behavior is not seen at every single reboot but after most reboots. Also, some times, the connectivity can be lost without even rebooting. That is not very often can have happened a few times. Best regards, Panagiotis On 2/4/2015 5:44 ??, Arnaud Quette wrote: > Hello

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

FWIW, there is precedent with libusb{1,0}, libshut and libhid which abstract NUT operations from a "backend lib" to build against; similar for serial.c used by many drivers. Take care to not conflict by filenames with "real" third-party libs used by the build - especially to avoid mixups for headers and in docs/discussion. Jim On Thu, Feb 23, 2023, 22:16 MODRIS B?RZONIS

Dear LLVMdev, I've noticed an unusual behavior of the LLVM x86 code generator (with default options) that results in nearly a 4x slow-down in floating-point throughput for my microbenchmark. I've written a compute-intensive microbenchmark to approach theoretical peak throughput of the target processor by issuing a large number of independent floating-point multiplies. The distance

Sorry about the noise guys. Below a significantly improved patch. The main difference is that all calls to usb_get_string_.. have been wrapped in a new function nut_usb_get_string()  that is implemented in libusb.c This was necessary in order to make the bufflen_fix available in libusb.c where usb_get_string() is called in libusb_open() This wrapper function mops up and hides all the work

(Is this the right list for libao patches?) The following adds support for a sndio plugin to libao. sndio is OpenBSD's new audio API. diff -uNrp libao-0.8.8.orig/configure.ac libao-0.8.8/configure.ac --- libao-0.8.8.orig/configure.ac Thu May 24 12:51:05 2007 +++ libao-0.8.8/configure.ac Mon Dec 8 16:34:44 2008 @@ -300,6 +300,11 @@ dnl Check for Sun audio AC_CHECK_HEADERS(sys/audioio.h)

Hello Panagiotis 2015-04-03 14:28 GMT+02:00 Panagiotis Kritikakos < panagiotis.kritikakos at nikitec.gr>: > Hello Arno, > > Question: have you also tested oldmge-shut? >> Otherwise, that might be interesting to do so and send back the results >> of these tests... >> > Yes, I've tried this as well with worse results unfortunately. This driver > seems to

I get the following error on r809 (but it looks like the code change happened here). Does HIDDevice_t need to be defined/changed in one of the headers? if gcc -DHAVE_CONFIG_H -I. -I../../drivers -I../include -I../../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I.

Defaults to disabled --- .gitignore | 2 + acinclude.m4 | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 4 +++ shave-libtool.in | 69 +++++++++++++++++++++++++++++++++++++++++++++++ shave.in | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 231 insertions(+), 0 deletions(-) create mode 100644 acinclude.m4

Hi Panagiotis 2015-04-06 9:13 GMT+02:00 Panagiotis Kritikakos < panagiotis.kritikakos at nikitec.gr>: > Hello Arno, > > Can apply the patch directly or should I recompile nut? > not sure to fully understand your comment, but... this is a source code patch, so you indeed have to apply it to the NUT source code (from within the source tree, "patch -p1 <

Hello Arno, Can apply the patch directly or should I recompile nut? Best regards, Panagiotis On 3/4/2015 5:06 ??, Arnaud Quette wrote: > Hello Panagiotis > > 2015-04-03 14:28 GMT+02:00 Panagiotis Kritikakos > <panagiotis.kritikakos at nikitec.gr > <mailto:panagiotis.kritikakos at nikitec.gr>>: > > Hello Arno, > > Question: have you also

Hello Arno, FreeNAS doesn't come with a compiler and I had to compile with the patch on FreebBSD-9.3 and then copy the produced mge-shut. Unfortunately it didn't work out. For every try I was getting "Connection Refused" and when I tried /usr/local/libexec/nut/mge-shut -D -a <ups_name> I was always getting 'No matching HID UPS found'. I returned back to the