nagios-nrpe: update to v4.1.3

Bump 4.0.2 -> 4.1.3 (3 patch releases on the 4.1.x line). New tarball
checksums from the upstream GitHub release asset:

  md5sum    = 92c61b315fd7c51d3cb52b848a9a5821
  sha256sum = 5a86dfde6b9732681abcd6ea618984f69781c294b8862a45dfc18afaca99a27a
  sha1sum   = b8842c6f6d555deb5ec0359fd49dfcc7952085d6
  sha384sum = 81c83ae3713d0baeef5636d7adae47c27c14eeae757e3962c579ac1486856998bc17a6e1a87aff9b290817fbb474ee09
  sha512sum = dc81e2104b7604e6c67a0dc73a3e6449f7e089390a807be7281492b5ab61e13347ed264292e0642798cee4bafc5978d423184e81bbe753343aaa68daea091f7e

LIC_FILES_CHKSUM md5 of src/nrpe.c lines 1-35 unchanged at
0dadd78599abbc737af81432702e9161, so the existing pin still applies.

A number of recipe-level fixes were needed to get this building under
modern OE-core. The build chain across the 15-month gap from 4.0.2
surfaced each one in turn:

  - S = "${WORKDIR}/${SRCNAME}-${PV}" updated to "${UNPACKDIR}/...".
    OE-core moved unpacked sources out of WORKDIR and into UNPACKDIR
    a while back; this recipe predates that transition and was caught
    by the do_unpack QA check now that we rebuild from scratch.

  - Drop file://0001-Should-fix-235-nasty_metachars-was-not-being-
    returne.patch. The CVE-2020-6581 fix (add `return copy;` to
    process_metachars()) is now present in upstream src/nrpe.c at
    line 622, so the patch fails to apply and is no longer needed.

  - Add file://0001-nrpe-ssl.h-guard-ssl_verify_callback_common-
    declarat.patch. v4.1.3 introduced an `int
    ssl_verify_callback_common(int, X509_STORE_CTX *, int)` prototype
    in include/nrpe-ssl.h *outside* the existing #ifdef HAVE_SSL
    block. The header is included unconditionally by check_nrpe.c
    and nrpe.c, so any --disable-ssl build hits
    `unknown type name 'X509_STORE_CTX'`. The patch wraps the
    prototype in the matching HAVE_SSL guard; the other openssl-
    typed externs in the same file were already correctly guarded.

  - PACKAGECONFIG default flipped from "cmdargs bashcomp" to
    "cmdargs bashcomp ssl". v4.1.3 references `use_ssl` from
    check_nrpe.c and nrpe.c outside HAVE_SSL guards, but the
    variable is only defined in src/nrpe-ssl.c — which configure
    adds to $(SSL_OBJS) only when --enable-ssl is passed. Disabling
    SSL therefore produces undefined-reference link errors. Enabling
    by default sidesteps the regression; the new
    0001-nrpe-ssl.h-* patch keeps --disable-ssl at least compilable
    if a downstream user opts out.

  - EXTRA_OECONF_SSL emptied. The previous value passed
    --with-ssl-inc=${STAGING_DIR_HOST}${includedir} and
    --with-ssl-lib=${STAGING_DIR_HOST}${libdir} to configure. When
    either of those is set, configure disables pkg-config probing
    and falls back to a hardcoded library search that appends
    `-L$SSL_LIB_DIR -Wl,-rpath,$SSL_LIB_DIR` to LDFLAGS (visible in
    configure around line 7695). With our sysroot path that lands
    as a recipe-sysroot RPATH baked into the installed nrpe and
    check_nrpe binaries — tripping do_package_qa [rpaths] and
    [buildpaths]. An empty EXTRA_OECONF_SSL leaves PACKAGECONFIG[ssl]
    adding nothing to OECONF; pkg-config (driven by the openssl
    DEPENDS) then finds the library cleanly via the standard --libs
    flow, which does not bake an rpath into the link.

  - inherit pkgconfig added. Without it pkgconfig-native is not in
    the build environment, x86_64-poky-linux-pkg-config is not on
    PATH, and the EXTRA_OECONF_SSL-empty path above falls through
    to "found in /usr/include/openssl" (host paths, not sysroot)
    with a final "compiling and linking against SSL works... no".

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>

0 files changed, 0 insertions, 0 deletions