Charles Lepple
2017-Jun-18 14:42 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:> > running autogen.sh was triggered automatically. but even if I do it explicitly, I still get: > + autoreconf -i > configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body > ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... > /usr/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... > /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from... > /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from... > /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... > /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... > /usr/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... > configure.ac:887: the top level > > [.... looong part of output deleted...] > > configure.ac:1526: required file `scripts/augeas/nutupsconf.aug.in' not found > configure.ac:1526: required file `scripts/devd/nut-usb.conf.in' not found > configure.ac:1526: required file `scripts/udev/nut-usbups.rules.in' not found > Makefile.am: installing `./INSTALL' > autoreconf: automake failed with exit status: 1This sounds like an autotools incompatibility. Which versions of autoconf, automake, libtool, etc. are you using? In the mean time, Buildbot generates snapshots using "make dist" that do not require auto*. Since there have not been any recent builds, they aren't on the first page of the waterfall, but usually there is a link to the snapshot off of the Debian jessie builder when the branch is rebuilt. Here is the generic URL: http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/nut-latest.tar.gz <http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/nut-latest.tar.gz> If you need a specific version for the .spec file, that link currently points to http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/rb1314c693bef0ce639991dcee6e5742f25e94a88-753/nut-v2.7.4-418-gb1314c62.7.4.1.tar.gz <http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/rb1314c693bef0ce639991dcee6e5742f25e94a88-753/nut-v2.7.4-418-gb1314c62.7.4.1.tar.gz> (not a typo; the code that generates the version stuck in both 2.7.4 and 2.7.4.1) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170618/eabed40e/attachment.html>
Manuel Wolfshant
2017-Jun-19 08:02 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
On 06/18/2017 05:42 PM, Charles Lepple wrote:> On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant > <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote: >> >> running autogen.sh was triggered automatically. but even if I do it >> explicitly, I still get: >> + autoreconf -i >> configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call >> detected in body >> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... >> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... >> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... >> /usr/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is >> expanded from... >> /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded >> from... >> /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded >> from... >> /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... >> /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... >> /usr/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... >> configure.ac:887: the top level >> >> [.... looong part of output deleted...] >> >> configure.ac:1526: required file `scripts/augeas/nutupsconf.aug.in' >> not found >> configure.ac:1526: required file `scripts/devd/nut-usb.conf.in' not found >> configure.ac:1526: required file `scripts/udev/nut-usbups.rules.in' >> not found >> Makefile.am: installing `./INSTALL' >> autoreconf: automake failed with exit status: 1 > > This sounds like an autotools incompatibility. Which versions of > autoconf, automake, libtool, etc. are you using?As I am a packager for Fedora & EPEL I usually try to rely exclusively on the tools of the distribution ( RHEL / CentOS 6 in this case). Otherwise the packages would not be accepted as they could not be built using the official builders which use exclusively packages available in the distribution itself. In this particular case though I have updated some tools to versions from RHEL7 or Fedora so I am using: autoconf-2.69-23.el6.noarch ( instead of distro's 2.63 ) automake-1.11.1-4.el6.noarch libtool-2.2.6-15.5.el6.x86_64 libtool-ltdl-devel-2.2.6-15.5.el6.x86_64 m4-1.4.16-10.el6.x86_64 ( instead of 1.4.13 )> > In the mean time, Buildbot generates snapshots using "make dist" that > do not require auto*. Since there have not been any recent builds, > they aren't on the first page of the waterfall, but usually there is a > link to the snapshot off of the Debian jessie builder when the branch > is rebuilt. > > Here is the generic URL: > http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/nut-latest.tar.gz > <http://buildbot.networkupstools.org/%7Ebuildbot/docker-debian-jessie/snapshot/libusb-1.0/nut-latest.tar.gz> >Thank a lot ! Now, conclusions after attempting builds ( with no docs included since attempting to enable them triggers the errors related to missing or too old tools mentioned by me in an earlier message ) - building against libsub 1.0 triggers the following 2 errors : nutdrv_qx-nutdrv_qx.o: In function `ippon_command': /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:679: undefined reference to `libusb_strerror' /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:692: undefined reference to `libusb_strerror' nutdrv_qx-nutdrv_qx.o: In function `fabula_command': /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:907: undefined reference to `libusb_strerror' nutdrv_qx-nutdrv_qx.o: In function `krauler_command': /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:770: undefined reference to `libusb_strerror' nutdrv_qx-nutdrv_qx.o: In function `sgs_command': /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:542: undefined reference to `libusb_strerror' nutdrv_qx-nutdrv_qx.o:/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:568: more undefined references to `libusb_strerror' follow [...] libusb1.o: In function `nut_libusb_strerror': /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:484: undefined reference to `libusb_strerror' /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:469: undefined reference to `libusb_strerror' /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:479: undefined reference to `libusb_strerror' libusb1.o: In function `nut_libusb_open': /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:181: undefined reference to `libusb_strerror' /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:282: undefined reference to `libusb_strerror' libusb1.o:/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:289: more undefined references to `libusb_strerror' follow - building against libusb 0.1 does not change in any way the situation, I still get the same error related to lack of ability to claim the interface> If you need a specific version for the .spec file, that link currently > points to > http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/rb1314c693bef0ce639991dcee6e5742f25e94a88-753/nut-v2.7.4-418-gb1314c62.7.4.1.tar.gz > <http://buildbot.networkupstools.org/%7Ebuildbot/docker-debian-jessie/snapshot/libusb-1.0/rb1314c693bef0ce639991dcee6e5742f25e94a88-753/nut-v2.7.4-418-gb1314c62.7.4.1.tar.gz> (not > a typo; the code that generates the version stuck in both 2.7.4 and > 2.7.4.1)Thanks a lot. This is not needed as I can adjust the spec accordingly. After all I build rpms since 2007... :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170619/fe80c5ff/attachment-0001.html>
Manuel Wolfshant
2017-Jun-19 08:27 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
On 06/19/2017 11:02 AM, Manuel Wolfshant wrote:> Thank a lot ! > Now, conclusions after attempting builds ( with no docs included since > attempting to enable them triggers the errors related to missing or > too old tools mentioned by me in an earlier message ) > - building against libsub 1.0 triggers the following 2 errors : > nutdrv_qx-nutdrv_qx.o: In function `ippon_command': > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:679: > undefined reference to `libusb_strerror' > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:692: > undefined reference to `libusb_strerror' > nutdrv_qx-nutdrv_qx.o: In function `fabula_command': > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:907: > undefined reference to `libusb_strerror' > nutdrv_qx-nutdrv_qx.o: In function `krauler_command': > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:770: > undefined reference to `libusb_strerror' > nutdrv_qx-nutdrv_qx.o: In function `sgs_command': > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:542: > undefined reference to `libusb_strerror' > nutdrv_qx-nutdrv_qx.o:/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/nutdrv_qx.c:568: > more undefined references to `libusb_strerror' follow > [...] > libusb1.o: In function `nut_libusb_strerror': > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:484: > undefined reference to `libusb_strerror' > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:469: > undefined reference to `libusb_strerror' > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:479: > undefined reference to `libusb_strerror' > libusb1.o: In function `nut_libusb_open': > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:181: > undefined reference to `libusb_strerror' > /builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:282: > undefined reference to `libusb_strerror' > libusb1.o:/builddir/build/BUILD/nut-v2.7.4-418-gb1314c62.7.4.1/drivers/libusb1.c:289: > more undefined references to `libusb_strerror' followI did some more digging. It turns out that the version of libusb 1.0 ( 1.0.9 ) included by RH in RHEL 6 misses the libusr_strerror function completely. I bypassed that by building against libusbx ( oldish but good enough, I think -- 1.0.19). Unfortunately there not much gain as the usbhid driver still cannot access that f*ing interface: [root at belgrade ~]# usbhid-ups -DDDD -u root -x explore -x vendorid="0463" -a eaton Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1) USB communication driver (libusb 1.0) 0.02 0.000000 [D1] debug level is '4' 0.001696 [D1] upsdrv_initups... 0.011580 [D2] Checking device (0463/FFFF) 1.012644 [D2] - VendorID: 0463 1.012669 [D2] - ProductID: ffff 1.012681 [D2] - Manufacturer: unknown 1.012693 [D2] - Product: unknown 1.012767 [D2] - Serial Number: unknown 1.012777 [D2] - Bus: 002 1.012786 [D2] - Device release number: 0001 1.012797 [D2] Trying to match device 1.012836 [D2] Device matches 1.012842 [D2] Reading first configuration descriptor 1.012851 [D2] auto detached kernel driver from USB device 1.013972 [D2] Claimed interface 0 successfully 1.013983 [D3] nut_usb_set_altinterface: skipped libusb_set_interface_alt_setting(udev, 0, 0) 1.014501 [D2] Unable to get HID descriptor (Pipe error) 1.014511 [D3] HID descriptor length (method 1) -1 1.014517 [D4] i=0, extra[i]=09, extra[i+1]=21 1.014525 [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 25 02 1.014532 [D3] HID descriptor length (method 2) 549 1.014538 [D2] HID descriptor length 549 1.015007 [D2] Unable to get Report descriptor: Resource temporarily unavailable Short of updating the kernel, anything else I can do ?
Charles Lepple
2017-Jun-19 13:22 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
On Jun 19, 2017, at 4:02 AM, Manuel Wolfshant wrote:> On 06/18/2017 05:42 PM, Charles Lepple wrote: >> On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant wrote: >>> >>> running autogen.sh was triggered automatically. but even if I do it explicitly, I still get: >>> + autoreconf -i >>> configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body >>> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... >>> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... >>> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... >>> /usr/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... >>> /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from... >>> /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from... >>> /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... >>> /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... >>> /usr/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... >>> configure.ac:887: the top level...>> This sounds like an autotools incompatibility. Which versions of autoconf, automake, libtool, etc. are you using? > As I am a packager for Fedora & EPEL I usually try to rely exclusively on the tools of the distribution ( RHEL / CentOS 6 in this case). Otherwise the packages would not be accepted as they could not be built using the official builders which use exclusively packages available in the distribution itself. In this particular case though I have updated some tools to versions from RHEL7 or Fedora so I am using: >> autoconf-2.69-23.el6.noarch ( instead of distro's 2.63 ) >> automake-1.11.1-4.el6.noarch >> libtool-2.2.6-15.5.el6.x86_64 >> libtool-ltdl-devel-2.2.6-15.5.el6.x86_64 >> m4-1.4.16-10.el6.x86_64 ( instead of 1.4.13 ) >With the exception of libtool (I can never get the hang of libtool), I don't believe any of those packages are needed to compile from a tarball of NUT. Looking at the backtrace, though, I think that NUT is only including AC_PROG_LIBTOOL, so it seems like that version of libtool and autoconf are not compatible. (On Fink, I am currently using autoconf-2.69 and libtool-2.4.6)> - building against libusb 0.1 does not change in any way the situation, I still get the same error related to lack of ability to claim the interfaceAt some point, we took out a call to usb_set_altinterface() - the kernel is supposed to activate bAlternateSetting=0 automatically, and re-selecting it caused problems on other platforms. Maybe it was required with Linux kernel 2.6.x. With libusb-0.1 linked in, does "-x usb_set_altinterface=0" change anything?