NetBSD Problem Report #53826

From www@NetBSD.org  Tue Jan  1 22:12:46 2019
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EAE4F7A1AC
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  1 Jan 2019 22:12:46 +0000 (UTC)
Message-Id: <20190101221245.D648C7A233@mollari.NetBSD.org>
Date: Tue,  1 Jan 2019 22:12:45 +0000 (UTC)
From: david@gutteridge.ca
Reply-To: david@gutteridge.ca
To: gnats-bugs@NetBSD.org
Subject: devel/m4 fails to build on Linux distributions using glibc >= 2.27
X-Send-Pr-Version: www-1.0

>Number:         53826
>Category:       pkg
>Synopsis:       devel/m4 fails to build on Linux distributions using glibc >= 2.27
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gutteridge
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 01 22:15:00 +0000 2019
>Closed-Date:    Wed Mar 20 23:24:57 +0000 2019
>Last-Modified:  Wed Mar 20 23:24:57 +0000 2019
>Originator:     David H. Gutteridge
>Release:        HEAD
>Organization:
>Environment:
Linux arcusix.nonus-porta.net 4.19.12-300.fc29.x86_64 #1 SMP Sat Dec 22 22:03:59 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>Description:
During the glibc 2.27 development cycle, they removed features that
gnulib used to detect certain capabilities. This has broken devel/m4
on various Linux distributions, e.g. Fedora 28 and 29, Ubuntu 18.10,
Debian Sid, and probably others. (I came across this because I was
testing pkgsrc on Fedora 29.)

This was reported upstream back in March[1], and the m4 maintainers are
aware they need to update to reflect this, but there hasn't been a
release made yet. There are patches to adjust m4 provided in that email
thread, and they were taken as-is downstream by Fedora[2].

I've tested the patches in pkgsrc on Fedora 29, and I also tested them
on Debian Jessie (which has glibc 2.19) to confirm they were backwards
compatible, and there were no issues there. I presume if they work on
Jessie, there shouldn't be any older Linux LTS release where there'd be
an issue.

