Bug 665560 - Review Request: rubygem-mail - A Really Ruby Mail Library
Summary: Review Request: rubygem-mail - A Really Ruby Mail Library
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Mo Morsi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 646836 667465
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-24 18:09 UTC by Minnikhanov
Modified: 2011-02-04 18:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-04 18:37:17 UTC
Type: ---
Embargoed:
mmorsi: fedora-review+
notting: fedora-cvs+


Attachments (Terms of Use)

Description Minnikhanov 2010-12-24 18:09:17 UTC
Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.13-1.fc14.src.rpm
Description:
Hi. I just finished packaging up rubygem-mail, and I would appreciate a review so that I can get it into Fedora Extras. 

https://rubygems.org/gems/mail - A Really Ruby Mail Library.

Packed for "rails 3.0.x in F15" in "Ruby SIG mailing list"
http://lists.fedoraproject.org/pipermail/ruby-sig/2010-December/000376.html

Comment 1 Minnikhanov 2010-12-24 18:18:26 UTC
http://koji.fedoraproject.org/koji/taskinfo?taskID=2688270
koji scratch build successful.

1st Review Request (Bug #661436):
 rubygem-heroku - deploy apps to Heroku .

Comment 2 Mamoru TASAKA 2010-12-27 16:49:59 UTC
I guess currently you also cannot install the binary rpm rebuilt
from your srpm because of the dependency on rubygem-treetop 
(requested >= 1.4.8, the latest treetop on Fedora is 1.3.0).

Would you check if treetop version >= 1.4.8 is really needed?
If not, (for now) please modify spec file and installed
gemspec file so that rubygem-mail binary rpm can be installed.

Other points looks okay from the first glance.

Comment 3 Minnikhanov 2010-12-29 20:24:03 UTC
I create mail-2.2.13.1.gem from source, reduce dependence for treetop >= 1.3.0
Install rubygem-treetop-1.3.0.rpm by yum.
Test failed.

[dvl@lhost mail]$ spec spec/
Running Specs under Ruby Version 1.8.7
/usr/lib/ruby/gems/1.8/gems/treetop-1.3.0/lib/treetop/compiler/ruby_builder.rb:15:in `<<': undefined method `tabto' for "module RFC2822Obsolete":String (NoMethodError)
	from /usr/lib/ruby/gems/1.8/gems/treetop-1.3.0/lib/treetop/compiler/ruby_builder.rb:35:in `module_declaration'
	from /usr/lib/ruby/gems/1.8/gems/treetop-1.3.0/lib/treetop/compiler/node_classes/grammar.rb:7:in `compile'
	from /usr/lib/ruby/gems/1.8/gems/treetop-1.3.0/lib/treetop/compiler/metagrammar.rb:260:in `compile'
.....

History mail.gem:
# 2.2.1 May 12, 2010
# 2.2.0 April 10, 2010
# 2.1.5.3 March 28, 2010
# 2.1.5.2 March 27, 2010
# 2.1.5.1 March 27, 2010
# 2.1.5 March 27, 2010
# 2.1.3 February 21, 2010 

mail.gem had't on the dependencies rubygem-treetop till ver. 2.1.5.2 March 27, 2010.

History treetop.gem:
# 1.4.9 November 15, 2010
# 1.4.8 May 30, 2010
# 1.4.7 May 27, 2010
# 1.4.5 March 28, 2010
# 1.4.4 February 19, 2010
# 1.4.3 December 7, 2009
# 1.4.2 September 10, 2009
# 1.4.1 September 3, 2009
*****   # 1.3.0 July 21, 2009   *****  old chap :-)   my grand dad ran with it :-D
# 1.2.6 June 13, 2009 

Solution:
1. May be possible up packed version treetop.gem to 1.4.8 .
2. Pack mail-2.1.5.2.gem.

IMHO step 1 would be better.

Comment 4 Mamoru TASAKA 2011-01-05 16:54:40 UTC
Sorry for delay. For treetop dependency, I filed bug 667465

Comment 5 Minnikhanov 2011-01-13 17:51:13 UTC
Upstream release - 2.2.14 January 4, 2011 
Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-1.fc14.src.rpm

koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2719362

Comment 6 Mo Morsi 2011-01-19 03:37:41 UTC
I updated the treetop rpm to 1.4.9 and will push it to rawhide soon. Going off this srpm

http://mo.morsi.org/files/rpms/rubygem-treetop-1.4.9-1.fc14.src.rpm

* rpmlint, koji look good

* passes review guidelines (would be good to get a separate LICENSE file from upstream, but is not required)

* you can also download the spec suite from the upstream project and run it in a %check section if you want

Overall looks good, will approve once treetop 1.4.9 is in rawhide

Comment 7 Minnikhanov 2011-01-22 20:49:06 UTC
(In reply to comment #6)
Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-2.fc14.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-2.fc14.src.rpm

Don't make 'rubygem-mail.spec' for reason
koji scratch build: FAIL
http://koji.fedoraproject.org/koji/taskinfo?taskID=2737227 

(Now http://dl.dropbox.com/u/14118661/rubygem-mail.spec this is
 'rubygem-mail-2.2.14-1.fc14.spec' without %check section)

> * passes review guidelines (would be good to get a separate LICENSE file from
> upstream, but is not required)
> 
+ This fixed.
There isn't LICENSE file at upstream. There is the LICENSE section in README file.
I separate LICENSE file from the LICENSE section in README file in %prep section.

> * you can also download the spec suite from the upstream project and run it in
> a %check section if you want
> 
- not fixed yet.
Prepare spec suite from the upstream to tarball.  
For spec suite need rubygem-bundler  - it not packed yet (#646836).
I add %check section. No success yet - koji scratch build: FAIL.

build.log:
error: line 42: Unknown tag: BuildRequires(check): rubygem(rake)

Why 'Unknown tag:'? It is not clear for me. 

Solutions:
1. Comment %check section. Search solution later.
2. I need help. Direct me to right way, please.

Comment 8 Minnikhanov 2011-01-23 19:11:51 UTC
'BuildRequires:' correct wrong tag 'BuildRequires(check):'.
'BuildRequires(check):' wrong tag by http://fedoraproject.org/wiki/Packaging:Guidelines 

Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-3.fc14.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-3.fc14.src.rpm

Don't make 'rubygem-mail.spec' for reason
koji scratch build: FAIL
http://koji.fedoraproject.org/koji/taskinfo?taskID=2738013
>>>
DEBUG backend.py:745:  /usr/bin/yum-builddep --installroot /var/lib/mock/dist-f15-build-964293-145162/root/  '/var/lib/mock/dist-f15-build-964293-145162/root///builddir/build/SRPMS/rubygem-mail-2.2.14-3.fc15.src.rpm'
DEBUG util.py:281:  Executing command: /usr/bin/yum-builddep --installroot /var/lib/mock/dist-f15-build-964293-145162/root/  '/var/lib/mock/dist-f15-build-964293-145162/root///builddir/build/SRPMS/rubygem-mail-2.2.14-3.fc15.src.rpm'
DEBUG util.py:247:  Getting requirements for rubygem-mail-2.2.14-3.fc15.src
DEBUG util.py:247:   --> rubygems-1.3.7-2.fc14.noarch
DEBUG util.py:247:   --> ruby-libs-1.8.7.330-2.fc15.x86_64
DEBUG util.py:247:   --> rubygem-rake-0.8.7-2.fc12.noarch
DEBUG util.py:247:  Error: No Package found for rubygem(bundler)
DEBUG util.py:320:  Child returncode was: 1
<<<

Now the problem - For spec suite must be packed rubygem-bundler (it not packed yet #646836).

Comment 9 Mo Morsi 2011-01-23 20:35:50 UTC
(In reply to comment #7)
> (In reply to comment #6)
> Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-2.fc14.spec
> SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-2.fc14.src.rpm
> 
> Don't make 'rubygem-mail.spec' for reason
> koji scratch build: FAIL
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2737227 
> 
> (Now http://dl.dropbox.com/u/14118661/rubygem-mail.spec this is
>  'rubygem-mail-2.2.14-1.fc14.spec' without %check section)
> 

This is weird. I'm seeing this also, and not sure what the cause is. It seems to only occur when the build target is dist-rawhide, for example I just rebuilt the jnr-netdb package against dist-rawhide (which failed) and dist-f14 (which succeeded)

http://koji.fedoraproject.org/koji/taskinfo?taskID=2738420
http://koji.fedoraproject.org/koji/taskinfo?taskID=2738431

I'm not sure if moving the BuildRequies(check) to BuildRequires is the right solution (anyone care to comment on this? mamoru?), but can't find anything in the package guidelines pertaining to BuildRequires(check), so unless there are any contrary opinions/solutions, I'm fine with that fix.


> > * passes review guidelines (would be good to get a separate LICENSE file from
> > upstream, but is not required)
> > 
> + This fixed.
> There isn't LICENSE file at upstream. There is the LICENSE section in README
> file.
> I separate LICENSE file from the LICENSE section in README file in %prep
> section.
> 

This is not what I meant. I merely was suggesting you contact upstream to include the separate LICENSE file as directed here

http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text

Since this is a SHOULD it isn't a blocker for the package being accepted. 

The fix you added though doesn't seem to work though, at least not for me locally. When I run rpmbuild I get the following error


+ csplit ./usr/lib/ruby/gems/1.8/gems/mail-2.2.14/README.rdoc '/== License:/'
17683
1087
+ /bin/mv -f ./usr/lib/ruby/gems/1.8/gems/mail-2.2.14/xx00 ./usr/lib/ruby/gems/1.8/gems/mail-2.2.14/README.rdoc
/bin/mv: cannot stat `./usr/lib/ruby/gems/1.8/gems/mail-2.2.14/xx00': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.fiDfF8 (%prep)


This entire bit of extracting the LICENSE out of the readme can probably be removed all together.



> > * you can also download the spec suite from the upstream project and run it in
> > a %check section if you want
> > 
> - not fixed yet.
> Prepare spec suite from the upstream to tarball.  
> For spec suite need rubygem-bundler  - it not packed yet (#646836).
> I add %check section. No success yet - koji scratch build: FAIL.
> 

So thanks for doing this.. In addition to bundler the gemspec references several other gems which need to be installed for the spec suite to work. treetop is needed, and was just pushed to rawhide, as well as activesupport, mime-types, i18n, ZenTest, rcov, rspec, diff-lcs, ruby-debug (all of which are in Fedora).

Please add these all as BuildRequires dependencies. You will also need to pull https://github.com/mikel/mail/raw/master/Gemfile as a rpm source  and add it and Gemfile.lock to the %files section.

Additionally the ZenTest dep is too high in the Gemfile, but I've verified that the mail test suite works against the ZenTest version in fedora. You can downgrade it with the following patch


$ cat mail-downgrade-gemfile-deps.patch 
--- Gemfile.orig	2011-01-23 14:25:06.328793651 -0500
+++ Gemfile	2011-01-23 14:28:17.529793736 -0500
@@ -7,7 +7,7 @@ gem "treetop", "~> 1.4.8"
 gem "i18n", ">= 0.4.0"
 
 group :test do
-  gem "ZenTest",    "~> 4.4.0"
+  gem "ZenTest",    ">= 4.3.1"
   gem "rcov",       "~> 0.9.8"
   gem "rake",       "~> 0.8.7"
   gem "bundler"




> build.log:
> error: line 42: Unknown tag: BuildRequires(check): rubygem(rake)
> 
> Why 'Unknown tag:'? It is not clear for me. 
> 
> Solutions:
> 1. Comment %check section. Search solution later.
> 2. I need help. Direct me to right way, please.


Again I'm not sure whats causing this, and am fine w/ the BuildRequires(check) -> BuildRequires workaround unless there is a better solution. Once the other BuildRequires dependencies listed above are added to the spec and bundler and treetop are installed locally, 'rake spec' in the check section successfully runs. 

treetop was just pushed to Fedora rawhide. bundler was blocked on thor which has been updated in rawhide, so that should also be coming soon.

Comment 10 Mamoru TASAKA 2011-01-24 06:58:58 UTC
(In reply to comment #9)
> > build.log:
> > error: line 42: Unknown tag: BuildRequires(check): rubygem(rake)
> > 
> > Why 'Unknown tag:'? It is not clear for me. 
> > 
> > Solutions:
> > 1. Comment %check section. Search solution later.
> > 2. I need help. Direct me to right way, please.
> 
> 
> Again I'm not sure whats causing this, and am fine w/ the BuildRequires(check)
> -> BuildRequires workaround unless there is a better solution.

Well, with rawhide rpm (4.9.0) BuildRequires(foo) will always cause
error:
http://rpm.org/wiki/Releases/4.9.0
"Unknown dependency qualifiers are now always treated
 as errors and abort build"
http://lists.fedoraproject.org/pipermail/devel/2010-November/146378.html

So please just use BuildRequires: instead of BuildRequires(check). I will
also change this next time I build packages which uses BuildRequires(check).

Comment 11 Minnikhanov 2011-01-24 13:56:14 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > * passes review guidelines (would be good to get a separate LICENSE file from
> > > upstream, but is not required)
 
> This is not what I meant. I merely was suggesting you contact upstream to
> include the separate LICENSE file as directed here
> 
> http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text
> 
> Since this is a SHOULD it isn't a blocker for the package being accepted. 
> 

Publish issue at upstream
https://github.com/mikel/mail/issues#issue/190

Comment 12 Mo Morsi 2011-01-24 21:07:50 UTC
OK in this case please,

* remove the bits splitting the LICENSE out of the README and

* add the missing BuildRequires dependencies to the spec (you will need to pull the upstream Gemfile and downgrade the ZenTest dependency there)

After these two I will approve. Thanks.

Comment 13 Minnikhanov 2011-01-26 17:01:34 UTC
Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-4.fc14.src.rpm

koji scratch build: FAIL
http://koji.fedoraproject.org/koji/taskinfo?taskID=2742950 
'bundler' is not in rawhide - will wait.

(In reply to comment #12)
> OK in this case please,
> 
> * remove the bits splitting the LICENSE out of the README and

+ Fixed
 
> * add the missing BuildRequires dependencies to the spec (you will need to pull
> the upstream Gemfile and downgrade the ZenTest dependency there)

+ Fixed

Comment 14 Mo Morsi 2011-01-26 19:35:11 UTC
Everything looks good with the latest spec except for a couple of things

* Could you put the BuildRequires you just added onto separate lines. A style things yes, and not a blocker, but still I feel it makes it more legible

* Why did you add the sections in %prep to "fix anything executable that doesn't have a shebang" and "find files with a shebang that don't have executable permissions". Looking at the gem there are no executable files nor files that should be so I'm not sure what these blocks are trying to accomplish

* rpmlint complains about a missing %clean section, could you please add it, even if it is empty

* building the rpm results in an error stating the LICENSE.rdoc file cannot be found. Where are you getting this? If no such file exists could you please remove it from the %files section

* additionally building the rpm outputs that the Gemfile.lock file is not listed in %files. Furthermore the Gemfile is listed as a file in the doc subpackage, which is incorrect as its needed by the mail runtime. Please put both Gemfile and Gemfile.lock in the main package %files section (not marked as %doc either)

Thank you

Comment 15 Mamoru TASAKA 2011-01-26 19:43:49 UTC
(In reply to comment #14)
> * rpmlint complains about a missing %clean section, could you please add it,
> even if it is empty

%clean section is no longer needed (on Fedora):
https://fedoraproject.org/wiki/Packaging/Guidelines#.25clean

Comment 16 Minnikhanov 2011-01-27 17:18:56 UTC
Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-5.fc14.src.rpm

(In reply to comment #14)
> * Could you put the BuildRequires you just added onto separate lines. A style
> things yes, and not a blocker, but still I feel it makes it more legible

+ Fixed. (I saw like that anywhere, nothing else)

> * Why did you add the sections in %prep to "fix anything executable that
> doesn't have a shebang" and "find files with a shebang that don't have
> executable permissions". Looking at the gem there are no executable files nor
> files that should be so I'm not sure what these blocks are trying to accomplish
> 

+ Fixed. Remove these.

> * rpmlint complains about a missing %clean section, could you please add it,
> even if it is empty
> 

- Not need by Comment 15.

> * building the rpm results in an error stating the LICENSE.rdoc file cannot be
> found. Where are you getting this? If no such file exists could you please
> remove it from the %files section
> 

+ Fixed. (sorry)

> * additionally building the rpm outputs that the Gemfile.lock file is not
> listed in %files. Furthermore the Gemfile is listed as a file in the doc
> subpackage, which is incorrect as its needed by the mail runtime. Please put
> both Gemfile and Gemfile.lock in the main package %files section (not marked as
> %doc either)

+ Fixed. 
There is not 'Gemfile.lock' in upstream - create this file by 'touch' in %prep. Is this right?

Comment 17 Minnikhanov 2011-01-29 19:46:34 UTC
Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.15-1.fc14.src.rpm

Updated to latest upstream release (v.2.2.15 25/01/2011)

Spec(previous) URL:
 http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-5.fc14.spec

Comment 18 Mo Morsi 2011-01-31 17:53:04 UTC
> There is not 'Gemfile.lock' in upstream - create this file by 'touch' in %prep.
> Is this right?

No, this file gets created during the build. Please remove this.

(In reply to comment #17)
> Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail.spec
> SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.15-1.fc14.src.rpm
> 
> Updated to latest upstream release (v.2.2.15 25/01/2011)
> 
> Spec(previous) URL:
>  http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.14-5.fc14.spec


Once the touch 'Gemfile.lock' is removed, everything looks go. The package depends on bundler (BZ #646836), which has been approved but not pushed yet. The package builds fine in mock though with the bundler rpm preinstalled.


APPROVED.

Comment 19 Minnikhanov 2011-01-31 19:01:21 UTC
Spec URL: http://dl.dropbox.com/u/14118661/rubygem-mail.spec
SRPM URL: http://dl.dropbox.com/u/14118661/rubygem-mail-2.2.15-2.fc14.src.rpm

(In reply to comment #18)
> > There is not 'Gemfile.lock' in upstream - create this file by 'touch' in %prep.
> > Is this right?
> 
> No, this file gets created during the build. Please remove this.
> 

+ Fixed.

> 
> Once the touch 'Gemfile.lock' is removed, everything looks go. The package
> depends on bundler (BZ #646836), which has been approved but not pushed yet.
> The package builds fine in mock though with the bundler rpm preinstalled.
> 
> 
> APPROVED.

Thanks for review & collaboration.

Comment 20 Minnikhanov 2011-01-31 19:03:38 UTC
New Package SCM Request
=======================
Package Name: rubygem-mail
Short Description: A Really Ruby Mail Library.
Owners: minn
Branches: f14
InitialCC:

Comment 21 Vít Ondruch 2011-02-01 10:57:15 UTC
Bundler should be already in rawhide. I did not proposed it for F14 though. 

However, the Bundler is build dependency which could/should be avoided IMO. Here is way how to achieve it: https://fedoraproject.org/wiki/Packaging_talk:Ruby

Comment 22 Mamoru TASAKA 2011-02-01 12:44:48 UTC
(In reply to comment #21)
> However, the Bundler is build dependency which could/should be avoided IMO.
> Here is way how to achieve it:
> https://fedoraproject.org/wiki/Packaging_talk:Ruby

I just wrote the opposite opinion for this on wiki.

Comment 23 Minnikhanov 2011-02-01 15:05:51 UTC
(In reply to comment #21)
> Bundler should be already in rawhide. I did not proposed it for F14 though. 
> 
> However, the Bundler is build dependency which could/should be avoided IMO.
> Here is way how to achieve it:
> https://fedoraproject.org/wiki/Packaging_talk:Ruby

I mark "Branches: f14" as placeholder. I don't suppose to push & to build for F14.
When I made previous "New Package SCM Request" without "Branches:" for 'tzinfo.gem' I have a problem with 'fedpkg' https://bugzilla.redhat.com/show_bug.cgi?id=619979#c40 .
Solution: https://bugzilla.redhat.com/show_bug.cgi?id=619979#c41 

Now I decide make "Branches: f14" as placeholder; for reason - hav't any problem with 'fedpkg'.

If possible don't use branch F14 & remove it , I ready.

Comment 24 Vít Ondruch 2011-02-01 15:47:01 UTC
Great ... than you are probably aware of fedpkg update. I had no issues today pushing Bundler without f14 branch. May be you should give it a try.

Comment 25 Minnikhanov 2011-02-01 18:30:46 UTC
New Package SCM Request
=======================
Package Name: rubygem-mail
Short Description: A Really Ruby Mail Library.
Owners: minn
Branches: 
InitialCC:

Comment 26 Minnikhanov 2011-02-01 19:25:42 UTC
koji scratch build: FAIL at %check
http://koji.fedoraproject.org/koji/taskinfo?taskID=2755505

>>>
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.1RJLF5
+ umask 022
+ cd /builddir/build/BUILD
+ cd rubygem-mail-2.2.15
+ unset DISPLAY
+ pushd /builddir/build/BUILDROOT/rubygem-mail-2.2.15-2.fc15.noarch/usr/lib/ruby/gems/1.8/gems/mail-2.2.15
~/build/BUILDROOT/rubygem-mail-2.2.15-2.fc15.noarch/usr/lib/ruby/gems/1.8/gems/mail-2.2.15 ~/build/BUILD/rubygem-mail-2.2.15
+ rake spec
rake aborted!
Bundler couldn't find some gems.Did you run `bundle install`?
/builddir/build/BUILDROOT/rubygem-mail-2.2.15-2.fc15.noarch/usr/lib/ruby/gems/1.8/gems/mail-2.2.15/Rakefile:18
(See full trace by running task with --trace)
(in /builddir/build/BUILDROOT/rubygem-mail-2.2.15-2.fc15.noarch/usr/lib/ruby/gems/1.8/gems/mail-2.2.15)
error: Bad exit status from /var/tmp/rpm-tmp.1RJLF5 (%check)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.1RJLF5 (%check)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
<<<

Comment 27 Mo Morsi 2011-02-02 00:29:58 UTC
OK my bad. This was because I pushed the update to the treetop rpm but didn't request and official build. Just did that. When it propagates to the rawhide repos you should be able to build mail

http://koji.fedoraproject.org/koji/buildinfo?buildID=216551

Comment 28 Mo Morsi 2011-02-02 16:04:01 UTC
rubygem-mail Koji scratch build on dist-f15 is green:  

http://koji.fedoraproject.org/koji/taskinfo?taskID=2757226

Comment 29 Bill Nottingham 2011-02-02 22:33:42 UTC
Git done (by process-git-requests).

Comment 30 Minnikhanov 2011-02-04 18:37:17 UTC
Pushed to rawhide. Close.


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