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.bh...@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@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+...@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@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >> >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser