[Nut-upsdev] [Nut-upsuser] LibUSB-1.0+0.1 testing wanted, NUT 2.7.5 pending

[Yogesh Bhanu]

Hi Jim,
FWIW, the new version works with libusb and libusb-compat.

On Arch linux, I can install both libusb packages in parallel.

--snip--
[alarm at 3pi network-ups-tools-git]$ pacman -Ss libusb
core/libusb 1.0.24-2 [installed]
    Library that provides generic access to USB devices
extra/libgusb 0.3.8-1
    GObject wrapper for libusb1
extra/libusb-compat 0.1.7-1 [installed]
    Library to enable user space application programs to communicate with
USB devices
--snip--

+ I  modified the PKGBUILD to reflect the changes.

--snip--
[alarm at 3pi network-ups-tools-git]$ git diff PKGBUILD
diff --git a/PKGBUILD b/PKGBUILD
index 148fb37..2726e0a 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -5,19 +5,19 @@
 # Contributor: Dan Ziemba <zman0900 at gmail.com>

 pkgname=network-ups-tools-git
-pkgver=v2.7.4.r371.g30e04684
+pkgver=v2.7.4.r3891.gea87c8c7
 pkgrel=1
 pkgdesc="NUT is a collection of programs for monitoring and administering
UPS hardware"
 arch=('i686' 'x86_64' 'armv6h' 'armv7h')
 url="http://www.networkupstools.org/"
 license=('GPL2')
-depends=('openssl-1.0' 'libusb-compat' 'libltdl' 'neon' 'net-snmp')
+depends=('openssl-1.0' 'libusb' 'libltdl' 'neon' 'net-snmp')
 provides=('network-ups-tools')
 conflicts=('network-ups-tools')
 makedepends=('asciidoc' 'git')
 backup=(etc/ups/{ups.conf,upsd.conf,upsd.users,upsmon.conf,upssched.conf})
 install=nut.install
