[Nut-upsdev] [Nut-upsuser] NUT v2.8.4 coming up

[Jim Klimov]

Thanks Greg,

  Regarding `\s` - good catch, as I read your post, I was sure it is used
all over the place... but in fact only in perl code (also Java/groovy in CI
libs), so not quite a GNU-only extension. Native Sun and BSD sed's were
okay with that too. Most shell code went with "[ ${TABCHAR}]" where
TABCHAR="`printf '\t'`" because indeed many sed's or especially grep's
treat direct `\t` as escaped character "t". Missed doing that here. Once!
And you got me on that! :D

  Truth be told, one script does mention `[[:blank:]]`.

  Regarding commentary on docs, fair enough about the configure.ac script,
but does at least `docs/configure.txt` explain it satisfactorily?

Jim

On Sat, Aug 2, 2025, 18:43 Greg Troxel via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>
> > FWIW, I did merge the previously queued "small PRs",
>
> Great, thanks.
>
> > now probably gotta
> > figure out what Greg found with pkgsrc's `sed` (or await his PR with a
> fix
> > that would work everywhere - can't reproduce the problem so far), and
> > planned changes will be done.
>
> This is not about pkgsrc's sed; it's about the sed that is part of the
> NetBSD base system, which is believed to conform to POSIX.  (When
> building under pkgsrc, the base sed is used even if gsed is installed,
> as part of repeatable build hygiene.)
>
> I am 99% sure that the problem is this, from doc/Makefile.am, building
> ChangeLog.adoc from ChangeLog:
>
>   -e 's,^\(\s\s*\)\([0-9]\),\1{empty}\2,g'
>
> resulting in
>
>   "s,^\(\s\s*\)\([0-9]\),\ ..."
>
>
> I think the problem is that  \s is a GNU beyond-POSIX extension and the
> standards-compliant way to write this is
>
>   -e 's,^\([:blank:][:blank:]*\)\([0-9]\),\1{empty}2\,g' \
>
> instead.
>
>
> (In general, I find the sed magic surrounding docs builds too hard to
> understand, even for someone who has used sed, probably starting with
> Seventh Edition.)
>
> > On one hand, a build is expected to deliver man pages. Historically *roff
> > files were directly edited and served by projects; nowadays it is
> asciidoc
> > or similar, rendered into man pages as one of many output formats.  Dist
> > tarballs include those page files so they can be installed even where
> > asciidoc renderer is not available. So some options manage this part.
>
> ok, but which options actually do what precisely?  Does --without-doc
> say "don't build them" or "don't install them"?  What happens if you
> give --without-doc, and you don't, or do, have them built?  One could
> make an argument that "don't build them, and install what should have
> been built into distfile, erroring out if not there" is mild/acceptable,
> resulting in a correct package.  And that "don't build and don't
> install" is, while useful to some, an instruction that results in a
> defective install.
>
> This is not understandable from reading configure.ac.
>
> > Another issue is the codes assigned to man page sections in different
> OSes
> > - this was previously bolted to what is seen in Linux and FreeBSD; now
> can
> > be amended for package builds (especially on other platforms), to avoid
> > clumsy distro-specific patch files or scripts in their recipes.
>
> sure, good to have --do-foo to accomodate.  So far that's not my issue!
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250802/73f312c7/attachment-0001.htm>