Bug 706914 - invalid date format in specification
Summary: invalid date format in specification
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rubygem-rspec-core
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 706934
TreeView+ depends on / blocked
 
Reported: 2011-05-23 13:13 UTC by Vít Ondruch
Modified: 2011-06-02 19:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-23 15:59:16 UTC
Type: ---


Attachments (Terms of Use)

Description Vít Ondruch 2011-05-23 13:13:14 UTC
> gem --version
Invalid gemspec in [/usr/lib/ruby/gems/1.8/specifications/rspec-core-2.6.2.gemspec]: invalid date format in specification: "2011-05-21 00:00:00.000000000Z"
1.7.2

> rspec spec
Invalid gemspec in [/usr/lib/ruby/gems/1.8/specifications/rspec-core-2.6.2.gemspec]: invalid date format in specification: "2011-05-21 00:00:00.000000000Z"
/usr/lib/ruby/site_ruby/1.8/rubygems.rb:926:in `report_activate_error': Could not find RubyGem rspec-core (>= 0) (Gem::LoadError)
	from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:244:in `activate_dep'
	from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:236:in `activate'
	from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:1307:in `gem'
	from /usr/bin/rspec:18

I am not sure if the fix should be applied on rubygem-rspec-core, but I found upstream report against RubyGems:

http://help.rubygems.org/discussions/problems/575-invalid-gemspec-with-invalid-date-format-in-specification

Comment 1 Mamoru TASAKA 2011-05-23 14:59:46 UTC
Both build of rubygem-rspec-core 2.6.0 and 2.6.2 on Fedora koji 
used rubygems 1.7.2, and only 2.6.2 build result is broken.

rspec-core 2.6.2 already has broken date format in metadata.gz.
Once switching back to rubygem-rspec-core (because I think we won't backport
rubygem size "workaround" to F-14 rubygems 1.3.7, while updates-candidate
rubygem-rspec-core 2.6.2 on F-14 is also broken).

Comment 2 Mamoru TASAKA 2011-05-23 15:01:57 UTC
BTW I have not checked rubygems 1.8.x yet

Comment 3 Mamoru TASAKA 2011-05-23 15:59:16 UTC
Fixed in both rubygem-rspec-core and rubygems side

Comment 4 Fedora Update System 2011-05-24 00:48:21 UTC
rubygems-1.7.2-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/rubygems-1.7.2-2.fc15

Comment 5 Vít Ondruch 2011-05-24 08:00:09 UTC
(In reply to comment #1)
> Both build of rubygem-rspec-core 2.6.0 and 2.6.2 on Fedora koji 
> used rubygems 1.7.2, and only 2.6.2 build result is broken.
> 
> rspec-core 2.6.2 already has broken date format in metadata.gz.
> Once switching back to rubygem-rspec-core (because I think we won't backport
> rubygem size "workaround" to F-14 rubygems 1.3.7, while updates-candidate
> rubygem-rspec-core 2.6.2 on F-14 is also broken).

It seems that the upstream gem was prepared using R 1.9.2 while the previous versions were not (or at least they were not prepared using Psych). I am afraid that we will see more problems of this kind in the future.



(In reply to comment #2)
> BTW I have not checked rubygems 1.8.x yet

I am perfectly fine with rubygems 1.8 for rawhide (just announce it on Ruby-SIG since this updates tends to break things), but IMO we should stay with 1.7.2 for F15 anyway.

Comment 6 Mamoru TASAKA 2011-05-30 03:49:35 UTC
Well, now I've checked rubygems 1.3.7 (on F-14), and rubygems 1.3.7 actually seem to read "broken" rspec-core 2.6.2 gemspec file.
---------------------------------------------------------
--- rubygems-1.3.7-2.fc14.src/rubygems-1.3.7/lib/rubygems/specification.rb      2010-04-22 13:43:03.000000000 +0900
+++ rubygems-1.7.2-2.fc16.src/rubygems-1.7.2/lib/rubygems/specification.rb      2011-04-06 05:55:10.000000000 +0900
---------------------------------------------------------
@@ -1272,117 +1167,210 @@
....<skip>.....
+  def date= date
     # We want to end up with a Time object with one-day resolution.
     # This is the cleanest, most-readable, faster-than-using-Date
     # way to do it.
-    case date
-    when String then
-      @date = if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then
-                Time.local($1.to_i, $2.to_i, $3.to_i)
+    @date = case date
+            when String then
+              if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then
+                Time.utc($1.to_i, $2.to_i, $3.to_i)
               else
-                require 'time'
-                Time.parse date
+                raise(Gem::InvalidSpecificationException,
+                      "invalid date format in specification: #{date.inspect}")
               end
-------------------------------------------------------------
So rubygem 1.3.7 uses Time.parse() and on F-14:
-------------------------------------------------------------
$ irb
irb(main):001:0> require "time"
=> true
irb(main):002:0> Time.parse("2011-05-21 00:00:00.000000000Z")
=> Sat May 21 00:00:00 UTC 2011
irb(main):003:0> 
-------------------------------------------------------------
parsing "wrong" time format does not fail 
(and it seems that parsing really "wrong" time string doesn't seem to fail either).
-------------------------------------------------------------
irb(main):003:0> Time.parse("foo")
=> Mon May 30 12:47:51 +0900 2011
-------------------------------------------------------------

So it seems that backporting fix on rubygems 1.7.2 to F-14 1.3.7 seems unnecessary

(note that I've already modified both rubygems and rubygem-rspec-core on F15 and rawhide, although I've not tried rubygems 1.8.4(currently) yet)

Comment 7 Mamoru TASAKA 2011-06-02 00:55:34 UTC
I will upgrade rubygems to 1.8.5 on rawhide once I get back to home today (source already imported into Fedora git repository, however build queue was cancelled because of koji server down: I will resubmit it)

Comment 8 Fedora Update System 2011-06-02 19:04:48 UTC
rubygems-1.7.2-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.