Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Article Poll

Poll I found this article to be
Very Helpful
Helpful
Not Helpful
Not Very Helpful
[ Results | Polls ]
Comments:0 | Votes:1

SuSE8.1 installation test failures for Mysql modul

posted by Krow on 04:50 PM February 19th, 2003   Printer-friendly   Email story
I have installed slash test sites on debian a few times before, but now I'm trying to install a permanent site on SuSE8.1 I'm having problems installing Bundle::Slash - MIME, Mysql modules & libapreq are all failing their tests. I'm installing Bundle::Slash within a perl shell. I'll concentrate on Mysql module here. I'm no perl expert (not even a perl beginner), but it seems to be a problem with lib.pl in testing the Mysql module. At line 253 & 254, my build complains about these 2 lines with "Illegal character in prototype for main::ErrMsgF : @_ at t/lib.pl line 254" Here's the lines, what's wrong with them ? If they're wrong, how come they're in the bundle ? sub ErrMsg (@_) { print (@_); } sub ErrMsgF (@_) { printf (@_); } There's also a warning during the "perl Makefile.PL" phase about CAPI & PL_FILES which I don't understand either. " WARNING: CAPI is not a known parameter. WARNING: PL_FILES takes a hash reference not a array reference. Please inform the author. " Again, if the code is wrong, why is it bundled as a stable release ? I suspect that my problems are just a side effect of something else....can anyone out there point me in the right direction? I have a build log if anyone needs to see it. thanks!
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • I'm talking to myself, but I've sort of overcome this issue - by simply ignoring the tests. Firstly, a couple of the modules were failing because I didn't use UNINST=1 (yes, I'm embarrassed).
    libapreq, however, staunchly refused to pass its tests. After much digging under the hood, I discovered it was due to some privilege problem with apache when libapreq was going through its tests. The test phase launchs httpd with a test httpd.conf file that it creates, and I'm getting forbidden errors when the test tries to execute the test .pl scripts.
    I've not been able to solve the privilege problem. I'm installing libapreq as root, and apache is being run as nobody/nogroup & all the files within the documentroot have nice open permissions rwxr-x-r-x for the test .pl scripts, and rw-r--r-- for everything else. In the end I just forced an install and hoped for the best.

    It seems to work.
  • I forgot to mention that I still get the errors & warnings that I posted in my original story when compiling Msql-Mysql-modules, but now the test passes and it installs itself despite the errors, now that I'm using UNINST=1.
    Which leaves me wondering about perl module tests - how come so many perl modules (almost all in my experience) fail so many tests, but are still regarded as a 'pass' and get installed ? Does that mean that some functionality will be missing when installed on my system ?
  • I've always just forced the install, when needed.

    And I've (*knocks on wood*) never had any problems.

    --
    lottadot [lottadot.com]