On 06/24/2017 04:52 AM, Charles Lepple wrote:> On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti <ambrojohn at gmail.com> wrote: >> "This TrippLite device (09ae:1330) is not (or perhaps not yet) supported by usbhid-ups. [...]" >> but my device (SU2200RTXLCD2U) is supported, as clearly state here. > No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB PID other than 0001 is generally the protocol number. So your SU2200* model is different. > > https://github.com/networkupstools/nut/issues/64 > >> Then I thought I needed the last src code (2.7.4), hence I built it for my machine, but when I run it by: >> /usr/local/ups/sbin/upsdrvctl start > The Protocol 1330 support was added after 2.7.4 was released. You might be able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but voltages might be off by a factor of 10. You will also need to adjust the udev files manually to fix /dev/bus/usb permissions. > > If you do choose to build using the latest source code from Git, be aware that you will need more tools, as specified in the Developer Guide: http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building > > It may be easier to use the 2.7.4 tarball, and add the patch which introduces Protocol 1330 support to the RPM spec file: https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580I've uploaded to http://wolfy.fedorapeople.org/nut a new set of packages based on the latest source code from git. Unfortunately they do not include any man pages, I did not have time to find a workaround for the hard requirement of newer versions for the tools used by the build process to create the man pages. I will fix that in a later set of packages.
Charles Lepple
2017-Jun-24 13:37 UTC
[Nut-upsuser] man pages and asciidoc (was: Device not supported?)
On Jun 23, 2017, at 10:28 PM, Manuel Wolfshant wrote:> > Unfortunately they do not include any man pages, I did not have time to find a workaround for the hard requirement of newer versions for the tools used by the build process to create the man pages.You have mentioned the man pages several times, and I am slightly confused. If I grab a tarball from http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/master/nut-latest.tar.gz , the man pages are included. Are they not being installed if there is not a new-enough version of asciidoc available? Also, how much of a version mismatch are we talking about? I don't remember all of the errors in the older versions that led us to add the version checks to configure.ac, but we can certainly look into them. However, asciidoc is not difficult to upgrade. True, it has a lot of dependencies, but those dependencies apply equally to the earlier versions as well.
On 06/24/2017 04:37 PM, Charles Lepple wrote: Hi Charles. Thank you for looking into this !> On Jun 23, 2017, at 10:28 PM, Manuel Wolfshant wrote: >> Unfortunately they do not include any man pages, I did not have time to find a workaround for the hard requirement of newer versions for the tools used by the build process to create the man pages. > You have mentioned the man pages several times, and I am slightly confused. > > If I grab a tarball from http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/master/nut-latest.tar.gz , the man pages are included.Yes, it is true. My spec was originally based on https://github.com/networkupstools/nut/tree/libusb-1.0 and that one did not include man pages at all. Later I tried the tarball recommended by you ( and this is the one I will refer below ) and for some reason it also does "something" at build time prohibiting build even if perfect valid manpages ( that could be included as such ) are already included in the tarball> Are they not being installed if there is not a new-enough version of asciidoc available?Hellas yes, RHEL /CentOS 6 provide asciidoc-8.4.5 while nut seems to need a newer version. I tried to build a newer version and include it in my buildroot but I failed ( I do not remember what was needed and missing ) and O had not time to debug, I just postponed including the docs altogether Here is an excerpt of the build process. First the actual recipe: #BuildRequires: autoconf <==== explicitly do NOT include auto* in the buildroot #BuildRequires: automake %if %{includedocs} #BuildRequires: asciidoc # too old, gets rejected and breaks build if present BuildRequires: aspell BuildRequires: libxslt %endif %build #autoreconf -i # prevent assignment of default value, it would break configure's tests export LDFLAGS="-Wl,-z,now" #autogen.sh <=== notice how this is specifically disabled %configure \ --with-all \ --with-libltdl \ --with-cgi \ --datadir=%{_datadir}/%{name} \ --with-user=%{name} \ --with-group=dialout \ --with-statepath=%{piddir} \ --with-pidpath=%{piddir} \ --with-altpidpath=%{piddir} \ --sysconfdir=%{_sysconfdir}/ups \ --with-cgipath=%{cgidir} \ --with-drvpath=%{modeldir} \ --with-pkgconfig-dir=%{_libdir}/pkgconfig \ --disable-static \ --with-udev-dir=/lib/udev \ --libdir=%{_libdir} \ --with-doc # does not seem to work in 2.7.1& pre 2.7.5 %global _hardened_build 1 make %{?_smp_mflags} CFLAGS="%{optflags}" LDFLAGS="-Wl,-z,now, relro %{optflags}" and this is the output of configure ( mind that asciidoc , as I said , is explicitly not included in the build root as it terminates the build if present due to its version being lower than 8.6.3): checking whether to enable libltdl (Libtool dlopen abstraction) support... yes checking for gd version via gdlib-config... 2.0.34 found checking for gd include flags... -I/usr/include checking for gd library flags... -L/usr/lib64 -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm checking for gd.h... yes checking for gdfontmb.h... yes checking for library containing gdImagePng... -lgd checking whether to build CGI programs... yes checking for asciidoc... no checking for a2x... no checking for dblatex... no checking for xsltproc... /usr/bin/xsltproc checking for xsltproc version... 20706 found checking for xmllint... /usr/bin/xmllint checking for xmllint version... 20706 found checking for source-highlight... no checking for aspell... /usr/bin/aspell checking if asciidoc version can build manpages (minimum required 8.6.3)... no checking if a2x version can build manpages (minimum required 8.6.3)... no checking if xsltproc is present (mandatory for man page regeneration)... yes checking if xmllint is present (mandatory for man page regeneration)... yes checking if we have all the tools mandatory for man page regeneration... no checking if source-highlight is present (preferable for documentation generation)... no checking whether to build and install documentation... yes checking desire and ability to build man documentation... yes checking if we can build man... no configure: WARNING: Unable to build man documentation which you requested checking desire and ability to build html-single documentation... yes checking if asciidoc version can build html-single (minimum required 8.6.3)... no checking desire and ability to build html-chunked documentation... yes configure: WARNING: Unable to build html-single documentation which you requested checking if a2x version can build html-chunked (minimum required 8.6.3)... no checking desire and ability to build pdf documentation... yes configure: WARNING: Unable to build html-chunked documentation which you requested checking if dblatex version can build pdf (minimum required 0.2.5)... no configure: WARNING: Unable to build pdf documentation which you requested configure: error: Unable to build man html-single html-chunked pdf documentation (check for 'no' results above) error: Bad exit status from /var/tmp/rpm-tmp.gy5Lpj (%build) Bad exit status from /var/tmp/rpm-tmp.gy5Lpj (%build)> > Also, how much of a version mismatch are we talking about? I don't remember all of the errors in the older versions that led us to add the version checks to configure.ac, but we can certainly look into them. > > However, asciidoc is not difficult to upgrade. True, it has a lot of dependencies,For one, the Fedora ( & EPEL by matter of consequence ) kind of prohibit relying on tools from outside the distro ( + EPEL ) during build time ( yes, I know, let's not comment this as I cannot do anything ) which, in shorter words, make using updated packages kind of difficult ( that's an euphemism for almost impossible ). As a side note, this is the reason for the nut packages that I distributed being built on my personal build system rather than Fedora's and I did not sign them because I want to make obvious ( at least for those who can read :) ) that they are a personal effort not endorsed by anyone else or by any organization. For my personal builds ( which I shared.. ) I do include whatever I need when I can but in this case some dependency + lack of time prohibited me to do that. However, IF configure would not blindly bail out, I would happily include those man*.8 from the tarball's docs/man directory. Unfortunatelly in the output of ./configure --help I did not find anything useful for cherry picking the docs, all I have seen is: --with-docs build and install documentation (alias to --with-doc) (man=auto) --with-doc build and install documentation (${nut_with_docs})> but those dependencies apply equally to the earlier versions as well.I might be mistaken as I truly do not remember ( and I do not know where is the difference coming from ) but I am pretty sure that the earlier versions of nut ( 2.6.x ) did not bail out in configure. However there might be a change in the build recipe which led to this issue, my recipe for 2.7.x is adapted from RHEL 7
I've eventually installed Manuel's packages (nut and nut-client). When I run the driver as root (for my tripplite ups) I get: /usr/sbin/upsdrvctl start Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1) USB communication driver (libusb 0.1) 0.33 writepid: fopen /var/run/nut/usbhid-ups-trippliteups.pid: Permission denied Can't claim USB device [09ae:1330]: could not detach kernel driver from interface 0: Operation not permitted Driver failed to start (exit status=1) And I had to create manually /var/run/nut. What is the problem there? On Fri, Jun 23, 2017 at 8:27 PM Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:> On 06/24/2017 04:52 AM, Charles Lepple wrote: > > On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti <ambrojohn at gmail.com> > wrote: > >> "This TrippLite device (09ae:1330) is not (or perhaps not yet) > supported by usbhid-ups. [...]" > >> but my device (SU2200RTXLCD2U) is supported, as clearly state here. > > No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB PID > other than 0001 is generally the protocol number. So your SU2200* model is > different. > > > > https://github.com/networkupstools/nut/issues/64 > > > >> Then I thought I needed the last src code (2.7.4), hence I built it for > my machine, but when I run it by: > >> /usr/local/ups/sbin/upsdrvctl start > > The Protocol 1330 support was added after 2.7.4 was released. You might > be able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but > voltages might be off by a factor of 10. You will also need to adjust the > udev files manually to fix /dev/bus/usb permissions. > > > > If you do choose to build using the latest source code from Git, be > aware that you will need more tools, as specified in the Developer Guide: > http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building > > > > It may be easier to use the 2.7.4 tarball, and add the patch which > introduces Protocol 1330 support to the RPM spec file: > https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580 > I've uploaded to http://wolfy.fedorapeople.org/nut a new set of packages > based on the latest source code from git. Unfortunately they do not > include any man pages, I did not have time to find a workaround for the > hard requirement of newer versions for the tools used by the build > process to create the man pages. I will fix that in a later set of > packages. > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170705/a406f7f7/attachment.html>
>From section 4.23 of the Developer Guide:"There are a few USB UPS devices that are not HID devices. These devices typically implement some version of the manufacturer?s serial protocol over USB (which is a really dumb idea, by the way). An example is the Tripplite USB. Such devices are *not* supported by the usbhid-ups driver, and are not covered in this document." I guess that applies to me? On Wed, Jul 5, 2017 at 3:19 PM Ambrogio Coletti <ambrojohn at gmail.com> wrote:> I've eventually installed Manuel's packages (nut and nut-client). > > When I run the driver as root (for my tripplite ups) I get: > > /usr/sbin/upsdrvctl start > Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1) > USB communication driver (libusb 0.1) 0.33 > writepid: fopen /var/run/nut/usbhid-ups-trippliteups.pid: Permission denied > Can't claim USB device [09ae:1330]: could not detach kernel driver from > interface 0: Operation not permitted > Driver failed to start (exit status=1) > > And I had to create manually /var/run/nut. > > What is the problem there? > > On Fri, Jun 23, 2017 at 8:27 PM Manuel Wolfshant <wolfy at nobugconsulting.ro> > wrote: > >> On 06/24/2017 04:52 AM, Charles Lepple wrote: >> > On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti <ambrojohn at gmail.com> >> wrote: >> >> "This TrippLite device (09ae:1330) is not (or perhaps not yet) >> supported by usbhid-ups. [...]" >> >> but my device (SU2200RTXLCD2U) is supported, as clearly state here. >> > No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB PID >> other than 0001 is generally the protocol number. So your SU2200* model is >> different. >> > >> > https://github.com/networkupstools/nut/issues/64 >> > >> >> Then I thought I needed the last src code (2.7.4), hence I built it >> for my machine, but when I run it by: >> >> /usr/local/ups/sbin/upsdrvctl start >> > The Protocol 1330 support was added after 2.7.4 was released. You might >> be able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but >> voltages might be off by a factor of 10. You will also need to adjust the >> udev files manually to fix /dev/bus/usb permissions. >> > >> > If you do choose to build using the latest source code from Git, be >> aware that you will need more tools, as specified in the Developer Guide: >> http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building >> > >> > It may be easier to use the 2.7.4 tarball, and add the patch which >> introduces Protocol 1330 support to the RPM spec file: >> https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580 >> I've uploaded to http://wolfy.fedorapeople.org/nut a new set of packages >> based on the latest source code from git. Unfortunately they do not >> include any man pages, I did not have time to find a workaround for the >> hard requirement of newer versions for the tools used by the build >> process to create the man pages. I will fix that in a later set of >> packages. >> >> _______________________________________________ >> Nut-upsuser mailing list >> Nut-upsuser at lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170705/41db7bc9/attachment.html>
On 07/06/2017 12:19 AM, Ambrogio Coletti wrote:> I've eventually installed Manuel's packages (nut and nut-client). > > When I run the driver as root (for my tripplite ups) I get: > > /usr/sbin/upsdrvctl start > Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1) > USB communication driver (libusb 0.1) 0.33 > writepid: fopen /var/run/nut/usbhid-ups-trippliteups.pid: Permission > deniedthat is odd because nut-client should have created /var/run/nut/. If you run rpm -ql nut-client you will notice that /var/run/nut is listed in the very last line: [root at belgrade ~]# rpm -ql --qf "%{name}-%{version}-%{release}\n\n" nut-client nut-client-2.7.5-0.20170613gitb1314c6.el6.wolfy.usb01 (ignore the "usb01" tag, I added it for my personal reference since I built against various libusb versions) /etc/rc.d/init.d/ups /etc/ups /etc/ups/upsmon.conf /etc/ups/upssched.conf [...] /usr/share/pixmaps/nut-monitor.png /var/lib/ups /var/run/nut <============> Can't claim USB device [09ae:1330]: could not detach kernel driver > from interface 0: Operation not permittedThat's the error I get with one of my UPSes ( an Eaton ) as well. No solution so far for me.> Driver failed to start (exit status=1) > > And I had to create manually /var/run/nut. > > What is the problem there?I am really puzzled. Do you get any selinux related errors ( running aureport -ts today -a should list the AVCs if any )?> > On Fri, Jun 23, 2017 at 8:27 PM Manuel Wolfshant > <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote: > > On 06/24/2017 04:52 AM, Charles Lepple wrote: > > On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti > <ambrojohn at gmail.com <mailto:ambrojohn at gmail.com>> wrote: > >> "This TrippLite device (09ae:1330) is not (or perhaps not yet) > supported by usbhid-ups. [...]" > >> but my device (SU2200RTXLCD2U) is supported, as clearly state here. > > No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB > PID other than 0001 is generally the protocol number. So your > SU2200* model is different. > > > > https://github.com/networkupstools/nut/issues/64 > > > >> Then I thought I needed the last src code (2.7.4), hence I > built it for my machine, but when I run it by: > >> /usr/local/ups/sbin/upsdrvctl start > > The Protocol 1330 support was added after 2.7.4 was released. > You might be able to use a 2.7.4 tarball with "productid = 1330" > in ups.conf, but voltages might be off by a factor of 10. You will > also need to adjust the udev files manually to fix /dev/bus/usb > permissions. > > > > If you do choose to build using the latest source code from Git, > be aware that you will need more tools, as specified in the > Developer Guide: > http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building > > > > It may be easier to use the 2.7.4 tarball, and add the patch > which introduces Protocol 1330 support to the RPM spec file: > https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580 > I've uploaded to http://wolfy.fedorapeople.org/nut a new set of > packages > based on the latest source code from git. Unfortunately they do not > include any man pages, I did not have time to find a workaround > for the > hard requirement of newer versions for the tools used by the build > process to create the man pages. I will fix that in a later set of > packages. > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > <mailto:Nut-upsuser at lists.alioth.debian.org> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170706/cfceb6f3/attachment-0001.html>
On July 5, 2017 11:19:55 PM GMT+02:00, Ambrogio Coletti <ambrojohn at gmail.com> wrote:>I've eventually installed Manuel's packages (nut and nut-client). > >When I run the driver as root (for my tripplite ups) I get: > >/usr/sbin/upsdrvctl start >Network UPS Tools - Generic HID driver 0.42 >(v2.7.4-418-gb1314c62.7.4.1) >USB communication driver (libusb 0.1) 0.33 >writepid: fopen /var/run/nut/usbhid-ups-trippliteups.pid: Permission >denied >Can't claim USB device [09ae:1330]: could not detach kernel driver from >interface 0: Operation not permitted >Driver failed to start (exit status=1) > >And I had to create manually /var/run/nut. > >What is the problem there? > >On Fri, Jun 23, 2017 at 8:27 PM Manuel Wolfshant ><wolfy at nobugconsulting.ro> >wrote: > >> On 06/24/2017 04:52 AM, Charles Lepple wrote: >> > On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti <ambrojohn at gmail.com> >> wrote: >> >> "This TrippLite device (09ae:1330) is not (or perhaps not yet) >> supported by usbhid-ups. [...]" >> >> but my device (SU2200RTXLCD2U) is supported, as clearly state >here. >> > No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB >PID >> other than 0001 is generally the protocol number. So your SU2200* >model is >> different. >> > >> > https://github.com/networkupstools/nut/issues/64 >> > >> >> Then I thought I needed the last src code (2.7.4), hence I built >it for >> my machine, but when I run it by: >> >> /usr/local/ups/sbin/upsdrvctl start >> > The Protocol 1330 support was added after 2.7.4 was released. You >might >> be able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, >but >> voltages might be off by a factor of 10. You will also need to adjust >the >> udev files manually to fix /dev/bus/usb permissions. >> > >> > If you do choose to build using the latest source code from Git, be >> aware that you will need more tools, as specified in the Developer >Guide: >> >http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building >> > >> > It may be easier to use the 2.7.4 tarball, and add the patch which >> introduces Protocol 1330 support to the RPM spec file: >> >https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580 >> I've uploaded to http://wolfy.fedorapeople.org/nut a new set of >packages >> based on the latest source code from git. Unfortunately they do not >> include any man pages, I did not have time to find a workaround for >the >> hard requirement of newer versions for the tools used by the build >> process to create the man pages. I will fix that in a later set of >> packages. >> >> _______________________________________________ >> Nut-upsuser mailing list >> Nut-upsuser at lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser >>Hi all, I may be a bit late to the main party, but: * /var/run/nut : on systems with volatile (/var)/run backed by tmpfs, ramdisk etc. - the directory must be created upon every startup with proper owner and rights. Usually init-scripts handle that; systemd-tmpfiles can too (if given an appropriate config file) on newer Linuxes. * for devfs nodes like sockets of USB stuff, you also need to assign access rights - as done by udev in newer posts to the thread. Hope this clarifies a bit, Jim Jim -- Typos courtesy of K-9 Mail on my Redmi Android