Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 19, 2017, at 7:56 PM, Manuel Wolfshant wrote:
> 
> On 06/20/2017 02:27 AM, Charles Lepple wrote:
>> On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
>> 
>>> #lsusb -vvv -d 0463:
>>> 
>>> Bus 002 Device 012: ID 0463: MGE UPS Systems UPS
>>> 
>> ...
>> 
>>>   HID Device Descriptor:
>>>  bLength 9
>>>  bDescriptorType33
>>>  bcdHID   1.10
>>>  bCountryCode   33 US
>>>  bNumDescriptors 1
>>>  bDescriptorType34 Report
>>>  wDescriptorLength 549
>>>  Warning: incomplete report descriptor
>>>  Report Descriptor: (length is 9)
>>>Item(Main  ): (null), data=none
>>>Item(Main  ): (null), data=none
>>>Item(Main  ): (null), data=none
>>> 
>>> 
>> If I recall, this is equivalent to the usbhid-ups "method 2" approach to 
>> retrieving the descriptor. 
> 
> That's greek to me, I am completely unfamiliar to any of nut ( and its 
> drivers ) internals :) But if I can configure usbhid-ups in a different 
> manner which I did not spot from the docs, please point me to the correct 
> docs.

No configuration needed - the driver tries both methods:

  1.013273 HID descriptor length (method 1) -1
  1.013277 i=0, extra[i]=09, extra[i+1]=21
  1.013283 HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 25 02
  1.013287 HID descriptor length (method 2) 549
  1.013290 HID descriptor length 549
  1.013920 Unable to get Report descriptor: Broken pipe

It does not get a length for method 1, so it moves on to method 2, which gets a 
length, but fails to get the rest of the descriptor. This is what is happening 
to lsusb, too (tries to fetch 549 bytes, gets only 9).

> However I am using the very same package on my personal workstation (which is 
> also running CentOS 6 but has a whole lot of packages installed either from 
> 3rd party repos or built by me  ) since Fri 09 Jan 2015 (I needed it for 
> heimdall ) and I had zero issues so far.

Can you be more specific about this? What hardware are you testing libusbx 
1.0.19 with?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Manuel Wolfshant]

On 06/20/2017 02:27 AM, Charles Lepple wrote:

On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:

#lsusb -vvv -d 0463:

Bus 002 Device 012: ID 0463: MGE UPS Systems UPS

...

   HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 549
  Warning: incomplete report descriptor
  Report Descriptor: (length is 9)
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none


If I recall, this is equivalent to the usbhid-ups "method 2" approach to 
retrieving the descriptor.


That's greek to me, I am completely unfamiliar to any of nut ( and its 
drivers ) internals :) But if I can configure usbhid-ups in a different 
manner which I did not spot from the docs, please point me to the 
correct docs.





  or try to roll back the userspace tools to match what was current when the 
kernel was current.


I am afraid I did not understand this part...

If there are newer kernels out there, it is possible that some of the userspace 
tools (usbutils, libusb, etc.) are expecting a newer kernel. Is it possible to 
downgrade any of them, to test with package versions that were released at the 
same time as the 2.6.32 kernel?
If you mean the applications/libraries running on that server, I can 
guarantee that every one (minus libusb 1.0.19 -- see below) of them is 
compatible with the running kernel. Everything but nut is stock CentOS 6 
and fully updated. I am 100% positive that libsub0.1 which was used 
until yesterday ( and 1.0.9 which proved to be incompatible with nut ) 
are 100% compatible with the kernel. I cannot guarantee for libusbx 
1.0.19  (which I used instead of 1.0.9) because I built it myself. 
However I am using the very same package on my personal workstation 
(which is also running CentOS 6 but has a whole lot of packages 
installed either from 3rd party repos or built by me  ) since Fri 09 Jan 
2015 (I needed it for heimdall  ) 
and I had zero issues so far.


