This item is to track
TWiki:Codev/WhatVersionsOfPerlAreSupported, as a follow-up to
Item3476
Goal is to get TWiki 4.1.2 to run on Perl 5.0.3, and if that is not possible without substantial work, support Perl 5.6.5.
This is an urgent release blocker of 4.1.2. We are inevitably losing evaluators with the current requirement on 5.8, e.g. we should release TWiki 4.1.2 within the next 2 weeks.
--
TWiki:Main/PeterThoeny - 05 Feb 2007
I now have a Redhat 7.3 running with Perl 5.6 and TWiki on Apache 1.3.
And the first error I run into is
configure: Argument "" isn't numeric in numeric lt (<) at /var/www/twiki/lib/TWiki/Configure/Checker.pm line 207.
I added some poor mans debugging and found that it stops when it checks File::Find.
It seems that File::Find in older versions does not return a version number. This should not make configure fail but just report that it is unknown version.
To confirm that the old File::Find does not return a version I tried from the command line.
perl -e 'use File::Find; print "$File::Find::VERSION\n";'
And the result is just en empty line. If I write some garbage I get an error message. I guess we need to peel the layers off the onion until it runs. So this is first bug. I am running the Patch04x01 branch on it.
--
TWiki:Main.KennethLavrsen - 13 Feb 2007
I made a quick little fix which I can check in later to overcome the configure error.
Next errors I run into are.
Can't locate Unicode/Normalize.pm in @INC (@INC contains: /var/www/twiki/lib/CPAN/lib//arch /var/www/twiki/lib/CPAN/lib//5.6.1/i386-linux /var/www/twiki/lib/CPAN/lib//5.6.1 /var/www/twiki/lib/CPAN/lib/ /var/www/twiki/lib /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl .) at /var/www/twiki/lib/TWiki/Sandbox.pm line 193.
BEGIN failed--compilation aborted at /var/www/twiki/lib/TWiki/Sandbox.pm line 193.
Compilation failed in require at /var/www/twiki/lib/TWiki.pm line 142.
BEGIN failed--compilation aborted at /var/www/twiki/lib/TWiki.pm line 142.
Compilation failed in require at (eval 71) line 3.
I still need to install some CPAN libs that are required so some of these errors may go away. I just report the errors as I see them in case it inspires someone to give hints.
--
TWiki:Main.KennethLavrsen - 13 Feb 2007
I have checked in the fix for configure for both Patch04x01 and MAIN. Very simple and changes nothing for newer Perls where all libs return versions.
--
TWiki:Main.KennethLavrsen - 13 Feb 2007
I am trying to figure out why the Can't locate Unicode/Normalize.pm occurs??!
In the Sandbox.pm line 190 we have
if ( $TWiki::cfg{Site}{CharSet} =~ /^iso-?8859-?15?$/i ) {
if( $] >= 5.008 && eval { require Unicode::Normalize } ) {
require Encode;
eval { use Unicode::Normalize };
How come Perl 5.6.1 goes into the if( $] >= 5.008 && eval { require Unicode::Normalize } ) and stil tries to
eval { use Unicode::Normalize };
???
--
TWiki:Main.KennethLavrsen - 13 Feb 2007
I commented out the
eval { use Unicode::Normalize };
to continue finding more errors. And my next problem has been seen before:
view: Can't locate object method "generate_id" via package "CGI::Session::ID::" at /usr/lib/perl5/vendor_perl/5.6.1/CGI/Session.pm line 74.
I found out that this was due to a problem with the RPM perl libs I had installed from Dag. I uninstalled the perl-CGI-Session rpm. Upgraded the CPAN itself. And finally installed CGI::Session with CPAN instead. And then it runs. I can view topics in TWiki with Apache 1.3 and Perl 5.6.1.
I have not yet tested editing and plugins. But it seems that if we can fix that Unicode::Normalize problem - then we are very far. Unicode::Normalize seems to require Perl 5.8 so we have to make it work so the
eval { use
does not get parsed by Perl 5.6.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
Excellent progress, great work Kenneth!
--
TWiki:Main.PeterThoeny - 14 Feb 2007
As far as I can read in my perl book the reason for the error is that eval { BLOCK } is compiled at compile time and not runtime.
eval 'use Unicode::Normalize';
would be evaluated at runtime. What is the reason for the block syntax? And can we just change it? The error goes away in 5.6.1 with the runtime syntax.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
The purpose of
eval
with a block is simply to trap fatal runtime errors.
An
eval
with a string is compiled at runtime, which is more flexible, but slower in execution. You need string
eval
if you want to use variables when constructing the code, or if you fear that the code to be
eval
ed doesn't compile.
To make the intention of runtime evaluation clear, I'd rather use
require
:
eval { require Unicode::Normalize; }
Perl's
require
is executed at runtime regardless of whether you use it in a block or a string.
--
TWiki:Main.HaraldJoerg - 14 Feb 2007
After having studied the code we use in general we never use the eval BLOCK anywhere else. And I have additionally tested the code with the runtime type eval and it works well. It is working in perl 5.8.5 with the Unicode libs and in 5.6.1 it is ignored as it should be. Checking in this fix.
For the moment I see no other issues playing with Patch04x01 in perl 5.6.1. I am not closing this bug item yet because configure reports that some libs are too old. I doubt this is really the case for all of them.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
The configure errors that I fear are just too aggresive requirements
- CGI::Carp - Error: 1.20 installed. Version 1.26 required for for base TWiki. Do we really need 1.26?
- File::Copy - Error: 2.03 installed. Version 2.06 required for for base TWiki. Do we really need 2.06?
- File::Find - Error: Unknown version installed. Version 1.05 required for for base TWiki. What is the real minumum version?
- IO::File - Error: 1.08 installed. Version 1.10 required for for base TWiki. Do we really need v 1.10?
- Time::Local - Error: Unknown version installed. Version 0 required for for base TWiki. My fix from yesterday needs a little more shine to avoid this bogus error. Easy to fix.
Perhaps the one that added these requirements could enlighten us why the specific versions were chosen? Knowledge that earlier versions fail? Or just a matter of the earlier versions not being tested? (Like with Perl 5.6.X - which I can understand - no blame here). IF it is a matter of testing can I get some guidance what specific TWiki features I should test to verify that the versions I currently have are OK? If they pass I can lower the requirements to being my versions.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
Looking at CGI::Carp. All this module does is send messages to the httpd error log.
The change history
1.23 ineval() now checks both $^S and inspects the message for the "eval" pattern (hack alert!) in order to accomodate various combinations of Perl and mod_perl.
1.24 Patch from Scott Gifford (sgifford@suspectclassNOSPAM.com): Add support for overriding program name.
1.26 Replaced CORE::GLOBAL::die with the evil $SIG{__DIE__} because the former isn't working in some people's hands. There is no such thing as reliable exception handling in Perl.
Hard to believe that we should really require 1.26. I bet we can use even earlier versions that 1.20. And if we loose something it is messages to error log. As long as the syntax we use is new I am sure we can pick a much older version as requirement. At least 1.20.
I looked at the sources for this module and our use. We use use
CGI::Carp qw(fatalsToBrowser);
The old sources from 1998 rev 1.13 had this feature.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
Next I look at is File::Copy. It is modules that comes with standard Perl The version that came with Perl 5.6.1 is 2.03. I have been comparing the sources and the basic features have not changed. Both copy and move were there. But some error handling when copying a file with same source and target name has been added and some handling of filenames on MacOS. But my impression is that we do not really need to worry about the version of File::Copy. If the Perl version is 5.5 you have version 2.03 of File copy so instead of trying to define a version of this module I would just remove it from the DEPENDENCIES file and trust the check for the Perl version to handle this.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
File::Find is part of Perl 5.6.1 and 5.5.3 but has no revision in any of those versions. Again I am sure all we need to do is remove the check for this specific module and just count on the check for the perl version.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
Finally looked at IO:File. Another standard perl lib which has been part of Perl since 5.5.3 at least. Anything before that we do not want to care about.
The only place we use it is in Statistics.pm for a simple temporary file. We do not even need to use this module. I would say the risk is nill that the simple use we have would be an issue with the version from Perl 5.5.3. So again I would just remove this from the DEPENDENCIES.
Conclusion
Many of the modules that configure complain about seems to be noise.
The admin will run on a machine with a Perl which we must assume contains the standard Perl modules. The modules listed that the admin should need worry about are those that he needs to install in addition to standard basic Perl. And I find it to be nothing but noise to list those that should be included and should be OK.
So I say - let us remove the check for CGI::Carp, File::Copy, File::Find and IO::File and Time::Local.
They have all been in Perl since 5.5.3 or older.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
I have now tested all the
TestCases cases and all look normal under 5.6.1. So so far it looks very good indeed.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
Unit tests fails under 5.6.1. And I am sure many of the failures are because the test cases fail and not because the actual code fails. I will start analysing.
First error I see is:
There were 6 errors:
1) /var/www/Patch04x01/test/unit/ConfigureTests.pm:203 - test_resection(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
2) /var/www/Patch04x01/test/unit/ConfigureTests.pm:128 - test_loadpluggables(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
3) /var/www/Patch04x01/test/unit/ConfigureTests.pm:151 - test_conflict(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
4) /var/www/Patch04x01/test/unit/ConfigureTests.pm:24 - test_parseSave(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
5) /var/www/Patch04x01/test/unit/ConfigureTests.pm:244 - test_UI(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
6) /var/www/Patch04x01/test/unit/ConfigureTests.pm:99 - test_2parse(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
It seems that File::Temp back in 5.6.1 was not object orientated. In the sources for File::Temp the object method is documented and a note added "not yet implemented". The object method is only used one place. In
lib/configure/UIs/Extend.pm
. I am sure this could be turned non-object without any loss of anything.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
InitFormTests.pm fails. But they also fail on perl 5.8. The test case is simply broken.
RegisterTests.pm fails. And also here is the test case broken and needs fixing. Same error on perl 5.8
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
# perl ../bin/TestRunner.pl RenameTests.pm
exporting TWIKI_ASSERTS=1 for extra checking; disable by exporting TWIKI_ASSERTS=0
Assert checking on 1
....F
Time: 2 wallclock secs ( 0.77 usr 1.11 sys + 0.00 cusr 0.76 csys = 2.64 CPU)
!!!FAILURES!!!
Test Results:
Run: 4, Failures: 1, Errors: 0
There was 1 failure:
1) /var/www/Patch04x01/test/unit/RenameTests.pm:343 - test_rename_from_lowercase(RenameTests)
Status: 302 Moved
Set-Cookie: TWIKISID=9ce2a3bc4b3e2fb5480e67e0a6e58f10; path=/
Date: Wed, 14 Feb 2007 23:24:13 GMT
location: /twiki/bin/view/TemporaryRenameOldWeb/UpperCase
didn't match /(?s-xim:Location:\s+\S+?/view/TemporaryRenameOldWeb/UpperCase)/
Test was not successful.
This test pass on 5.8. But there is something wrong. Try and create using the filesystem a topic which is all lowercase. This was once allowed and we changed TWiki so it renames topics to uppercase first letter. But as code works you cannot open such a topic anymore. This is also an error on 5.8 perl. It will get its own bug topic. Until that is fixed the test case makes no sense.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
perl ../bin/TestRunner.pl TOCTests.pm
exporting TWIKI_ASSERTS=1 for extra checking; disable by exporting TWIKI_ASSERTS=0
Assert checking on 1
..F
Time: 0 wallclock secs ( 0.26 usr 0.23 sys + 0.00 cusr 0.04 csys = 0.53 CPU)
!!!FAILURES!!!
Test Results:
Run: 2, Failures: 1, Errors: 0
There was 1 failure:
1) /var/www/Patch04x01/test/unit/TOCTests.pm:132 - test_parameters(TOCTests)
expected '?param2=no%20luck;param1=a%20little%20luck', got '?param1=a%20little%20luck;param2=no%20luck'
Test was not successful.
The test result is actually fully valid. The two URL params are simply swapped in order but it is fully valid. Probably a change in behavour of the way the hash of params is pulled. That is know to be non-reproduceable in Perl. So in fact the test case could pass if modified. So maybe an action on the test case.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
conclusion on tests
Our Patch04x01 is very ready for being a "tested on 5.6.1" product. There are these actions required:
- Robustness unit case required perl 5.8. Not needed. Lower requirement to 5.6 for now.
- I remove the 5 dependencies now.
- I fix the false error that a module with no version is too old when the required version is 0.
- Change configure warning from less than 5.8 to less than 5.6. (Note we are still far from 5.5.3 support and may choose not to get there).
- Configure's use of File::Temp need to be changed to non-object
- And independently of the 5.6.1 Perl support the broken test cases needs to get fixed.
- And I need to raise a bug item for the lowercase cannot be viewed problem.
--
TWiki:Main.KennethLavrsen - 14 Feb 2007
I am currently working on the non-object use of File::Temp and I think I have it. Just need to check and test more after todays work. Also found that a method in Archive::Tar is missing in the 0.22 version which came with Perl 5.6.1. Also here I think I have a solution. I am currently testing these but because I have another error not related to my changes I am not sure enough yet to check it in this morning.
I would appreciate a quick review of the patch below which is what I am working with. And I would like someone to give feedback if the unmodified Patch04x01 can download and install
VotePlugin from configure without error.
Index: lib/TWiki/Configure/UIs/EXTEND.pm
===================================================================
--- lib/TWiki/Configure/UIs/EXTEND.pm (revision 12875)
+++ lib/TWiki/Configure/UIs/EXTEND.pm (working copy)
@@ -102,12 +102,13 @@
}
# Save it somewhere it will be cleaned up
- my $tmp = new File::Temp(SUFFIX => $ext, UNLINK=>1);
+ # my $tmp = new File::Temp(SUFFIX => $ext, UNLINK=>1);
+ my ($tmp, $tmpfilename) = File::Temp::tempfile(SUFFIX => $ext, UNLINK=>1);
binmode($tmp);
print $tmp $ar;
$tmp->close();
print "Unpacking...<br />\n";
- my $dir = _unpackArchive($tmp->filename());
+ my $dir = _unpackArchive($tmpfilename);
my @names = _listDir($dir);
# install the contents
@@ -313,9 +314,7 @@
my @members = $tar->list_files();
foreach my $file ( @members ) {
- my $target = $file;
-
- my $err = $tar->extract_file( $file, $target );
+ my $err = $tar->extract( $file );
unless ( $err ) {
print 'Failed to extract ',$file,' from tar file ',
$tar,". Archive may be corrupt.\n";
--
TWiki:Main.KennethLavrsen - 15 Feb 2007
I had to get rid of some other configure extension installer errors before I could test the above. And it is not working yet. I continue working on this.
--
TWiki:Main.KennethLavrsen - 16 Feb 2007
OK. All bugs fixed. And the extension installer no longer uses methods that did not exist in File::Temp in Perl 5.6.1.
Left is to fix the unit test cases.
--
TWiki:Main.KennethLavrsen - 17 Feb 2007
This is amazing work, Kenneth!
--
TWiki:Main.PeterThoeny - 17 Feb 2007
Fixed the unit test cases
ConfigureTests so they now pass in Perl 5.6. Again it is the File::Temp that did not have all the object methods implemented yet in the version shipping with Perl 5.6.1. Easy to fix if it shows up else where.
Just replace
my $fh = new File::Temp(UNLINK=>1);
.... $fh->filename()
with
my ($fh, $filename) = File::Temp::tempfile(unlink=>1);
.... $filename
--
TWiki:Main.KennethLavrsen - 17 Feb 2007
Found the object File::Temp was used in the extension installer template code. Fixed that. Note that some installers already on t.o will fail with perl 5.6.1. That will get fixed with new releases.
--
TWiki:Main.KennethLavrsen - 18 Feb 2007
Fixed a 5.6.1 related item. Gave it its own item as it could also be a bug in 5.8. See
Item3656
--
TWiki:Main.KennethLavrsen - 18 Feb 2007
Unit test case status
- AccessControlTests.pm
- AttrsTests.pm
- AutoAttachTests.pm
- ClientTests.pm
- ConfigureTests.pm
- ExampleTests.pm
- Fn_IF.pm
- Fn_NOP.pm
- Fn_SCRIPTURL.pm
- Fn_SEARCH.pm
- Fn_SECTION.pm
- Fn_SEP.pm
- Fn_USERINFO.pm
- FormattingTests.pm
- FormDefTests.pm
- FuncTests.pm
- HierarchicalWebsTests.pm
- InitFormTests.pm - 9 errors are false alarms because the test cases are designed assuming that CGI always delivers parameters for tags in same sequence. Test case needs to get redesigned. Manual inspection shows correct code generated.
- MergeTests.pm
- MetaTests.pm
- PasswordTests.pm (with same warning as when run in Perl 5.8)
- PrefsTests.pm
- RcsTests.pm (with the same type of errors as in Perl 5.8 - do they really pass? In 5.8 the warning is illegal seek. In 5.6 it is bad file descriptor)
- RegisterTests.pm
- RenameTests.pm
- RenderFormTests.pm
- RobustnessTests.pm
- SaveScriptTests.pm
- StoreSmokeTests.pm
- StoreTests.pm
- TemplatesTests.pm
- TimeTests.pm
- TOCTests.pm - test says failed but it is the test case which assumes the query parameters never get swapped. Test case needs to be redesigned. Manual inspection shows that the test case result is OK.
- UsersTests.pm
- VariableTests.pm
- ViewParamSectionTests.pm
- ViewScriptTests.pm
- CommentPlugin test case
So getting closer.
--
TWiki:Main.KennethLavrsen - 18 Feb 2007
Updated status above. Only Rename case is now having an unexplained failure. That is my next step
Item3666, Item3665, Item3656, Item3655, Item3648, Item3640 have so far been found and fixed as part of this work. Item3639 is opened but not yet fixed. So it has been a good exercise so far.
--
TWiki:Main.KennethLavrsen - 21 Feb 2007
Another one fixed. Rename problem was just a matter of a lowercase "l" in "Location" probably an old typo bug in the CGI module or similar module and has no impact on the browsers that understand the message anyway.
So that is the last 5.6.1 unit test case failure nailed.
I will functionally test some default plugins before I declare TWiki 4.1.2 supported by Perl 5.6.1
--
TWiki:Main.KennethLavrsen - 21 Feb 2007
I have run out of ideas of what to test now so I am closing this bug item declaring:
TWiki 4.1.2 has been tested on RedHat 7.3, Apache 1.3.23, Perl 5.6.1!
I only have a few other bugs I want to fix - then I will release 4.1.2. We are talking days till a release, not weeks.
--
TWiki:Main.KennethLavrsen - 24 Feb 2007
Closed with release of 4.1.2
KJL
Cleaned "WaitingFor" field.
--
TWiki:Main.GilmarSantosJr - 10 Aug 2008