Re: [Nut-upsdev] NUT v2.8.0(-rc1)
Thank you for the test and report! Regarding the changes, I hoped the NEWS and UPGRADING files detail them extensively enough :) Protocol-wise, there were some aliases added, and one notable change was addition of TRACKING for queries and replies to not mix up, more so with massive setups of many devices. Servers and clients of different versions should be compatible both ways though; tested vs 2.7.4 during development. Jim On Fri, Apr 1, 2022, 15:40 René Garcia via Nut-upsdev < nut-upsdev@alioth-lists.debian.net> wrote: > Hi, > > I built successfully package with 2.8.0-rc1 for VMware ESXi (6.7 and 7.0 > tested). Now, this package provides only the client part of NUT (upsc and > upsmon) and I think that this part of code has few evolutions since 2.7.4 > > Client has to be able to communicate with NUT servers running older > versions as customers may not be able to chose server version. I did not > notice significant network protocol changes in 2.8.0 (no change at all ?) > and every test I did has ran fine. > > Thank you, > René > > > > Le 1 avr. 2022 à 02:01, Jim Klimov via Nut-upsdev < > nut-upsdev@alioth-lists.debian.net> a écrit : > > > > Hello, fellow NUTs! > > > > It is with a [happy] heart that I must proclaim today, that the long > reign of NUT v2.7.4 is coming to an end. Its anticipated successor of half > a dozen years, release-in-waiting NUT v2.7.5 has also quietly expired, and > [won't] be sorely missed. They were survived by the next name in line, NUT > v2.8.0(-rc1). Le NUT est mort, long live the NUT! > > > > Along just this leg of the journey, NUT codebase survived at least > four separate CI farms and technologies to make its builds easier and more > reliable, all while succeeding on a wide range of CPU and OS platforms, > ranging from current distros to the dawn of millenium (nearly-immutable > appliances and sturdy reliable servers matter too!), as well as multiple > generations and implementations of compiler toolkits, "make" and scripted > code interpreters involved. > > > > We are grateful to the many freely available projects, services and > communities who helped us in particular (maybe unwittingly) and the FOSS > ecosystem in general (intentionally), such as (and not limited to) > Asciidoc, Autotools and family, BuildBot, CCache, Clang/LLVM, FossHost, > GCC, GitHub, Google, illumos, Jenkins, LiberaChat, Proxmox, QEMU, > StackExchange, Travis, ZeroMQ... bits here, swathes there - it would have > been much harder without the likes of them (and many others). > > > > Advances in compiler code analysis in particular, as is seen on a > daily basis with CI non-regression builds across the range of 10 major > releases of clang and 7 of gcc, is immense. At times annoying, yes, but it > led to a great cleansing of the codebase from questionable code (and indeed > some potential bugs). And it was possible to do so in a way that all those > regularly tested systems are satisfied, so the codebase stays clean and > green and portable as we iterate new contributions, and merged with peace > of mind many ports and features from long-awaited branches (such as > libusb-1.0+0.1 support finally), or forks (notably 42ity/nut). > > > > Let me take a moment to tender our special thanks from both the > maintainer team and countless users of UPS, ePDU, solar panel and similar > hardware, to numerous personal and corporate contributors of new drivers > and features or fixes for existing ones, as well as to community members > who ask and answer questions, and who log github issues with their ideas, > experiences or grievances. > > > > As always we would welcome people willing to regularly share their > expertise in certain areas and tools (in particular, thanks @nbriggs for > solving many practical mysteries around USB bit-stream lately), or > protocols (more active experts on prolific Qx family would be great for PR > reviews), or packaging, service and distro integrations, or HCL/DDL > maintenance based on reports trickling in... just about anything! > > > > While we have a lot of features queued to complete or port for the > next releases (hopefully with a healthier cadence), we expect to see more > feedback by exposing thevrelease, and hope for little fallout from the many > changes made while cleaning up the warnings. > > > > Handing over to creative packagers now... > > > > Jim Klimov, > > on behalf of the Network UPS Tools Project > > ___ > > Nut-upsdev mailing list > > Nut-upsdev@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev > > > ___ > Nut-upsdev mailing list > Nut-upsdev@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev > ___ Nut-upsdev mailing list Nut-upsdev@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] packaging update to rc1: trip report
Thanks for the update. I'm currently away from a PC so can't dig into libusb nuances. Cursorily I remember discussions that FreeBSD at least had a different implementation or build of libusb, in particular for error handling (-1 or more nuanced IIRC). Not sure which side NetBSD picked. As for shells, historically Solaris/illumos had a system shell (at some point also statically linked and so self-sufficient) as the efficient standard interpreter and root recovery shell (but not too convenient, no cruft). Since /usr could and still can be a separate partition, dataset or an NFS mount, and /bin is nowadays a symlink to usr/bin, the system/root shell remained separate from interactive one(s) for users - the choice of which can vary with no impact to init scripts, service methods and other system tooling. So yes, /sbin/sh is the correct thing :) Jim On Fri, Apr 1, 2022, 15:05 Greg Troxel wrote: > > I am taking the tarball I built from rc1 and using it as if released in > pkgsrc. The great news is that it only took me about 15 minutes to > update the package. > > I am getting one error: > > => Checking for non-existent script interpreters in ups-nut-2.7.4.1 > ERROR: [check-interpreter.mk] The interpreter "/sbin/sh" of > "/tmp/work/sysutils/ups-nut/work/.destdir/usr/pkg/share/nut/solaris-init/nut" > does not exist. > > And I wonder: > > Should the solaris-init file only be installed on Solaris? > > Is /sbin/sh really right? I've never heard of 1) sh in sbin or 2) a > system without /bin/sh as POSIX requires. > > I've appended my diff, trimmed to remove pkgsrc stuff not of interest. > > - The PLIST diff is perhaps interesting, showing the files installed > by 2.7.4.1 and not installed by 2.7.4. > > - It looks like drivers/hidparser.c has been rewritten so that the > previous BIGENDIAN branch that used "long" when it should perhaps be > fixed-width is no longer present, and this was fixed in > 24293b3f6d0cd157ac76f4901e0b6732068b55d4 > and thus it really is correct for me to just drop the patch. > > - We had a patch to change libusb_strerror to be >=0 instead of >0, > and I am not entirely sure why or what the correct semantics are. > Looking at libusb.h (focusing on libusb1), it seems 0 is > LIBUSB_SUCCESS, which isn't an error. Is the idea that if you > called libusb_strerror with 0, that was wrong and hence should be > logged? I am not really following the mapping from enum > libusb_error to this function. Also the name is confusing as > strerror indicates a translation from errno to a string, and this > function takes both and does logging. > > And that's it, a wicked short list, as we say in Boston. > > I will try to actually run it when I can schedule a maintenance window. > > > Index: PLIST > === > RCS file: /cvsroot/pkgsrc/sysutils/ups-nut/PLIST,v > retrieving revision 1.28 > diff -u -p -r1.28 PLIST > --- PLIST 13 Jul 2020 18:50:05 - 1.28 > +++ PLIST 1 Apr 2022 12:26:28 - > @@ -6,14 +6,18 @@ bin/upsrw > bin/upssched-cmd > include/nut-scan.h > include/nutclient.h > +include/nutclientmem.h > include/nutscan-device.h > include/nutscan-init.h > include/nutscan-ip.h > +include/nutscan-serial.h > include/parseconf.h > include/upsclient.h > lib/libnutclient.la > +lib/libnutclientstub.la > lib/libupsclient.la > lib/pkgconfig/libnutclient.pc > +lib/pkgconfig/libnutclientstub.pc > lib/pkgconfig/libnutscan.pc > lib/pkgconfig/libupsclient.pc > libexec/nut/al175 > @@ -44,8 +48,9 @@ libexec/nut/metasys > libexec/nut/mge-shut > libexec/nut/mge-utalk > libexec/nut/microdowell > +libexec/nut/microsol-apc > libexec/nut/nutdrv_qx > -libexec/nut/oldmge-shut > +libexec/nut/nutdrv_siemens-sitop > libexec/nut/oneac > libexec/nut/optiups > libexec/nut/powercom > @@ -120,7 +125,9 @@ man/man3/upscli_init.3 > man/man3/upscli_list_next.3 > man/man3/upscli_list_start.3 > man/man3/upscli_readline.3 > +man/man3/upscli_readline_timeout.3 > man/man3/upscli_sendline.3 > +man/man3/upscli_sendline_timeout.3 > man/man3/upscli_splitaddr.3 > man/man3/upscli_splitname.3 > man/man3/upscli_ssl.3 > @@ -160,9 +167,12 @@ man/man8/metasys.8 > man/man8/mge-shut.8 > man/man8/mge-utalk.8 > man/man8/microdowell.8 > +man/man8/microsol-apc.8 > +man/man8/nut-driver-enumerator.8 > man/man8/nut-recorder.8 > man/man8/nut-scanner.8 > man/man8/nutdrv_qx.8 > +man/man8/nutdrv_siemens_sitop.8 > man/man8/nutupsdrv.8 > man/man8/oneac.8 > man/man8/optiups.8 > @@ -179,6 +189,7 @@ man/man8/upscmd.8 > man/man8/upscode2.8 > man/man8/upsd.8 > man/man8/upsdrvctl.8 > +man/man8/upsdrvsvcctl.8 > man/man8/upslog.8 > man/man8/upsmon.8 > man/man8/upsrw.8 > @@ -196,6 +207,7 @@ share/doc/nut/NEWS > share/doc/nut/README > share/doc/nut/UPGRADING > share/doc/nut/acknowledgements.txt > +share/doc/nut/asciidoc.txt > share/doc/nut/cables.txt >
Re: [Nut-upsdev] NUT v2.8.0(-rc1)
Hi, I built successfully package with 2.8.0-rc1 for VMware ESXi (6.7 and 7.0 tested). Now, this package provides only the client part of NUT (upsc and upsmon) and I think that this part of code has few evolutions since 2.7.4 Client has to be able to communicate with NUT servers running older versions as customers may not be able to chose server version. I did not notice significant network protocol changes in 2.8.0 (no change at all ?) and every test I did has ran fine. Thank you, René > Le 1 avr. 2022 à 02:01, Jim Klimov via Nut-upsdev > a écrit : > > Hello, fellow NUTs! > > It is with a [happy] heart that I must proclaim today, that the long reign > of NUT v2.7.4 is coming to an end. Its anticipated successor of half a dozen > years, release-in-waiting NUT v2.7.5 has also quietly expired, and [won't] be > sorely missed. They were survived by the next name in line, NUT v2.8.0(-rc1). > Le NUT est mort, long live the NUT! > > Along just this leg of the journey, NUT codebase survived at least four > separate CI farms and technologies to make its builds easier and more > reliable, all while succeeding on a wide range of CPU and OS platforms, > ranging from current distros to the dawn of millenium (nearly-immutable > appliances and sturdy reliable servers matter too!), as well as multiple > generations and implementations of compiler toolkits, "make" and scripted > code interpreters involved. > > We are grateful to the many freely available projects, services and > communities who helped us in particular (maybe unwittingly) and the FOSS > ecosystem in general (intentionally), such as (and not limited to) Asciidoc, > Autotools and family, BuildBot, CCache, Clang/LLVM, FossHost, GCC, GitHub, > Google, illumos, Jenkins, LiberaChat, Proxmox, QEMU, StackExchange, Travis, > ZeroMQ... bits here, swathes there - it would have been much harder without > the likes of them (and many others). > > Advances in compiler code analysis in particular, as is seen on a daily > basis with CI non-regression builds across the range of 10 major releases of > clang and 7 of gcc, is immense. At times annoying, yes, but it led to a great > cleansing of the codebase from questionable code (and indeed some potential > bugs). And it was possible to do so in a way that all those regularly tested > systems are satisfied, so the codebase stays clean and green and portable as > we iterate new contributions, and merged with peace of mind many ports and > features from long-awaited branches (such as libusb-1.0+0.1 support finally), > or forks (notably 42ity/nut). > > Let me take a moment to tender our special thanks from both the maintainer > team and countless users of UPS, ePDU, solar panel and similar hardware, to > numerous personal and corporate contributors of new drivers and features or > fixes for existing ones, as well as to community members who ask and answer > questions, and who log github issues with their ideas, experiences or > grievances. > > As always we would welcome people willing to regularly share their > expertise in certain areas and tools (in particular, thanks @nbriggs for > solving many practical mysteries around USB bit-stream lately), or protocols > (more active experts on prolific Qx family would be great for PR reviews), or > packaging, service and distro integrations, or HCL/DDL maintenance based on > reports trickling in... just about anything! > > While we have a lot of features queued to complete or port for the next > releases (hopefully with a healthier cadence), we expect to see more feedback > by exposing thevrelease, and hope for little fallout from the many changes > made while cleaning up the warnings. > > Handing over to creative packagers now... > > Jim Klimov, > on behalf of the Network UPS Tools Project > ___ > Nut-upsdev mailing list > Nut-upsdev@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev ___ Nut-upsdev mailing list Nut-upsdev@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
[Nut-upsdev] packaging update to rc1: trip report
I am taking the tarball I built from rc1 and using it as if released in pkgsrc. The great news is that it only took me about 15 minutes to update the package. I am getting one error: => Checking for non-existent script interpreters in ups-nut-2.7.4.1 ERROR: [check-interpreter.mk] The interpreter "/sbin/sh" of "/tmp/work/sysutils/ups-nut/work/.destdir/usr/pkg/share/nut/solaris-init/nut" does not exist. And I wonder: Should the solaris-init file only be installed on Solaris? Is /sbin/sh really right? I've never heard of 1) sh in sbin or 2) a system without /bin/sh as POSIX requires. I've appended my diff, trimmed to remove pkgsrc stuff not of interest. - The PLIST diff is perhaps interesting, showing the files installed by 2.7.4.1 and not installed by 2.7.4. - It looks like drivers/hidparser.c has been rewritten so that the previous BIGENDIAN branch that used "long" when it should perhaps be fixed-width is no longer present, and this was fixed in 24293b3f6d0cd157ac76f4901e0b6732068b55d4 and thus it really is correct for me to just drop the patch. - We had a patch to change libusb_strerror to be >=0 instead of >0, and I am not entirely sure why or what the correct semantics are. Looking at libusb.h (focusing on libusb1), it seems 0 is LIBUSB_SUCCESS, which isn't an error. Is the idea that if you called libusb_strerror with 0, that was wrong and hence should be logged? I am not really following the mapping from enum libusb_error to this function. Also the name is confusing as strerror indicates a translation from errno to a string, and this function takes both and does logging. And that's it, a wicked short list, as we say in Boston. I will try to actually run it when I can schedule a maintenance window. Index: PLIST === RCS file: /cvsroot/pkgsrc/sysutils/ups-nut/PLIST,v retrieving revision 1.28 diff -u -p -r1.28 PLIST --- PLIST 13 Jul 2020 18:50:05 - 1.28 +++ PLIST 1 Apr 2022 12:26:28 - @@ -6,14 +6,18 @@ bin/upsrw bin/upssched-cmd include/nut-scan.h include/nutclient.h +include/nutclientmem.h include/nutscan-device.h include/nutscan-init.h include/nutscan-ip.h +include/nutscan-serial.h include/parseconf.h include/upsclient.h lib/libnutclient.la +lib/libnutclientstub.la lib/libupsclient.la lib/pkgconfig/libnutclient.pc +lib/pkgconfig/libnutclientstub.pc lib/pkgconfig/libnutscan.pc lib/pkgconfig/libupsclient.pc libexec/nut/al175 @@ -44,8 +48,9 @@ libexec/nut/metasys libexec/nut/mge-shut libexec/nut/mge-utalk libexec/nut/microdowell +libexec/nut/microsol-apc libexec/nut/nutdrv_qx -libexec/nut/oldmge-shut +libexec/nut/nutdrv_siemens-sitop libexec/nut/oneac libexec/nut/optiups libexec/nut/powercom @@ -120,7 +125,9 @@ man/man3/upscli_init.3 man/man3/upscli_list_next.3 man/man3/upscli_list_start.3 man/man3/upscli_readline.3 +man/man3/upscli_readline_timeout.3 man/man3/upscli_sendline.3 +man/man3/upscli_sendline_timeout.3 man/man3/upscli_splitaddr.3 man/man3/upscli_splitname.3 man/man3/upscli_ssl.3 @@ -160,9 +167,12 @@ man/man8/metasys.8 man/man8/mge-shut.8 man/man8/mge-utalk.8 man/man8/microdowell.8 +man/man8/microsol-apc.8 +man/man8/nut-driver-enumerator.8 man/man8/nut-recorder.8 man/man8/nut-scanner.8 man/man8/nutdrv_qx.8 +man/man8/nutdrv_siemens_sitop.8 man/man8/nutupsdrv.8 man/man8/oneac.8 man/man8/optiups.8 @@ -179,6 +189,7 @@ man/man8/upscmd.8 man/man8/upscode2.8 man/man8/upsd.8 man/man8/upsdrvctl.8 +man/man8/upsdrvsvcctl.8 man/man8/upslog.8 man/man8/upsmon.8 man/man8/upsrw.8 @@ -196,6 +207,7 @@ share/doc/nut/NEWS share/doc/nut/README share/doc/nut/UPGRADING share/doc/nut/acknowledgements.txt +share/doc/nut/asciidoc.txt share/doc/nut/cables.txt share/doc/nut/cables/apc-rs500-serial.txt share/doc/nut/cables/apc.txt @@ -205,9 +217,12 @@ share/doc/nut/cables/mgeups.txt share/doc/nut/cables/powerware.txt share/doc/nut/cables/repotec.txt share/doc/nut/cables/sms.txt +share/doc/nut/ci-farm-lxc-setup.txt share/doc/nut/config-notes.txt +share/doc/nut/config-prereqs.txt share/doc/nut/configure.txt share/doc/nut/contact-closure.txt +share/doc/nut/daisychain.txt share/doc/nut/design.txt share/doc/nut/developer-guide.txt share/doc/nut/developers.txt @@ -230,6 +245,7 @@ share/doc/nut/security.txt share/doc/nut/snmp-subdrivers.txt share/doc/nut/snmp.txt share/doc/nut/sock-protocol.txt +share/doc/nut/solaris-usb.txt share/doc/nut/support.txt share/doc/nut/user-manual.txt share/examples/nut/nut.conf.sample @@ -240,5 +256,6 @@ share/examples/nut/upsmon.conf.sample share/examples/nut/upssched.conf.sample share/nut/cmdvartab share/nut/driver.list +share/nut/solaris-init/nut @pkgdir share/doc/nut/drivers @pkgdir etc/nut Index: patches/patch-drivers_hidparser.c === RCS file: patches/patch-drivers_hidparser.c diff -N
Re: [Nut-upsdev] a few build nits
On Mar 31, 2022, at 9:18 AM, Greg Troxel wrote: > > I see your point about distcheck. I tend to build tarballs from source > to then use in pkgsrc (not that I publish those tarballs and packages), > to be able to debug the combination of upstream and pkgsrc to be ready > for a release. I can certainly just flip my script to the light version. > mostly for the archives (sounds like Greg has a solution), this page talks about the difference between "make distcheck" and "make distcheck-light" in NUT: https://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building - C ___ Nut-upsdev mailing list Nut-upsdev@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [Nut-upsuser] NUT v2.8.0(-rc1)
> Are there any known backward incompatible changes? e.g. conf file settings or commands that won't work anymore? None that I am aware of. There are a few new config keywords (and aliases to older concepts), so programs from the older NUT packages would probably safely refuse to start while parsing configurations that take advantage of these new features. This is a large part of what prompted semantic versioning to be bumped to 2.8.x. Also the protocol between NUT server and clients got a few new words (and aliases), but its implementation over the years should be less picky - unsupported commands are rejected as such, so the chatter can effectively constrain to the common denominator. The version was formally bumped to "1.3" but it does not seem the value is used by NUT itself to make any decisions. And of course, closely related to the pending release is the work spearheaded by Roger Price to document the protocol as an upcoming standard that other solutions might implement (e.g. an upsd equivalent running directly on the UPS or ePDU). Discussions with community and committee reviewers took their welcome toll on codebase too. Hope this helps, Jim Klimov On Fri, Apr 1, 2022, 07:07 Zomaya, David wrote: > > They were survived by the next name in line, NUT v2.8.0(-rc1). Le NUT > est mort, long live the NUT! > > Thank you to everyone who made this happen! > > Are there any known backward incompatible changes? > e.g. conf file settings or commands that won't work anymore? > > Thank you, > David Zomaya > Eaton Tripp Lite > > ___ Nut-upsdev mailing list Nut-upsdev@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [EXTERNAL] [Nut-upsuser] NUT v2.8.0(-rc1)
> They were survived by the next name in line, NUT v2.8.0(-rc1). Le NUT est > mort, long live the NUT! Thank you to everyone who made this happen! Are there any known backward incompatible changes? e.g. conf file settings or commands that won't work anymore? Thank you, David Zomaya Eaton Tripp Lite ___ Nut-upsdev mailing list Nut-upsdev@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