As of newer kernels: RH does not introduce incompatibilities between 
kernel and userspace. For the whole 10 years of life of a major version 
of a distribution, the major release of the kernel (and of most packages 
-- which is why both libsub and libusb1 aka 1.0.9 are oldish ) is frozen 
to the version used at launch date. It was 2.6.32 4.5 years ago when 6.0 
was launched and it will claim to be 2.6.32 when it will be EOLed 4 
years from now. They do backport stuff into the kernel ( actually the 
current kernel has huge backports from 3.10 ),  but breaking the ABI is 
extremely rare and normally never affects the packages from the distro 
itself because they are tested for months prior to any minor release of 
the distro. The newer kernels that exist and are let's say reputable are 
provided by a 3rd party repository ( ElRepo.org ). Over there there is 
one person who maintains two sets of kernels, the most recent one that 
is available from kernel.org ( "kernel mainline" ) and one long term 
version ( kernel-lt ). The kernel-lt is the one that failed for me.



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
> 
> #lsusb -vvv -d 0463:
> 
> Bus 002 Device 012: ID 0463: MGE UPS Systems UPS
...
>   HID Device Descriptor:
>  bLength 9
>  bDescriptorType33
>  bcdHID   1.10
>  bCountryCode   33 US
>  bNumDescriptors 1
>  bDescriptorType34 Report
>  wDescriptorLength 549
>  Warning: incomplete report descriptor
>  Report Descriptor: (length is 9)
>Item(Main  ): (null), data=none
>Item(Main  ): (null), data=none
>Item(Main  ): (null), data=none
> 
If I recall, this is equivalent to the usbhid-ups "method 2" approach to 
retrieving the descriptor. 


>> If not (lsusb returns "Report Descriptors:" / "** UNAVAILABLE **"), it seems 
>> like the two options are to upgrade the kernel (which I understand is an 
>> issue),
> 
> unfortunately it is. If mandatory I guess I can do some tricks with cron to 
> rollback a known good situation but given that I have no idea what failed 
> during the previous attempt ( nothing got logged -- I suspect a kernel panic 
> although I have no idea why would this happen ) I'd prefer to avoid, if 
> possible.
> 
> 
>>  or try to roll back the userspace tools to match what was current when the 
>> kernel was current.
>> 
> I am afraid I did not understand this part...

If there are newer kernels out there, it is possible that some of the userspace 
tools (usbutils, libusb, etc.) are expecting a newer kernel. Is it possible to 
downgrade any of them, to test with package versions that were released at the 
same time as the 2.6.32 kernel?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Manuel Wolfshant]

On 06/19/2017 05:33 PM, Charles Lepple wrote:

On Jun 19, 2017, at 4:27 AM, Manuel Wolfshant wrote:

   1.014501 [D2] Unable to get HID descriptor (Pipe error)
   1.014511 [D3] HID descriptor length (method 1) -1

So at this point in the logs, the kernel USB HID driver is detached from the UPS HID 
interface (until the UPS USB cable is unplugged and reattached). If you run "lsusb 
-vvv -d 0463:", does it print the HID report descriptor? (Normally, lsusb will 
only print descriptors for interfaces that are not claimed by a kernel driver or 
userspace library.)

If so, then it is worth checking to see how usbutils is talking to the UPS.


This is what I get:

#lsusb -vvv -d 0463:

Bus 002 Device 012: ID 0463: MGE UPS Systems UPS
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x0463 MGE UPS Systems
  idProduct  0x UPS
  bcdDevice0.01
  iManufacturer   1
  iProduct2
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   34
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower   20mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 549
  Warning: incomplete report descriptor
  Report Descriptor: (length is 9)
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  20
Device Status: 0x0001
  Self Powered



If not (lsusb returns "Report Descriptors:" / "** UNAVAILABLE **"), it seems 
like the two options are to upgrade the kernel (which I understand is an issue),


unfortunately it is. If mandatory I guess I can do some tricks with cron 
to rollback a known good situation but given that I have no idea what 
failed during the previous attempt ( nothing got logged -- I suspect a 
kernel panic although I have no idea why would this happen ) I'd prefer 
to avoid, if possible.




  or try to roll back the userspace tools to match what was current when the 
kernel was current.


I am afraid I did not understand this part...



Thanks for assistance

M.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 19, 2017, at 4:27 AM, Manuel Wolfshant wrote:
> 
>   1.014501 [D2] Unable to get HID descriptor (Pipe error)
>   1.014511 [D3] HID descriptor length (method 1) -1

