Thank you for the details, I hope they would help others following in your footsteps on the platform :)
Jim On Wed, Dec 29, 2021, 06:04 Yogesh Bhanu <yogesh.bh...@gmail.com> wrote: > 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@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@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 <zman0...@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 <jimkli...@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.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