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

[Jim Klimov]

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/20211227/fab24401/attachment.htm>