So at this point in the logs, the kernel USB HID driver is detached from the 
UPS HID interface (until the UPS USB cable is unplugged and reattached). If you 
run "lsusb -vvv -d 0463:", does it print the HID report descriptor? 
(Normally, lsusb will only print descriptors for interfaces that are not 
claimed by a kernel driver or userspace library.)

If so, then it is worth checking to see how usbutils is talking to the UPS.

If not (lsusb returns "Report Descriptors:" / "** UNAVAILABLE **"), it seems 
like the two options are to upgrade the kernel (which I understand is an 
issue), or try to roll back the userspace tools to match what was current when 
the kernel was current.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Manuel Wolfshant]

On 06/19/2017 04:22 PM, Charles Lepple wrote:


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.
right, 6 hours ago I have disabled the inclusion of automake and 
autoconf in the buildroot. I've built the packages several times since ( 
against libusb 0.1, 1.0.9 and 1.0.19 )



-x usb_set_altinterface=0
Both 2.7.4 and the version you pointed me to fail identically. I have a 
strong feeling it's high time I cry again and send my tears towards the 
friendly Eaton support team


[root@belgrade ~]# usbhid-ups - -u root -x explore -x 
vendorid="0463" -a eaton -x usb_set_altinterface=0

Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
   0.00 debug level is '4'
   0.011576 upsdrv_initups...
   0.011876 Checking device (0463/) (002/012)
   1.012048 - VendorID: 0463
   1.012071 - ProductID: 
   1.012083 - Manufacturer: unknown
   1.012098 - Product: unknown
   1.012125 - Serial Number: unknown
   1.012137 - Bus: 002
   1.012148 - Device release number: 0001
   1.012158 Trying to match device
   1.012207 Device matches
   1.012217 failed to claim USB device: could not claim interface 
0: Device or resource busy

   1.012360 detached kernel driver from USB device...
   1.012377 nut_usb_set_altinterface: calling 
usb_set_altinterface(udev, 0)
   1.012891 nut_usb_set_altinterface: usb_set_altinterface() should 
not be necessary - please email the nut-upsdev list with information 
about your UPS.
   1.013266 Unable to get HID descriptor (error sending control 
message: Broken pipe)

   1.013273 HID descriptor length (method 1) -1
   1.013277 i=0, extra[i]=09, extra[i+1]=21
   1.013283 HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 
01 22 25 02

   1.013287 HID descriptor length (method 2) 549
   1.013290 HID descriptor length 549
   1.013920 Unable to get Report descriptor: Broken pipe



Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1)
USB communication driver (libusb 0.1) 0.33
   0.00 [D1] debug level is '4'
   0.011705 [D1] upsdrv_initups...
   0.012015 [D2] Checking device (0463/) (002/012)
   0.012938 [D2] - VendorID: 0463
   0.013011 [D2] - ProductID: 
   0.013021 [D2] - Manufacturer: unknown
   0.013031 [D2] - Product: unknown
   0.013035 [D2] - Serial Number: unknown
   0.013038 [D2] - Bus: 002
   0.013041 [D2] - Device release number: 0001
   0.013045 [D2] Trying to match device
   0.013076 [D2] Device matches
   0.013096 [D2] nut_usb_set_altinterface: calling 
usb_set_altinterface(udev, 0)
   0.013637 nut_usb_set_altinterface: usb_set_altinterface() should 
not be necessary - please email the nut-upsdev list with information 
about your UPS.
   0.013988 [D2] Unable to get HID descriptor (error sending 
control message: Broken pipe)

   0.014006 [D3] HID descriptor length (method 1) -1
   0.014019 [D4] i=0, extra[i]=09, extra[i+1]=21
   0.014035 [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 01 
21 01 22 25 02

   0.014048 [D3] HID descriptor length (method 2) 549
   0.014059 [D2] HID descriptor length 549
   0.014647 [D2] Unable to get Report descriptor: Broken pipe



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

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 interface

At 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?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Manuel Wolfshant]

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' follow


I 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@belgrade ~]# usbhid-ups - -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.00 [D1] debug level is '4'
   0.001696 [D1] upsdrv_initups...
   0.011580 [D2] Checking device (0463/)
   1.012644 [D2] - VendorID: 0463
   1.012669 [D2] - ProductID: 
   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 ?


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Manuel Wolfshant]

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

[ 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 




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