[ruby-core:17393] URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk
Igal Koshevoy
attacks, failing with segmentation faults, or
change the API in ways that make it impossible to run critical Ruby
libraries such as Rails 2.0 and RSpec.
There are currently two unofficial patches submitted by ruby-talk
members that seem to fix these problems:
* http://www.ruby-forum.com/topic/157034#693292
* http://www.ruby-forum.com/topic/157034#693303
One is a backport of fixes to 1.8.6p111 by Stanislav Sedov and Hongli
Lai. The other is a fix to 1.8.6p230 by Smartleaf
which reverts a recent patch that's causing segmentation faults.
I've personally confirmed that both of these work as well as the stock
1.8.6p111 in running the Rails 2.0, RSpec 1.1.4,
and RubySpec test suites. However, I do not understand the C patches
well enough to be able to help with them myself.
Please review these patches and join in the discussion at ruby-talk or
the online thread
at http://www.ruby-forum.com/topic/157034
Thank you!
-igal
Urabe Shyouhei
please try the latest ruby_1_8_6 branch?
Igal Koshevoy
> Sorry for a late reply but I think I've fixed this issue. Can someone
> please try the latest ruby_1_8_6 branch?
>
I've checked out the latest source code and ran the test suites of
RubySpec, Rails and RSpec on it. The segfaults are gone and I'm able to
run Rails applications again. However, many tests are failing in a way
that indicates there are either bugs or changes in the API which cause
p238 to behave differently than p111.
I've updated the RedMine ticket
[http://redmine.ruby-lang.org/issues/show/199] and uploaded the
following files:
1. wrapper.sh -- Sample commands I'm running to build Ruby and execute
the test suites
2. logs.tar.gz -- The test suite logs for the various programs
In the logs, the "p111.log" files were created with Ubuntu 8.04's
patched Ruby 1.8.6p111, while the "17630.log" files were created with
SVN r17630. The best way to work with these log files is to use a modern
diff program like "gvimdiff" or "meld" which can detect intra-line
changes (a few characters changed within a line), and visually compare
them side-by-side. Note that a number of tests fail on both, this is
unfortunately normal. What's important is that the same tests pass and
fail on both versions. I'll try to make sense of the changes and errors
after I get some sleep.
Because the lastest SVN version seems to introduce API changes, trying
to fix it may be time consuming and stressful.
I urge you to consider reviewing the submitted unofficial patches and
make a new release based on a well-known stable version of the code,
such as p111 or p114.
Thank you!
-igal
Urabe Shyouhei
> Because the lastest SVN version seems to introduce API changes, trying
> to fix it may be time consuming and stressful.
>
> I urge you to consider reviewing the submitted unofficial patches and
> make a new release based on a well-known stable version of the code,
> such as p111 or p114.
No, I don't like that menu. Please take a look at the ChangeLog. All
modifications applied to 1.8.6 are bugfixes. You may think p114 was
stable enough, but it wasn't than the current one. I apologize for some
of them being incomplete, but simply reverting them won't make you happy.
Igal Koshevoy
Thank you for the explanation.
We are grateful for the bug fixes, but this version seems to change the
API. If the tests fail and API changes, then we can't deploy this
version to our users because their applications won't work.
I respect your concerns and recognize that both options I listed are
unpleasant, but urgency may require a compromised choice. Creating a
backport against p111 or p114 using some of the submitted patches as
guidance will make it possible to create a fully-compatible official
solution within hours. In contrast, figuring out how to make the latest
SVN version compatible can take days to weeks.
I realize that a backport using an older version may seem distasteful,
but most people are using p36, p111, and p114 with selected patches.
These older versions may have issues, but nothing that's so noticeable
that it prevents them from being used, unlike the new versions.
For the sake of protecting Ruby's good image, I believe it's necessary
to ship an *official* version that's compatible and addresses these
vulnerabilities as soon as possible. After that's shipped, resolving the
matter with the API changes in the current code will likely be a
priority. If there's anything that we in the Ruby community can help you
with, please ask. :)
To: All
If anyone can lend a, check out the RedMine ticket at
[http://redmine.ruby-lang.org/issues/show/199]. It contains a
mostly-automated set of commands for downloading, compiling the new
Ruby, and running it against the various test suites. It also contains
full logs of my test output which demonstrate how the new code is
failing dozens of tests that the old stable releases passed. Please join
me in trying to figure out what's wrong and filing bug reports so that
the current Ruby branch can be improved.
-igal
Tanaka Akira
Igal Koshevoy <ig...@pragmaticraft.com> writes:
> [http://redmine.ruby-lang.org/issues/show/199] and uploaded the
> following files:
> 1. wrapper.sh -- Sample commands I'm running to build Ruby and execute
> the test suites
> 2. logs.tar.gz -- The test suite logs for the various programs
I read the logs of rubyspec.
I think there are bugs in Ruby and RubySpec.
Ruby bugs:
Module#remove_method
String#%
Iconv
RubySpec bugs:
BigDecimal
Date
ERB
REXML
Singleton#_dump
--
Tanaka Akira
Federico Builes
On Jun 28, 2008, at 11:01 PM, Tanaka Akira wrote:
> I read the logs of rubyspec.
>
> BigDecimal
> Date
> ERB
> REXML
> Singleton#_dump
I'm not sure how's the situation with most of these libraries but I
was responsible for the REXML specs so let me chime in. P111 had a
_really_ buggy REXML revision with several typos/small bugs that were
(mostly) fixed in P114 so that might be a better target for
compatibility (for that library at least).
Anyway, if you consider there's a wrong spec somewhere in there please
let me know.
As for the other libraries, I'm sure we'll be checking them tomorrow
since what we consider a Ruby bugs usually goe together with a filled
bug report.
--
Federico
Tanaka Akira
Federico Builes <federic...@gmail.com> writes:
> I'm not sure how's the situation with most of these libraries but I
> was responsible for the REXML specs so let me chime in. P111 had a
> _really_ buggy REXML revision with several typos/small bugs that were
> (mostly) fixed in P114 so that might be a better target for
> compatibility (for that library at least).
Yes. REXML has typo.
This is an example of failure caused by typo.
| REXML::Document#add overwrites existing DocType ERROR
| NoMethodError: undefined method `kind_of' for #<REXML::DocType:0xb7580630>
> Anyway, if you consider there's a wrong spec somewhere in there please
> let me know.
The test has ruby_bug guard.
rubyspec/1.8/library/rexml/document/add_spec.rb:
| ruby_bug "#19058", "1.8.6.114" do
The test is run for 1.8.6p238 but not for ruby 1.8.6p114.
This causes rubyspec/1.8/17630.log has the above failure
which is not in rubyspec/1.8/p111.log in the reported log.
But this doesn't mean REXML in 1.8.6p238 has new bug or spec
change.
--
Tanaka Akira
Urabe Shyouhei
> For the sake of protecting Ruby's good image, I believe it's necessary
> to ship an *official* version that's compatible and addresses these
> vulnerabilities as soon as possible. After that's shipped, resolving
> the matter with the API changes in the current code will likely be a
> priority. If there's anything that we in the Ruby community can help
> you with, please ask. :)
Yes. Please write a patch :)
I know your concerns. I know you all need a stable Ruby, rather than a
beautifully working Ruby. Actually that's why I'm still maintaining
1.8.6. And sorry again for its unexpectedly unstable.
But honestly I'm doubtful for urgency of current situation. If things
are that dangerous someone might be writing patches, like some people
did for p230. I think p230 was dangerous enough. But now that fixes
are made, it seems it's less urgent. I think we should wait for fixes
made into 1.8.6, rather than reverting to p114 + a security fix. If you
can't wait please fix it by yourself; we are very grateful to merge that
into our repository. In other words, I think it's not that urgent
because no one seems to trying to fix those APIs.
Anyway, p238 source code can be downloaded via
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_6_238
Igal Koshevoy
> I'm not sure how's the situation with most of these libraries but I
> was responsible for the REXML specs so let me chime in. P111 had a
> _really_ buggy REXML revision with several typos/small bugs that were
> (mostly) fixed in P114 so that might be a better target for
> compatibility (for that library at least).
p111, I mean the copy shipped with Ubuntu that's got 11 patches applied
to it, including the REXML fixes. It would be a worthwhile effort to
figure out what patches the various distros are using, making sure
they're providing a complete solution, and also ensuring that we're
incorporating these into the other solutions we've been throwing around.
Here's what some vendors are doing:
FreeBSD ports patches the vulnerability against p111:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/
Ubuntu 7.10 patches the vulnerability against p36:
https://launchpad.net/ubuntu/gutsy/+source/ruby1.8/1.8.6.36-1ubuntu3.2/+files/ruby1.8_1.8.6.36-1ubuntu3.2.diff.gz
Ubuntu 8.04 patches the vulnerability against p111:
https://launchpad.net/ubuntu/hardy/+source/ruby1.8/1.8.6.111-2ubuntu1.1/+files/ruby1.8_1.8.6.111-2ubuntu1.1.diff.gz
Fedora 9 patches the vulnerability against p230:
http://download.fedora.redhat.com/pub/fedora/linux/updates/9/SRPMS/ruby-1.8.6.230-2.fc9.src.rpm
RedHat Enterprise Linux 5.1, their latest, uses 1.8.5 and is vulnerable:
http://install.linux.duke.edu/pub/linux/updates/centos-5.1/SRPMS/ruby-1.8.5-5.el5_1.1.src.rpm
-igal
M. Edward (Ed) Borasky
>>>> Emerging (1 of 1) dev-lang/ruby-1.8.6_p114 to /
> * ruby-1.8.6-p114.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
> * checking ebuild checksums ;-) ... [ ok ]
> * checking auxfile checksums ;-) ... [ ok ]
> * checking miscfile checksums ;-) ... [ ok ]
> * checking ruby-1.8.6-p114.tar.bz2 ;-) ... [ ok ]
>>>> Unpacking source...
>>>> Unpacking ruby-1.8.6-p114.tar.bz2 to /var/tmp/portage/dev-lang/ruby-1.8.6_p114/work
> * Applying ruby-1.8.6-memory-leak.diff ... [ ok ]
> * Applying ruby-1.8.6_p111-r13657.patch ... [ ok ]
Incidentally, Ruby 1.8.7 is in the Portage tree, but it's masked.
Igal Koshevoy
> Igal Koshevoy wrote:
>> Federico Builes wrote:
>>> I'm not sure how's the situation with most of these libraries but I
>>> was responsible for the REXML specs so let me chime in. P111 had a
>>> _really_ buggy REXML revision with several typos/small bugs that
>>> were (mostly) fixed in P114 so that might be a better target for
>>> compatibility (for that library at least).
>> I'm glad you mentioned this. When I was talking about using a stable
>> p111, I mean the copy shipped with Ubuntu that's got 11 patches
>> applied to it, including the REXML fixes. It would be a worthwhile
>> effort to figure out what patches the various distros are using,
>> making sure they're providing a complete solution, and also ensuring
>> that we're incorporating these into the other solutions we've been
>> throwing around.
>>
>> Here's what some vendors are doing:
>>
>> FreeBSD ports patches the vulnerability against p111:
>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/
>>
>> Ubuntu 7.10 patches the vulnerability against p36:
>>
>> https://launchpad.net/ubuntu/gutsy/+source/ruby1.8/1.8.6.36-1ubuntu3.2/+files/ruby1.8_1.8.6.36-1ubuntu3.2.diff.gz
>>
>>
>> Ubuntu 8.04 patches the vulnerability against p111:
>>
>> https://launchpad.net/ubuntu/hardy/+source/ruby1.8/1.8.6.111-2ubuntu1.1/+files/ruby1.8_1.8.6.111-2ubuntu1.1.diff.gz
>>
Providing support and patches for 1.8.5 may be necessary. The latest
releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or "stable"),
SUSE, and possibly others are still shipping 1.8.5 and will be
frustrated by the abrupt termination of updates.
-igal
Igal Koshevoy
guard conditions. I've read up on the topic at
http://rubyspec.org/wiki/rubyspec/Guards
As I understand this, the #ruby_bug method silently acts as if the
example passed when run on an implementation with a known bug. Shouldn't
this provide some warning, kind of like RSpec treats "pending"?
The SVN r17630 Ruby that I tested still has this bug that Federico
Builes reported and provided a patch for three months ago.
The spec says that the bug is only present up to p114, but if the patch
was never officially applied, shouldn't the guard condition be updated
or relaxed?
-igal
Urabe Shyouhei
> Providing support and patches for 1.8.5 may be necessary. The latest
> releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or
> "stable"), SUSE, and possibly others are still shipping 1.8.5 and will
> be frustrated by the abrupt termination of updates.
>
> -igal
1.8.5 life-span has been scheduled and informed at least since 2006,
plus, to be frank, we have no human resources remaining to prolong this
version.
I will never stop YOU to maintenance 1.8.5; forking Ruby is your
right. And some OS vendors may actually do so. But do not expect
further support by us.
Igal Koshevoy
> 1.8.5 life-span has been scheduled and informed at least since 2006,
> plus, to be frank, we have no human resources remaining to prolong this
> version.
>
releases?
> I will never stop YOU to maintenance 1.8.5; forking Ruby is your
> right. And some OS vendors may actually do so. But do not expect
> further support by us.
What if resources for keeping 1.8.5 on life support could be found and
provided by members outside the current Ruby core developer team and
these people met whatever criteria you set for them? Would your team be
willing to consider providing them with a way to continue to make
official Ruby 1.8.5 releases and distribute them from ruby-lang.org?
-igal
Igal Koshevoy
> In article <48662E99...@pragmaticraft.com>,
> Igal Koshevoy <ig...@pragmaticraft.com> writes:
>> [http://redmine.ruby-lang.org/issues/show/199] and uploaded the
>> following files:
>> 1. wrapper.sh -- Sample commands I'm running to build Ruby and execute
>> the test suites
>> 2. logs.tar.gz -- The test suite logs for the various programs
>>
> I read the logs of rubyspec.
>
>
> I think there are bugs in Ruby and RubySpec.
>
> Ruby bugs:
> Module#remove_method
> String#%
> Iconv
>
I agree, these seem to be bugs in the current implementation of Ruby and
these definitely worked earlier.
> RubySpec bugs:
> BigDecimal
> Date
>
I agree. But how should these be fixed? The spec examples say these bugs
only exist in Ruby versions up to and including p114, but these bugs
still exist. Should the patchlevel value in these examples be updated to
p238 or should it be set to a more general value, like :ruby18, to
indicate that no known version of MRI 1.8 can pass this test?
> RubySpec bugs:
> [...]
> ERB
> REXML
> Singleton#_dump
>
I think these are bugs in Ruby, not in RubySpec. The code in these
worked correctly without any guard conditions on my older interpreter,
therefore if the new version is failing these, something has changed.
Can you or someone else please review these specs to confirm this?
Just to be clear, REXML has some errors due to the guard conditions
explained in the "RubySpec bugs" section above. However, some of the
REXML errors were in examples without guard conditions, therefore I
think they're Ruby errors.
The above list is all the errors that were flagged for attention in the
RubySpec logs. Bugs in String#%, Iconv, ERB and REXML bugs are fairly
important given that these are widely used.
Is there a way to generate code coverage reports for both the C and Ruby
code being run? This would really provide a better idea of how complete
RubySpec really is.
I'm delighted that we have RubySpecs to help us. Thank you for the hard
work: Brian Ford, Federico Builes, Arthur Schreiber, and all the other
contributors. You're providing a valuable service to the Ruby community. :)
-igal
Tanaka Akira
Igal Koshevoy <ig...@pragmaticraft.com> writes:
> I think these are bugs in Ruby, not in RubySpec. The code in these
> worked correctly without any guard conditions on my older interpreter,
> therefore if the new version is failing these, something has changed.
> Can you or someone else please review these specs to confirm this?
ERB tests compare Ruby code generated internaly in ERB.
It is internal of ERB. RubySpec shouldn't specify library
internals.
Singleton#_dump should be public. It is discussed recently
in ruby-core. This is a bug fix. RubySpec shouldn't
specify a bug.
> Just to be clear, REXML has some errors due to the guard conditions
> explained in the "RubySpec bugs" section above. However, some of the
> REXML errors were in examples without guard conditions, therefore I
> think they're Ruby errors.
Do you want to fix REXML problems in 1.8.6 line?
--
Tanaka Akira
Igal Koshevoy
> Igal Koshevoy wrote:
>
>> For the sake of protecting Ruby's good image, I believe it's necessary
>> to ship an *official* version that's compatible and addresses these
>> vulnerabilities as soon as possible. After that's shipped, resolving
>> the matter with the API changes in the current code will likely be a
>> priority. If there's anything that we in the Ruby community can help
>> you with, please ask. :)
>>
>
> Yes. Please write a patch :)
>
to offer assistance.
> I know you all need a stable Ruby, rather than abeautifully working Ruby.
I love Ruby because it's beautiful. But the people that pay me don't
care about beauty, only stability. :/
> But honestly I'm doubtful for urgency of current situation. If things
> are that dangerous someone might be writing patches, like some people
> did for p230. I think p230 was dangerous enough. But now that fixes
> are made, it seems it's less urgent.
Please release an official fix and soon. The urgency is that it's now
been 9 days and there's no official solution to the vulnerabilities
reported and the segmentation faults in p230.
Ruby user's options for resolving this currently are very problematic.
They either must scour websites and mailing lists for patches, and
personally decide which of these complex unofficial patches to use,
which is far beyond most people's ability. Meanwhile, many OS vendors
have lost patience and are now beginning to ship patched versions, but
they're also making guesses about how to patch this.
The Ruby community and distros are waiting for an *official* release
that provides a solution to these problems.
Although p238 breaks some things, it's better than the
officially-released p230 version. This p238 may be worth releasing
because it addresses the immediate problems with that failed release and
passes the Rails and RSpec test suites just as well as the Ubuntu
patched p111 version that I was comparing it to. But please note that I
can't evaluate the C code, so I'm entirely depending on your judgment
about whether it's ready.
Depending on how long it takes to address the compatibility issues
uncovered by RubySpec, it may make sense to ship p238 now and ship
another release with the compatibility fixes as soon as they're ready.
-igal
Igal Koshevoy
> In article <48678E3D...@pragmaticraft.com>,
> Igal Koshevoy <ig...@pragmaticraft.com> writes:
>
>
>> I think these are bugs in Ruby, not in RubySpec. The code in these
>> worked correctly without any guard conditions on my older interpreter,
>> therefore if the new version is failing these, something has changed.
>> Can you or someone else please review these specs to confirm this?
>>
>
> ERB tests compare Ruby code generated internaly in ERB.
> It is internal of ERB. RubySpec shouldn't specify library
> internals.
>
mean. The ERB spec is comparing the Ruby code generated, which it really
should be comparing just the output.
> Singleton#_dump should be public. It is discussed recently
> in ruby-core. This is a bug fix. RubySpec shouldn't
> specify a bug.
>
I see, thank you for the explanation.
>> Just to be clear, REXML has some errors due to the guard conditions
>> explained in the "RubySpec bugs" section above. However, some of the
>> REXML errors were in examples without guard conditions, therefore I
>> think they're Ruby errors.
>>
> Do you want to fix REXML problems in 1.8.6 line?
>
I'd personally like to see the patch that Federico Builes reviewed,
improved and applied if it seems reasonable. At the very least, Ruby
shouldn't be shipping a library that fails due to a syntax error in it.
However, there are some unguarded REXML examples that are failing, which
may indicate a new Ruby bug/incompatibility. I also think there's
another Ruby problem exposed by "library/bigdecimal/divmod_spec.rb". So
if you or someone else can review these, I'd appreciate it.
So the list of things we think may be broken based on reviewing
RubySpec's logs seem to be:
Module#remove_method
String#%
Iconv
ERB (?)
BigDecimal (?)
Thank you again for the assistance.
-igal
Tanaka Akira
Igal Koshevoy <ig...@pragmaticraft.com> writes:
> However, there are some unguarded REXML examples that are failing, which
> may indicate a new Ruby bug/incompatibility.
In your log, which is not guarded?
| 36)
| REXML::Document#add overwrites existing DocType ERROR
| NoMethodError: undefined method `kind_of' for #<REXML::DocType:0xb7580630>
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:80:in `add'
| ./library/rexml/document/add_spec.rb:40
|
| 37)
| REXML::Document#<< overwrites existing DocType ERROR
| NoMethodError: undefined method `kind_of' for #<REXML::DocType:0xb7579024>
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:80:in `add'
| ./library/rexml/document/add_spec.rb:40
|
| 38)
| REXML::Document#write returns document with transitive support ERROR
| ArgumentError: wrong number of arguments (2 for 1)
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:188:in `initialize'
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:188:in `new'
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:188:in `write'
| ./library/rexml/document/write_spec.rb:33
|
| 39)
| REXML::Element#delete_element deletes Element and returns it FAILED
| Expected nil
| to equal <some_node/>
|
| /home/igal/mtmp/rubyfix/ruby-svn17630/lib/ruby/gems/1.8/gems/mspec-1.0.0/lib/mspec/expectations/expectations.rb:10:in `fail_with'
| /home/igal/mtmp/rubyfix/ruby-svn17630/lib/ruby/gems/1.8/gems/mspec-1.0.0/lib/mspec/matchers/base.rb:8:in `=='
| ./library/rexml/element/delete_element_spec.rb:35
--
Tanaka Akira
Urabe Shyouhei
> Urabe Shyouhei wrote:
>> 1.8.5 life-span has been scheduled and informed at least since 2006,
>> plus, to be frank, we have no human resources remaining to prolong this
>> version.
>>
> Just to confirm, you're terminating support for 1.8.5 and all earlier
> releases?
Yes. All releases prior to 1.8.5, including all 1.4 series and all 1.6
series, are not supported any longer.
Also for a side note, support for 1.8.6 will be terminated once we
release 1.8.8. Support for 1.8.7 will also be terminated once we
release 1.8.9.
>> I will never stop YOU to maintenance 1.8.5; forking Ruby is your
>> right. And some OS vendors may actually do so. But do not expect
>> further support by us.
> What if resources for keeping 1.8.5 on life support could be found and
> provided by members outside the current Ruby core developer team and
> these people met whatever criteria you set for them?
That's great. Far better than I can imagine.
> Would your team be willing to consider providing them with a way to
> continue to make official Ruby 1.8.5 releases and distribute them from
> ruby-lang.org?
This is my personal opinion but it's OK for a new mentor to get a full
control of everything to officially release 1.8.5. Final decision
should be made by matz so I cannot tell any particular thing but, I
wish he says yes.
Igal Koshevoy
> In article <4867A6AC...@pragmaticraft.com>,
> Igal Koshevoy <ig...@pragmaticraft.com> writes:
>
>> However, there are some unguarded REXML examples that are failing, which
>> may indicate a new Ruby bug/incompatibility.
>>
>
> In your log, which is not guarded?
>
be accounted for by stale version numbers in the spec.
The current guard lines read like this:
ruby_bug "#17910", "1.8.6.114" do
What should these sorts of lines be changed to if no official version of
MRI supports the code in these examples? "1.8.6"? "1.8"?
-igal
M. Edward (Ed) Borasky
> Providing support and patches for 1.8.5 may be necessary. The latest
> releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or "stable"),
> SUSE, and possibly others are still shipping 1.8.5 and will be
> frustrated by the abrupt termination of updates.
RHEL *5* is still using 1.8.5? In that case, dropping support for 1.8.5
is a *huge* problem. RHEL *4* using 1.8.5 I think the world could deal
with. After all, Red Hat is always going to market their own upgrades
aggressively, and anybody who's still on RHEL 3/2.4.21-EL deserves what
they get. :)
I'm not all that concerned about Etch. It's fairly rare in the server
world, it's not really "marketed", and Debian's Ruby packaging structure
isn't particularly well-liked by Rubyists. You're probably more likely
to see a Fedora server than one running Etch. If I were running a Debian
server I'd simply put Ruby up from source. What about the paid-for
versions of Novell SuSE?
Federico Builes
On Jun 29, 2008, at 11:51 AM, Igal Koshevoy wrote:
> The current guard lines read like this:
> ruby_bug "#17910", "1.8.6.114" do
>
> What should these sorts of lines be changed to if no official
> version of MRI supports the code in these examples? "1.8.6"? "1.8"?
The correct guard in this case should be 1.8 as you propose. I'll be
taking a look at the specs this afternoon to ensure it's correctly
guarded, but remember REXML is kept in a separate repository so
there's a chance that these issues have been already corrected there
(I know some of the bug reports were ported).
--
Federico
M. Edward (Ed) Borasky
>> Providing support and patches for 1.8.5 may be necessary. The latest
>> releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or
>> "stable"), SUSE, and possibly others are still shipping 1.8.5 and will
>> be frustrated by the abrupt termination of updates.
>
> RHEL *5* is still using 1.8.5? In that case, dropping support for 1.8.5
> is a *huge* problem. RHEL *4* using 1.8.5 I think the world could deal
> with. After all, Red Hat is always going to market their own upgrades
> aggressively, and anybody who's still on RHEL 3/2.4.21-EL deserves what
> they get. :)
Well ... it looks like RHEL 5 *is* using 1.8.5:
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ruby-1.8.5-5.el5_1.1.src.rpm
dated 12 November 2007.
What are the odds that Red Hat corporate will put manpower onto
supporting Ruby 1.8.5? This is a security issue, and they pretty much
have to fix it. I don't know anyone there, nor do I own any licenses. I
do from time to time experiment with the CentOS and Scientific Linux
re-spins of RHEL 5, but they have to wait for Red Hat to release the
source RPM.
Urabe Shyouhei
> 1.8.5 is a *huge* problem. RHEL
Why on earth?
We are not cat's-paw of RedHat, nor Sun, nor Microsoft; we are
individual from any OS vendors. It is quite natural for them to have
different maintenance plan than ours. Equally natural for us to have
different plans than theirs.
Joel VanderWerf
Bravo.
The Ruby core developers are hardly going to get any work done if they
are supporting more than 2 or 3 releases at a time. Let the distributors
keep up with the developers, rather than drag them down. As long as
there is a current stable release, everyone who wants a stable ruby
should move their code to it (how hard can it be to move from 1.8.5. to
1.8.6, especially since 1.8.5 was a bit problematic itself, IIRC).
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Urabe Shyouhei
to release them again. Expected date for that is Jul. 4 (in Japanese
Timezone).
Can you check to see if they works on your machine? I don't want to
release again and again (that make users confuse.) I want to make next
release acceptable for you.
M. Edward (Ed) Borasky
some Subversion code to check out the exact source?
Vladimir Sizikov
* 1.8.6 HEAD has 7 rubyspec falures for StringIO
* 1.8.7 HEAD has *57* rubyspec failures for StringIO
Take a look here (for 1.8.7 faliures)
http://pastie.org/226299
Would it be possible to fix at least 1.8.7 branch?
Please note that 1.8 HEAD passes all 100% StringIO rubyspecs.
Thanks,
--Vladimir
Charles Oliver Nutter
> Hi Urabe,
>
> * 1.8.6 HEAD has 7 rubyspec falures for StringIO
> * 1.8.7 HEAD has *57* rubyspec failures for StringIO
>
> Take a look here (for 1.8.7 faliures)
> http://pastie.org/226299
>
> Would it be possible to fix at least 1.8.7 branch?
>
> Please note that 1.8 HEAD passes all 100% StringIO rubyspecs.
There should not be a release until the failures in rubyspec are addressed.
- Charlie
Igal Koshevoy
> Hello, I think current 1.8.6/1.8.7 is stable than p230/p22
serious, such as the breakage of Iconv.
> Can you check to see if they works on your machine? I don't want to
> release again and again (that make users confuse.) I want to make next
> release acceptable for you.
I've re-run the test suites, along with some additional ones, against
Ruby 1.8.6 SVN 17631 and the results seem promising.
The RubySpec team's been working hard to expand their specs and
eliminate the false positives I reported last time. Many thanks to
Federico Builes, Vladimir Sizikov, Arthur Schreiber, Tanaka Akira, Brian
Ford, and others for the timely effort.
Here are the latest results from the test suites:
RubySpec [Wed Jul 2 11:27:11 2008 -0500]
* Module#remove_method fails
* String#% failures
* Iconv has many, many failures
Rails 1.2.6
* Fine!
Rails 2.0.2
* Fine!
Rails 2.1.0
* Fine!
Rails tip
* Hundreds of tests seem to be skipped, haven't figured out why.
RSpec 1.1.4
* Fine. Although it fails the 'identical HTML' spec, that spec is flaky
and shouldn't count.
Complete, updated logs: http://redmine.ruby-lang.org/attachments/download/15
Please double-check my findings.
-igal
Igal Koshevoy
memory leaks.
Two separate users have reported leaks when running p230 with the
Smartleaf patch, while having no such problems when running p111/p114
backported versions. Because the Smartleaf patch simply reverts some
refactoring to resolve segfaults, it's unlikely that its causing the
leaks, and the probable source is changes introduced into Ruby itself
between p114 and p230. Here's a link to that other thread
http://www.ruby-forum.com/topic/157034#697304
I've asked both of those reporting the problem to give us further
information, but it may be difficult for them to do, especially since
both are trying to stabilize their apps and may not have time for debugging.
Can someone please try to come up with a way to reproduce this memory
leak with p230 and confirm whether it's been resolved with p238?
Thanks!
-igal
Vladimir Sizikov
I'd strongly suggest to postpone 1.8.7 release untill te majority of
the rubyspec failures is fixed. I already reported 57 StringIO
failures. There are also *127* String rubyspec failures (thanks to
Federico Builes for reminding me about those).
Please note that 1.8 HEAD passes all tests (so the fixes are already there).
Also, I see some securerandom spec failues with 1.8.7 head, while 1.8
HEAD is clean.
P.S. There could be more reports from RubySpec folks who are currently
running the tests.
Thanks,
--Vladimir
On Wed, Jul 2, 2008 at 12:41 PM, Urabe Shyouhei <shyo...@ruby-lang.org> wrote:
Luis Lavena
I'm not happy to inform that the make test-all procedure still stall
in test_07_public_private_protected_missing(TestDRbCore) for
i386-mingw32 platform.
Tested with SVN:
http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_6
revision: 17815
Our testing procedure uses the same version of ruby just build to host
the test and also serve as baseruby (adding it to the path before the
one used to actually build the sandbox).
This procedure has worked for us in the past, even way before I made
public the sandbox project repository.
Moreover, I'll like to mention that I can replicate the same behavior
using many version of base ruby and many Windows XP and Vista 32bits
installation, since the sanbox of RubyInstaller is designed to make it
easy recreate the whole environment:
http://github.com/luislavena/rubyinstaller
On the other hand, using 1.8.6-p114, even with the patches [1]
applied, still passes those tests.
I'll likely help tracking this issue down, but the several
branches/tags per-commit make it hard and very difficult to obtain a
clear commit/log history to determine the correct place of those
issues and revert or fix the ones affecting us.
[1] http://www.rubyinstaller.org/patches/
Regards,
--
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams
Urabe Shyouhei
> There should not be a release until the failures in rubyspec are
> addressed.
OK, so all of you can wait until rubyspec passes? I think I cannot
review every failures in a 24 hours so releases should be delayed. Is it
really OK?
I'm neutral whether we should make an immediate release, or we need more
brush-up to release.
Federico Builes
On Jul 2, 2008, at 10:30 PM, Urabe Shyouhei wrote:
> Charles Oliver Nutter wrote:
>> There should not be a release until the failures in rubyspec are
>> addressed.
>
> OK, so all of you can wait until rubyspec passes? I think I cannot
> review every failures in a 24 hours so releases should be delayed.
> Is it
> really OK?
We'd appreciate it if you could hold on a bit. Most of the current
failures are related to Iconv, StringIO (reported by Vladimir Sizikov
in 17504) and the EditLine wrapper for OS X users (17479).
Memory leaks reported in http://redmine.ruby-lang.org/issues/show/216
should be checked too.
Thanks.
--
Federico
Federico Builes
On Jul 2, 2008, at 2:31 PM, Vladimir Sizikov wrote:
> P.S. There could be more reports from RubySpec folks who are currently
> running the tests.
I'll chime in here and post some more results:
* Iconv
The version of Iconv bundled in 1.8.6 HEAD has 16 spec failures:
- http://pastie.caboo.se/paste/226883
The version of Iconv bundled in 1.8.7 HEAD has 3 spec failures:
- http://pastie.caboo.se/paste/226885
You can see the full specs in:
- http://github.com/rubyspec/rubyspec/tree/master/1.8/library/iconv
If you consider any of these behaviors to be wrong please let us know.
* BasicSocket#close_read
The current implementation in 1.8 and 1.9 allows the user to call
close_read (or close_write) twice on a socket without raising errors.
s = Socket.new(AF_INET, SOCK_STREAM, 0)
s.bind(Socket.pack_sockaddr_in(9999, "localhost")
s.close_read
s.close_read # No errors raised
Contrast this with IO#close_read(and #close_write) which will raise an
IOError if you try to close an already closed end.
What behavior should we spec in this case?
--
Federico
Tanaka Akira
Federico Builes <federic...@gmail.com> writes:
> * Iconv
>
> The version of Iconv bundled in 1.8.6 HEAD has 16 spec failures:
> - http://pastie.caboo.se/paste/226883
> The version of Iconv bundled in 1.8.7 HEAD has 3 spec failures:
> - http://pastie.caboo.se/paste/226885
What the revision or patchlevel of the "HEAD"?
What the output of "ruby -v"?
It seems iconv.c in 1.8.6 and 1.8.7 differs only comments now.
So they should behave similar.
% svn diff http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_6/ext/iconv/iconv.c http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_7/ext/iconv/iconv.c
Index: iconv.c
===================================================================
--- iconv.c (.../ruby_1_8_6/ext/iconv/iconv.c) (revision 17840)
+++ iconv.c (.../ruby_1_8_7/ext/iconv/iconv.c) (revision 17840)
@@ -43,8 +43,12 @@
...
> You can see the full specs in:
> - http://github.com/rubyspec/rubyspec/tree/master/1.8/library/iconv
>
> If you consider any of these behaviors to be wrong please let us know.
As far as nobu's opinion, [ruby-core:17127], RubySpec
specifys bug behavior.
> * BasicSocket#close_read
>
> The current implementation in 1.8 and 1.9 allows the user to call
> close_read (or close_write) twice on a socket without raising errors.
>
> s = Socket.new(AF_INET, SOCK_STREAM, 0)
> s.bind(Socket.pack_sockaddr_in(9999, "localhost")
> s.close_read
> s.close_read # No errors raised
>
> Contrast this with IO#close_read(and #close_write) which will raise an
> IOError if you try to close an already closed end.
>
> What behavior should we spec in this case?
I feel it should cause an error.
Successive shutdown system calls doesn't fail, though.
% strace ruby -rsocket -e 's1, s2 = UNIXSocket.pair; 10.times { s1.close_read }'
...
socketpair(PF_FILE, SOCK_STREAM, 0, [3, 4]) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
...
--
Tanaka Akira
U.Nakamura
In message "[ruby-core:17517] Re: We'll release 1.8.6/1.8.7 this Friday"
on Jul.03,2008 07:05:43, <luisl...@gmail.com> wrote:
> I'm not happy to inform that the make test-all procedure still stall
> in test_07_public_private_protected_missing(TestDRbCore) for
> i386-mingw32 platform.
I can't reproduce it with mswin32...
Can you test with reverting r17290 (socket changes)?
Regards,
--
U.Nakamura <u...@garbagecollect.jp>
Federico Builes
On Jul 3, 2008, at 12:47 AM, Tanaka Akira wrote:
> It seems iconv.c in 1.8.6 and 1.8.7 differs only comments now.
> So they should behave similar.
You're right, I was testing against 1.8.6p255 but p264 seems to fix
the issue and fail the same specs that 1.8.7 was failing. We'll look
into it.
> I feel it should cause an error.
> Successive shutdown system calls doesn't fail, though.
We'll spec this behavior then, thanks for your support.
--
Federico
Vladimir Sizikov
On Thu, Jul 3, 2008 at 5:30 AM, Urabe Shyouhei <shyo...@ruby-lang.org> wrote:
> Charles Oliver Nutter wrote:
>> There should not be a release until the failures in rubyspec are
>> addressed.
>
> OK, so all of you can wait until rubyspec passes? I think I cannot
> review every failures in a 24 hours so releases should be delayed.
It seems to me that the majority of String and StringIO failures is
caused by common cause and removing it will bring that huge number of
failing specs down.
> Is it really OK?
This is perfectly OK with me :)
> I'm neutral whether we should make an immediate release, or we need more
> brush-up to release.
There are multiple folks looking at and working on RubySpecs now,
including 3 Google Sommer of Code students, so it is a perfect
opportunity to make next Ruby release as good as possible and to
improve RubySpecs too.
Feel free to join #rubyspec IRC on freenode, most folks hang out
there, so we could shorten the failures evaluation time and help out
in any way we could.
Thanks,
--Vladimir
Tanaka Akira
Federico Builes <federic...@gmail.com> writes:
> We'll spec this behavior then, thanks for your support.
Note that my feeling is not the decision of ruby.
Ask matz for that.
--
Tanaka Akira
Luis Lavena
> Hello,
>
> In message "[ruby-core:17517] Re: We'll release 1.8.6/1.8.7 this Friday"
> on Jul.03,2008 07:05:43, <luisl...@gmail.com> wrote:
>> I'm not happy to inform that the make test-all procedure still stall
>> in test_07_public_private_protected_missing(TestDRbCore) for
>> i386-mingw32 platform.
>
> I can't reproduce it with mswin32...
>
> Can you test with reverting r17290 (socket changes)?
>
>
The bad thing is I don't have my VC6 environment to reproduce it
accurately (running on my laptop right now).
Reverting the specified revision fix the issue:
> Regards,
> --
> U.Nakamura <u...@garbagecollect.jp>
>
>
>
1588 tests, 15068 assertions, 3 failures, 0 errors
http://pastie.org/private/xk8thrwcbzeb2h1s7lm3tw
Those are the same errors that are failing under p114, which is nice.
One comment about r17290 is that it previously worked, since before
1.8.7 was released I've been able to use ruby_1_8 branch, which
included the same backport.
Now I'll run the specs to avoid missing something.
Thanks for your time.
schreibe...@googlemail.com
Most of these 57 rubyspec failures are caused by the convert_type
change, that made convert_type check for private methods, too. This
change has already been reverted in 1.8.6 and 1.8 HEAD (even in
1.8.5), but not yet in 1.8.7.
Simply backporting http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=17396
into the 1.8.7 branch should fix these and many, many more failures
that we are currently seeing when running the latest 1.8.7 versions
against the rubyspecs.
Thanks, Arthur
On 2 Jul., 16:51, "Vladimir Sizikov" <vsizi...@gmail.com> wrote:
> Hi Urabe,
>
> * 1.8.6 HEAD has 7 rubyspec falures for StringIO
> * 1.8.7 HEAD has *57* rubyspec failures for StringIO
>
> Take a look here (for 1.8.7 faliures)http://pastie.org/226299
U.Nakamura
In message "[ruby-core:17530] Re: We'll release 1.8.6/1.8.7 this Friday"
on Jul.03,2008 16:16:34, <luisl...@gmail.com> wrote:
> > Can you test with reverting r17290 (socket changes)?
Oh, sorry, I'd mistaken.
These are select changes, not socket changes.
> Reverting the specified revision fix the issue:
>
> 1588 tests, 15068 assertions, 3 failures, 0 errors
> http://pastie.org/private/xk8thrwcbzeb2h1s7lm3tw
>
> Those are the same errors that are failing under p114, which is nice.
Good news :)
> One comment about r17290 is that it previously worked, since before
> 1.8.7 was released I've been able to use ruby_1_8 branch, which
> included the same backport.
Hmm...
I consider four senarios.
1) drb changes cause this problem.
2) ext/socket changes cause this problem.
3) win32/win32.c changes cause this problem.
4) another changes cause this problem.
First, drb was not changed between p114 and p230. So, drb is
not guilty.
Second, ext/socket was changed, but it doesn't seems to affect.
Third, win32/win32.c contains the changes about select. These
are very suspicious.
Fourth, ... I have no idea :(
So, I suggested to revert r17290.
On ruby_1_8 branch, ext/socket changes are older than win32's
select changes.
So, probably ext/socket changes doesn't cause it, too.
BTW, r17290 is tagged as p207.
So, if p207 has same problem, ruby_1_8_6 needs something to
backport from ruby_1_8.
If p207 doesn't has the problem, something between p208 and
p230 causes it.
Luis, could you test p207, please?
Regards,
--
U.Nakamura <u...@garbagecollect.jp>
gde...@attglobal.net
I am pleased to say that I finally got the payment
made earlier today. Sorry for the delay.
graeme
---- Original Message ----
U.Nakamura
In message "[ruby-core:17533] Re: We'll release 1.8.6/1.8.7 this Friday"
on Jul.03,2008 17:01:17, <u...@garbagecollect.jp> wrote:
> > Reverting the specified revision fix the issue:
> >
> > 1588 tests, 15068 assertions, 3 failures, 0 errors
> > http://pastie.org/private/xk8thrwcbzeb2h1s7lm3tw
> >
> > Those are the same errors that are failing under p114, which is nice.
>
> Good news :)
>
>
> > One comment about r17290 is that it previously worked, since before
> > 1.8.7 was released I've been able to use ruby_1_8 branch, which
> > included the same backport.
Now I've decided to revert r17290 from ruby_1_8_6 in consultation
with Urabe-san.
r17290 solves the "gets blocks another threads" problem, but I
consider that the problem is the limitation in specification of
ruby_1_8_6, not a bug.
Regards,
--
U.Nakamura <u...@garbagecollect.jp>
Luis Lavena
Done, the test stall.
We can attribute this to the gets() and thread as you suggested in your email.
In any case, the mix gets() and Thread on Windows is something that
needs more attention taking in consideration all those changes.
(Part Heesob from win32utils worked on a new version for it, but still
imperfect).
Thank you again Mr. Nakamura for your time and your work looking into
this issue.
Regards,
U.Nakamura
In message "[ruby-core:17536] Re: We'll release 1.8.6/1.8.7 this Friday"
on Jul.03,2008 17:25:48, <luisl...@gmail.com> wrote:
> > BTW, r17290 is tagged as p207.
> > So, if p207 has same problem, ruby_1_8_6 needs something to
> > backport from ruby_1_8.
> > If p207 doesn't has the problem, something between p208 and
> > p230 causes it.
> > Luis, could you test p207, please?
>
> Done, the test stall.
Thank you!
OK, r17290 needs something more, maybe it's ruby core changes.
If we find it and it is merged into ruby_1_8_6, r17290 will
be mereged again.
But, next release of ruby_1_8_6 will be shipped without r17290
because there is no time to find and test it.
> We can attribute this to the gets() and thread as you suggested in your email.
>
> In any case, the mix gets() and Thread on Windows is something that
> needs more attention taking in consideration all those changes.
I agree.
> Thank you again Mr. Nakamura for your time and your work looking into
> this issue.
It is I who should express gratitude.
Thank you, Luis.
Regards,
--
U.Nakamura <u...@garbagecollect.jp>
Michal Suchanek
While it is nice to have a release on the planned date I find the
quality of the release much more important.
The security release of 1.8.6p230 which contained a lot of untested
changes caused a lot of headache.
Thus delaying the release when problems are found is much better then
releasing known broken code. People who want to start testing at the
scheduled date can always check out from svn.
It may or may not be feasible to set up automated testing of the code
as each commit is done but testing at least the release is important
in my view.
Thanks
Michal
Urabe Shyouhei
Tanaka Akira
Urabe Shyouhei <shyo...@ruby-lang.org> writes:
> Thank you, I merged this revision into 1.8.7.
It causes following problem.
% ./ruby -rsingleton -ve '
class C
include Singleton
end
m = Marshal.dump(C.instance)
p Marshal.load(m)
'
ruby 1.8.6 (2008-07-02 patchlevel 264) [i686-linux]
-e:6:in `load': class C needs to have method `_load' (TypeError)
from -e:6
r16659 is also required.
Note that r16659 causes RubySpec failure, it is another
RubySpec bug.
--
Tanaka Akira
schreibe...@googlemail.com
That problem seems to only exist in 1.8.6, r16659 seems to have been
merged into 1.8.7 already.
Thank you, Arthur
On 3 Jul., 13:56, Tanaka Akira <a...@fsij.org> wrote:
> In article <486CB4DC.4030...@ruby-lang.org>,
Tanaka Akira
"schreibe...@googlemail.com" <schreibe...@googlemail.com> writes:
> That problem seems to only exist in 1.8.6, r16659 seems to have been
> merged into 1.8.7 already.
You are right. r16659 is for 1.8.6.
--
Tanaka Akira
Charles Oliver Nutter
Others have already responded, but I think it's of paramount importance
that any release pass the tests it's expected to pass. So then the
question becomes whether ruby-core has decided that 1.8.x releases are
expected to pass rubyspec. I think the community would like very much
for that to be the case.
- Charlie
Igal Koshevoy
> Charles Oliver Nutter wrote:
>
>> There should not be a release until the failures in rubyspec are
>> addressed.
>>
>
> OK, so all of you can wait until rubyspec passes? I think I cannot
> review every failures in a 24 hours so releases should be delayed. Is it
> really OK?
>
remaining critical issues by Friday.
There's a definite, consistently reproducable memory leak[1] in both
p230 and p238, and likely in HEAD. This memory leak is a show-stopper
and will make it impossible for anyone running Rails or other
long-running processes to use these versions. There are also a number of
other problems that the RubySpec has identified, some of which seem severe.
What is the SVN URL for the current release candidate that we should be
testing? I was checking r17631 of the ruby_1_8_6 branch, which calls
itself p238.
I realize you and the other maintainers have been under a lot of strain
recently, but I sincerely appreciate you working through this with us.
Thank you.
-igal
Charles Oliver Nutter
> Please delay the release. I don't think we'll be able to resolve the
> remaining critical issues by Friday.
For what it's worth, this is all a strong argument for having a CI
server and keeping rubyspec "green" all the time. Nobody likes having to
delay a release because there's a stack of errors to be dealt with.
- Charlie
Igal Koshevoy
Is anyone providing CI for Ruby releases? Is there a good CI tool
written in Ruby? Would Hudson be acceptable for doing Ruby stuff? Is
JRuby or one of the other alternative implementations using something
for CI that they're happy with?
I've been building up a shell script, mostly for personal use, so I can
run the checks against various test suites. I attached an earlier
version with my bug report #199 asking for patch reviews. I can mop that
script up a bit and release versions so that others can run the full
suite of tests on-demand from their command line and or from a CI
server. I've been building this as a shell script because it minimizes
dependencies so that as long as the user has bash, svn, git, wget, tar
and maybe a tiny number of other utilities, they can run it. Does this
sound useful?
I also talked earlier about setting up a bunch of VMs running different
OSes and running the test scripts against these, which would be a good
way to catch platform-specific issues. Is there interest in such a thing?
However, if someone's already done this effort, it'd be good to know so
we can take a look at it and possibly build upon it instead.
-igal
Phlip
> Is anyone providing CI for Ruby releases? Is there a good CI tool
> written in Ruby?
CruiseControl.rb doesn't suck.
(Parenthetically, here's a tweak to draw charts of statistics over time with it:
http://www.oreillynet.com/ruby/blog/2008/03/cruisecontrol_charts.html )
--
Phlip
Wilson Bilkovich
Ryan Davis is working on a system for this right now. Last I heard, it
is nearing completion.
Igal Koshevoy
> Igal Koshevoy wrote:
>
>> Is anyone providing CI for Ruby releases? Is there a good CI tool
>> written in Ruby?
>
> CruiseControl.rb doesn't suck.
[http://cruisecontrolrb.thoughtworks.com/documentation/manual] describes
the product in a fairly sensible manner. Seems like it can run anything
that you can point a Rake task at, so it's quite flexible. Their demo
[http://cruisecontrolrb.thoughtworks.com/projects] gives a pretty good
idea of what the tool does too.
> (Parenthetically, here's a tweak to draw charts of statistics over
> time with it:
> http://www.oreillynet.com/ruby/blog/2008/03/cruisecontrol_charts.html )
Thanks for writing that up. :)
-igal
M. Edward (Ed) Borasky
Glad to hear it. I've got some spare cycles (day job starts again 8
July.) :) I was about to start up on this, but if someone is doing it,
I'll wait. My own thinking was to do
1. Check out Ruby 1.8.6 from SVN.
2. Compile with GCC 4.3.1 with the "gcov" coverage analysis and debug
options. I only have an AMD64 dual-core and 4 GB of RAM running Gentoo
Linux, not a buncha VMs with every conceivable environment. For other
environmental reasons, I compile *with* threads.
3. Run all the test suites and benchmark suites (someday, we really
should merge those.) :)
4. Post the code coverage analysis, test suite results, and tracebacks
for any crashes "somewhere". I've got "oprofile" working, so I can also
post profiles if anyone cares.
I'm definitely going to do the benchmarks; this started out as a
profiling exercise on Rubinius. :) A Rakefile would be nice, but I am a
terrible Rakefile writer -- for some reason, I can't do "DRY" Rakefiles.
I usually end up just defining a whole bunch of Ruby methods to make a
sensibly factored set of code, which seems somehow "un-Rake-like." :)
M. Edward (Ed) Borasky
*And*, some of us who don't have open source day jobs have a long
weekend. :)
Michal Suchanek
Setting up VMs for Windows or some BSDs should be easy. However, OS X
cannot be virtualized so only people with apple hardware running that
thing can test. There is the possibility to test on Darwin but it
would be probably hard to set up environment identical to current OS
X. There seem to be many people with OS X desktops but i am not sure
there are many OS X servers free to run some untested code. Perhaps
some best effort parallel execution like Seti@home could make things
easier for exotic platforms.
> 3. Run all the test suites and benchmark suites (someday, we really should
> merge those.) :)
> 4. Post the code coverage analysis, test suite results, and tracebacks for
> any crashes "somewhere". I've got "oprofile" working, so I can also post
> profiles if anyone cares.
This could also work for *BSDs that use the GNU toolchain and ELF
objects (but then there is only a small chance of platform specific
bugs here). However, the tools on different platforms might vary
wildly.
Thanks
Michal
M. Edward (Ed) Borasky
I'm guessing at least 95 percent of Ruby issues could be found using
just the latest GCC and its tools on a 64-bit GNU/Linux platform. :) If
the source is clean with respect to that platform before handing it to
the others, they will be "enabled" to focus their efforts on their
platform-specific issues.
--
M. Edward (Ed) Borasky
http://ruby-perspectives.blogspot.com/
"A mathematician is a machine for turning coffee into theorems." -- Paul
Erdos
Charles Oliver Nutter
I've heard of those before.
- Charlie
Phlip
>> *And*, some of us who don't have open source day jobs have a long
>> weekend. :)
>
> I've heard of those before.
Sez you! At my current day-job, we use Rails via assert{ 2.0 } and assert_xpath.
We are up to 6 coders, and we will hire 2 more as soon as we remodel.
Is that enough of an "open source day job"?
--
Phlip
Charles Oliver Nutter
I meant I've heard of weekends :) I don't really take many "off" days
anymore, and I have an "open source day job".
- Charlie
Igal Koshevoy
> Setting up VMs for Windows or some BSDs should be easy. However, OS X
> cannot be virtualized so only people with apple hardware running
> that thing can test.
legality is fuzzy:
http://wiki.osx86project.org/wiki/index.php/Vmware_how_to
> There is the possibility to test on Darwin but it would be probably
> hard to set up environment identical to current OS X.
Agreed, it'd be best to use a full copy of OS X to properly simulate
this. Most Rails developers use OS X, so it's important to support that
platform.
> There seem to be many people with OS X desktops but i am not sure
> there are many OS X servers free to run some untested code.
True. We can either ask for donations of a machine or run this off a
service similar to http://www.macminicolo.net/
> Perhaps some best effort parallel execution like Seti@home could make
> things easier for exotic platforms.
Perl uses a fully distributed system for testing CPAN modules
(conceptually similar to Gems). Folks can download an agent and it'll
run tests on various modules. This allows those running exotic platforms
like A/UX, z390s and HP/UX to contribute their results. We may be able
to reuse their system.
-igal
Phlip
>
> I meant I've heard of weekends :) I don't really take many "off" days
> anymore, and I have an "open source day job".
Did I mention we also do pure XP, and have a strictly 7-4 work day with no
overtime, ever?
Back in the day, I heard someone once grumble "I can tell it's the weekend
because the breaks are longer"...
Charles Oliver Nutter
> Michal Suchanek wrote:
>> Setting up VMs for Windows or some BSDs should be easy. However, OS X
>> cannot be virtualized so only people with apple hardware running
>> that thing can test.
> Running OS X in a VM works well, although it's a rather slow and the
> legality is fuzzy:
> http://wiki.osx86project.org/wiki/index.php/Vmware_how_to
>
>> There is the possibility to test on Darwin but it would be probably
>> hard to set up environment identical to current OS X.
> Agreed, it'd be best to use a full copy of OS X to properly simulate
> this. Most Rails developers use OS X, so it's important to support that
> platform.
>
>> There seem to be many people with OS X desktops but i am not sure
>> there are many OS X servers free to run some untested code.
> True. We can either ask for donations of a machine or run this off a
> service similar to http://www.macminicolo.net/
Honestly I'd almost like to see Apple step up to the plate here. They're
shipping Ruby and sponsoring work on MacRuby/RubyCocoa now. If anyone
could arrange to have an OS X machine hosted and available for
regression testing it would be them.
Laurent? Any chance of help here?
- Charlie
Laurent Sansonetti
Sorry for the late reply, I was discussing with my management.
Apple cannot provide access to a hosted machine, but we can provide a
decent Mac with a copy of the latest version of Mac OS X on an
infinite loan basis, so that the Ruby community can host it somewhere
and do regression testing on it (as well as any other things). The
machine would also be administered by the Ruby community.
I'm not really sure if it's what you're looking for, but if it helps,
drop me a note in private and we will discuss further!
Regards,
Laurent
Michal Suchanek
> Vladimir Sizikov wrote:
>
> > Hi Urabe,
> >
> > * 1.8.6 HEAD has 7 rubyspec falures for StringIO
> > * 1.8.7 HEAD has *57* rubyspec failures for StringIO
> >
> > Take a look here (for 1.8.7 faliures)
> > http://pastie.org/226299
> >
> > Would it be possible to fix at least 1.8.7 branch?
> >
> > Please note that 1.8 HEAD passes all 100% StringIO rubyspecs.
> >
>
> There should not be a release until the failures in rubyspec are addressed.
>
Could somebody, please, summarize the current status?
There has been a lot of email about test failures and non-failures
last week but I did not notice much activity this week (not being
subscribed to any SVN commits list).
Thanks
Michal
Tanaka Akira
"Michal Suchanek" <hram...@centrum.cz> writes:
>> There should not be a release until the failures in rubyspec are addressed.
>>
>
> Could somebody, please, summarize the current status?
RubySpec hangs.
--
Tanaka Akira
Federico Builes
What version of mspec are you using? 1.4.0 was recently released and
it's needed for some of the specs.
If you're running the latest mspec version, would you mind telling us
where it's freezing? A local run in Mac OS 10.5.4 fails on most of the
Readline specs (already reported in Redmine with a patch pending
review/push) in 1.8.6 and some minor issues in SortedSet (reported too
I think).
The following might seem a bit hackish but try to pass the -V option
to mspec, it's too verbose but it usually succeeds where a normal run
fails.
--
Federico
Tanaka Akira
Federico Builes <federic...@gmail.com> writes:
> What version of mspec are you using? 1.4.0 was recently released and
> it's needed for some of the specs.
git pulled 2008-07-19T11:37:04+09:00.
> If you're running the latest mspec version, would you mind telling us
> where it's freezing? A local run in Mac OS 10.5.4 fails on most of the
> Readline specs (already reported in Redmine with a patch pending
> review/push) in 1.8.6 and some minor issues in SortedSet (reported too
> I think).
>
> The following might seem a bit hackish but try to pass the -V option
> to mspec, it's too verbose but it usually succeeds where a normal run
> fails.
I use -V -f s.
http://www.rubyist.net/~akr/chkbuild/debian/ruby-1.8/log/20080719T113403.txt.gz
The hang is started since 20080716T184420.
http://www.rubyist.net/~akr/chkbuild/debian/ruby-1.8/summary.html
http://www.rubyist.net/~akr/chkbuild/debian/ruby-1.8/log/20080716T184420.txt.gz
For 1.8.6,
http://www.rubyist.net/~akr/chkbuild/debian/ruby-1.8.6/summary.html
The hang is started since 20080716T042428.
--
Tanaka Akira
Jeremy Henty
> What version of mspec are you using? 1.4.0 was recently released and
> it's needed for some of the specs. If you're running the latest
> mspec version, would you mind telling us where it's freezing?
I'm not the original poster but I'm seeing hangs too. If I run
"mspec --verbose rubyspec/1.8/library" the process hangs after printing:
rubyspec/1.8/library/socket/basicsocket/setsockopt_spec.rb .
If I interrupt the process it prints
rubyspec/1.8/library/socket/basicsocket/shutdown_spec.rb
Process aborted!
Now here's the strange thing: "mspec --verbose rubyspec/1.8/library/socket"
completes without problems! It is context dependent: something about
the complete library test set makes mspec hang inside
socket/basicsocket/shutdown_spec.rb .
I've no idea how to debug this further. Any tips?
Jeremy Henty
PS:
$ mspec --version
mspec 1.4.0
$ ruby -v
ruby 1.8.7 (2008-07-17 patchlevel 63) [i686-linux]
$ uname -a
Linux omphalos 2.6.26-0 #1 SMP PREEMPT Wed Jul 16 13:37:53 BST 2008 i686 athlon-4 i386 GNU/Linux
$ cd rubyspec
$ git pull --rebase
Current branch master is up to date.
Federico Builes
On Jul 19, 2008, at 6:30 AM, Jeremy Henty wrote:
> rubyspec/1.8/library/socket/basicsocket/shutdown_spec.rb
> Process aborted
Tanaka, Jeremy: Thanks for the reports. This particular spec has been
troublesome in Linux in the past so we're taking it down while we try
to find out what's wrong. I've verified it on Linux and this is the
output after removing it:
http://pastie.org/paste/237083
If you continue to see hangs or any other problems please let us know.
--
Federico
Jeremy Henty
>
> On Jul 19, 2008, at 6:30 AM, Jeremy Henty wrote:
> >rubyspec/1.8/library/socket/basicsocket/shutdown_spec.rb
> >Process aborted
>
> Tanaka, Jeremy: Thanks for the reports. This particular spec has
> been troublesome in Linux in the past so we're taking it down while
> we try to find out what's wrong.
Yes, pulling the latest ruby-spec removes the hang.
Regards,
Jeremy Henty
Jeremy Henty
> http://pastie.org/paste/237083
That's exactly what I get now, except that I don't see the two
BigDecimal.mode failures (maybe because I'm not 64-bit?).
Regards,
Jeremy Henty
Federico Builes
On Jul 19, 2008, at 11:49 AM, Jeremy Henty wrote:
> That's exactly what I get now, except that I don't see the two
> BigDecimal.mode failures (maybe because I'm not 64-bit?).
Yup, the value was not big enough for a 64 bit machine but it's been
fixed now.
--
Federico
Kurt Stephens
Kurt Stephens
Nobuyoshi Nakada
At Thu, 24 Jul 2008 19:51:49 +0900,
Kurt Stephens wrote in [ruby-core:17939]:
> When will we see a new 1.8.6 release?
Vladimir and Charles stopped Shyouhei from releasing it due to
failures of StringIO, but it seems to run well now.
And the errors seemed since Mock#respond_to? didn't implement
the optional argument.
--
Nobu Nakada
Vladimir Sizikov
The 1.8.6 and 1.8.7 branches have been OK w.r.t. RubySpecs for a while
now, and I don't have any objections for releases. Thanks for being
responsive and listening to our concerns!
Thanks,
--Vladimir
Urabe Shyouhei
> When will we see a new 1.8.6 release?
>
Unlike Matz, I'm not a dictator. I do have powers to, for
instance, put official tarballs on official places. And I was
not democratically directly chosen. But that was because we have
no democratic process to chose a person at my current position.
My powers are based on your consensus. Whether we should have a
release now is up to you.
--
Urabe, Shyouhei <shyo...@ruby-lang.org>
"Post id tempus auctoritate omnibus praestiti, potestatis autem
nihilo amplius habui quam ceteri qui mihi quoque in magistratu
conlegae fuerunt." -- Gaius Julius Caesar Octavianus
Jeremy Henty
> The 1.8.6 and 1.8.7 branches have been OK w.r.t. RubySpecs for a
> while now,
I'm not sure what you mean by "OK", but I'm still getting errors with
the latest ruby_1_8_7 branch and the latest RubySpec. (Log attached.)
Regards,
Jeremy Henty
Jeremy Henty
> On Fri, Jul 25, 2008 at 02:04:15AM +0900, Vladimir Sizikov wrote:
>
> > The 1.8.6 and 1.8.7 branches have been OK w.r.t. RubySpecs for a
> > while now,
>
> I'm not sure what you mean by "OK", but I'm still getting errors
> with the latest ruby_1_8_7 branch and the latest RubySpec.
To compare, with the latest ruby_1_8_6 branch I get the same Iconv
errors that I reported above, but the SortedSet errors are gone. The
relevant SortedSet tests are all guarded with 'ruby_bug
"http://redmine.ruby-lang.org/projects/ruby-18/issues/show?id=117",
"1.8.7.47" do ...', but if you check that URL it appears that no
action has been taken. In other words, RubySpec seems to think that
this is some bug that was fixed in 1.8.7.47 when in fact nothing has
changed. Three of the four SortedSet errors are due to RubySpec
calling SortedSet#<=> , which does not exist in either ruby_1_8_6 or
ruby_1_8_7 .
I don't know what is causing the Iconv errors. My Linux box is fairly
aged, so it may be due to OS bugs (I've already had to disable some of
the other tests for that reason). However, I've seen the same errors
reported on this list, so it's not just me.
Regards,
Jeremy Henty
Federico Builes
On Jul 24, 2008, at 5:15 PM, Jeremy Henty wrote:
> Three of the four SortedSet errors are due to RubySpec
> calling SortedSet#<=> , which does not exist in either ruby_1_8_6 or
> ruby_1_8_7 .
From what I can see we're not the ones calling #<=>, it's being
called in #to_a to sort the set:
(@keys = @hash.keys).sort! unless @keys
We're guarding it since as you said, no actions have been taken and we
think that it's a plausible use case. I like the suggestion Arthur
made on the ticket to undefine those methods for SortedSet if they're
not going to be supported.
> I don't know what is causing the Iconv errors. My Linux box is fairly
> aged, so it may be due to OS bugs (I've already had to disable some of
> the other tests for that reason). However, I've seen the same errors
> reported on this list, so it's not just me.
It is a platform specific behavior but I'm not sure if it's an "OS
bug" or if it's reproducible on all Linux systems besides Debian/
Ubuntu. Maybe we can get someone to take a look and let us know what
to do about it?
Having said that, I think these are minor issues that shouldn't stop
the release of a new version, a lot of stuff has been fixed since the
last official release.
--
Federico
Nobuyoshi Nakada
At Fri, 25 Jul 2008 08:17:27 +0900,
Federico Builes wrote in [ruby-core:17947]:
> > I don't know what is causing the Iconv errors. My Linux box is fairly
> > aged, so it may be due to OS bugs (I've already had to disable some of
> > the other tests for that reason). However, I've seen the same errors
> > reported on this list, so it's not just me.
>
> It is a platform specific behavior but I'm not sure if it's an "OS
> bug" or if it's reproducible on all Linux systems besides Debian/
> Ubuntu. Maybe we can get someone to take a look and let us know what
> to do about it?
SUS defines nothing about the conversion detail, nor encoding
names. Some implementation assign different encoding names for
UTF's with/without BOM, but it's definitely implementation
specific. I think the spec depends too much on particular
platforms.
--
Nobu Nakada
Daniel Luz
SUS defines nothing about the conversion detail, nor encoding
names. Some implementation assign different encoding names for
UTF's with/without BOM, but it's definitely implementation
specific. I think the spec depends too much on particular
platforms.
So, when writing those specs, I tried to find a minimum of encodings which would be available on any implementation from the last couple years (the most common Unicode-related ones), and then tried to use the least common denominator I could find among some platforms (basically, whatever libraries were being used by the common Ruby distributions on Windows, OS X and Ubuntu). This, of course, could still fail on some implementations, so feel free to remove those problematic tests.
Federico Builes
On Jul 24, 2008, at 9:53 PM, Daniel Luz wrote:
> So, when writing those specs, I tried to find a minimum of encodings
> which would be available on any implementation from the last couple
> years (the most common Unicode-related ones), and then tried to use
> the least common denominator I could find among some platforms
> (basically, whatever libraries were being used by the common Ruby
> distributions on Windows, OS X and Ubuntu). This, of course, could
> still fail on some implementations, so feel free to remove those
> problematic tests.
Thanks Jeremy, Nobuyoshi and Daniel. Following Daniel's advice I've
removed the two tests at least until there's some standarization on
these issues.
If you see any other problem please let us know.
--
Federico
Shugo Maeda
2008/7/25 Federico Builes <federic...@gmail.com>:
> If you see any other problem please let us know.
Currently ruby_1_8_6 has 2 rubyspec failures.
1)
Object#to_yaml returns the YAML representation of a Struct object FAILED
Expected "--- !ruby/struct:Person \nname: Jane\ngender: female\n"
to equal "--- !ruby/struct:Person\nname: Jane\ngender: female\n"
./rubyspec/1.8/library/yaml/to_yaml_spec.rb:58
./rubyspec/1.8/library/yaml/to_yaml_spec.rb:5
2)
Object#to_yaml returns the YAML representation of a Error object FAILED
Expected "--- !ruby/exception:StandardError \nmessage: foobar\n"
to equal "--- !ruby/exception:StandardError\nmessage: foobar\n"
./rubyspec/1.8/library/yaml/to_yaml_spec.rb:76
./rubyspec/1.8/library/yaml/to_yaml_spec.rb:5
Finished in 201.927533 seconds
2425 files, 8670 examples, 30036 expectations, 2 failures, 0 errors
I'm not familiar with git, but it's caused by your commit, isn't it?
commit 671f76a8fe54a34eca8c4eb8c6d242f646ff7c88
Author: Federico Builes <federic...@gmail.com>
Date: Thu Jul 24 18:51:16 2008 -0500
Cleaning white-space dependant specs in YAML.
Should we fix our implementation? Or could you fix your tests?
--
Shugo Maeda
Jeremy Henty
> Having said that, I think these are minor issues that shouldn't stop
> the release of a new version, a lot of stuff has been fixed since
> the last official release.
That's fine; I'm not claiming these are critical errors, just trying
to figure out what's going on and see what the offical position is.
Regards,
Jeremy Henty
Jeremy Henty
> Hi,
>
> 2008/7/25 Federico Builes <federic...@gmail.com>:
> > If you see any other problem please let us know.
>
> Currently ruby_1_8_6 has 2 rubyspec failures.
... and ruby_1_8_7 has exactly the same failures.
Regards,
Jeremy Henty
Vladimir Sizikov
Yes, there was a change in RubySpecs yesterday, that triggers these
two failures, we'll deal with them in RubySpecs. The problem is that
different implementations have different policy/behavior w.r.t. to
(insignificant) spaces in yaml. Some produce them, and some others
don't. Nothing really serious/critical.
Also, since RubySpec is always evolving, with the commits daily, there
is always a chance that all tests passed 5 minutes ago and now there
are some failures due to new commits.
In JRuby (and Rubinius) we deal with this fluid situation by
introducing the notion of "stable" or "frozen" specs, fixing particual
revision to avoid newly-introduced changes and to reduce instability.
From time to time, the "stable/frozen" pointer gets updated to newer
revision (and the excludes are updated, and bugs are filed if needed)
so that there are no failures.
Thanks,
--Vladimir
Jeremy Henty
> Also, since RubySpec is always evolving, with the commits daily, there
> is always a chance that all tests passed 5 minutes ago and now there
> are some failures due to new commits.
>
> In JRuby (and Rubinius) we deal with this fluid situation by
> introducing the notion of "stable" or "frozen" specs, fixing particual
> revision to avoid newly-introduced changes and to reduce instability.
>
> >From time to time, the "stable/frozen" pointer gets updated to newer
> revision (and the excludes are updated, and bugs are filed if needed)
> so that there are no failures.
Are there remote branches that we could track to follow the stable
specs? That way we could easily tell if a failure was due to a recent
spec change. Or is there a better way to do it?
Regards,
Jeremy Henty
Federico Builes
On Jul 25, 2008, at 3:08 AM, Shugo Maeda wrote:
> Currently ruby_1_8_6 has 2 rubyspec failures.
Yes Shugo, that was caused by my commit but as Vladimir said it's a
problem in the specs and not in the implementation. Since different
implementation's use different trailing whitespace for YAML we've
introduced a new matcher to deal with this.
It's been fixed in b2daeba64818997d3055049fcf5780426a522459.
--
Federico
Shugo Maeda
2008/7/25 Federico Builes <federic...@gmail.com>:
> Yes Shugo, that was caused by my commit but as Vladimir said it's a problem
> in the specs and not in the implementation. Since different implementation's
> use different trailing whitespace for YAML we've introduced a new matcher to
> deal with this.
> It's been fixed in b2daeba64818997d3055049fcf5780426a522459.
Thank you.
I confirmed it, and it looks fine:)
$ ruby mspec/bin/mspec --target ruby-1_8_6 rubyspec/1.8
(snip)
2426 files, 8673 examples, 30042 expectations, 0 failures, 0 errors
--
Shugo Maeda