Before applying these patches, I'd like input from the pkgsrc Linux
people, to ensure there aren't any potential problems on other
distributions. (E.g., it appears Arch is a popular choice amongst
pkgsrc users. I don't have a testing setup for it.) I can provide the
patches in pkgsrc format if anyone wants them.

1. https://lists.gnu.org/r/bug-gnulib/2018-03/msg00002.html
2. https://src.fedoraproject.org/rpms/m4/blob/master/f/m4-1.4.18-glibc-change-work-around.patch

>How-To-Repeat:
Try to build devel/m4 on a Linux distribution using glibc >=2.27.

It will result in an error such as:

freadahead.c: In function 'freadahead':
freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
  #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."


>Fix:
(Patches referenced above, and I can provide pkgsrc formatted
versions.)

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->linux-pkg-people
Responsible-Changed-By: gutteridge@NetBSD.org
Responsible-Changed-When: Tue, 01 Jan 2019 22:26:45 +0000
Responsible-Changed-Why:
Linux issue, over to role account.

State-Changed-From-To: open->analyzed
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Tue, 01 Jan 2019 22:31:52 +0000
State-Changed-Why:
PR analyzed, awaiting feedback from other developers.

From: triaxx <triaxx@triaxx.org>
To: gnats-bugs@netbsd.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
Subject: Re: pkg/53826: devel/m4 fails to build on Linux distributions using  glibc >= 2.27
Date: Wed, 02 Jan 2019 07:52:00 +0100

 Le 2019-01-01 23:15, david@gutteridge.ca a écrit :
 > Before applying these patches, I'd like input from the pkgsrc Linux
 > people, to ensure there aren't any potential problems on other
 > distributions. (E.g., it appears Arch is a popular choice amongst
 > pkgsrc users. I don't have a testing setup for it.) I can provide the
 > patches in pkgsrc format if anyone wants them.

 I would be interested to have the patches in pkgsrc format to test on 
 Arch.

 Regards,
 Fred

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/53826: devel/m4 fails to build on Linux distributions using
 glibc >= 2.27
Date: Wed, 02 Jan 2019 20:01:27 -0500

 Somehow, I didn't notice the email thread last month about this[1]:
 Sijmen J. Mulder also came across this issue and did some of the same
 investigation as me, and Maya had an alternate suggestion on how to
 handle the issue[2], which looks nicer.

 As Maya alluded, the problem is more widespread than just m4. Debian
 has noted the same issue with other applications, e.g. gzip[3]. As
 gnulib is embedded separately in each application as source, we'd have
 to deal with each issue individually.

 1. https://mail-index.netbsd.org/pkgsrc-users/2018/12/12/msg027789.html
 2. https://mail-index.netbsd.org/pkgsrc-users/2018/12/12/msg027795.html
 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915152


From: triaxx <triaxx@triaxx.org>
To: david@gutteridge.ca
Cc: gnats-bugs@netbsd.org, pkg-manager@netbsd.org, gnats-admin@netbsd.org,
 pkgsrc-bugs@netbsd.org
Subject: Re: pkg/53826: devel/m4 fails to build on Linux distributions using  glibc >= 2.27
Date: Thu, 03 Jan 2019 15:17:06 +0100

 Le 2019-01-02 07:52, triaxx a écrit :
 > Le 2019-01-01 23:15, david@gutteridge.ca a écrit :
 >> Before applying these patches, I'd like input from the pkgsrc Linux
 >> people, to ensure there aren't any potential problems on other
 >> distributions. (E.g., it appears Arch is a popular choice amongst
 >> pkgsrc users. I don't have a testing setup for it.) I can provide the
 >> patches in pkgsrc format if anyone wants them.
 > 
 > I would be interested to have the patches in pkgsrc format to test on 
 > Arch.
 > 
 > Regards,
 > Fred

 The build success by applying patches on my Arch Linux box (it failed 
 before).

 Regards,
 Fred

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/53826: devel/m4 fails to build on Linux distributions using
 glibc >= 2.27
Date: Sat, 05 Jan 2019 03:49:23 -0500

 As well as devel/m4, archivers/gzip is also affected by this problem.
 The difference, though, is that gzip has since been updated with a
 bundled version of gnulib that addresses the issue. So our fix there
 should probably be simply to update gzip from 1.6 to 1.10. Unless
 anyone knows of a reason not to do this?

 Dave


From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53826 CVS commit: pkgsrc/devel/m4
Date: Sun, 6 Jan 2019 05:45:30 +0000

 Module Name:	pkgsrc
 Committed By:	gutteridge
 Date:		Sun Jan  6 05:45:30 UTC 2019

 Modified Files:
 	pkgsrc/devel/m4: distinfo
 	pkgsrc/devel/m4/patches: patch-lib_fseeko.c patch-lib_stdio-impl.h
 Added Files:
 	pkgsrc/devel/m4/patches: patch-lib_fflush.c patch-lib_fpending.c
 	    patch-lib_fpurge.c patch-lib_freadahead.c patch-lib_freading.c

 Log Message:
 devel/m4: add patches to fix building with glibc >= 2.27

 Addresses PR pkg/53826, further details are provided there. This is a
 temporary fix, until the next m4 release. No PKGREVISION, because
 there should be no change to existing packages, it addresses build
 failures only.


 To generate a diff of this commit:
 cvs rdiff -u -r1.45 -r1.46 pkgsrc/devel/m4/distinfo
 cvs rdiff -u -r0 -r1.1 pkgsrc/devel/m4/patches/patch-lib_fflush.c \
     pkgsrc/devel/m4/patches/patch-lib_fpending.c \
     pkgsrc/devel/m4/patches/patch-lib_fpurge.c \
     pkgsrc/devel/m4/patches/patch-lib_freadahead.c \
     pkgsrc/devel/m4/patches/patch-lib_freading.c
 cvs rdiff -u -r1.1 -r1.2 pkgsrc/devel/m4/patches/patch-lib_fseeko.c \
     pkgsrc/devel/m4/patches/patch-lib_stdio-impl.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/53826: devel/m4 fails to build on Linux distributions using
 glibc >= 2.27
Date: Sun, 06 Jan 2019 01:13:18 -0500

 While applying patches here isn't as elegant as maya@'s alternate
 solution, I opted for it for a couple of reasons. There are already
 other patches applied to two of the same files, and it's simpler
 conceptually to use one means to apply all workarounds to a given
 file, rather than a maintainer having to check multiple places. And
 when patches are no longer applicable, they tend to force a maintainer
 to address that, whereas make file fragments may linger unnoticed for
 longer. Or such is my thinking, and I note this because I'm new here.

 I'm leaving this PR in an open state in case anyone needs to report
 any unanticipated fall-out, and if not, will request pull-ups to the
 latest stable branch in about a week.

 Thanks to triaxx@ for additional testing on Arch, maya@ for her input,
 and Sijmen J. Mulder for also catching and investigating this.

 Dave


Responsible-Changed-From-To: linux-pkg-people->gutteridge
Responsible-Changed-By: gutteridge@NetBSD.org
Responsible-Changed-When: Wed, 09 Jan 2019 23:17:33 +0000
Responsible-Changed-Why:
Take ownership, so I remember to complete activities.

From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53826 CVS commit: pkgsrc/archivers/gzip
Date: Thu, 10 Jan 2019 06:47:42 +0000

 Module Name:	pkgsrc
 Committed By:	gutteridge
 Date:		Thu Jan 10 06:47:42 UTC 2019

 Modified Files:
 	pkgsrc/archivers/gzip: Makefile distinfo
 	pkgsrc/archivers/gzip/patches: patch-lib_fflush.c
 Removed Files:
 	pkgsrc/archivers/gzip/patches: patch-lib_fseeko.c

 Log Message:
 archivers/gzip: update to release 1.10

 Prompted in part because prior releases fail to build on Linux
 distributions that use glibc >= 2.27 (relates to PR pkg/53826).

 * Noteworthy changes in release 1.10 (2018-12-29) [stable]

 ** Changes in behavior

   Compressed gzip output no longer contains the current time as a
   timestamp when the input is not a regular file.  Instead, the output
   contains a null (zero) timestamp.  This makes gzip's behavior more
   reproducible when used as part of a pipeline.  (As a reminder, even
   regular files will use null timestamps after the year 2106, due to a
   limitation in the gzip format.)

 ** Bug fixes

   A use of uninitialized memory on some malformed inputs has been fixed.
   [bug present since the beginning]

   A few theoretical race conditions in signal handers have been fixed.
   These bugs most likely do not happen on practical platforms.
   [bugs present since the beginning]

 * Noteworthy changes in release 1.9 (2018-01-07) [stable]

 ** Bug fixes

   gzip -d -S SUFFIX file.SUFFIX would fail for any upper-case byte in SUFFIX.
   E.g., before, this command would fail:
     $ :|gzip > kT && gzip -d -S T kT
     gzip: kT: unknown suffix -- ignored
   [bug present since the beginning]

   When decompressing data in 'pack' format, gzip no longer mishandles
   leading zeros in the end-of-block code.  [bug introduced in gzip-1.6]

   When converting from system-dependent time_t format to the 32-bit
   unsigned MTIME format used in gzip files, if a timestamp does not
   fit gzip now substitutes zero instead of the timestamp's low-order
   32 bits, as per Internet RFC 1952.  When converting from MTIME to
   time_t format, if a timestamp does not fit gzip now warns and
   substitutes the nearest in-range value instead of crashing or
   silently substituting an implementation-defined value (typically,
   the timestamp's low-order bits).  This affects timestamps before
   1970 and after 2106, and timestamps after 2038 on platforms with
   32-bit signed time_t.  [bug present since the beginning]

   Commands implemented via shell scripts are now more consistent about
   failure status.  For example, 'gunzip --help >/dev/full' now
   consistently exits with status 1 (error), instead of with status 2
   (warning) on some platforms.  [bug present since the beginning]

   Support for VMS and Amiga has been removed.  It was not working anyway,
   and it reportedly caused file name glitches on MS-Windowsish platforms.

 * Noteworthy changes in release 1.8 (2016-04-26) [stable]

 ** Bug fixes

   gzip -l no longer falsely reports a write error when writing to a pipe.
   [bug introduced in gzip-1.7]

   Port to Oracle Solaris Studio 12 on x86-64.
   [bug present since at least gzip-1.2.4]

   When configuring gzip, ./configure DEFS='...-DNO_ASM...' now
   suppresses assembler again.  [bug introduced in gzip-1.3.5]

 * Noteworthy changes in release 1.7 (2016-03-27) [stable]

 ** Changes in behavior

   The GZIP environment variable is now obsolescent; gzip now warns if
   it is used, and rejects attempts to use dangerous options or operands.
   You can use an alias or script instead.

   Installed programs like 'zgrep' now use the PATH environment variable
   as usual to find subsidiary programs like 'gzip' and 'grep'.
   Previously they prepended the installation directory to the PATH,
   which sometimes caused 'make check' to test the wrong gzip executable.
   [bug introduced in gzip-1.3.13]

 ** New features

   gzip now accepts the --synchronous option, which causes it to use
   fsync and similar primitives to transfer output data to the output
   file's storage device when the file system supports this.  Although
   this option makes gzip safer in the presence of system crashes, it
   can make gzip considerably slower.

   gzip now accepts the --rsyncable option. This option is accepted in
   all modes, but has effect only when compressing: it makes the resulting
   output more amenable to efficient use of rsync.  For example, when a
   large input file gets a small change, a gzip --rsyncable image of
   that file will remain largely unchanged, too.  Without --rsyncable,
   even a tiny change in the input could result in a totally different
   gzip-compressed output file.

 ** Bug fixes

   gzip -k -v no longer reports that files are replaced.
   [bug present since the beginning]

   zgrep -f A B C no longer reads A more than once if A is not a regular file.
   This better supports invocations like 'zgrep -f <(COMMAND) B C' in Bash.
   [bug introduced in gzip-1.2]


 To generate a diff of this commit:
 cvs rdiff -u -r1.35 -r1.36 pkgsrc/archivers/gzip/Makefile
 cvs rdiff -u -r1.9 -r1.10 pkgsrc/archivers/gzip/distinfo
 cvs rdiff -u -r1.2 -r1.3 pkgsrc/archivers/gzip/patches/patch-lib_fflush.c
 cvs rdiff -u -r1.2 -r0 pkgsrc/archivers/gzip/patches/patch-lib_fseeko.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53826 CVS commit: pkgsrc/devel/bison
Date: Wed, 16 Jan 2019 00:19:32 +0000

 Module Name:	pkgsrc
 Committed By:	gutteridge
 Date:		Wed Jan 16 00:19:32 UTC 2019

 Modified Files:
 	pkgsrc/devel/bison: distinfo
 Added Files:
 	pkgsrc/devel/bison/patches: patch-lib_fseterr.c

 Log Message:
 devel/bison: add patches to fix building with glibc >= 2.27

 Relates to PR pkg/53826, further details are provided there. This is a
 temporary fix: the newest release of Bison addresses this by including
 a newer version of gnulib. I'm applying this less obtrusive change for
 now. No PKGREVISION, because there should be no change to existing
 packages, it addresses build failures only.


 To generate a diff of this commit:
 cvs rdiff -u -r1.47 -r1.48 pkgsrc/devel/bison/distinfo
 cvs rdiff -u -r0 -r1.1 pkgsrc/devel/bison/patches/patch-lib_fseterr.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: analyzed->closed
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Wed, 20 Mar 2019 23:24:57 +0000
State-Changed-Why:
At this point, it'll be in the 2019Q1 branch by default.

>Unformatted:

Home	PR Database Search