Hello all, Due to some issues uncovered with NUT v2.8.3 release on one hand (fixable, but cumbersome for packagers to extract and patch in their recipes), and an upcoming hiatus due to vacation travels on another, I've pushed much of the more-ambitious plan slated for NUT v2.8.4 back to v2.8.5, and plan to release what has cropped up until now as a smaller v2.8.4 increment, just a few months after a preceding release. This is probably how things should be (aiming for smaller quicker releases), too :) Even so, it is by no means a trivial hot-fixing release - there were many contributions that have already landed, including new drivers, updates to existing drivers and other programs, recipes, CI tests, etc. While a few smaller PRs are still queued and iterated, it would be wise of the community to run some builds of the current master against their devices in their OS ecosystems of choice, to make sure we do not get big facepalms within a week after a release :) The plan is to cut off a snapshot of the `master` branch (slightly pre-doctored as usual) into a NUT v2.8.4 release, and so begin the v2.8.5 timeline, during the first week of August, probably before next Friday. Or forever hold our silence (that is, until September or later). Cheers, Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250801/bcddb902/attachment.htm>
Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes:> While a few smaller PRs are still queued and iterated, it would be wise > of the community to run some builds of the current master against their > devices in their OS ecosystems of choice, to make sure we do not get big > facepalms within a week after a release :)My usual request is that if there is going to be a release (which is great), then we need a decent interval -- nominally a week -- after freeze for everthing but typos and version changing, before release. I don't know what the "smaller PRs" are, and I don't mind testing now and refreshing the build to test again. But if we want a good release we really need to stop making changes and have a testing period. Making that short discourages people from testing.> The plan is to cut off a snapshot of the `master` branch (slightly > pre-doctored as usual) into a NUT v2.8.4 release, and so begin the v2.8.5 > timeline, during the first week of August, probably before next Friday. Or > forever hold our silence (that is, until September or later).Given that you seem to intend to still merge things (unless the merges end today), that's too fast, but otherwise sounds good. My first-stage build (not in pkgsrc) has finished build/check/dist on NetBSD 10 amd64. On to building the distfile with pkgsrc, then on older NetBSD and on arm and arm64, and live-testing with Best Fortress.
I'm getting a build failure under pkgsrc. This is likely due to
introduction of a sed construct not specified by POSIX. Posting first
before thinking due to threatened short timeframe :-)
/usr/bin/make all-recursive
Making all in .
Making all in NIT
SUBDIR-MAKE SUCCESS: 'make all' in tests
SUBDIR-MAKE STARTING: 'make prep-src-docs' in docs ...
SUBDIR-MAKE SUCCESS: 'make prep-src-docs' in docs
SUBDIR-MAKE STARTING: 'make all' in docs ...
Making all in cables
DOCS_NO_MAN SKIP: all-optional called in docs/man/Makefile: requested to
not work in this code path
DOC-FOLLOW-UP Basic 'make all' in
/tmp/work/wip/ups-nut/work/nut-2.8.3.724/docs is done, following up with
'make doc' to ensure complex document types
DOC-CHANGELOG-GENERATE-WRAPPER ../ChangeLog : call parent Makefile to
decide if (re-)generation is needed
DOC-CHANGELOG-GENERATE
/tmp/work/wip/ups-nut/work/nut-2.8.3.724/ChangeLog : SKIP (keep existing)
Using distributed ChangeLog file from sources (and builddir is srcdir)
DOC-NOT-MAN SKIP: man-man called in docs/Makefile
DOC-CHANGELOG-ASCIIDOC ../ChangeLog => ../ChangeLog.adoc : Block
for up to 10 sec, maybe another thread will make the file first
DOC-CHANGELOG-ASCIIDOC ../ChangeLog => ../ChangeLog.adoc :
GENERATE
DOC-CHANGELOG-ASCIIDOC ../ChangeLog => ../ChangeLog.adoc :
PROCEED, waited for 10 sec
sed: 1: "s,^\(\s\s*\)\([0-9]\),\ ...": RE error: trailing backslash
(\)
*** [../ChangeLog.adoc] Error code 1
make[3]: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724/docs
1 error
make[3]: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724/docs
*** [all] Error code 2
make[2]: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724/docs
1 error
make[2]: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724/docs
SUBDIR-MAKE FAILURE: 'make all' in docs
*** [all/docs] Error code 2
make[1]: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724
1 error
make[1]: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724
*** [all-fanout-maybe] Error code 2
make: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724
1 error
make: stopped in /tmp/work/wip/ups-nut/work/nut-2.8.3.724
*** Error code 2
Stop.
make[1]: stopped in /n0/gdt/pkgsrc-current/pkgsrc/wip/ups-nut
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/wip/ups-nut
Other issues:
-with-doc is very confusing. There is talk of "traditional",
"legacy", and other mumbo jumbo, but I can't tell from reading
configure.ac what is the documented, preferred option, and what is
accepted for compatibility. I also can't tell if, when building
from a tarball with docs, this results in not getting docs
(unacceptable in a package), or installing the ones that were built
and not rebuilding.
FWIW, I did merge the previously queued "small PRs", now probably gotta figure out what Greg found with pkgsrc's `sed` (or await his PR with a fix that would work everywhere - can't reproduce the problem so far), and planned changes will be done. If there's something to clarify about dcs - PRs are always welcome, though not sure this would hold up a release. Regarding `configure --with-doc(s)` and related options -- there indeed is a big can of worms due to portability and tools availability and standard expectations. TLDR summary of decades-long history, legacy and recent: On one hand, a build is expected to deliver man pages. Historically *roff files were directly edited and served by projects; nowadays it is asciidoc or similar, rendered into man pages as one of many output formats. Dist tarballs include those page files so they can be installed even where asciidoc renderer is not available. So some options manage this part. Another issue is the codes assigned to man page sections in different OSes - this was previously bolted to what is seen in Linux and FreeBSD; now can be amended for package builds (especially on other platforms), to avoid clumsy distro-specific patch files or scripts in their recipes. And another aspect regards other rendering formats (HTML*, PDF). Hope this helps, Jim Klimov On Fri, Aug 1, 2025, 10:19 Jim Klimov <jimklimov+nut at gmail.com> wrote:> Hello all, > > Due to some issues uncovered with NUT v2.8.3 release on one hand > (fixable, but cumbersome for packagers to extract and patch in their > recipes), and an upcoming hiatus due to vacation travels on another, I've > pushed much of the more-ambitious plan slated for NUT v2.8.4 back to > v2.8.5, and plan to release what has cropped up until now as a smaller > v2.8.4 increment, just a few months after a preceding release. This is > probably how things should be (aiming for smaller quicker releases), too :) > > Even so, it is by no means a trivial hot-fixing release - there were > many contributions that have already landed, including new drivers, updates > to existing drivers and other programs, recipes, CI tests, etc. > > While a few smaller PRs are still queued and iterated, it would be wise > of the community to run some builds of the current master against their > devices in their OS ecosystems of choice, to make sure we do not get big > facepalms within a week after a release :) > > The plan is to cut off a snapshot of the `master` branch (slightly > pre-doctored as usual) into a NUT v2.8.4 release, and so begin the v2.8.5 > timeline, during the first week of August, probably before next Friday. Or > forever hold our silence (that is, until September or later). > > Cheers, > Jim Klimov > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250802/263185eb/attachment.htm>
As some have already noticed, the labours of issuing NUT v2.8.4 have begun. The first shot looked promising, so the nut-website and similar resources began their updates, but eventually that commit got demoted to v2.8.4-rc1, and now iterating with rc4 to fix this hiccup: https://github.com/networkupstools/nut/issues/3053 Now this one looks promising (essentially, disables the change which misfired), so hopefully me and CI systems would complete the release properly during the day. Hope this helps, Jim Klimov On Fri, Aug 1, 2025 at 10:19?AM Jim Klimov <jimklimov+nut at gmail.com> wrote:> Hello all, > > Due to some issues uncovered with NUT v2.8.3 release on one hand > (fixable, but cumbersome for packagers to extract and patch in their > recipes), and an upcoming hiatus due to vacation travels on another, I've > pushed much of the more-ambitious plan slated for NUT v2.8.4 back to > v2.8.5, and plan to release what has cropped up until now as a smaller > v2.8.4 increment, just a few months after a preceding release. This is > probably how things should be (aiming for smaller quicker releases), too :) > > Even so, it is by no means a trivial hot-fixing release - there were > many contributions that have already landed, including new drivers, updates > to existing drivers and other programs, recipes, CI tests, etc. > > While a few smaller PRs are still queued and iterated, it would be wise > of the community to run some builds of the current master against their > devices in their OS ecosystems of choice, to make sure we do not get big > facepalms within a week after a release :) > > The plan is to cut off a snapshot of the `master` branch (slightly > pre-doctored as usual) into a NUT v2.8.4 release, and so begin the v2.8.5 > timeline, during the first week of August, probably before next Friday. Or > forever hold our silence (that is, until September or later). > > Cheers, > Jim Klimov > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250808/6d0a09bd/attachment.htm>
And, it is live! (again) CI passed, tarball and NUT for Windows build zip published (nut-website and github release) See y'alls next month! Jim Klimov On Fri, Aug 1, 2025, 10:19 Jim Klimov <jimklimov+nut at gmail.com> wrote:> Hello all, > > Due to some issues uncovered with NUT v2.8.3 release on one hand > (fixable, but cumbersome for packagers to extract and patch in their > recipes), and an upcoming hiatus due to vacation travels on another, I've > pushed much of the more-ambitious plan slated for NUT v2.8.4 back to > v2.8.5, and plan to release what has cropped up until now as a smaller > v2.8.4 increment, just a few months after a preceding release. This is > probably how things should be (aiming for smaller quicker releases), too :) > > Even so, it is by no means a trivial hot-fixing release - there were > many contributions that have already landed, including new drivers, updates > to existing drivers and other programs, recipes, CI tests, etc. > > While a few smaller PRs are still queued and iterated, it would be wise > of the community to run some builds of the current master against their > devices in their OS ecosystems of choice, to make sure we do not get big > facepalms within a week after a release :) > > The plan is to cut off a snapshot of the `master` branch (slightly > pre-doctored as usual) into a NUT v2.8.4 release, and so begin the v2.8.5 > timeline, during the first week of August, probably before next Friday. Or > forever hold our silence (that is, until September or later). > > Cheers, > Jim Klimov > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250809/fe85828a/attachment.htm>