Skip Menu |

This queue is for tickets about the ExtUtils-MakeMaker CPAN distribution.

Report information
The Basics
Id: 74095
Status: resolved
Priority: 0/
Queue: ExtUtils-MakeMaker

People
Owner: Nobody in particular
Requestors: RURBAN [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 6.62
Fixed in: (no value)



Subject: Broken on 5.6
Note the 1.e-02 $ make test PERL_DL_NONLAZY=1 /usr/local/bin/perl5.6.2d-nt "-Iblib/arch" "-Iblib/lib" "- MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00compile.t ............. ok t/arch_check.t ............ ok t/backwards.t ............. ok t/basic.t ................. 1/171 # Failed test ' <SOFTPKG>' # at t/basic.t line 83. # '<SOFTPKG NAME="Big-Dummy" VERSION="1.e-02"> # <ABSTRACT>Try "our" hot dog's</ABSTRACT> # <AUTHOR>Michael G Schwern &lt;schwern@pobox.com&gt;</AUTHOR> # <IMPLEMENTATION> # <REQUIRE NAME="strict::" /> # <ARCHITECTURE NAME="darwin" /> # <CODEBASE HREF="" /> # </IMPLEMENTATION> # </SOFTPKG> # ' # doesn't match '(?m-xis:^<SOFTPKG NAME="Big-Dummy" VERSION="0.01">)' t/basic.t ................. 62/171 # Failed test 'META.yml written to dist dir' # at t/basic.t line 240. # Failed test 'MYMETA.yml is written to dist dir on disttest' # at t/basic.t line 244. # Failed test 'META.json written to dist dir' # at t/basic.t line 247. # Failed test 'MYMETA.json is written to dist dir on disttest' # at t/basic.t line 251. # Failed test 'META.yml validates' # at t/basic.t line 263. Can't call method "name" on an undefined value at t/basic.t line 270. # Looks like you planned 171 tests but ran 75. # Looks like you failed 6 tests of 75 run. # Looks like your test exited with 255 just after 75. t/basic.t ................. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 102/171 subtests t/build_man.t ............. ok t/cd.t .................... ok t/config.t ................ ok t/dir_target.t ............ ok t/FIRST_MAKEFILE.t ........ ok t/fix_libs.t .............. ok t/fixin.t ................. ok t/hints.t ................. ok t/INST.t .................. ok t/INST_PREFIX.t ........... ok t/INSTALL_BASE.t .......... ok t/installed_file.t ........ ok t/is_of_type.t ............ ok t/Liblist.t ............... ok t/Liblist_Kid.t ........... ok t/make.t .................. ok t/MakeMaker_Parameters.t .. ok t/maketext_filter.t ....... ok t/meta_convert.t .......... ok t/metafile_data.t ......... ok t/metafile_file.t ......... ok t/min_perl_version.t ...... Name "_Prereq::Print::WithMPV::BUILD_REQUIRES" used only once: possible typo at t/min_perl_version.t line 125. t/min_perl_version.t ...... 27/32 # Failed test 'META.yml validates' # at t/min_perl_version.t line 195. Can't call method "prereqs" on an undefined value at t/min_perl_version.t line 200. # Looks like you planned 32 tests but ran 29. # Looks like you failed 1 test of 29 run. # Looks like your test exited with 2 just after 29. t/min_perl_version.t ...... Dubious, test returned 2 (wstat 512, 0x200) Failed 4/32 subtests t/miniperl.t .............. skipped: miniperl test only necessary for the perl core t/Mkbootstrap.t ........... ok t/MM_Any.t ................ ok t/MM_BeOS.t ............... skipped: This is not BeOS t/MM_Cygwin.t ............. skipped: This is not cygwin t/MM_NW5.t ................ skipped: This is not NW5 t/MM_OS2.t ................ skipped: This is not OS/2 t/MM_Unix.t ............... ok t/MM_VMS.t ................ skipped: This is not VMS t/MM_Win32.t .............. skipped: This is not Win32 t/oneliner.t .............. ok t/parse_abstract.t ........ ok t/parse_version.t ......... ok t/PL_FILES.t .............. ok t/pm.t .................... ok t/pm_to_blib.t ............ ok t/pod2man.t ............... ok t/postamble.t ............. ok t/prefixify.t ............. ok t/prereq.t ................ ok t/prereq_print.t .......... ok t/problems.t .............. ok t/prompt.t ................ ok t/recurs.t ................ ok t/revision.t .............. ok t/several_authors.t ....... 4/20 # Failed test 'META.yml validates' # at t/several_authors.t line 135. Can't call method "authors" on an undefined value at t/several_authors.t line 140. # Looks like you planned 20 tests but ran 17. # Looks like you failed 1 test of 17 run. # Looks like your test exited with 2 just after 17. t/several_authors.t ....... Dubious, test returned 2 (wstat 512, 0x200) Failed 4/20 subtests t/split_command.t ......... ok t/test_boilerplate.t ...... ok t/testlib.t ............... ok t/VERSION_FROM.t .......... ok t/WriteEmptyMakefile.t .... ok t/writemakefile_args.t .... ok t/xs.t .................... ok Test Summary Report ------------------- t/basic.t (Wstat: 65280 Tests: 75 Failed: 6) Failed tests: 12, 64, 67, 69, 72-73 Non-zero exit status: 255 Parse errors: Bad plan. You planned 171 tests but ran 75. t/min_perl_version.t (Wstat: 512 Tests: 29 Failed: 1) Failed test: 27 Non-zero exit status: 2 Parse errors: Bad plan. You planned 32 tests but ran 29. t/several_authors.t (Wstat: 512 Tests: 17 Failed: 1) Failed test: 15 Non-zero exit status: 2 Parse errors: Bad plan. You planned 20 tests but ran 17. Files=59, Tests=843, 50 wallclock secs ( 0.49 usr 0.23 sys + 30.24 cusr 5.11 csys = 36.07 CPU) Result: FAIL Failed 3/59 test programs. 8/843 subtests failed. make: *** [test_dynamic] Error 35 -- Reini Urban
Subject: Tell the user their Perl numification is broken
On Tue Jan 17 14:04:22 2012, RURBAN wrote: Show quoted text
> Note the 1.e-02
Thanks for the report, the test is absolutely correct... except the problem is your perl install. It's a known bug in 5.6.2 on some BSDs, usually only showing up in OS X. A simple 'print "0.01"' should illustrate the problem. The fix is to compile with -Dd_Gconvert=sprintf as explained here: https://www.socialtext.net/perl5/installing_perl_on_os_x This is a common enough problem with 5.6, so I'll add an early test that clearly explains the problem. I don't have a broken 5.6 handy to test that it works, could you please give it a shot? https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/c5f1a5900d8a0bf5afb5f27b8deea3178528df5c
CC: RURBAN [...] cpan.org
Subject: Re: [rt.cpan.org #74095] Tell the user their Perl numification is broken
Date: Wed, 18 Jan 2012 12:46:55 -0600
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Reini Urban <rurban [...] x-ray.at>
On Wed, Jan 18, 2012 at 10:32 AM, Michael G Schwern via RT <bug-ExtUtils-MakeMaker@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=74095 > > > On Tue Jan 17 14:04:22 2012, RURBAN wrote:
>> Note the 1.e-02
> > Thanks for the report, the test is absolutely correct... except the > problem is your perl install.  It's a known bug in 5.6.2 on some BSDs, > usually only showing up in OS X.  A simple 'print "0.01"' should > illustrate the problem. > > The fix is to compile with -Dd_Gconvert=sprintf as explained here: > https://www.socialtext.net/perl5/installing_perl_on_os_x > > This is a common enough problem with 5.6, so I'll add an early test that > clearly explains the problem. > > I don't have a broken 5.6 handy to test that it works, could you please > give it a shot? > https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/c5f1a5900d8a0bf5afb5f27b8deea3178528df5c
Sorry, but this is no solution. perl5.6.2 works fine even with this bug, and most modules work fine with this bug. If you want to check for the Gconvert bug warn but do not die. EUMM tests should be TODO or skipped. The whole CPAN toolchain is depending on EUMM so you deliberately break perl by assuming the world is broken whilst it is only broken for you, for the optional CPAN::META and YAML, nothing else. There are worse 5.6 bugs than Gconvert, e.g. glob,m hash randomizations, utf8 You do not fail on this and you should not be deliberate module authors. Requiring a broken EUMM 6.30 is aggressive behavior and breaking all old perls. -- Reini Urban http://cpanel.net/   http://www.perl-compiler.org/
Subject: Re: [rt.cpan.org #74095] Tell the user their Perl numification is broken
Date: Wed, 18 Jan 2012 18:23:01 -0800
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
It is better to inform the user of this this problem, one which both breaks MakeMaker and has wide spread consequences outside of MakeMaker, early and clearly rather than wasting hours tracking down mysterious failures later. Then they can decide whether to deal with it quickly, cheaply and decisively... or do something else. The user is informed of a problem and the purpose of the tests is fulfilled. This is not a new situation nor a new test, it has existed for years. EUMM 6.30 is equally broken, the tests just might not tickle the bug. I'm sorry but there is no easy work around which restores automated installs for you AND guarantees a working toolchain. If you have one, please let us know. I'm sorry this is immediately inconvenient; the purpose of testing and the install process is not just to provide the user with a toolchain, but with a WORKING toolchain. If the tests indicate the toolchain will not work, the install must inform the user about the problem. The best way we have to do this is to halt and catch fire. MakeMaker is clearly broken by this Perl bug, it cannot correctly write version numbers, pretty important in a packaging system, and likely has deeper consequences. MakeMaker only incidentally catches it in a largely unrelated test, so I added an explicit check with clearer information for the user. Other CPAN modules likely only "work" in the sense that they pass tests because their testing does not tickle this bug. My assumption that the world is broken by this Perl bug is IN ADDITION to the fact that MakeMaker is definitely broken. That there may be OTHER Perl bugs the test suite does not catch is irrelevant; two wrongs do not make a right. If they break MakeMaker, and are common, I would be interested to know about them, test for them and try to put in a non-invasive work around. While MakeMaker usually attempts to work around Perl bugs, they are usually small, subtle and only of concern to MakeMaker. I have no work around for the problem which isn't extremely invasive. If I did it would serve little purpose because the bug would still affect many other module and programs. If you're concerned about 5.6, consider fixing it in the hints and releasing 5.6.3.
CC: RURBAN [...] cpan.org
Subject: Re: [rt.cpan.org #74095] Tell the user their Perl numification is broken
Date: Thu, 19 Jan 2012 12:45:53 -0600
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Reini Urban <rurban [...] x-ray.at>
On Wed, Jan 18, 2012 at 8:23 PM, Michael G Schwern via RT <bug-ExtUtils-MakeMaker@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=74095 > > > It is better to inform the user of this this problem, one which both breaks > MakeMaker and has wide spread consequences outside of MakeMaker, early and > clearly rather than wasting hours tracking down mysterious failures later. > Then they can decide whether to deal with it quickly, cheaply and > decisively... or do something else.  The user is informed of a problem and the > purpose of the tests is fulfilled. > > This is not a new situation nor a new test, it has existed for years.  EUMM > 6.30 is equally broken, the tests just might not tickle the bug.  I'm sorry > but there is no easy work around which restores automated installs for you AND > guarantees a working toolchain.  If you have one, please let us know. > > I'm sorry this is immediately inconvenient; the purpose of testing and the > install process is not just to provide the user with a toolchain, but with a > WORKING toolchain.  If the tests indicate the toolchain will not work, the > install must inform the user about the problem.  The best way we have to do > this is to halt and catch fire. > > MakeMaker is clearly broken by this Perl bug, it cannot correctly write > version numbers, pretty important in a packaging system, and likely has deeper > consequences.  MakeMaker only incidentally catches it in a largely unrelated > test, so I added an explicit check with clearer information for the user. > > Other CPAN modules likely only "work" in the sense that they pass tests > because their testing does not tickle this bug.  My assumption that the world > is broken by this Perl bug is IN ADDITION to the fact that MakeMaker is > definitely broken. > > That there may be OTHER Perl bugs the test suite does not catch is irrelevant; > two wrongs do not make a right.  If they break MakeMaker, and are common, I > would be interested to know about them, test for them and try to put in a > non-invasive work around.  While MakeMaker usually attempts to work around > Perl bugs, they are usually small, subtle and only of concern to MakeMaker.  I > have no work around for the problem which isn't extremely invasive.  If I did > it would serve little purpose because the bug would still affect many other > module and programs.
Even with this or other 5.6 bugs the module testsuites pass. It's the authors concern and not yours. You should just let the user test and install the module and not artificially break the dependency toolchain. It's annoying and time-consuming to fix away all these new EUMM restrictions/bug and users typically blame perl, not you. I have a working 5.6 toolchain on linux, darwin and windows. It just causes a lot of effort to fight schwern and his followers who think without META you are not allowed to install working CPAN modules. Show quoted text
> If you're concerned about 5.6, consider fixing it in the hints and releasing > 5.6.3.
That's indeed a good option, since hash randomization is needed also. But it has nothing to do with this EUMM bug. -- Reini Urban http://cpanel.net/   http://www.perl-compiler.org/
Subject: Re: [rt.cpan.org #74095] Tell the user their Perl numification is broken
Date: Thu, 19 Jan 2012 12:01:52 -0800
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
On 2012.1.19 10:46 AM, Reini Urban via RT wrote: Show quoted text
> I have a working 5.6 toolchain on linux, darwin and windows. It just > causes a lot of effort to fight schwern and his followers who think > without META you are not allowed to install working CPAN modules.
I've been very patient with you. You're being obtuse, paranoid and disingenuous. Stop it. This isn't a META conspiracy or even an anti-5.6 thing. PPM files were introduced before I even touched MakeMaker and the failing test has been there for years. If you actually want to discuss this, I think I can finally surmise what you're wanting to express: A) Most users just want MakeMaker so they can install modules. B) This 5.6 bug doesn't effect INSTALLATION, just PACKAGING of modules. C) Most other modules work fine with the bug. Therefore: D) The bug doesn't affect most users. E) Let them install a semi-broken MakeMaker. F) Turn off the PPM test. I believe A. I don't really believe B or C, but let's believe them for the purposes of this exercise. Once one believes A, B and C then D, E and F follow along logically... except that "works for most" is not good enough. There's a significant chunk of users who DO want to package modules. We can't predict who those are and only warn them about the problem. To make matters worse, when they do go to package and release a module it may contain broken META information. I know YOU don't care about META information, but the toolchain you're concerned about does. Other users will then download that module, the install will get very confused and users will spend a bunch of time trying to figure out what's wrong. The people effected and the time lost to the bug expands. If you're going to advocate a "works for most people" philosophy so lightly, then 5.6 support would be the first thing to go. Most people don't use it and it costs a lot of energy to maintain. It would be very nice if MakeMaker were separated into "module to INSTALL modules" and "module to MAKE modules" but it isn't. Either we fix that or live with the consequences. Living with the consequences means shipping a MakeMaker where BOTH use cases work. Full stop. Just recompile your damn Perl, Reini. It's broken.
I claim this is obsolete since not EUMM issue at all.
On Thu Jul 31 22:12:36 2014, ETJ wrote: Show quoted text
> I claim this is obsolete since not EUMM issue at all.
The EUMM issue is that those tests are fatal with the Gconvert bug. schwerns patch to note about the bug is very good. But to fail to install because of META problems is too restrictive. META should be hints, but not mandatory. As analogy, do you want to refuse to let a user install a package when he has no LICENSE file or meta? -- Reini Urban
Schwern's patch to warn users in t/01perl_bugs.t about Perl config bug is the most that can be done. Closing.