The reason for pmask request: see m4/m4.m4 in autoconf-2.69 tarball, it fails to to build with m4 1.4.15.
autoconf-2.69 is ~arch m4-1.4.15 is arch Why are you mixing visibility levels?
Maybe we should just change the autoconf's dependencies to >=1.4.16
(In reply to comment #2) > Maybe we should just change the autoconf's dependencies to >=1.4.16 That would be the way to go. 1.4.15 can't be p.masked anyway, being the only stable version in the tree.
Well, given comments in that macro, I'd say this might not be a security vulnerability, but still a very good point for a quick stabilization. I called for pmask, cause the comments suggest that version should be removed from the tree the moment 1.4.16 gets into stable.
the code people are referring to: ... # Root out GNU M4 1.4.15 with buggy false negative replacement strstr. # Root out Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 with buggy # false positive strstr. ... [AC_MSG_ERROR([no acceptable m4 could be found in \$PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. GNU M4 1.4.15 uses a buggy replacement strstr on some systems. Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.])])]) ... only in *some* cases does autoconf-2.69 fail to build with m4-1.4.15 (i.e. when m4 detects an already broken system, but its workarounds have bugs of their own). it isn't *all* systems. i also don't see how this could be a security issue in the slightest. so pmasking doesn't make sense. m4-1.4.16 has been around for over a year at this point, so stabilizing it sounds fine. i'll do it in a sep bug. autoconf doesn't strictly require m4-1.4.16, so i'm not entirely keen on forcing the depend. not that it'll probably matter in practice. let's see how stabilization goes with people noticing.
@comment 5: all I can say is that while I was setting up a standard amd64 glibc system from stage3 (granted - with a quite large keywords set), autoconf has bailed out due to m4.
m4-1.4.16 is stable now
