Re: [Nut-upsuser] Network UPS Tools version 2.2.2-pre2 released
2008/4/21, Arjen de Korte [EMAIL PROTECTED]: Arnaud Quette wrote: No, and that's because I doubt that openSUSE will follow this approach. Historically, there hasn't been too much interest in splitting packages, since SuSE (now openSUSE) attempts to create a working configuration out of the box. Therefor, it made little sense to split these packages up as they all needed to be installed anyway. that's indeed what I saw. Even installing the CGI in the bare install! Yes. Although the disadvantages of following this approach are clear (dependencies for stuff that isn't actually used), I don't think this is too bad. Most desktop systems will have many of these things installed already (possibly with the exception of the net-snmp library), so the only thing you're gaining is maybe a few MB of hard-disk space, which is too cheap to really worry about. If you're looking at configuring a tightly controlled server where you don't want anything installed that isn't actually needed, you won't be installing openSUSE anyway (which is mainly aimed at the desktop). well, that's the biggest problematic of packaging. none of the solutions are perfect, and both have big pros and cons. there are still many rooms for improvement there... Arnaud -- Linux / Unix Expert RD - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3
Hi Roger 2008/4/21, Roger Price [EMAIL PROTECTED]: On Mon, 21 Apr 2008, Roger Price wrote: On Mon, 21 Apr 2008, Arnaud Quette wrote: A source RPM for SuSE is also available, but I'm not sure it's x64 ready! http://opensource.mgeops.com/stable/sources/suse/ I had confused mgeups and mgeops. well, the whole *MGE* situation tends to make things blurry, even if you're an insider ;-) I downloaded the source rpm and ran the command script -c rpmbuild --rebuild /tmp/mgeops-psp-3.0.6-2.src.rpm /tmp/rpmbuild.log It ends with: checking for NUT... configure: error: Package requirements (libupsclient = 2.0.0) were not met: No package 'libupsclient' found Although not asked for, I installed nut-devel-2.2.2-pre2.x86_64.rpm and tried again; this time the build went further and found errors in eggstatusicon.c for example: eggstatusicon.c: In function 'egg_status_icon_get_is_blinking': eggstatusicon.c:795: error: 'EggStatusIconPrivate' has no member named 'blinking' You will find the full result at http://rogerprice.org/mgeops-psp-3.0.6/rpmbuild.log right. the API used is an old one, to have a wide platform support spectrum. You'll find a 3.0.7 archive here: http://opensource.mgeops.com/stable/sources/projects/psp/ - Retrieve the .bz2 - extract it, and get into the dir - call configure a first time to generate packaging/mgeops-psp-suse.spec - then /packaging/mgeops-psp-suse.spec to your SPEC dir, and the .bz2 to your SOURCES dir - then issue an rpmbuild -ba .../mgeops-psp-suse.spec Since I'm unsure about x64 support, feedback is welcome. Arnaud -- Linux / Unix Expert RD - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools version 2.2.2-pre2 released
well, that's the biggest problematic of packaging. none of the solutions are perfect, and both have big pros and cons. there are still many rooms for improvement there... Indeed. In the mean time, I have divided the main 'nut' package in the following sub packages: - nut (client applications) - nut-server (drivers and upsd server, requires 'nut') - nut-snmp (net-snmp based SNMP driver, requires 'nut-server') - nut-xml (neon based XML driver, requires 'nut-server') - nut-cgi (web interface, requires 'nut') - nut-hal (HAL drivers, conflicts with 'nut') - nut-devel (libupsclient library, requires 'nut' (?)) I think this should more or less suit most needs. I'll prepare an updated .src.rpm later today or tomorrow. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3
On Tue, 22 Apr 2008, Arnaud Quette wrote: right. the API used is an old one, to have a wide platform support spectrum. You'll find a 3.0.7 archive here: http://opensource.mgeops.com/stable/sources/projects/psp/ - Retrieve the .bz2 - extract it, and get into the dir - call configure a first time to generate packaging/mgeops-psp-suse.spec - then /packaging/mgeops-psp-suse.spec to your SPEC dir, and the .bz2 to your SOURCES dir - then issue an rpmbuild -ba .../mgeops-psp-suse.spec All went well until I typed the command script -c rpmbuild -ba /usr/src/packages/SPECS/mgeops-psp-suse.spec /tmp/mgeops-psp/rpmbuild.log which produced the message ../../libtool: line 1311: g++: command not found make[4]: *** [tray-icon.lo] Error 1 I loaded g++ which had not been asked for; it requires package gcc42-c++. The build then went much further, ending in /usr/lib64/libupsclient.so: undefined reference to `select_read' /usr/lib64/libupsclient.so: undefined reference to `select_write' collect2: ld returned 1 exit status make[3]: *** [psp] Error 1 make[3]: Leaving directory `/usr/src/packages/BUILD/mgeops-psp-3.0.7/src' See http://rogerprice.org/mgeops-psp-3.0.7/rpmbuild.log for the gory details. Best Regards, Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3
I loaded g++ which had not been asked for; it requires package gcc42-c++. The build then went much further, ending in /usr/lib64/libupsclient.so: undefined reference to `select_read' /usr/lib64/libupsclient.so: undefined reference to `select_write' collect2: ld returned 1 exit status make[3]: *** [psp] Error 1 make[3]: Leaving directory `/usr/src/packages/BUILD/mgeops-psp-3.0.7/src' Ooops. Those are references to the common/common.o which are obviously not available to external programs. We should put the select() in the library. Yet another reason for a -pre3 release. Thanks for this valuable input! :-) Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3
Roger Price wrote: On Tue, 22 Apr 2008, Arnaud Quette wrote: right. the API used is an old one, to have a wide platform support spectrum. You'll find a 3.0.7 archive here: http://opensource.mgeops.com/stable/sources/projects/psp/ - Retrieve the .bz2 - extract it, and get into the dir - call configure a first time to generate packaging/mgeops-psp-suse.spec - then /packaging/mgeops-psp-suse.spec to your SPEC dir, and the .bz2 to your SOURCES dir - then issue an rpmbuild -ba .../mgeops-psp-suse.spec All went well until I typed the command script -c rpmbuild -ba /usr/src/packages/SPECS/mgeops-psp-suse.spec /tmp/mgeops-psp/rpmbuild.log which produced the message ../../libtool: line 1311: g++: command not found make[4]: *** [tray-icon.lo] Error 1 I loaded g++ which had not been asked for; it requires package gcc42-c++. I'd say that the correct package is gcc-c++ http://ftp.iasi.roedu.net/mirrors/opensuse.org/distribution/openSUSE-stable/repo/oss/suse/i586/gcc-c++-4.2-24.i586.rpm ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3
2008/4/21, Arjen de Korte [EMAIL PROTECTED]: Arnaud Quette wrote: There is no /var/state in openSUSE 10.3, so I changed PIPEFN and LOCKFN to /var/run and defined directory /var/run/ups. We need a pre3 to fix this since this has been a long standing bug. This path is hardcoded in the example configuration, where running ./configure should set this path properly. In fact, Charles fixed this in the trunk, but apparently we didn't backport the fix to Testing. Good catch! +1 -1 We already backported this to testing in r1163 or something. After digging deeper into this it turned out that Roger was using an older configuration file from an earlier (before we fixed this) configuration. The new one *was* installed (so the .spec file can't be blamed either), but with the .rpmnew extension, since he upgraded his configuration. fine Where we might have an issue, is in 'data/html/header.html.in'. It hardcodes the path to the CGI files. though I've created the .in to deal with these paths, the instructions I've put in data/html/README state that one should install the NUT cgi in a cgi-bin directory, pointed as such in the webserver directives (ie ScriptAlias /cgi-bin/ /some-path-to-nut-cgi/cgi-bin/) but I'm thinking about adding a template apache file to declare nut things, and be able to put it in the sites-available directory. Though this is pure apache, and there are many other webservers in the land (lighttpd for example) Arnaud -- Linux / Unix Expert RD - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools version 2.2.2-pre2 released
2008/4/22, Arjen de Korte [EMAIL PROTECTED]: well, that's the biggest problematic of packaging. none of the solutions are perfect, and both have big pros and cons. there are still many rooms for improvement there... Indeed. In the mean time, I have divided the main 'nut' package in the following sub packages: - nut (client applications) - nut-server (drivers and upsd server, requires 'nut') - nut-snmp (net-snmp based SNMP driver, requires 'nut-server') - nut-xml (neon based XML driver, requires 'nut-server') - nut-cgi (web interface, requires 'nut') - nut-hal (HAL drivers, conflicts with 'nut') - nut-devel (libupsclient library, requires 'nut' (?)) I think this should more or less suit most needs. I'll prepare an updated .src.rpm later today or tomorrow. great! Any news from Stan btw? A side note on nut and nut-server: I've thought about that in the past, and come to the conclusion that nut should be a meta package (either depending upon nut-client + nut-server, or asking (like with debconf) for the flavor to be installed ; ie classic standalone|client, hal, ...). Then you have nut-client, nut-server, ... I also come to the conclusion that we won't be able to have a uniform implementation (ie the same packages split) on all supported systems. But we should: - provide advices and shared resources (packages descriptions, translations, LSB init scripts, ...). That will still be addressed by the NUT Packaging Standard - provide the needed helpers to deal with these differences and the needs of config / client UI. So an upsconfig library should provide functions to query the various paths, user/group, ... I'm also updating the debs on my side, both merging the last official one for -pre3 and updating these (adds the nut-xml package) Arnaud -- Linux / Unix Expert RD - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools version 2.2.2-pre2 released
Arnaud Quette wrote: In the mean time, I have divided the main 'nut' package in the following sub packages: - nut (client applications) - nut-server (drivers and upsd server, requires 'nut') - nut-snmp (net-snmp based SNMP driver, requires 'nut-server') - nut-xml (neon based XML driver, requires 'nut-server') - nut-cgi (web interface, requires 'nut') - nut-hal (HAL drivers, conflicts with 'nut') - nut-devel (libupsclient library, requires 'nut' (?)) I think this should more or less suit most needs. I'll prepare an updated .src.rpm later today or tomorrow. great! Any news from Stan btw? No, not yet. I haven't asked him yet. I'm actually quite busy preparing for a two weeks leave. Our last holiday before Junior is born... :-) A side note on nut and nut-server: I've thought about that in the past, and come to the conclusion that nut should be a meta package (either depending upon nut-client + nut-server, or asking (like with debconf) for the flavor to be installed ; ie classic standalone|client, hal, ...). Then you have nut-client, nut-server, ... For the moment I made the split like it is. There is not much point in running anything NUT related without either the clients or HAL drivers, so the starting point is basically 'nut' or 'nut-hal'. The latter pretty much excludes 'nut-server', but you could run a client alongside it (I got my conflicts wrong there). Running a server without clients is useless most of the time (some bizarre configurations aside), so having 'nut' is a requirement. And lastly, the 'nut-snmp' and 'nut-xml' drivers are worthless without 'nut-server'. I also come to the conclusion that we won't be able to have a uniform implementation (ie the same packages split) on all supported systems. I'm afraid we won't. This shouldn't be too bad, provided we have list of people that run as many platforms that we know of. But we should: - provide advices and shared resources (packages descriptions, translations, LSB init scripts, ...). That will still be addressed by the NUT Packaging Standard - provide the needed helpers to deal with these differences and the needs of config / client UI. So an upsconfig library should provide functions to query the various paths, user/group, ... I'm also updating the debs on my side, both merging the last official one for -pre3 and updating these (adds the nut-xml package) Should I make one available for openSUSE as well (the version *we* like, not necessarily the one that is bundled by openSUSE?) Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp Lite OMNI1000 LCD issues
On Tue, Apr 22, 2008 at 11:15:27AM +0200, Arjen de Korte wrote:
Attached is approx 30 sec of output from the following command:
[...]
/* Get HID notifications on Interrupt pipe first */
/* TODO: cap number of times we check for events? */
while ((evtCount = HIDGetEvents(udev, event, MAX_EVENT_NUM)) 0) {
If you replace the 'while' with 'if', you'll probably be fine. Having said
that, it makes sense to upgrade to nut-2.2.2-pre2 as well (this has the
same bug), since that also fixed some other issues with the 'usbhid-ups'
driver.
I changed the 'while' to an 'if'.
I now responds to Ctl-C.
The socket is being created.
Nothing more to fix... now i'm bored ;-)
Thanks
--
John
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Liebert ITON 600 VA
Is there a chance to use NUT with a Liebert ITON 600 UPS? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
