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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220401/768a4402/attachment.htm>
Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:> 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!I built v2.8.0-rc1 on NetBSD 9 amd64, make check passed, and distcheck-light passed. I do not see any real warnings, just something about libtool and -lgcc that I don't understand yet. Next up is trying to package the generated distfile, and running it against a real UPS (Best Power Fortress 660) and upsc clients.
Zomaya, David
2022-Apr-01 05:07 UTC
[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
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 at 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 at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
Hello all, A concern was raised (in issue #1344 among other things dealing with recent git-source NUT setup on Rocky Linux 8) that new systemd service definitions misbehaved on a client-only system. Per report, the `nut-monitor.service` (which both `Wants` and is `After` the `nut-server.service`) did not even try to start on a system without a `nut-server` unit defined (if I got their setup right) until the "After" constraint was removed (`Wants` is still there), e.g. it was not auto-starting upsmon after a reboot. I can't exclude that the issue got fixed by something else done during investigation, though. My understanding was that `Wants` is a weak dependency - telling systemd to try starting stuff and move on (unlike `Requires` or `Requisite` that consider success of that attempt), and `After` queues the start of current unit to begin after the listed one gets into a definitive state (or necessarily success?). If it really does not work like that when the listed unit is not known (and/or is known but masked and may not start ever?), I'm in for a bit of surprise =D and would welcome suggestions about optional dependencies of this sort. It can also help if people try to reproduce the situation in their Linux distros (old and new), maybe something works differently in various systemd versions out there. At least, this is something to get a better understanding of before cutting a release. Thanks in advance, Jim Klimov On Fri, Apr 1, 2022, 02:01 Jim Klimov <jimklimov+nut at gmail.com> wrote:> 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220403/67792b92/attachment.htm>
Hello all, Having 10 days since an rc1 and a number of issues fixed and late-coming features integrated, I'm rolling the dice again with NUT v2.8.0-rc2 Hope it brings no bad surprises either :) Jim Klimov On Fri, Apr 1, 2022, 02:01 Jim Klimov <jimklimov+nut at gmail.com> wrote:> 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220410/544da1ae/attachment.htm>
I updated git to bce1d5201679e0dd64a839ceaaf47dc14c3c6a16 and got a build failure in the docs. The problem seems to be </refsect2> which xmllint says does not follow the DTD. I don't see how this can build for anyone else. Making all in docs Making all in man DOC-MAN Generating nut.conf.5 DOC-MAN Generating ups.conf.5 DOC-MAN Generating upsd.conf.5 DOC-MAN Generating upsd.users.5 DOC-MAN Generating upsmon.conf.5 DOC-MAN Generating upssched.conf.5 DOC-MAN Generating nutupsdrv.8 a2x: ERROR: "xmllint" --nonet --noout --valid "/home/n0/gdt/SOFTWARE/IOT/nut/obj/docs/man/tmp/man8.nutupsdrv.8.7370/nutupsdrv.xml" returned non-zero exit status 4 mv: rename ./tmp/man8.nutupsdrv.8.7370/nutupsdrv.8 to ./nutupsdrv.8: No such file or directory *** Error code 1