NUT 2.8.4 ./configure error

[teoberi]

./configure
CPPFLAGS="-O2 -D_FORTIFY_SOURCE=3"
CFLAGS="-fPIC -pie -fstack-protector-strong"
CXXFLAGS="-fPIC -pie -fstack-protector-strong"
LDFLAGS="-Wl,-z,now,-s,--enable-new-dtags"
--build=x86_64-slackware-linux
--disable-static
--without-python2
--without-ssl
--without-usb
--with-user=nut
--with-group=nut

configure: Got explicit list of document formats to build or not: man=auto; formats not listed will be silently skipped
checking whether to requested to build and install documentation... 'man=auto' => 'man=auto'
checking desire and ability to build man documentation... auto
checking if we can build man... yes
checking whether to would build specific documentation format(s)... yes man-man mans-progs-built
configure: error: Can not enable WITH_CHANGELOG_HTML_SINGLE due to build settings or environment

Crude solution, adding to the configuration options:
--enable-docs-changelog=no

[jimklimov]

Thanks, also hit that in CI builds. First guessed it misfired for tagged builds where the changelog part since last tag (esp. for final release) is empty, but at least this one was about #3019 by default requiring the changelog to be enabled when building (pre-)release tagged commits. So requiring tools to be present and enabled - but the default --with-doc=man=auto did not check/enable HTML/PDF building ability.

Hopefully v2.8.4-rc3 fixes this.

Initial release attempt demoted to v2.8.4-rc1.

[jimklimov]

With v2.8.4-rc4, that requirement to enable changelog was commented away (became a logged recommendation), so build scenarios on CI systems without docs tools and/or without ci_bulid.sh that added a workaround based on envvars, would pass.

The idea was to stress for packagers that when they build NUT releases, their build environment toolkits should be as full and capable as possible, to produce the best results we can (and/or to be explicit what we do not produce those). I guess commenting that away forfeits this fine goal too; maybe would find a way to catch both birds in a later release.

[bjornfor]

The idea was to stress for packagers that when they build NUT releases, their build environment toolkits should be as full and capable as possible, to produce the best results we can (and/or to be explicit what we do not produce those).

That's fine, but perhaps bump at least the minor version number for such changes? I was surprised to see build breakage in a patch update.

[jimklimov]

That is a reasonable request; unfortunately for a few decades NUT semver usage is a bit skewed in that regard. Like 3.x is "reserved" for a rewrite to C++ (or maybe Rust nowadays?) which is logged for 10 or 15 years or so. And scripts expecting more or less alphanumeric comparisons (so single-digit version components) do not help either. And releases being now sped up to have more than one in a year certainly still exceed the tolerance for what a "patch" number bump wold be by just collecting a lot of stuff since the last release (being snapshots of a master branch - and that also does not lend itself to proper tracking of e.g. Major.Minor releases as such, and Patch ones as branches for hotfixes).

I agree these are all true problems (at least in not being what the world expects of semver, or myself in other projects for that matter), and that recent hiccup with several errata in what was named NUT v2.8.3 could have been a few committed fixes for next patch versions, while "real work" marches on to be released in 2.9.x... But with the NUT team as small as it is, some corners get cut apparently. Some even before my time.

Maybe a later Major.Minor release would set the healthier trend.

As for the build breakage per se - I was surprised too; CI builds (of not-tagged code) went along with that PR's change just fine.