similar to: Happy New Year 2024

Hello all, For decades, the NUT project ran without any formal entity or a "money purse" of its own. This proved to be a somewhat limiting factor, since paid services like DNS have to be covered by maintainers (as in ancient times, when city celebrations were paid by randomly elected officials personally), and some other services like hosting for the NUT CI farm have to be solicited

Hello all, For decades, the NUT project ran without any formal entity or a "money purse" of its own. This proved to be a somewhat limiting factor, since paid services like DNS have to be covered by maintainers (as in ancient times, when city celebrations were paid by randomly elected officials personally), and some other services like hosting for the NUT CI farm have to be solicited

Let's hope it will prove to be better than the last... several. Season's greetings and best regards, Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20221231/44b09461/attachment.htm>

Let's hope it will prove to be better than the last... several. Season's greetings and best regards, Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20221231/44b09461/attachment.htm>

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

Hello Jim, That?s a great help for me. You?re a so kind person ~ Our engineer download the branches f17d9f5 as below and repackage it for test. After testing, The Beta NUT works well with ST VID "0x0483", PID "0xA430. Please tell me how to speed up for merging this to formal version. May I have your predict schedule if possible? Thanks.

Hello fellow NUT users and contributors! A lot has happened during the past months, culminating with last Friday of July (Sysadmins' Day) as a reasonable moment to mark a milestone. Sorry, not yet NUT 2.7.5, but with CI make-over to help it happen. As some may know, we were using the public Travis CI offering, and just as that multi-platform setup was nearing perfection (ha-ha) with dozens

Hello fellow NUT users and contributors! A lot has happened during the past months, culminating with last Friday of July (Sysadmins' Day) as a reasonable moment to mark a milestone. Sorry, not yet NUT 2.7.5, but with CI make-over to help it happen. As some may know, we were using the public Travis CI offering, and just as that multi-platform setup was nearing perfection (ha-ha) with dozens

Hello, and thanks for the clarifications. As described, the change does not seem to be too complex on the NUT project's side, the PR posted below took about an hour with some research and this write-up, so I'm not sure I can put a price tag on it :) A donation at https://opencollective.com/networkupstools or https://github.com/sponsors/networkupstools would be welcome though, more so a

Windoze in da NUT house! Codebase of the NUT for Windows branch was merged to main codebase, not in the least to avoid bit-rot and need for resynchronisation with merge conflicts that regularly arose as the two branches "just co-existed". More community work is needed to complete some drivers' functionality and MSI package delivery, but for many use-cases it may already "just

Windoze in da NUT house! Codebase of the NUT for Windows branch was merged to main codebase, not in the least to avoid bit-rot and need for resynchronisation with merge conflicts that regularly arose as the two branches "just co-existed". More community work is needed to complete some drivers' functionality and MSI package delivery, but for many use-cases it may already "just

Cheers all, you may have seen related preparatory news on the NUT website or in the README changes, but now the next step is official: The fine folks at DigitalOcean approved FOSS sponsoring credits to re-host the custom-built multi-platform non-regression NUT CI farm, which builds several hundred scenarios per iteration (to cover a matrix with many OSes, toolkit versions and

Cheers all, you may have seen related preparatory news on the NUT website or in the README changes, but now the next step is official: The fine folks at DigitalOcean approved FOSS sponsoring credits to re-host the custom-built multi-platform non-regression NUT CI farm, which builds several hundred scenarios per iteration (to cover a matrix with many OSes, toolkit versions and

Jim Klimov <jimklimov+nut at gmail.com> writes: > By the way, on the NUT CI farm the libwrap is present on some (though not > all) systems - covering linux, freebsd, openindiana... and neither > complained about `sockdebug` :\ > > What version do you have? Maybe it is some alternate implementation? Looks like 7.4, as amended in NetBSD over the years. Looks like the

"Good news, everyone!" With CI builds of the branch now regularly passing on both the multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including integration tests with live upsd and some dummy-ups instances), after ironing a few wrinkles I intend to PR and merge it into the main NUT codebase soon,

"Good news, everyone!" With CI builds of the branch now regularly passing on both the multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including integration tests with live upsd and some dummy-ups instances), after ironing a few wrinkles I intend to PR and merge it into the main NUT codebase soon,

Thanks again for all the suggestions. For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology. Now that we know where to change it, should not be too great a hassle to replace again by some other choice... subordinate was a bit too long to type :) To make the election of team choice more simple, I

Thanks again for all the suggestions. For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology. Now that we know where to change it, should not be too great a hassle to replace again by some other choice... subordinate was a bit too long to type :) To make the election of team choice more simple, I

Errata coming up for NUT v2.8.2: * it was discovered that the nut-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its