Jim Klimov
2021-Dec-28 16:52 UTC
[Nut-upsuser] [Nut-upsdev] LibUSB-1.0+0.1 testing wanted, NUT 2.7.5 pending
I've made a centos7 container on the farm today and updated the docs to reflect the nuances. The libusb* branches seem to be building ok there (with some warnings for system headers). Do I get it right that there is no libi2c-devel (smbus.h and userland i2c-dev.h) in the distro? Jim On Sun, Dec 26, 2021, 23:20 Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:> On 12/27/21 00:06, Manuel Wolfshant wrote: > > Hello > > I've packaged > https://github.com/networkupstools/nut/tree/fightwarn-libusb-1.0+0.1 for > EL7 and uploaded the resulting rpms to > https://wolfy.fedorapeople.org/nut-2.7.5-0.nut_fightwarn/ > These packages are built against stock libusb i.e. compatible with > libusb-0.1. Minimal testing shows them as functional but as always, YMMV. > I had to disable support for i2c, it triggered some build errors and I am > in no mood to debug them. > > As a sidenote, upsc reports 2.7.4.1 not 2.7.5 so probably I should rename > the packages as well: > [wolfy at wolfy epel-7-x86_64]$ which upsc > /usr/bin/upsc > [wolfy at wolfy epel-7-x86_64]$ rpm -qf /usr/bin/upsc > nut-client-2.7.5-0.nut_fightwarn_libusb.wolfy.x86_64 > [wolfy at wolfy epel-7-x86_64]$ upsc -V > Network UPS Tools upscmd 2.7.4.1 > > > I'll try to build another set of packages against libusbx aka EL7's > libusb-1.0 > > The packages built against libusb-1.0 are available at > https://wolfy.fedorapeople.org/nut-2.7.5-0.nut_fightwarn_libusbx/ > > For now I've left in place ( at https://wolfy.fedorapeople.org/nut ) the > old versions of nut I built 4-5 years ago but, if memory serves, those were > built for EL6 which has an year since it is no longer supported. Therefore > I recommend against using them and I will probably remove them after New > Year's day. > > > wolfy > > > > Manuel > > On 12/26/21 12:07, Strahil Nikolov via Nut-upsuser wrote: > > Hey Jim, > > > do we have precompiled binaries or rpm ? > > Best Regards, > Strahil Nikolov > > On Sun, Dec 26, 2021 at 11:51, Jim Klimov via Nut-upsdev > <nut-upsdev at alioth-lists.debian.net> <nut-upsdev at alioth-lists.debian.net> > wrote: > > 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). > > > > > > _______________________________________________ > Nut-upsuser mailing listNut-upsuser at alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > > _______________________________________________ > 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-upsuser/attachments/20211228/738b907a/attachment.htm>
Strahil Nikolov
2021-Dec-28 16:58 UTC
[Nut-upsuser] [Nut-upsdev] LibUSB-1.0+0.1 testing wanted, NUT 2.7.5 pending
For EL-7 based , check in Fedora for version close to it. Usually development goes Fedora -> RHEL 7-> CentOS 7 Since December that changed for EL8 only:Fedora -> CentOS Stream 8 -> RHEL 8 Best Regards,Strahil Nikolov On Tue, Dec 28, 2021 at 18:52, Jim Klimov via Nut-upsdev<nut-upsdev at alioth-lists.debian.net> wrote: _______________________________________________ Nut-upsdev mailing list Nut-upsdev at alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20211228/c3390da4/attachment-0001.htm>
Manuel Wolfshant
2021-Dec-29 02:25 UTC
[Nut-upsuser] [Nut-upsdev] LibUSB-1.0+0.1 testing wanted, NUT 2.7.5 pending
On 12/28/21 18:52, Jim Klimov wrote:> I've made a centos7 container on the farm today and updated the docs > to reflect the nuances. The libusb* branches seem to be building ok > there (with some warnings for system headers). > > Do I get it right that there is no libi2c-devel (smbus.h and userland > i2c-dev.h) in the distro? >That is correct, there is no equivalent for libi2c-devel ( which, in the RedHat land would be named i2c-<something>-devel ) . smbus.h is provided by the kernel-devel package and i2c-dev.h by the kernel-headers package. However the build fails even when including both packages in the buildroot; at the first glance, it seems that i2c_smbus_access does not exist in the version of headers provided by the distro: [wolfy at wolfy nut-fightwarn-libusb-1.0-0.1]$ grep i2c_smbus_access /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/* -r [wolfy at wolfy nut-fightwarn-libusb-1.0-0.1]$ The output of configure is: checking linux/i2c-dev.h usability... yes checking linux/i2c-dev.h presence... yes checking for linux/i2c-dev.h... yes checking i2c/smbus.h usability... no checking i2c/smbus.h presence... no checking for i2c/smbus.h... no checking whether i2c_smbus_access is declared... no configure: error: i2c was required but can not be fulfilled for this build error: Bad exit status from /var/tmp/rpm-tmp.TjebuB (%build) ??? Bad exit status from /var/tmp/rpm-tmp.TjebuB (%build) The i2c files that exist: [wolfy at wolfy tmp]$ ls /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c* -l -rw-r--r--. 3 root root? 2298 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-algo-bit.h -rw-r--r--. 3 root root? 2560 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-algo-pca.h -rw-r--r--. 3 root root? 1926 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-algo-pcf.h -rw-r--r--. 3 root root? 1051 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-dev.h -rw-r--r--. 3 root root? 1344 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-gpio.h -rw-r--r--. 3 root root 25336 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c.h -rw-r--r--. 3 root root? 1383 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-mux-gpio.h -rw-r--r--. 3 root root? 1683 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-mux.h -rw-r--r--. 3 root root? 1475 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-mux-pinctrl.h -rw-r--r--. 3 root root?? 708 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-ocores.h -rw-r--r--. 3 root root? 1202 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-omap.h -rw-r--r--. 3 root root?? 402 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-pca-platform.h -rw-r--r--. 3 root root?? 943 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-pnx.h -rw-r--r--. 3 root root?? 399 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-pxa.h -rw-r--r--. 3 root root? 1820 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-smbus.h -rw-r--r--. 3 root root? 1444 Nov 30? 2020 /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c-xiic.h There are 30 header files below /usr/src/kernels/3.10.0-1160.49.1.el7.x86_64/include/linux/i2c but I doubt that listing them here is useful so I skipped that. wolfy> Jim > > > On Sun, Dec 26, 2021, 23:20 Manuel Wolfshant > <wolfy at nobugconsulting.ro> wrote: > > On 12/27/21 00:06, Manuel Wolfshant wrote: >> Hello >> >> I've packaged >> https://github.com/networkupstools/nut/tree/fightwarn-libusb-1.0+0.1 >> for EL7 and uploaded the resulting rpms to >> https://wolfy.fedorapeople.org/nut-2.7.5-0.nut_fightwarn/ >> These packages are built against stock libusb i.e. compatible >> with libusb-0.1. Minimal testing shows them as functional but as >> always, YMMV. >> I had to disable support for i2c, it triggered some build errors >> and I am in no mood to debug them. >> >> As a sidenote, upsc reports 2.7.4.1 not 2.7.5 so probably I >> should rename the packages as well: >> [wolfy at wolfy epel-7-x86_64]$ which upsc >> /usr/bin/upsc >> [wolfy at wolfy epel-7-x86_64]$ rpm -qf /usr/bin/upsc >> nut-client-2.7.5-0.nut_fightwarn_libusb.wolfy.x86_64 >> [wolfy at wolfy epel-7-x86_64]$ upsc -V >> Network UPS Tools upscmd 2.7.4.1 >> >> >> I'll try to build another set of packages against libusbx aka >> EL7's libusb-1.0 >> > > The packages built against libusb-1.0 are available at > https://wolfy.fedorapeople.org/nut-2.7.5-0.nut_fightwarn_libusbx/ > > For now I've left in place ( at https://wolfy.fedorapeople.org/nut > ) the old versions of nut I built 4-5 years ago but, if memory > serves, those were built for? EL6 which has an year since it is no > longer supported. Therefore I recommend against using them and I > will probably remove them after New Year's day. > > > > > > wolfy > > > > > > > >> Manuel >> >> On 12/26/21 12:07, Strahil Nikolov via Nut-upsuser wrote: >>> Hey Jim, >>> >>> >>> do we have precompiled binaries or rpm ? >>> >>> Best Regards, >>> Strahil Nikolov >>> >>> On Sun, Dec 26, 2021 at 11:51, Jim Klimov via Nut-upsdev >>> <nut-upsdev at alioth-lists.debian.net> >>> <mailto:nut-upsdev at alioth-lists.debian.net> wrote: >>> >>>> ? 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). >>> >>> >> >> >> >> _______________________________________________ Nut-upsuser >> mailing list Nut-upsuser at alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > > > _______________________________________________ > 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-upsuser/attachments/20211229/a8248c1a/attachment.htm>