Skip to content

Upstreaming improvements from 42ity/nut fork #1316

Open

Description

@jimklimov

A lot of work on NUT was done under the auspices of Eaton-backed 42ity project, as well as some earlier bundled releases that became part of its codebase. While much of the development was cross-posted for PRs, some was only pursued in the fork to perfect there first. 42ity took the decision to eventually move from the burden of maintaining a separate fork (thereby regularly solving merge conflicts) towards using the "upstream NUT" codebase directly, so I imported the "FTY" branch and identified the largest differing subjects to reconcile between the two:


Notes about known feature changes between the forks (as of comparison in early 2022, before some of these changes got upstreamed in e.g. #320):

  • mibs=eaton_epdu
    ** added "device.N.outlet.switchable" fields
    ** renamed the value of "ambient.contacts.N.status" from "opened" to "open"; note they are "opened" in other MIBs as seen below
-ambient.contacts.1.status: opened
+ambient.contacts.1.status: open
+outlet.switchable: yes

** "device.N.input.feed.desc", "device.N.outlet.M.name", separated "device.N.outlet.group.M.name" vs. "device.N.outlet.group.M.desc" (also added "device.N.outlet.switchable")
** NOTE: compared to those master-branch builds, LOST phase info "outlet.group.N.phase" however maybe only for single-phase devices? seems there is a rename for three-phased ones:

### 1ph:
-outlet.group.1.phase: L1
-outlet.group.2.phase: L1

### 3ph:
+outlet.group.1.desc: Section A
-outlet.group.1.name: Section A
-outlet.group.1.phase: L1
+outlet.group.1.name: A
+outlet.group.1.phase: 1-N
+outlet.group.2.desc: Section B
-outlet.group.2.name: Section B
-outlet.group.2.phase: L2
+outlet.group.2.name: B
+outlet.group.2.phase: 2-N
+outlet.group.3.desc: Section C
-outlet.group.3.name: Section C
-outlet.group.3.phase: L3
+outlet.group.3.name: C
+outlet.group.3.phase: 3-N

...and in at least one case for one phase also (but that may be some experimental ePDU? its data dump includes three separate input phase data collections, but just one outlet group... can that be a three-phase outlet actually?):

+input.feed.desc: Feed A
+outlet.1.name: A1
+outlet.group.1.desc: Section A
-outlet.group.1.name: Section A
-outlet.group.1.phase: L1
+outlet.group.1.name: A
+outlet.group.1.phase: 1-N
  • mibs=pw
    ** between 42ity/nut versions, iteratively added lots of info categories for ambient sensors; listing some unique-name samples here:
+ambient.1.contacts.1.config: normal-opened
+ambient.1.contacts.1.name: EMPDT1H1C2 @1-C1
+ambient.1.contacts.1.status: inactive
...
+ambient.1.humidity.status: good
+ambient.1.id: d01fd439-a44e-5367-bc99-5b5108c9abc5
+ambient.1.mfr: Eaton
+ambient.1.model: Eaton EMPDT1H1C2
+ambient.1.name: EMPDT1H1C2 @1
+ambient.1.present: no
+ambient.1.serial: GBxxxxxxxx
+ambient.1.temperature.status: good
+ambient.1.temperature.unit: celsius
...
+ambient.contacts.1.name: EMPDT1H1C2 @1-C1
+ambient.contacts.2.name: EMPDT1H1C2 @1-C2

...and "outlet.N.status" and "outlet.switchable" where applicable (UPS):

...
+outlet.1.status: on
+outlet.2.status: on
+outlet.switchable: yes

** compared to upstream, added "ambient.contacts.N.status" status (note "opened" not "open" here, while "ambient.N.contacts.M.status" flip between "active"/"inactive") and changed "ups.type" reading, and added "outlet.N.status" and "outlet.switchable" for UPS:

+ambient.contacts.2.name: EMPDT1H1C2 @1-C2
+ambient.contacts.2.status: opened
+outlet.1.status: on
+outlet.2.status: on
+outlet.switchable: yes
-ups.type: high efficiency
+ups.type: On-Line UPS, Single Phase
  • mibs=pxgx_ups
    ** added "ambient.contacts.N.name" and "outlet.N.status"
    ** Compared to master builds (same for 20190711, 20211102_a12302c90ae) added more (note: "opened" not "open"):
+ambient.contacts.1.name: Input \#1
+ambient.contacts.1.status: opened
+ambient.contacts.2.name: Input \#2
+ambient.contacts.2.status: closed
+device.contact: Team
+device.location: Rack
+outlet.1.status: on
+outlet.2.status: on
-ups.type: normal
+ups.type: On-Line UPS, Single Phase
  • mibs=mge
    ** Compared to master builds, added "ambient.contacts.N.status" (note: "opened" not "open") and "device.contact"/"device.location":
+ambient.contacts.1.status: opened
+ambient.contacts.2.status: closed
+device.contact: Team
+device.location: Rack
  • mibs=ietf
    ** Compared to master builds, added device.contact and device.location like above

Also it would help migrations and refactoring with peace of mind, if the 42ity/nut codebase passed same CI requirements as the upstream NUT. Some notes in this regard:

The work about bug-fixing is quite iterative and "simple" structurally, after all the recent improvements that landed in NUT and its recipes already:

:; git clone -b FTY https://github.com/42ity/nut .
:; BUILD_WARNFATAL=yes BUILD_WARNOPT=medium CANBUILD_DRIVERS_DMF=yes BUILD_TYPE=default-alldrv ./ci_build.sh

...and read the warnings which pop up, fix them, make until the recipe looks okay.

Note how many of these warnings follow some same pattern; it makes sense to address each "family" separately, possibly coming up with some common systemic solution.
In a few cases warnings may be mis-fires from the static analyser in compiler, and pragmas would be used to quiesce them - see precedent to check and define the platform support for particular pragmas and warning options.
In many cases note the mess with integer types - prefer fixed-width types (rather than architecture-dependent int/short/long) and particular signedness following system headers; particularly note e.g. ssize_t (rarely) or size_t (often) for read sizes, array sizes, memory buffer sizes etc. instead of opportunistic int. All this is related to range-checks in many cases, with "tautology" quiesced by pragmas because on some platforms the check is pointless and protects against the other platforms.
Then post a PR to have NUT CI farm go at it, using a hundred combos on different platforms and toolkit versions.
See docs/config-prereq.txt for different platform setup notes, to reproduce faults in local VMs.
Repeat until NUT CI passes green.

Currently known issues fall into just a few buckets:
Helper script _wsum to summarize issues:

#!/bin/sh
date; \
echo "Making whatever succeeds"; \
make -j -k >/dev/null 2>&1; \
echo "Making for error report"; \
make -k > wall.tmp 2>&1 ; \
mv -f wall.tmp wall; \
egrep '\[K?-Werror' < wall > wsum \
&& awk '{print $NF}' < wsum | sort | uniq -c | sort -n > wsum.count \
&& wc -l wsum >> wsum.count \
&& cat wsum.count

Example run:

$ ./_wsum 
February  2, 2022 at 02:58:20 PM CET
Making whatever succeeds
Making for error report
      1 [-Werror=pedantic]
      1 [-Werror=unused-parameter]
     39 [-Werror]
    697 [-Werror=missing-field-initializers]
738 wsum

The few errors above are about definitions:

scan_snmp.c:106:13: error: redefinition of typedef 'bool_t' [-Werror=pedantic]

../../include/config.h:29: error: "BINDIR" redefined [-Werror]
../../include/config.h:32: error: "CGIPATH" redefined [-Werror]
../../include/config.h:35: error: "CONFPATH" redefined [-Werror]
../../include/config.h:47: error: "DATADIR" redefined [-Werror]
../../include/config.h:51: error: "DEFAULT_DMFNUTSCAN_DIR" redefined [-Werror]
../../include/config.h:55: error: "DEFAULT_DMFNUTSCAN_RES_DIR" redefined [-Werror]
../../include/config.h:58: error: "DEFAULT_DMFSNMP_DIR" redefined [-Werror]
../../include/config.h:61: error: "DEFAULT_DMFSNMP_RES_DIR" redefined [-Werror]
../../include/config.h:64: error: "DRVPATH" redefined [-Werror]
../../include/config.h:812: error: "HTMLPATH" redefined [-Werror]
../../include/config.h:815: error: "LIBDIR" redefined [-Werror]
../../include/config.h:818: error: "LIBEXECDIR" redefined [-Werror]
../../include/config.h:914: error: "SBINDIR" redefined [-Werror]

drivers/eaton-pdu-marlin-mib.c:825:42: error: unused parameter 'daisy_dev_list' [-Werror=unused-parameter]

...and a large amount of same error with missing field initializers for snmp_info_t tables (DMF codebase has more fields there, aiming for more conversion function types; if that approach survives - an initialization macro may be due to substitute the NULLs where no value was given).

Activity

  1. added
    CIEntries related to continuous integration infrastructure (here CI = tools + scripts + recipes)
    refactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warnings
    on Feb 25, 2022
  2. added this to the 2.8.1 milestone on Apr 24, 2022
  3. modified the milestones: 2.8.1, 2.8.2 on Jan 6, 2023
  4. added
    DMFNUT Data/Dynamic Mapping File/Format/Functionality feature
    on Oct 16, 2023
  5. jimklimov commented on Apr 4, 2024

    @jimklimov
    MemberAuthor

    Updated checklist above with achievements around PR #2275 which merged current master into FTY branch so it built green for the first time, and ported back the installer, nutconf and some smaller fixes to minimize the difference - those became part of recent NUT v2.8.2 release.

  6. modified the milestones: 2.8.2, 2.8.3 on Apr 4, 2024
  7. added a commit that references this issue on Jun 24, 2024
  8. jimklimov commented on Jul 4, 2024

    @jimklimov
    MemberAuthor
  9. modified the milestones: 2.8.3, 2.8.4 on Sep 12, 2024
  10. modified the milestones: 2.8.4, 2.8.5 on Aug 7, 2025
  11. jimklimov commented on Oct 24, 2025

    @jimklimov
    MemberAuthor

    There was some recent development landing into https://github.com/42ity/nut/tree/work/fix-deb13 ; notable changes include:

    • MAC address support in snmp-ups
    • updates to several *-mib.c sources to pick up MACs from Eaton-branded/OEMed devices
    • updates to clients/nutclient.{h,cpp} introducing a ConnectionClient class
    • ...and some to MemClientStub class which now implements some methods it did not before, lost others, and inherits from ConnectionClient
    • somewhat evolved OBS/packaging scripting, but hard to judge quickly if there's anything to actually import (compared to what is arriving via PR CI: upstream OBS recipes from FTY branch #3144)
    • general code base in the branch is far behind, cca NUT v2.8.1 release => @arnaudquette-eaton as a side product of these comparisons, I've prepared a merge from upstream/master (without an upstreamed version of OBS recipes at the moment) into your work/fix-deb13 branch, see https://github.com/jimklimov/nut/pull/new/FTY-work-fix-deb13-mergeFrom-upstream-20251024 so 42ITy NUT can be improved to post-2.8.4; there were a few merge conflicts but not as few as I feared initially :)

    Checked by ./ci_build.sh -- in the merged branch, C++ behaves a bit differently so make check failed (presence/lack of quotes around CERTFILE, arguably always having them is more correct - did not dig deeper though):

    FAIL: cppunittest
    =================
    
    D: Getting test suite...
    D: Preparing test runner...
    D: Setting test runner outputter...
    D: Launching the test run...
    ...............--- expected ---
    MAXAGE 15
    MAXCONN 1024
    STATEPATH "/var/run/nut"
    CERTFILE /usr/share/ssl-cert/ssleay.cnf
    LISTEN 127.0.0.1 3493
    LISTEN ::1 3493
    --- end ---
    --- serialized ---
    MAXAGE 15
    MAXCONN 1024
    ALLOW_NO_DEVICE 1
    STATEPATH "/var/run/nut"
    CERTFILE "/usr/share/ssl-cert/ssleay.cnf"
    LISTEN 127.0.0.1 3493
    LISTEN ::1 3493
    --- end ---
    F...................
    
    nutconf_ut.cpp:173:Assertion
    Test name: NutConfigUnitTest::testUpsdConfiguration
    assertion failed
    - Expression: 0
    - Configuration serialization check failed
    
    Failures !!!
    Run: 34   Failure total: 1   Failures: 1   Errors: 0
    D: Got to the end of test suite with code 'false'
    FAIL cppunittest (exit status: 1)
    

    The make check-NIT passes well.

  12. jimklimov commented on Oct 24, 2025

    @jimklimov
    MemberAuthor

    @arnaudquette-eaton : FWIW, some compilers disliked the C++ changes as they are now:

    In file included from nutclientmem.cpp:21:
    In file included from ./nutclientmem.h:26:
    ./nutclient.h:378:23: error: extra ';' after member function definition [-Werror,-Wextra-semi]
            ConnectionClient() {};
                                 ^
    ./nutclient.h:379:41: error: extra ';' after member function definition [-Werror,-Wextra-semi]
            virtual ~ConnectionClient() override {};
                                                   ^
    In file included from nutclientmem.cpp:21:
    ./nutclientmem.h:54:28: error: extra ';' after member function definition [-Werror,-Wextra-semi]
            void connect() override {};
                                      ^
    ./nutclientmem.h:55:31: error: extra ';' after member function definition [-Werror,-Wextra-semi]
            void disconnect() override {};
                                         ^
    In file included from nutclientmem.cpp:21:
    In file included from ./nutclientmem.h:26:
    ./nutclient.h:372:7: error: 'ConnectionClient' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Werror,-Wweak-vtables]
    class ConnectionClient : public Client
          ^
    5 errors generated.
    make[1]: *** [nutclientmem.lo] Error 1
      CCLD     libupsclient.la
    In file included from nutclient.cpp:27:
    ./nutclient.h:378:23: error: extra ';' after member function definition [-Werror,-Wextra-semi]
            ConnectionClient() {};
                                 ^
    ./nutclient.h:379:41: error: extra ';' after member function definition [-Werror,-Wextra-semi]
            virtual ~ConnectionClient() override {};
                                                   ^
    ./nutclient.h:372:7: error: 'ConnectionClient' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Werror,-Wweak-vtables]
    class ConnectionClient : public Client
          ^
    3 errors generated.
    make[1]: *** [nutclient.lo] Error 1
    
  13. modified the milestones: 2.8.5, 2.8.6 on Feb 12, 2026
  14. added a commit that references this issue on Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

C++CIEntries related to continuous integration infrastructure (here CI = tools + scripts + recipes)DMFNUT Data/Dynamic Mapping File/Format/Functionality featureSNMPenhancementnut-scannerpatchrefactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warnings

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions