Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CPAN-Reporter CPAN distribution.

Report information
The Basics
Id: 39240
Status: resolved
Priority: 0/
Queue: CPAN-Reporter

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

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Subject: Unquoted string "tmp" may clash with...
Today I saw several tests in sequence complain Unquoted string "tmp" may clash with future reserved word. Argument "tmp" isn't numeric in division (/). Argument "-I" isn't numeric in division (/). Illegal division by zero. I saw these FAILs with CPAN::Reporter and not with CPAN when test-report was false. And not if I ran 'make test' in that directory. First guess is somebody uses a bogus PERL5OPT? Let me see... build_dir_reuse os false. I start a fresh CPAN shell with 1.92_64 and CPAN::Reporter 1.1701. I run fforce test Catalyst::Model::XML::Feed and I reproduce this failure on the first test. I downgrade to CPAN::Reporter 1.17, 'reload cpan' and the tests pass. I upgrade to 1.1701 again and can reproduce the failure. I debug the PERL5OPT by editing the Makefile and it tells me echo "PERL5OPT being $PERL5OPT" PERL5OPT being -MDevel::Autoflush -I/tmp/CPAN-Reporter-lib-fJUO So there is something putting something into an eval? At the moment I cannot diagnose this. It is not on all my perls. This perl is % /usr/local/perl-5.10/bin/perl -V Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.24-1-amd64, archname=x86_64-linux uname='linux k81 2.6.24-1-amd64 #1 smp thu mar 27 16:52:38 utc 2008 x86_64 gnulinux ' config_args='-Dprefix=/usr/local/perl-5.10 -des -Ui_db' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.2.3 (Debian 4.2.3-3)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 libs=-lnsl -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.7.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.7' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Apr 20 2008 15:17:17 @INC: /usr/local/perl-5.10/lib/5.10.0/x86_64-linux /usr/local/perl-5.10/lib/5.10.0 /usr/local/perl-5.10/lib/site_perl/5.10.0/x86_64-linux /usr/local/perl-5.10/lib/site_perl/5.10.0 . Need to look around more.
I was wrong when I thought not all my perls are affected. I just posted an alert to cpantesters with a couple of liks to bogus fail reports. I'm backing out 1.1701 now everywhere. I'll learn to use File transport with sending out later.
N.B. This only affects tests that set taint mode in the shebang line. This is actually a Test::Harness bug because for T::H <= 3.14 it doesn't split PERL5OPT before adding it to the command line switches (which it does when taint mode is set). I've released 1.1702 to work around this behavior and committed a patch to Test::Harness to get it fixed in the next release. In the meantime, tests with taint won't die in this way, though it's still likely that Perl is processing the converted PERL5OPT switches incorrectly. -- David