On Fri, Aug 28, 2020 at 5:51 PM Bruno Haible <br...@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
