[Nut-upsuser] NUT v2.8.0(-rc1)

[Jim Klimov]

UPDATE: could not reproduce in Rocky Linux 8.5 nor Ubuntu 20.04, detailed
in issue #1344

On Sun, Apr 3, 2022, 12:16 Jim Klimov <jimklimov+nut at gmail.com> wrote:

> 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-upsuser/attachments/20220408/4f329eff/attachment.htm>