similar to: Question about nut-dependencies

On Aug 21, 2024, at 12:34?PM, Heath Smith via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote: > > 1) Who is deciding what goes in to fink and port packages? Do the maintainers of NUT have any say with fink, Mac Ports, and Home Brew (for MacOs machines)? > As Jim mentioned, the distributions like Fink and MacPorts are free to choose the subset of dependencies that they

Packaging issues would be brought up with the distro... I have recently worked with Homebrew on a Mac VM for the CI farm, but otherwise have no clue about the ecosystem. Last saw/touched a physical Mac in school, 1994 or so :D Upsmon as such has no need for XML (libneon et al); that would be nut-scanner and the Eaton NetXML protocol driver. On Wed, Aug 21, 2024, 18:59 Heath Smith via Nut-upsuser

Well, NUT does "since forever" have reference docs on packaging into 8 or so entities each with its dependency tree, so heavy stuff can be pulled in on a need-to-have basis. As anything, it can be improved and updated, but it is there and many systems follow it. Those who missed the memo... the onus is on them. The `nut-scanner` tool (and its lib) design using run-time `dlopen()` of

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes: > Upsmon as such has no need for XML (libneon et al); that would be > nut-scanner and the Eaton NetXML protocol driver. Sure, but it is normal for packaging systems to build the entire project, so that whatever someone wants is available, and thus depend on the union of the dependencies. That's what

I've created fink packaging for a building the llvm and llvm-gcc-4.2 svn pulls under fink on Mac OS X. Hopefully the fink info script and patch should be clear enough for some comments on my build approach. The llvm-gcc and llvm-g++ compilers seem okay so far. The llvm-gfortran compiler seems to always spew a warning.. WARNING: 128-bit integers not supported! ...even when just compiling a

Hi all, some time ago I bought at discount price a NMC for managing a few computers using the programmable outlets features available on my MGE Evolution, unuseful otherwise (ATM). However, expecially for my server machine, I don't like very much the NSM client provided by MGE/Eaton and I'd rather use only NUT from my distribution. So, looking at the netxml-ups driver, I started adding

I also operate an HP T1500 G3 which it's an Eaton made UPS. Connected on usb i get frequent communication errors and data aquisition stopped. Mine has a serial connection, also. Operating via serial has no trouble. Maybe it's something related to usb setting in bios, i.e. Legacy mode, speed setting, etc. However on serial mode looks like the eaton or hoe power protector software does not

Hello all, I have exhausted my research and need a little help with some basic concepts. First time configuration working with NUT and putting into a OS X environment. Was able to install the package using Brew. Have read the documentation and have been able to get the server running and agent running using MACOSX-UPS driver and connect to UPS via USB. I would however like to integrate a TrippLite

On Thu, 6 Feb 2020, Hisashi T Fujinaka wrote: > Built and passed tests on NetBSD-9_RC2 on amd64 and on NetBSD-current on > amd64. Issues with MacOS Catalina: > configure: error: *** working libcrypto not found, check config.log AFAIK MacOS no longer includes libcrypto or headers in the base operating system, so you'll either need to compile them yourself or install them via

Hello, we try to use Network UPS tools to monitor a network connected Eaton 93PS UPS. It basically works but we get frequent "Data is stale - check driver" warnings with a "data is no longer stale" shortly after in the log. We tried both snmp-ups and netxml-ups driver and both raise the same error. If have captured the communication between nut and UPS but all

The new cmake 3.7.0-rc1 release produces a stage2 bootstrap failure in openmp project build on OS X 10.11 under Xcode 8.... In file included from /sw/src/fink.build/llvm40-4.0.0-1/llvm-4.0.0.src/projects/openmp/runtime/src/kmp_alloc.c:16: In file included from /sw/src/fink.build/llvm40-4.0.0-1/llvm-4.0.0.src/projects/openmp/runtime/src/kmp.h:98:

Current llvm svn fails make check when built for only x86... [100%] Running the LLVM regression tests FAIL: LLVM :: DebugInfo/inlined-vars.ll (3994 of 7466) ******************** TEST 'LLVM :: DebugInfo/inlined-vars.ll' FAILED ******************** Script: -- /sw/src/fink.build/llvm33-3.3-0/llvm-3.3/build/bin/./llc -O0 <

Hi Devs, do you have an estimate for a new release date? We want to deploy linux boxes which will include support for the newly contributed phoenixcontact_modbus driver. As we would like to create a package for both CentOS and an embedded Linux device we have, we would prefer if the package was based on a official release. If 2.7.5 is not coming soon (say 1 week) do you have a suggestion of a

At 167457 on x86_64-apple-darwin12, I am seeing a slew of AddressSanitizer failures due to unresolved symbols such as... Exit Code: 1 Command Output (stderr): -- Undefined symbols for architecture x86_64: "___asan_init", referenced from: _asan.module_ctor in shared-lib-test-so-moBSTe.o "___asan_register_globals", referenced from: _asan.module_ctor in

Thanks for the response, Roger. On 7/31/2024 12:19 AM, Roger Price wrote: > On Tue, 30 Jul 2024, Harlan Stenn via Nut-upsuser wrote: > >> I've got a client who lives in an area where there are now frequent >> power outages that last for several hours at a time. > > I live in an area with frequent power outages, so I use a nut > configuration [1] which shuts down

> Is there anything I can do to make the build more verbose so I can debug this? make VERBOSE=1

Good day! This is just a reminder that branching for the 3.4 release will occur at this time: Monday, November 18, 2013 at 7:00:00 PM PST / Tuesday, November 19, 2013 at 3:00:00 AM UTC What this means for you! ------------------------ * Please keep the release notes up to date -- There has been very few commits to them. Please be proactive and update them with any significant feature that was

On Wed, Mar 20, 2013 at 6:42 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > Current llvm svn fails make check when built for only x86... Ah, right, need to put that behind a "requires"... hrm. (or I could just drop it & let the machines that are armv5 native catch this) > > [100%] Running the LLVM regression tests > FAIL: LLVM ::

i'd like to install nut on Mac OS X 10.4.9; i can't seem to get the Fink install to work (notes below), and i'm only semi-facile at command line installs; is installing nut on Mac OS X as simple as "make install" and no dependencies? if not is there a summary of what i'd need to do? regarding nut on Fink: based on a note in this list's archive i found that nut

I hope this is addressed by r177545 - please let me know if this test is still failing for you after that change. On Wed, Mar 20, 2013 at 8:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Mar 20, 2013 at 6:42 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: >> Current llvm svn fails make check when built for only x86... > > Ah, right, need to put