Nut upsdev - Apr 2025 - NUT testing for v2.8.3 (hopefully imminent)

So, NUT v2.8.3-rc1 is out.

  I first thought it was the release, but some CI runs convinced me
otherwise, so there would be a bit of back and forth on the master branch
as some recipes get fixed. Apparently, some parallel runs stepped onto each
other's toes sometimes, but coinciding the wrong way just once in a few
hundred builds. Hopefully I found why and will re-publish in a few hours.

Jim Klimov


On Wed, Apr 2, 2025 at 10:57?AM Jim Klimov <jimklimov+nut at gmail.com>
wrote:
> So... April 1st came and went, busy with last-minute warnings from a newly
> set-up NetBSD build agent for the NUT CI farm, as Greg-inspired warnings
> exposed by the stricter platform kept popping up and biting.  Led to some
> discoveries in toolkits and standards I thought I knew for decades, too. So
> it was a tad bit annoying, but good overall :)
>
> But now we are a day over the hopeful "not more than a year"
since the
> last release... Still, maybe sometime later in the week all CI stars will
> converge to let the release be cut.
>
> Has any other platform got last-minute changes to tackle? Plan 9 maybe? :)
>
> Jim Klimov
>
> PS: Colleagues from another community pointed to
> https://tailscale.com/blog/tailscale-enterprise-plan-9-support - fun
> read, true story, true PRs; their request
> https://github.com/tailscale/tailscale/issues/5794 posted some 3 years
> ago got fulfilled just now.
>
>
> On Fri, Mar 28, 2025 at 10:27?AM Jim Klimov <jimklimov+nut at
gmail.com>
> wrote:
>
>> Hello all,
>>
>>   It has been too long that I was feeling a release is just around the
>> corner, just gotta tie up a few loose ends. The significant ones we had
are
>> finally tied, some others delayed to v2.8.4 trail, and a documentation
>> refresh remains. Thanks to some package maintainers taking a look at
the
>> master branch, some issues with "dist" archive creation and
parallel builds
>> were also located and addressed.
>>
>>   So, it is that time of the year again, folks, when flowers bloom and
>> code gets ripe for picking a new release snapshot -- so everybody is
>> welcome to give it a round during the weekend. After too many hopeful
>> deadlines missed, I hope to at least not exceed a year since the last
>> release snapshot :)
>>
>>   As usual,
>>
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
>> (and the build prerequisites linked from there as
>>
https://networkupstools.org/docs/user-manual.chunked/_build_prerequisites_to_make_nut_from_scratch_on_various_operating_systems.html)
>> should help you get started.
>>
>> Hoping for good news and no blocker issues,
>> Jim Klimov
>>
>> PS: One known problem remains with the recently introduced apc_modbus
>> driver and/or the libmodbus (core or our fork with rtu_usb branch) -
that
>> the USB connections tend to fall apart, as tracked at
>> https://github.com/networkupstools/nut/issues/2609 and others linked
>> from it - for now I've exhausted the hardware-less ideas and the
time I
>> had; help is welcome.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20250408/adda4b56/attachment.htm>

I'm starting down the path of testing.


There are commits in the rc tag that are not on master:

  $ git log --oneline ..v2.8.3-rc1
  3d286fb1b (tag: v2.8.3-rc1, jimklimov/pre-283-2) appveyor.yml: handle also FTY
and fightwarn branches
  4e92275c1 .github/workflows/codeql.yml: handle also FTY and fightwarn branches
  504706d45 Makefile.am: nut-scanner does directly depend on clients after all
  051b49d9f Revert "Revert "NEWS.adoc, UPGRADING.adoc,
docs/docinfo.xml.in: finalize text before NUT v2.8.3 release""
  70faea2af Revert "tools/gitlog2version.sh: bump
NUT_VERSION_DEFAULT=2.8.3.1 for next development cycle"
  e1d399b5e include/Makefile.am: nut_version.h: propagate failure (if there ever
is one) writing the temporary output
  a33fb1616 clients/Makefile.am: libupsclient-version.h: take a transactional
approach to changing (or not) the file others depend on

so all in all I find this far more confusing than it needs to be.



As an aside about CM practices:

  I think when there's an RC, then it should just be on master, with the
  idea that other changes are not allowed until release.  The current
  state is more confusing than necessary.

  Running 'git branch -a', there are 66.  I realize there are probably
  reasons for some of them to exist, but there are no many that the
  noise makes it harder to understand the repository.  I suggest
  removing most of them (or parking them in a private repo if it's
  really not ok to just remove them, but they don't have significant
  continuing value).

  There's no branch in the repo for the release.  (I prefer releases
  from master with other commits banned, but if it's not that way it
  needs a release branch.)

  (I realize nut does not have release branches to be able to make micro
  releases, and I realize we could create one retrospectively if that
  turns out to be necessary.  I'm ok with that as long as releases are
  from master.)