bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PSPP-BUG: PSPP make check errors [cross posting to address@hidden]


From: Jeffrey Walton
Subject: Re: PSPP-BUG: PSPP make check errors [cross posting to address@hidden]
Date: Fri, 28 Aug 2020 18:20:26 -0400

On Fri, Aug 28, 2020 at 5:51 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Ruth Waite wrote:
> > Here it is.
>
> In order to evaluate the impact of this problem, it would be useful to know
> what kind of system this is (distro and version).
>
> I can see from your log that it's a glibc 2.17 system. But on CentOS 7.3.1611,
> which also uses glibc 2.17, building pspp-1.4.0 works fine (except for an
> outdated 'perl').

Oracle Linux Server 7.8. It is buried in the first email:

    On Thu, Aug 27, 2020 at 03:19:36PM +0000, Ruth Waite wrote:
    Please see attached errors when attempting to install PSPP on
    Oracle Linux Server 7.8.

The PSPP folks did not make an announcement on the platform-testers
mailing list. Cf.,
https://lists.gnu.org/archive/html/platform-testers/. Pre-release
testing may have identified the issue before release.

Maybe the GNU Coding Standards should (1) tell a maintainer to build a
release candidate before a release, and (2) make an announcement on
platform-testers . Currently neither platform-testers nor release
candidates are discussed in the manual. [1]

Solaris 11 testing may have caught the issue, but there's another
problem on Solaris:

   checking whether makeinfo supports @clicksequence... yes
    checking whether makeinfo generates broken DocBook XML... yes
    checking for dot... no
   ./configure: line 16169: syntax error at line 16200: `newline' unexpected

This particular [testing] problem is not limited to PSPP. Other
projects do the same, and they also find they have problems after a
release.

In the post-mortem analysis, this is a procedural problem in the
release process. The release process has gaps and needs a control to
contain the risk. In this case I think the control to place is:
document release candidate testing in the manual. That puts everyone
on the same page and ensures some coverage to catch some of these
problems.

Jeff

[1] https://www.gnu.org/prep/standards/standards.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]