Looking at CPAN I found out I could see a general status for all the tests run against the latest releases of my modules.
Tests are failing, so I decided to investigate, since I like to keep things in the green - and there seems to be a pattern, apparently DateTime on the FreeBSD platform and perhaps it is even on the same host fails with missing requirements being met - Params::Validate seem to be missing.
I wrote one of the testers and asked whether his modules where installed from CPAN or the Ports tree and it seems to be CPAN, we makes it even more weird hence it is only on FreeBSD.
Maybe I should report the bug eventhough it looks as if it is ok in the DateTime distribution.
You're not the only one
cog on 2005-10-14T14:06:49
I'm getting
something similar with Lingua::Identify, for instance.
Heck... it's from the same guy! :-\
FreeBSD 5.4 - Fails different reason..
shild on 2005-10-14T17:44:51
I am running 5.4-STABLE as well, perl 5.8.6. I use cpan, not ports (never for Perl), and Date::Holidays fails the tests because it cannot find Date::Holidays::?? (AU ... etc). Is there a Bundle?
Re:FreeBSD 5.4 - Fails different reason..
jonasbn on 2005-10-16T06:40:39
Oh,
Well the module should issue a lot of warnings for Date::Holidays::* which does not exist, but you are right I am using 2 two modules in my test which is not listed in the prerequisites, I will fix this imidiately.
Thanks,
jonasbn
Um, that would be me
grinder on 2005-10-17T20:15:19
The plan, when I first thought of it, sounded wonderful. I thought about installing all perls from 5.6.1 (5.6.0 would be a bit unfair) to 5.8.8 and blead on one box, and smoke testing new uploads to CPAN upon all (12, by my count) versions. And then the idea was to try smoking on threaded and non-threaded perls too. If a module got through all that, it would be Good. Too many test reports are from 5.8.7 these days.
So I started out with most of 5.8 to see how things worked out. The idea was to have as vanilla installations as possible. The more modules not available in the local installation, the more likely it would be that it would catch an overlooked assumption about such-and-such a module being present.
The first thing that went wrong is that CPANPLUS doesn't really expect you to share the config between a dozen different perls on one box. For a start, it downloads the same file over and over again, for each version...
The next thing that went wrong is all the modules that use Module::Build (that don't provide a Makefile.PL) failed. So I had to install that, along with its prerequisites. And a couple of other modules were more or less manditory.
Then there was the problem of modules that have prerequisites. And those modules themselves in turn have other prerequisites. By the time you come back to the top to build the module you set out to build in the first place, the @INC array doesn't contain the paths to the grandchild prerequisites, and so the test suites fail because they can't find modules that aren't even directly used.
That problem doesn't show up in real builds, because those modules are really installed and are thus found in the regular @INC paths. Modules that use ExtUtils::AutoInstall seemed to be more affected.
Not to mention all the modules that sit and hang waiting for a reply on STDIN for something or other. Why don't they know they're being run under a smoke environment and choose a sensible default?
Finally, I tried upgrading to the latest version of CPAN::YACSmoke, but then it started reporting all tests as successes, regardless of the actual results. While this would no doubt make the authors happy, it wasn't really what I was after.
I have burnt up enough tuits getting as far as I did; I can't really spend the time to go through the source and find out what's going wrong. Bug reports have been filed. In the meantime, I've given up smoking.
Sorry about the fails. Release a new version, and I promise not to smoke it, at least not until the necessary modules go through a couple of point releases.
Re:Um, that would be me
n1vux on 2005-10-17T20:28:13
Sounds like a great plan. Smoking both threaded and non-threaded but otherwise identical is an excellent idea.
For a start, it downloads the same file over and over again, for each version...
Would CPAN::Mini help, getting everything once, and then you deploy from there into each?
Re:Um, that would be me
grinder on 2005-10-17T20:40:37
Well... I actually wound up setting up a full local mirror, the initial rsync took about half an hour. But that's not the problem, that's just fixing the symptom without resolving the underlying cause.
The backend should realise that if the tarball is sitting in the local author cache, it doesn't have to go out and fetch it again. It should not. Unless you delete the file or othtewise diddle with it so that the checksum no longer matches.
I did spend a while trying to understand the code the provide a patch to make it do just that, but got sidetracked by the other, more serious problems.
But man, I hope I get this working one day.
