Installed from source :
ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-linux] (installed with
prefix option)
rake, version 0.8.4
sqlite, version 3.6.13
rubygems, version 1.3.2
Installed from gem :
actionpack-2.3.2.gem
mocha-0.9.5.gem
rails-2.3.2.gem
rspec-1.2.2.gem
sqlite3-ruby-1.2.4.gem
tests logs : http://pastie.org/462457
spec log : http://pastie.org/462467
--
Stéphan Gorget
Seems like there's something kind of fundamentally broken. Most of
those tests imply that something is quite broken, rather than being
local problems. Unfortunately, those are quite difficult to track
down remotely.
I know that the spec files run in inverse order of modification or
something like that, so sometimes the tests running in a different
order will break things. That doesn't provide you much help, though.
I'd try running those individual test files that are failing. If they
work fine on their own, then you've got conflicts between tests.
I wouldn't be surprised if the master branch has acquired a few broken
tests, but it shouldn't be anywhere near that many.
--
Getting caught is the mother of invention. --Robert Byrne
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
To be more precise, I can reproduce on my mac the sqlite3 issues when
running with ruby 1.8.7, but not with apple default 1.8.6.
I didn't bother looking deeper this issue because I thought it was local
only.
If Stéphan can reproduce those on another platform then it is an
indication it's more general than what I thought.
--
Brice Figureau
My Blog: http://www.masterzen.fr/
>
> On Wed, 2009-04-29 at 18:01 +0200, Stéphan Gorget wrote:
>> Brice thought most of them can be due to the ruby version which is
>> not 1.8.6.
>
> To be more precise, I can reproduce on my mac the sqlite3 issues when
> running with ruby 1.8.7, but not with apple default 1.8.6.
> I didn't bother looking deeper this issue because I thought it was
> local
> only.
> If Stéphan can reproduce those on another platform then it is an
> indication it's more general than what I thought.
My understanding is that 1.8.7 is an amalgam of 1.9 and 1.8.6, so it's
not surprising that there are compatibility issues, but it'd be nice
to get them fixed.
--
Reality is that which, when you stop believing in it, doesn't go
away. -- Philip K. Dick, "How to Build a Universe"
[gorget@galion10 test]$ ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-linux]
tests logs : http://pastie.org/463594
--
Stéphan Gorget
Luke Kanies a écrit :
Yes, I managed to reproduce the failing tests, and also I've fixed some
of them (I'll send the patch later this week).
As Luke said earlier, it comes from
inter-dependencies/ordering/interaction of tests.
Basically all the test/language/snippets tests are failing because
they're trying to use active_record which is initialized by the
collection tests in test/language/parser.
I could fix those by "proctecting" the various new indirector
active_record save/find call with some "return unless
Puppet[:storeconfigs]", but I don't think it is the proper way to fix
those (in fact it seems that what puppet wants to do is to use caching
on active_record which somewhat seems to be the default).
I'm going to try harder to isolate the cause, but IMHO it seems that the
asynchronous_storeconfig patchs produced those regressions.
There's probably a test that sets storeconfigs = true, which then sets
up everything to use ActiveRecord, and the test should unset these but
does not.
Even worse, setting 'storeconfigs = false' doesn't currently unset all
of the types, because I figured it was unnecessary (in a normal
process, you wouldn't normally do this).
So, if you find a test that sets storeconfigs to true, you've probably
found the culprit.
--
Between two evils, I always pick the one I never tried before.
-- Mae West
Yes I know where it is:
test/language/parser.rb
I fixed the issue (see my upcoming patch) by explicitely checking for a
storeconfigs=true in the various indirector active_record.rb.
I don't think that's the right solution, though, so I expect you'll have
lots of comments on this patch :-)
But I'm ready to fix this.
--
Brice Figureau
Days of Wonder
http://www.daysofwonder.com