-source=("git+https://github.com/networkupstools/nut.git")
+source=("git+
https://github.com/networkupstools/nut.git#branch=fightwarn-libusb-1.0+0.1")
 options=()
 md5sums=('SKIP')
--snip--

Cheers,

Yogi

On Mon, Dec 27, 2021 at 12:02 PM Jim Klimov <jimklimov at gmail.com> wrote:

> Great news, more so for the test on an RPi which popped up as problematic
> with USB too many times this year in the github issues tracker. I did have
> big hopes that libusb-1.0 shipped for the platform handles it better than
> the nearly abandoned old library.
>
> By the way, did you test just the default build (preferring libusb-1.0 I
> suppose), or did you try to build and test with libusb-compat too? If yes,
> how did that go? (My understanding is that it's a fork of 1.0 to serve 0.1
> API with a few caveats, so under the hood should have the benefits of the
> newer 1.0 architecture; and can't/shouldn't be installed on same system as
> a real libusb-0.1 - so recipes and code do not need special handling for
> *three* variants at once).
>
> I commented about versioning in another sub-thread, but in short yes -
> code thinks it is 3k'th iteration over 2.7.4 since it is not marked as
> 2.7.5 yet in configure.ac.
>
> Jim
>
>
> On Mon, Dec 27, 2021, 11:00 Yogesh Bhanu <yogesh.bhanu at gmail.com> wrote:
>
>> Hi Jim,
>>
>> I was able to test it on Arch linux on RPI3 against my Tripplite
>> SMC1000LCD. It Works.
>> P.S: on Arch Linux there is libusb-compat (0.1) and libusb (1.0) .
>> Also the git version is still 2.7.4 ~ v2.7.4.r3891.gea87c8c7.
>>
>> Good Luck and a Happy new year.
>>
>> Cheers,
>>
>> Yogi
>>
>> On Sun, Dec 26, 2021 at 10:51 AM Jim Klimov via Nut-upsuser <
>> nut-upsuser at alioth-lists.debian.net> wrote:
>>
>>> Reminder: I plan to merge
>>> https://github.com/networkupstools/nut/tree/fightwarn-libusb-1.0+0.1 as
>>> "libusb-1.0+0.1" branch and as master after that, early next week.
>>>
>>> If anyone has tested this codebase against hardware, or needs a few more
>>> days to do so, please let me know here or in issue #300.
>>>
>>> Happy holidays,
>>> Jim
>>>
>>> On Tue, Dec 21, 2021, 21:42 Jim Klimov <jimklimov+nut at gmail.com> wrote:
>>>
>>>> Hello fellow NUTs :)
>>>>
>>>>   It seems the magic of the season might just help us finish some long
>>>> story arcs and tie up loose ends... oh, wait, that is wording about other
>>>> "seasons" ;)
>>>>
>>>>   In our case, the "fightwarn" effort is reaching a major milestone to
>>>> finally pass the builds with "medium" level of warnings treated as fatal
>>>> errors - with zero warnings. This achievement took a bit over a year, and
>>>> almost 3000 commits to analyze and stomp out different small bugs, and it
>>>> allows to set that tolerance level as default and insist on non-regressions
>>>> with future iterations - as well as to work towards clearing the "hard"
>>>> level eventually. And this became one of the criteria for cutting a new
>>>> official NUT release (especially as new platforms refused to build release
>>>> 2.7.4 with their default settings).
>>>>
>>>>   This work has originally delayed merging of libusb-1.0 support (from
>>>> issue https://github.com/networkupstools/nut/issues/300 and several
>>>> candidate branches to pick from), in particular because with the original
>>>> codebase sporting thousands of build warnings, it was hard to notice any
>>>> new "offences" introduced by this large set of changes. I was afraid that
>>>> merging it would even have to wait until after the next NUT release, but in
>>>> the end found that some remaining warnings in the original USB-related NUT
>>>> codebase made those branches' changes the better solution.
>>>>
>>>>   Now, before we find the hard way if the cure is worse than the
>>>> disease, I would like to ask people with USB-connected UPSes (and also
>>>> those using the MGE SHUT protocol) to build and test
>>>> https://github.com/networkupstools/nut/tree/fightwarn-libusb-1.0+0.1
>>>> branch with their setups - hopefully hitting as many OSes and CPU types as
>>>> feasible, as well as trying both libusb-0.1, libusb-1.0 (and not sure about
>>>> libusb-0.1-compat).
>>>>
>>>>   For building from scratch, note we now have a list of prerequisite
>>>> packages for several platforms at
>>>> https://github.com/networkupstools/nut/blob/master/docs/config-prereqs.txt
>>>> - and as for other code, PRs there are welcome too.
>>>> Note also the new `ci_build.sh` script to automate a number of
>>>> configurations and setups, usually reducing the typing needed to reproduce
>>>> build attempts :)
>>>>
>>>>   I understand that some people would be away for holidays, but also
>>>> realize that for others these days may be among the few times in the year
>>>> that can be dedicated to such experiments and other hobbies. It would be
>>>> much appreciated if you can help bring the official new confident NUT
>>>> release date closer ;)
>>>>
>>>>   The NUT CI farm is busy testing hundreds of build combinations
>>>> formally in software, but it is no replacement for tests against actual
>>>> hardware.
>>>>
>>>>   Also, great thanks to dozens of individual and corporate contributors
>>>> adding and fixing NUT drivers and other features (a few are still being
>>>> tested and may become part of the new release too), and sharing findings
>>>> and ideas in the issue tracker -- you guys and gals are our real heroes!
>>>>
>>>>   Finally, on behalf of the NUT core team, please let me wish you all a
>>>> happy holiday season and some quality time to rest, walk, ski and be with
>>>> family and friends!
>>>>
>>>> Jim Klimov
>>>>
>>>>
>>>> _______________________________________________
>>> Nut-upsuser mailing list
>>> Nut-upsuser at alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20211229/ef7ea509/attachment-0001.htm>