similar to: NUT on Windows revival

Back from vacations, and before I dive into real-life work, I went over some ideas and notes from the NUT for Windows effort. Now they should be tracked at https://github.com/orgs/networkupstools/projects/2/views/1 and community help is welcome :) I probably forgot or missed some caveats - so feel free to post issues for this project if you think of some more... Jim On Thu, Jun 23, 2022, 23:52

Back from vacations, and before I dive into real-life work, I went over some ideas and notes from the NUT for Windows effort. Now they should be tracked at https://github.com/orgs/networkupstools/projects/2/views/1 and community help is welcome :) I probably forgot or missed some caveats - so feel free to post issues for this project if you think of some more... Jim On Thu, Jun 23, 2022, 23:52

"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,

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

--- Sigmund Augdal <sigmunau@stud.ntnu.no> wrote: > On Sun, Mar 09, 2003 at 03:58:22PM +0100, Sander Roobol wrote: > > Hello Dan Johnson, hello list, > > > > It's really weird that there's no working command line player for > FLAC > > files. Dan Johnson created flac123 (licensed under the GPL) to fill > that > > gap, and started the flac-tools

On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote: > > running autogen.sh was triggered automatically. but even if I do it explicitly, I still get: > + autoreconf -i > configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

Hello Dan Johnson, hello list, It's really weird that there's no working command line player for FLAC files. Dan Johnson created flac123 (licensed under the GPL) to fill that gap, and started the flac-tools project. Unfortunately, flac123 doesn't work anymore with the latest FLAC, and the flac-tools project has been idle for more than a year. I created a patch that makes flac123

> Previously, the manufacturer tested this UPS on version 2.6.5-6 NUT for Windows. Thanks for this important detail. For immediate re-testing, I would recommend to use either NUT v2.8.0 already packaged by some distributions in their testing/bleeding-edge repositories (unfortunately, during the almost year since release many distros - especially for LTS versions - did not change recipes to

Cheers, One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 The gist of it is that "battery.voltage" and "battery.charge" were not always reported correctly with nutdrv-qx driver (might be handled better by blazer drivers though), and the overrides

On 06/18/2017 05:42 PM, Charles Lepple wrote: > On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant > <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote: >> >> running autogen.sh was triggered automatically. but even if I do it >> explicitly, I still get: >> + autoreconf -i >> configure.ac:887: warning: AC_LANG_CONFTEST: no

On up-to-date f36, with latest kernel 6.1.7-100.fc36.x86_64. After receiving a few of these messages Broadcast message from nut at e7.eyal.emu.id.au (somewhere) UPS ups at ups is unavailable I noticed and ran sudo systemctl restart nut-driver at ups.service which triggered Broadcast message from nut at e7.eyal.emu.id.au (somewhere) Communications with UPS ups at ups established I now added

On 12/03/2016 08:03 AM, Charles Lepple wrote: > On Dec 2, 2016, at 10:23 PM, Jack McGee <jack at greendesk.net> wrote: >> This is new install on Ubuntu 16.04, using packages from Synaptic, >> Network UPS Tools upsd 2.7.2 >> >> I am getting these messages in the terminal: >> Broadcast message from nut at amethi (somewhere) (Fri Dec 2 12:33:03 2016): >>

I upgraded an operating system to openSUSE 42.2, kernel 4.4 and recompiled nut 2.7.4. ./configure, make clean and make went well, but make install failed. Make reports Making install in clients make[1]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' make[2]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' /usr/bin/mkdir -p '/usr/lib64'

Hi, when building with the WITH_DEV conditional, either `libupsclient.pc' *or* `libupsclient-config' is installed. This is annoying when linking with libupsclient, because you basically have to do the check twice, once using `pkg-config' and once using `libupsclient-config'. Please consider the attached patch, which changes the behavior of `lib/Makefile.am' to install

Please do take over the pass revival. College hasn't left me with the bandwidth to continue this side project :) If there's small things here and there, I'd be happy to pitch in. However,.whipping the patch into shape is beyond me right now. Thanks Siddharth On Fri 23 Mar, 2018, 00:53 via llvm-dev, <llvm-dev at lists.llvm.org> wrote: > > >> This work could also

>> This work could also be used to fix [3]. Although this probably needs >> more though because there's the question of whether we should preserve >> existing debug information in an LLVM IR file or write over it when it >> is given to Clang. > > If foo.ll contains edited debug info, `clang -g` shouldn't silently drop > the edits. A warning + no-op seems

Hello together, after upgrading from nut 2.2.1 to nut 2.2.2, I noticed there's a (new?) libupsclient.so library. On my Redhat based system, f.e. the "upsc" binary links against it and is unhappy as the library is not included in the current RPM file. If you look at the .spec file for Redhat, the libupsclient.* stuff is included in the "nut-devel" package only. The SuSE

Dear developers, libnutclient has been added as a C++ alternative to libupsclient in 2.7.1. As a result I can't compile nut 2.7.3 with gcc-3.3.6. There wasn't such a problem with nut-2.6.5. Is it possible to add a configuration parameter like '-without-libnutclient' to provide better compatibility with older gcc versions please (since libnutclient is an alternative to