Ruby 1.9.3 testing repository

[Vít Ondruch]

Hello,

I have prepared testing repository with Ruby 1.9.3 rev 33347 (i.e. bit 
newer version then RC1). You can enable it by downloading repo file [1] 
into your /etc/yum.repos.d directory. You can later install the Ruby 
package by issuing:

# sudo yum install  ruby rubygems-1.8.10-rc1.1.fc17

Please note that installation of fully versioned rubygems is *mandatory* 
ATM and you have to *uninstall rubygems* package prior installing this 
test release to avoid version conflicts. This will be fixes as soon as 
final release of Ruby will be available.

Vit

[1] http://vondruch.fedorapeople.org/ruby_1.9.3.repo

[Vít Ondruch]

Hi guys,

I have updated the repository to the officially released Rugy 1.9.3-p0. 
Installation should be now as simple as:

# yum install  ruby

Vit

Dne 4.10.2011 16:23, Vít Ondruch napsal(a):
> Hello,
>
> I have prepared testing repository with Ruby 1.9.3 rev 33347 (i.e. bit
> newer version then RC1). You can enable it by downloading repo file [1]
> into your /etc/yum.repos.d directory. You can later install the Ruby
> package by issuing:
>
> # sudo yum install  ruby rubygems-1.8.10-rc1.1.fc17
>
> Please note that installation of fully versioned rubygems is *mandatory*
> ATM and you have to *uninstall rubygems* package prior installing this
> test release to avoid version conflicts. This will be fixes as soon as
> final release of Ruby will be available.
>
> Vit
>
> [1] http://vondruch.fedorapeople.org/ruby_1.9.3.repo
> _______________________________________________
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Shawn Starr]

On Tuesday, November 01, 2011 10:41:47 AM Vít Ondruch wrote:
> Hi guys,
>
> I have updated the repository to the officially released Rugy 1.9.3-p0.
> Installation should be now as simple as:
>
> # yum install  ruby
>
> Vit

Hi Vit,

If I may request, can we have the Ruby/Rubygem packaging guidelines updated 
for 1.9.x and compat for 1.8.x?

I have a lot of rubygems to package and I'm unsure if some of these will work 
for 1.9 and RSPec 2.x standards.

This is in relation to getting OpenNebula 3.x in for Fedora 17 timeframe.

Thanks,
Shawn.
> Dne 4.10.2011 16:23, Vít Ondruch napsal(a):
> > Hello,
> >
> > I have prepared testing repository with Ruby 1.9.3 rev 33347 (i.e. bit
> > newer version then RC1). You can enable it by downloading repo file [1]
> > into your /etc/yum.repos.d directory. You can later install the Ruby
> > package by issuing:
> >
> > # sudo yum install  ruby rubygems-1.8.10-rc1.1.fc17
> >
> > Please note that installation of fully versioned rubygems is *mandatory*
> > ATM and you have to *uninstall rubygems* package prior installing this
> > test release to avoid version conflicts. This will be fixes as soon as
> > final release of Ruby will be available.
> >
> > Vit
> >
> > [1] http://vondruch.fedorapeople.org/ruby_1.9.3.repo
> > _______________________________________________
> > ruby-sig mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Dne 6.11.2011 06:55, Shawn Starr napsal(a):
> On Tuesday, November 01, 2011 10:41:47 AM Vít Ondruch wrote:
> > Hi guys,
> >
> > I have updated the repository to the officially released Rugy 1.9.3-p0.
> > Installation should be now as simple as:
> >
> > # yum install  ruby
> >
> > Vit
>
> Hi Vit,
>
> If I may request, can we have the Ruby/Rubygem packaging guidelines updated
> for 1.9.x and compat for 1.8.x?
>
> I have a lot of rubygems to package and I'm unsure if some of these will work
> for 1.9 and RSPec 2.x standards.
>
> This is in relation to getting OpenNebula 3.x in for Fedora 17 timeframe.
>
> Thanks,
> Shawn.

Hi Shawn,

Updated packaging guidelines are definitely on my TODO list, I just did 
not get the chance yet, since the Ruby package itself is still evolving.

Nevertheless, the RSpec 2.x is independent topic from Ruby 1.9. Please 
go ahead and use RSpec 2.x for all your packages. It should not be any 
issue.

Vit
> > Dne 4.10.2011 16:23, Vít Ondruch napsal(a):
> > > Hello,
> > >
> > > I have prepared testing repository with Ruby 1.9.3 rev 33347 (i.e. bit
> > > newer version then RC1). You can enable it by downloading repo file [1]
> > > into your /etc/yum.repos.d directory. You can later install the Ruby
> > > package by issuing:
> > >
> > > # sudo yum install  ruby rubygems-1.8.10-rc1.1.fc17
> > >
> > > Please note that installation of fully versioned rubygems is *mandatory*
> > > ATM and you have to *uninstall rubygems* package prior installing this
> > > test release to avoid version conflicts. This will be fixes as soon as
> > > final release of Ruby will be available.
> > >
> > > Vit
> > >
> > > [1] http://vondruch.fedorapeople.org/ruby_1.9.3.repo
> > > _______________________________________________
> > > ruby-sig mailing list
> > > [e-mail]
> > > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> >
> > ruby-sig mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Hi,

I have uploaded updated version of Ruby 1.9.3 packages into my testing 
repository. They are probably very close to the shape of Ruby I'd like 
to see in future Fedoras. The main changes are:

- Install RubyGems library outside of Ruby directory structure into 
/usr/share/rubygems folder. This should allows us to share RubyGems 
among different Ruby implementations.
- Installed gems are now divided into different directories. Gems 
installed by regular user goes into his/her home directory, gems 
installed by root goes to /usr/local/ directory, while the gems 
installed by RPM will go into /usr directory.
- "gem install" now installs gems into share/gems directory while their 
binary extensions goes into lib{64}/gems directory. This (in theory) 
allows to install binary gems side by side without conflicts.
- RubyGems has now its own -devel subpackage, which will be need in the 
future for build of RPM packages.
- Enhanced macros.ruby and macros.rubygems.
- All tests are green now (credits goes to bkabrda).

The detailed changelog you can find at GitHub repo [1]. If you have 
previously installed Ruby 1.9.3 from my testing repository, you should 
be able to simply do:

# yum update ruby

However, please note that due to directory structure changes, you might 
need reinstall all your gems.

And as always, any feedback is appreciated.

Vit

[1] https://github.com/voxik/ruby.spec

[Mo Morsi]

On 12/14/2011 08:33 AM, Vít Ondruch wrote:
> Hi,
>
> I have uploaded updated version of Ruby 1.9.3 packages into my testing 
> repository. They are probably very close to the shape of Ruby I'd like 
> to see in future Fedoras. The main changes are:

Hey Vit, a couple questions came up RE: Ruby 1.9.3 at today's cloud-sig 
meeting

- what changes to packaging guidelines if any will ruby 1.9.3 entail

- what fedora version are you targeting this for and are you going to 
file a feature?

- to what extent will rubygems need repackaging/rebuilding/mass 
rebuilding? how to best go about proceeding w/ that

Thanks,
    -Mo

[Vít Ondruch]

Dne 16.12.2011 21:20, Mo Morsi napsal(a):
> On 12/14/2011 08:33 AM, Vít Ondruch wrote:
> > Hi,
> >
> > I have uploaded updated version of Ruby 1.9.3 packages into my 
> > testing repository. They are probably very close to the shape of Ruby 
> > I'd like to see in future Fedoras. The main changes are:
>
> Hey Vit, a couple questions came up RE: Ruby 1.9.3 at today's 
> cloud-sig meeting
> what changes to packaging guidelines if any will ruby 1.9.3 entail

There will be definitely new packaging guidelines. I hope we will be 
able to prepare the guidelines draft before end of the week. Some of the 
changes that we are planing are:

* New ruby(abi) constant version
* ruby-devel newly provides some RPM macros, typically used by non-gem 
packages.
* rubygems-devel package now provides macros required by gem install 
(instead of querying ruby each time)
* New location for RubyGems and their binary extensions
* Deprecation of ruby- subpackages
* Encourage execution of test suite, however discourage of using Rake 
for such purpose
> what fedora version are you targeting this for and are you going to
>
> file a feature?

We are targeting Fedora 17. I have already prepared the draft of feature 
proposal [1] and I'd like to submit it to FESCo aproval before Christmas.
> to what extent will rubygems need repackaging/rebuilding/mass
>
> rebuilding? how to best go about proceeding w/ that

We have already tested to rebuild all ruby packages we were able to 
found (327 in total) and for most of them, we have already prepared 
patches. We were not able to rebuild 14 of them yet (but we'll try to 
reduce this number further). Nevertheless, these packages are typically 
un-maintained for longer period of time.
> Thanks,
>    -Mo

[1] https://fedoraproject.org/wiki/Features/Ruby_1.9.3

[Darryl L. Pierce]

On Mon, Dec 19, 2011 at 10:33:53AM +0100, Vít Ondruch wrote:
> > what fedora version are you targeting this for and are you going
> >
> > to file a feature?
>
> We are targeting Fedora 17. I have already prepared the draft of
> feature proposal [1] and I'd like to submit it to FESCo aproval
> before Christmas.

How will Ruby 1.8 be handled? Will we keep a ruby-1.8 package around?

[Vít Ondruch]

Dne 19.12.2011 16:26, Darryl L. Pierce napsal(a):
> On Mon, Dec 19, 2011 at 10:33:53AM +0100, Vít Ondruch wrote:
> > > what fedora version are you targeting this for and are you going
> > >
> > > to file a feature?
> >
> > We are targeting Fedora 17. I have already prepared the draft of
> > feature proposal [1] and I'd like to submit it to FESCo aproval
> > before Christmas.
>
> How will Ruby 1.8 be handled? Will we keep a ruby-1.8 package around?

No, sorry, I don't plan it. There is no reason except nostalgia. You can 
use JRuby if you really need.

Vit

[Darryl L. Pierce]

On Mon, Dec 19, 2011 at 04:40:46PM +0100, Vít Ondruch wrote:
> Dne 19.12.2011 16:26, Darryl L. Pierce napsal(a):
> > On Mon, Dec 19, 2011 at 10:33:53AM +0100, Vít Ondruch wrote:
> > > > what fedora version are you targeting this for and are you going
> > > >
> > > > to file a feature?
> > >
> > > We are targeting Fedora 17. I have already prepared the draft of
> > > feature proposal [1] and I'd like to submit it to FESCo aproval
> > > before Christmas.
> > How will Ruby 1.8 be handled? Will we keep a ruby-1.8 package around?
>
> No, sorry, I don't plan it. There is no reason except nostalgia. You
> can use JRuby if you really need.

I was thinking that, similarly to how Python 2.6 and 2.7 were handled,
we could have a compatibility RPM for people who depend on 1.8, such as
myself for my downstream projects.

[Vít Ondruch]

Dne 19.12.2011 16:51, Darryl L. Pierce napsal(a):
> On Mon, Dec 19, 2011 at 04:40:46PM +0100, Vít Ondruch wrote:
> > Dne 19.12.2011 16:26, Darryl L. Pierce napsal(a):
> > > On Mon, Dec 19, 2011 at 10:33:53AM +0100, Vít Ondruch wrote:
> > > > > what fedora version are you targeting this for and are you going
> > > > >
> > > > > to file a feature?
> > > >
> > > > We are targeting Fedora 17. I have already prepared the draft of
> > > > feature proposal [1] and I'd like to submit it to FESCo aproval
> > > > before Christmas.
> > >
> > > How will Ruby 1.8 be handled? Will we keep a ruby-1.8 package around?
> >
> > No, sorry, I don't plan it. There is no reason except nostalgia. You
> > can use JRuby if you really need.
>
> I was thinking that, similarly to how Python 2.6 and 2.7 were handled,
> we could have a compatibility RPM for people who depend on 1.8, such as
> myself for my downstream projects.

May be you should provide more details for what reason you cannot use 
Ruby 1.9.3 to help me understand. And believe me, we went through more 
than 320 packages in Fedora to make sure they are at least buildable 
with Ruby 1.9.3, if they had properly executed test suited, there is 
also high chance that these packages will work. There is less then 15 
packages from the total amount which are still troubling us but these 
packages are typically obsolete anyway (take sdljava as an example).

Vit

[Darryl L. Pierce]

On Mon, Dec 19, 2011 at 05:06:23PM +0100, Vít Ondruch wrote:
> > I was thinking that, similarly to how Python 2.6 and 2.7 were handled,
> > we could have a compatibility RPM for people who depend on 1.8, such as
> > myself for my downstream projects.
>
> May be you should provide more details for what reason you cannot
> use Ruby 1.9.3 to help me understand. And believe me, we went
> through more than 320 packages in Fedora to make sure they are at
> least buildable with Ruby 1.9.3, if they had properly executed test
> suited, there is also high chance that these packages will work.
> There is less then 15 packages from the total amount which are still
> troubling us but these packages are typically obsolete anyway (take
> sdljava as an example).

I'm just being conservative about it. Since there's so much that's
changed from 1.8 to 1.9 I'd like to see a transition period where both
are available before the older is completely phased out.

My main downstream project is based on 1.8 (since that's what's in RHEL
and will be for a while) so I'd like to see at least two releases with
1.8 to give me time to transition my work to 1.9 completely.

[Vít Ondruch]

Dne 19.12.2011 17:18, Darryl L. Pierce napsal(a):
> On Mon, Dec 19, 2011 at 05:06:23PM +0100, Vít Ondruch wrote:
> > > I was thinking that, similarly to how Python 2.6 and 2.7 were handled,
> > > we could have a compatibility RPM for people who depend on 1.8, such as
> > > myself for my downstream projects.
> >
> > May be you should provide more details for what reason you cannot
> > use Ruby 1.9.3 to help me understand. And believe me, we went
> > through more than 320 packages in Fedora to make sure they are at
> > least buildable with Ruby 1.9.3, if they had properly executed test
> > suited, there is also high chance that these packages will work.
> > There is less then 15 packages from the total amount which are still
> > troubling us but these packages are typically obsolete anyway (take
> > sdljava as an example).
>
> I'm just being conservative about it. Since there's so much that's
> changed from 1.8 to 1.9 I'd like to see a transition period where both
> are available before the older is completely phased out.
>
> My main downstream project is based on 1.8 (since that's what's in RHEL
> and will be for a while) so I'd like to see at least two releases with
> 1.8 to give me time to transition my work to 1.9 completely.

May be you should start to be worried about RHEL 7.

Honestly, if you are developing for current RHEL, then it is best to 
develop on RHEL. If you are developing for future RHEL, then it is best 
to develop on Rawhide. However, this is not discussion about RHEL but 
about Fedora.

Vit

[Darryl L. Pierce]

On Mon, Dec 19, 2011 at 05:30:39PM +0100, Vít Ondruch wrote:
> > My main downstream project is based on 1.8 (since that's what's in RHEL
> > and will be for a while) so I'd like to see at least two releases with
> > 1.8 to give me time to transition my work to 1.9 completely.
>
> May be you should start to be worried about RHEL 7.

I am looking to the future and especially to Ruby 1.9. :)
> Honestly, if you are developing for current RHEL, then it is best to
> develop on RHEL. If you are developing for future RHEL, then it is
> best to develop on Rawhide. However, this is not discussion about
> RHEL but about Fedora.

That's already the process. As I said, I'm just being conservative about
the transition; i.e., the idea of "we're going to completely dump LANG
vX for LANG vY with this release" (when there are incompatibilities
between X and Y) gives me chills. ;)

[Bohuslav Kabrda]

----- Original Message -----
> From: "Darryl L. Pierce" 
> To: "Ruby SIG mailing list" 
> Sent: Monday, December 19, 2011 5:45:19 PM
> Subject: Re: Ruby 1.9.3 testing repository
>
> On Mon, Dec 19, 2011 at 05:30:39PM +0100, Vít Ondruch wrote:
> > > My main downstream project is based on 1.8 (since that's what's in
> > > RHEL
> > > and will be for a while) so I'd like to see at least two releases
> > > with
> > > 1.8 to give me time to transition my work to 1.9 completely.
> >
> > May be you should start to be worried about RHEL 7.
>
> I am looking to the future and especially to Ruby 1.9. :)
> > Honestly, if you are developing for current RHEL, then it is best
> > to
> > develop on RHEL. If you are developing for future RHEL, then it is
> > best to develop on Rawhide. However, this is not discussion about
> > RHEL but about Fedora.
>
> That's already the process. As I said, I'm just being conservative
> about
> the transition; i.e., the idea of "we're going to completely dump
> LANG
> vX for LANG vY with this release" (when there are incompatibilities
> between X and Y) gives me chills. ;)

There is a remote possibility (and I put the stress on "remote") that a software collection with Ruby 1.8.7 and a subset of Rubygems will go into Fedora 17 (see [1] for information on software collections). However, maintaining software collections is a huge overhead and we should focus on the new stuff more - like getting newest versions into Rawhide and encourage everyone to use them (and actually use them ourselves). Ruby 1.8.7 will be reaching EOL in year and half [2] and only a half of year from that is normal maintenance, so it's time to move on.

[1] http://baseos.lab.eng.brq.redhat.com/Stack/ISVDeveloperGuide
[2] http://www.ruby-forum.com/topic/2094567

Regards,
Bohuslav.
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Dne 20.12.2011 07:51, Bohuslav Kabrda napsal(a):
> ----- Original Message -----
> > From: "Darryl L. Pierce"
> > To: "Ruby SIG mailing list"
> > Sent: Monday, December 19, 2011 5:45:19 PM
> > Subject: Re: Ruby 1.9.3 testing repository
> >
> > On Mon, Dec 19, 2011 at 05:30:39PM +0100, Vít Ondruch wrote:
> > > > My main downstream project is based on 1.8 (since that's what's in
> > > > RHEL
> > > > and will be for a while) so I'd like to see at least two releases
> > > > with
> > > > 1.8 to give me time to transition my work to 1.9 completely.
> > >
> > > May be you should start to be worried about RHEL 7.
> >
> > I am looking to the future and especially to Ruby 1.9. :)
> > > Honestly, if you are developing for current RHEL, then it is best
> > > to
> > > develop on RHEL. If you are developing for future RHEL, then it is
> > > best to develop on Rawhide. However, this is not discussion about
> > > RHEL but about Fedora.
> >
> > That's already the process. As I said, I'm just being conservative
> > about
> > the transition; i.e., the idea of "we're going to completely dump
> > LANG
> > vX for LANG vY with this release" (when there are incompatibilities
> > between X and Y) gives me chills. ;)
>
> There is a remote possibility (and I put the stress on "remote") that a software collection with Ruby 1.8.7 and a subset of Rubygems will go into Fedora 17 (see [1] for information on software collections). However, maintaining software collections is a huge overhead and we should focus on the new stuff more - like getting newest versions into Rawhide and encourage everyone to use them (and actually use them ourselves). Ruby 1.8.7 will be reaching EOL in year and half [2] and only a half of year from that is normal maintenance, so it's time to move on.
>
> [1] http://baseos.lab.eng.brq.redhat.com/Stack/ISVDeveloperGuide

All Fedorians could use following links:

https://admin.fedoraproject.org/updates/FEDORA-2011-17203/scl-utils-20111214...
https://admin.fedoraproject.org/pkgdb/acls/name/scl-utils

Vit
> [2] http://www.ruby-forum.com/topic/2094567
>
> Regards,
> Bohuslav.
> > --
> > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> > Delivering value year after year.
> > Red Hat ranks #1 in value among software vendors.
> > http://www.redhat.com/promo/vendor/
> >
> > ruby-sig mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Darryl L. Pierce]

On Tue, Dec 20, 2011 at 01:51:41AM -0500, Bohuslav Kabrda wrote:
> There is a remote possibility (and I put the stress on "remote") that a software collection with Ruby 1.8.7 and a subset of Rubygems will go into Fedora 17 (see [1] for information on software collections). However, maintaining software collections is a huge overhead and we should focus on the new stuff more - like getting newest versions into Rawhide and encourage everyone to use them (and actually use them ourselves). Ruby 1.8.7 will be reaching EOL in year and half [2] and only a half of year from that is normal maintenance, so it's time to move on.

I agree. All I'm arguing for is a transition period rather than a hard
cutover.

[Michael Stahnke]

Thanks for these rpms.  I've been trying to get the 1.9.3 srpm to rebuild
onto EL6 and I've been having some issues.  It looks to be centered around
autoconf and m4 (surprise ensues).  I can cleanly compile ruby 1.9.3
outside the spec file (without patches, macros etc) but once I attempt to
build within the spec framework it fails.  Would anybody happen to have any
pointers?

stahnma

[Vít Ondruch]

Dne 24.12.2011 01:54, Michael Stahnke napsal(a):
> Thanks for these rpms.  I've been trying to get the 1.9.3 srpm to 
> rebuild onto EL6 and I've been having some issues.  It looks to be 
> centered around autoconf and m4 (surprise ensues).  I can cleanly 
> compile ruby 1.9.3 outside the spec file (without patches, macros etc) 
> but once I attempt to build within the spec framework it fails.  Would 
> anybody happen to have any pointers?
>
> stahnma
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Hi,

Thank you for pointing it out. I found that there was typo in RubyGems 
patch, which is now fixed in git [1]. The build in Koji works just fine 
now [2]. I also successfully tried build for RHEL-6 for all supported 
platforms.

Vit

[1] 
https://github.com/voxik/ruby.spec/commit/b51d19470e704c9460c0c55ebf725cf2d7...
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=3613876

[Michael Stahnke]

On Mon, Jan 2, 2012 at 5:19 AM, Vít Ondruch  wrote:
> Dne 24.12.2011 01:54, Michael Stahnke napsal(a):
>
> Thanks for these rpms.  I've been trying to get the 1.9.3 srpm to rebuild
> onto EL6 and I've been having some issues.  It looks to be centered around
> autoconf and m4 (surprise ensues).  I can cleanly compile ruby 1.9.3
> outside the spec file (without patches, macros etc) but once I attempt to
> build within the spec framework it fails.  Would anybody happen to have any
> pointers?
>
> stahnma
>
> ruby-sig mailing [e-mail]://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
> Hi,
>
> Thank you for pointing it out. I found that there was typo in RubyGems
> patch, which is now fixed in git [1]. The build in Koji works just fine now
> [2]. I also successfully tried build for RHEL-6 for all supported platforms.
>
> Vit

Awesome.  Thanks
> [1]
> https://github.com/voxik/ruby.spec/commit/b51d19470e704c9460c0c55ebf725cf2d7...
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=3613876
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mamoru TASAKA]

Vít Ondruch wrote, at 12/20/2011 01:06 AM +9:00:
> Dne 19.12.2011 16:51, Darryl L. Pierce napsal(a):
> > On Mon, Dec 19, 2011 at 04:40:46PM +0100, Vít Ondruch wrote:
> > > Dne 19.12.2011 16:26, Darryl L. Pierce napsal(a):
> > > > On Mon, Dec 19, 2011 at 10:33:53AM +0100, Vít Ondruch wrote:
> > > > > > what fedora version are you targeting this for and are you going
> > > > > >
> > > > > > to file a feature?
> > > > >
> > > > > We are targeting Fedora 17. I have already prepared the draft of
> > > > > feature proposal [1] and I'd like to submit it to FESCo aproval
> > > > > before Christmas.
> > > >
> > > > How will Ruby 1.8 be handled? Will we keep a ruby-1.8 package around?
> > >
> > > No, sorry, I don't plan it. There is no reason except nostalgia. You
> > > can use JRuby if you really need.
> >
> > I was thinking that, similarly to how Python 2.6 and 2.7 were handled,
> > we could have a compatibility RPM for people who depend on 1.8, such as
> > myself for my downstream projects.
>
> May be you should provide more details for what reason you cannot use
> Ruby 1.9.3 to help me understand. And believe me, we went through more
> than 320 packages in Fedora to make sure they are at least buildable with
> Ruby 1.9.3, if they had properly executed test suited, there is also high
> chance that these packages will work. There is less then 15 packages from
> the total amount which are still troubling us but these packages are
> typically obsolete anyway (take sdljava as an example).
>
> Vit

One of the biggest changes between ruby 1.8.x and ruby 1.9.x is how
ruby handles strings, in non-ascii environments.

Small  example

[tasaka1@localhost ~]$ rpm -q ruby
ruby-1.8.7.352-3.fc17.i686
[tasaka1@localhost ~]$ ruby -e "puts 'あいう'.size"
9

v.s.

<mock-chroot>[root@localhost /]# rpm -q ruby
ruby-1.9.3.0-2.fc17.i686
<mock-chroot>[root@localhost /]# ruby -e "puts 'あいう'.size"
3

This diffecence may not be visible in ASCII world. However when
dealing with multibyte characters this change can be impact.

Regards,
Mamoru

[Mamoru TASAKA]

Hello,

Vít Ondruch wrote, at 12/14/2011 10:33 PM +9:00:
> Hi,
>
> I have uploaded updated version of Ruby 1.9.3 packages into my testing repository.
> They are probably very close to the shape of Ruby I'd like to see in future Fedoras.

First of all, I appreciate your work on ruby 193 packaging. Then I leave some quick
comments now.
> The main changes are:
> Install RubyGems library outside of Ruby directory structure into /usr/share/rubygems folder.
> This should allows us to share RubyGems among different Ruby implementations.
> Installed gems are now divided into different directories. Gems installed by regular user goes into his/her home directory,
> gems installed by root goes to /usr/local/ directory, while the gems installed by RPM will go into /usr directory.

I don't this behavior is right. If gems installed by regular users goes into under their home
directory, so should be on root because root is one of the users and we should prevent root's
installing gems under root's home directory.
> "gem install" now installs gems into share/gems directory while their binary extensions goes into lib{64}/gems
> directory. This (in theory) allows to install binary gems side by side without conflicts.
> RubyGems has now its own -devel subpackage, which will be need in the future for build of RPM packages.
> Enhanced macros.ruby and macros.rubygems.
> All tests are green now (credits goes to bkabrda).
>
> The detailed changelog you can find at GitHub repo [1].

Some packaging issue.
- Please check directory ownership issue.
   - For example, the directory %{ruby_libarchdir}/digest/ or so are not owned by
     any packages.
   - The directory %_libdir/pkgconfig should not be owned by ruby-devel.
- The dependency of -tcltk subpackage on -libs package should be %_isa specific.
- Maybe ri directory should be moved to %_libdir/ri for now?
- It seems that %{ruby_libdir}/rbconfig should belong to rubygems, not ruby-libs.
- build.log just shows:
--------------------------------------------------
compiling main.c
compiling dmydln.c
compiling dmyencoding.c
compiling version.c
--------------------------------------------------
   or so, It is hard to check from this log if Fedora specific compilation flags are
   passed correctly or not. Please make build.log more verbose so that we can
   see what commands are actually executed during build.
- Isn't COPY="cp -p" needed also on %install? Also
   "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults"
   in %spec file should be replaced by "cp -p".
- Consider to move mkmf.rb to ruby-devel:
--------------------------------------------------
<mock-chroot>[root@localhost /]# rpm -q ruby
ruby-1.9.3.0-2.fc17.i686
<mock-chroot>[root@localhost /]# rpm -q ruby-devel
package ruby-devel is not installed
<mock-chroot>[root@localhost /]# ruby -e "require 'mkmf'"
mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
--------------------------------------------------
- rubygems rpm contains "bigdecimal-1.1.0.gemspec  io-console-0.3.gemspec
   json-1.5.4.gemspec minitest-2.5.1.gemspec"??
   - At least these components should have its own subpackage rpms.
   - Also, for example the latest minitest is 2.9.1. rubygems (or rubygem-minitest
     built from ruby.... too complicated) should use latest minitest
   (and also please re-check components bundled in ruby - I hope
    ruby upstream will again unbundle these components ... this is
    again too complicated ..)
- include/ruby/ contains origuruma.h, however origuruma is separately
   packaged on Fedora.
   http://koji.fedoraproject.org/koji/packageinfo?packageID=5432
   Can ruby use system-widely provided origuruma?
   If not, what prevents it?

If you have previously installed Ruby
> 1.9.3 from my testing repository, you should be able to simply do:
> # yum update ruby
> However, please note that due to directory structure changes, you might need reinstall all your gems.
> And as always, any feedback is appreciated.
>
> Vit
>
> [1] https://github.com/voxik/ruby.spec

Regards,
Mamoru

[Bohuslav Kabrda]

----- Original Message -----
> From: "TASAKA Mamoru" 
> To: "Ruby SIG mailing list" 
> Sent: Saturday, December 17, 2011 7:26:20 PM
> Subject: Re: Ruby 1.9.3 testing repository
>
> Hello,
>
> Vít Ondruch wrote, at 12/14/2011 10:33 PM +9:00:
> > Hi,
> >
> > I have uploaded updated version of Ruby 1.9.3 packages into my
> > testing repository.
> > They are probably very close to the shape of Ruby I'd like to see
> > in future Fedoras.
>
> First of all, I appreciate your work on ruby 193 packaging. Then I
> leave some quick
> comments now.
> > The main changes are:
> > Install RubyGems library outside of Ruby directory structure into
> >
> > /usr/share/rubygems folder.
> >   This should allows us to share RubyGems among different Ruby
> >   implementations.
> > Installed gems are now divided into different directories. Gems
> >
> > installed by regular user goes into his/her home directory,
> >   gems installed by root goes to /usr/local/ directory, while the
> >   gems installed by RPM will go into /usr directory.
>
> I don't this behavior is right. If gems installed by regular users
> goes into under their home
> directory, so should be on root because root is one of the users and
> we should prevent root's
> installing gems under root's home directory.

I don't quite understand what you are saying - in one sentence you say that we should install gems in root home because root is just another user and then you say that we should prevent it. Personally, I think the Vit's proposed behaviour is right, as root is not (should not) be used for development/running applications and therefore there is no need for gem directory in his home. At the same time, root should be able to install non-rpm gems if he wants to make their new/unpackaged versions available system-wide.
> > "gem install" now installs gems into share/gems directory while
> >
> > their binary extensions goes into lib{64}/gems
> >   directory. This (in theory) allows to install binary gems side by
> >   side without conflicts.
> > RubyGems has now its own -devel subpackage, which will be need in
> >
> > the future for build of RPM packages.
> > Enhanced macros.ruby and macros.rubygems.
> > All tests are green now (credits goes to bkabrda).
> >
> > The detailed changelog you can find at GitHub repo [1].
>
> Some packaging issue.
> Please check directory ownership issue.
> For example, the directory %{ruby_libarchdir}/digest/ or so are
> not owned by
>    any packages.
> The directory %_libdir/pkgconfig should not be owned by
> ruby-devel.
> The dependency of -tcltk subpackage on -libs package should be
>
> %_isa specific.
> Maybe ri directory should be moved to %_libdir/ri for now?
> It seems that %{ruby_libdir}/rbconfig should belong to rubygems,
>
> not ruby-libs.

Why? It contains information about ruby, not about rubygems.
> build.log just shows:
>
> compiling main.c
> compiling dmydln.c
> compiling dmyencoding.c
> compiling version.c
>
> or so, It is hard to check from this log if Fedora specific
>    compilation flags are
>    passed correctly or not. Please make build.log more verbose so
>    that we can
>    see what commands are actually executed during build.
> Isn't COPY="cp -p" needed also on %install? Also
>  "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults"
>  in %spec file should be replaced by "cp -p".
> Consider to move mkmf.rb to ruby-devel:
>
> <mock-chroot>[root@localhost /]# rpm -q ruby
> ruby-1.9.3.0-2.fc17.i686
> <mock-chroot>[root@localhost /]# rpm -q ruby-devel
> package ruby-devel is not installed
> <mock-chroot>[root@localhost /]# ruby -e "require 'mkmf'"
> mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
> rubygems rpm contains "bigdecimal-1.1.0.gemspec
>
> io-console-0.3.gemspec
>    json-1.5.4.gemspec minitest-2.5.1.gemspec"??
> At least these components should have its own subpackage rpms.
> Also, for example the latest minitest is 2.9.1. rubygems (or
>
> rubygem-minitest
>      built from ruby.... too complicated) should use latest minitest
>    (and also please re-check components bundled in ruby - I hope
>     ruby upstream will again unbundle these components ... this is
>     again too complicated ..)

There has already been a proposal to gemify standard library: https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem - the question is, when it will really happen. For now, I agree we should look into moving these gems into subpackages (Is it even possible/feasible? Will everything work if we update them to newer versions?) and _consider_ it.
> include/ruby/ contains origuruma.h, however origuruma is separately
>  packaged on Fedora.
>  http://koji.fedoraproject.org/koji/packageinfo?packageID=5432
>  Can ruby use system-widely provided origuruma?
>  If not, what prevents it?
>
> If you have previously installed Ruby
> > 1.9.3 from my testing repository, you should be able to simply do:
> > # yum update ruby
> > However, please note that due to directory structure changes, you
> > might need reinstall all your gems.
> > And as always, any feedback is appreciated.
> >
> > Vit
> >
> > [1] https://github.com/voxik/ruby.spec
>
> Regards,
> Mamoru

Regards,
Bohuslav.
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mamoru TASAKA]

Hello:

Bohuslav Kabrda wrote, at 12/19/2011 06:06 PM +9:00:
> > > Installed gems are now divided into different directories. Gems
> > >
> > > installed by regular user goes into his/her home directory,
> > >    gems installed by root goes to /usr/local/ directory, while the
> > >    gems installed by RPM will go into /usr directory.
> >
> > I don't this behavior is right. If gems installed by regular users
> > goes into under their home
> > directory, so should be on root because root is one of the users and
> > we should prevent root's
> > installing gems under root's home directory.
>
> I don't quite understand what you are saying - in one sentence you say that
> we should install gems in root home because root is just another user and
> then you say that we should prevent it. Personally, I think the Vit's proposed
> behaviour is right, as root is not (should not) be used for development/running
> applications and therefore there is no need for gem directory in his home.
> At the same time, root should be able to install non-rpm gems if he wants to
> make their new/unpackaged versions available system-wide.

Note this: https://bugzilla.redhat.com/show_bug.cgi?id=513048#c9
CVE-2007-0469, still open)

(Although I left some comment that I don't agree on that bug) security responsible
team complains about _default_ behavior of installing system-wide even with root.
(Again although I left some comments that I don't agree with this) I think
changing _default_ behavior between root and normal users just introduces
unneeded confusion.
> > It seems that %{ruby_libdir}/rbconfig should belong to rubygems,
> >
> > not ruby-libs.
>
> Why? It contains information about ruby, not about rubygems.

It seems that I got confused between /usr/share/ruby/rbconfig and
/usr/share/rubygems/rbconfig ... however now why they both exist?
(ruby-18 does not have /usr/share/ruby/rbconfig and rubygems 1.8.11
with ruby-18 contains /usr/lib/ruby/site_ruby/1.8/rbconfig)

Note that /usr/lib/ruby/rbconfig.rb is there and "RbConfig" means
this > Vit
> > rubygems rpm contains "bigdecimal-1.1.0.gemspec
> > io-console-0.3.gemspec
> >   json-1.5.4.gemspec minitest-2.5.1.gemspec"??
> > At least these components should have its own subpackage rpms.
> > Also, for example the latest minitest is 2.9.1. rubygems (or
> > rubygem-minitest
> >     built from ruby.... too complicated) should use latest minitest
> >   (and also please re-check components bundled in ruby - I hope
> >    ruby upstream will again unbundle these components ... this is
> >    again too complicated ..)
>
> There has already been a proposal to gemify standard library: https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem
> the question is, when it will really happen. For now, I agree we should look into moving these gems into subpackages
>
> (Is it even possible/feasible? Will everything work if we update them to newer versions?) and _consider_ it.

If newer versions don't work, then it is a bug on such submodule, as people is
always able to upgrade individual submodule by themselves.
(Well, perl approach may be applicable).

Regards,
Mamoru

[Vít Ondruch]

Dne 19.12.2011 15:48, TASAKA Mamoru napsal(a):
> Hello:
>
> Bohuslav Kabrda wrote, at 12/19/2011 06:06 PM +9:00:
> > > > Installed gems are now divided into different directories. Gems
> > > >
> > > > installed by regular user goes into his/her home directory,
> > > >    gems installed by root goes to /usr/local/ directory, while the
> > > >    gems installed by RPM will go into /usr directory.
> > >
> > > I don't this behavior is right. If gems installed by regular users
> > > goes into under their home
> > > directory, so should be on root because root is one of the users and
> > > we should prevent root's
> > > installing gems under root's home directory.
> >
> > I don't quite understand what you are saying - in one sentence you 
> > say that
> > we should install gems in root home because root is just another user 
> > and
> > then you say that we should prevent it. Personally, I think the Vit's 
> > proposed
> > behaviour is right, as root is not (should not) be used for 
> > development/running
> > applications and therefore there is no need for gem directory in his 
> > home.
> > At the same time, root should be able to install non-rpm gems if he 
> > wants to
> > make their new/unpackaged versions available system-wide.
>
> Note this: https://bugzilla.redhat.com/show_bug.cgi?id=513048#c9
> CVE-2007-0469, still open)
>
> (Although I left some comment that I don't agree on that bug) security 
> responsible
> team complains about _default_ behavior of installing system-wide even 
> with root.
> (Again although I left some comments that I don't agree with this) I 
> think
> changing _default_ behavior between root and normal users just introduces
> unneeded confusion.

Let me rephrase what I said:

"If you are logged in as a root, and do "# gem install foo", the gem is 
going to be installed into the /usr/local directory"

That means it does not conflict with any gems installed by RPM nor with 
any other stuff installed by RPM.

Vit

[Vít Ondruch]

Dne 17.12.2011 19:26, TASAKA Mamoru napsal(a):
> Hello,
>
> Vít Ondruch wrote, at 12/14/2011 10:33 PM +9:00:
> > Hi,
> >
> > I have uploaded updated version of Ruby 1.9.3 packages into my 
> > testing repository.
> > They are probably very close to the shape of Ruby I'd like to see in 
> > future Fedoras.
>
> First of all, I appreciate your work on ruby 193 packaging. Then I 
> leave some quick
> comments now.

Thank you for your great feedback!
> > The main changes are:
> > Install RubyGems library outside of Ruby directory structure into
> >
> > /usr/share/rubygems folder.
> >   This should allows us to share RubyGems among different Ruby 
> > implementations.
> > Installed gems are now divided into different directories. Gems
> >
> > installed by regular user goes into his/her home directory,
> >   gems installed by root goes to /usr/local/ directory, while the 
> > gems installed by RPM will go into /usr directory.
>
> I don't this behavior is right. If gems installed by regular users 
> goes into under their home
> directory, so should be on root because root is one of the users and 
> we should prevent root's
> installing gems under root's home directory.

root user is exceptional anyway. Even his home directory is not in the 
same location as other users have. So I believe that this behavior is 
justifiable, although not everyone will necessarily agree. Preferred way 
of installing gem is using RPM anyway. Moreover, if you really like to 
install gems into root's home directory, you have still plenty of 
options such as GEM_HOME or --install-dir.
> > "gem install" now installs gems into share/gems directory while
> >
> > their binary extensions goes into lib{64}/gems
> >   directory. This (in theory) allows to install binary gems side by 
> > side without conflicts.
> > RubyGems has now its own -devel subpackage, which will be need in
> >
> > the future for build of RPM packages.
> > Enhanced macros.ruby and macros.rubygems.
> > All tests are green now (credits goes to bkabrda).
> >
> > The detailed changelog you can find at GitHub repo [1].
>
> Some packaging issue.
> Please check directory ownership issue.
> For example, the directory %{ruby_libarchdir}/digest/ or so are
>
> not owned by
>     any packages.
> The directory %_libdir/pkgconfig should not be owned by ruby-devel.
> The dependency of -tcltk subpackage on -libs package should be %_isa
>
> specific.

These are all valid points. I'll fix them.
> Maybe ri directory should be moved to %_libdir/ri for now?

Are you referring to my TODO [2]? Since this is really tricky. I agree 
that, if I claim that the RI documentation is platform specific, it 
should go into the %{_libdir}, on the other side this is bug IMO and I 
believe that it was also agreed by upstrem.
> It seems that %{ruby_libdir}/rbconfig should belong to rubygems, not
>
> ruby-libs.

If you check RubyGems upstream [3], you'll see that it contains only the 
"datadir.rb" file, therefore it means the "obsolete.rb" is own by Ruby 
ant herefore the rbconfig dir has to be owned by Ruby, not RubyGems. 
Also, RbConfig is clearly feature or Ruby. However, according to what I 
mentioned above, I have to exclude "datadir.rb" from Ruby and include in 
RubyGems package.
> build.log just shows:
>
> compiling main.c
> compiling dmydln.c
> compiling dmyencoding.c
> compiling version.c
>
> or so, It is hard to check from this log if Fedora specific 
> compilation flags are
>   passed correctly or not. Please make build.log more verbose so that 
> we can
>   see what commands are actually executed during build.

You are right that build of 1.8.7 was more verbose. However I can't see 
any difference in configuration or make flags. I'll try to take a look 
into it but I can't promise.
> Isn't COPY="cp -p" needed also on %install? Also
> "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults"
> in %spec file should be replaced by "cp -p".

Is it required at all? It is not used even in %install of 1.8.7, but 
there might be different reason. However there is guideline [5], so it 
is probably good idea.
> Consider to move mkmf.rb to ruby-devel:
>
> <mock-chroot>[root@localhost /]# rpm -q ruby
> ruby-1.9.3.0-2.fc17.i686
> <mock-chroot>[root@localhost /]# rpm -q ruby-devel
> package ruby-devel is not installed
> <mock-chroot>[root@localhost /]# ruby -e "require 'mkmf'"
> mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h

Actually this is interesting idea. Never thought about it.
> rubygems rpm contains "bigdecimal-1.1.0.gemspec  io-console-0.3.gemspec
> json-1.5.4.gemspec minitest-2.5.1.gemspec"??
> At least these components should have its own subpackage rpms.
> Also, for example the latest minitest is 2.9.1. rubygems (or
>
> rubygem-minitest
>     built from ruby.... too complicated) should use latest minitest
>   (and also please re-check components bundled in ruby - I hope
>    ruby upstream will again unbundle these components ... this is
>    again too complicated ..)

Yes, it is on my TODO list, however not a big priority. I believe that 
we can work on it later and can't see any immediate problem with that.
> include/ruby/ contains origuruma.h, however origuruma is separately
> packaged on Fedora.
> http://koji.fedoraproject.org/koji/packageinfo?packageID=5432
> Can ruby use system-widely provided origuruma?
> If not, what prevents it?

This is though. I remember this lengthy discussion [4] about (not only) 
oniguruma and from that, I had the feeling that the upstream version is 
not compatible with Ruby. Moreover, I checked the latest sources from 
Fedora and from Ruby and they differs. I cannot imagine to patch Ruby to 
support the upstream library, although we can try to open request 
upstream? What do you think?
> If you have previously installed Ruby
> > 1.9.3 from my testing repository, you should be able to simply do:
> > # yum update ruby
> > However, please note that due to directory structure changes, you 
> > might need reinstall all your gems.
> > And as always, any feedback is appreciated.
> >
> > Vit
> >
> > [1] https://github.com/voxik/ruby.spec
>
> Regards,
> Mamoru
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[2] https://github.com/voxik/ruby.spec/blob/master/ruby.spec#L195-199
[3] https://github.com/rubygems/rubygems/tree/master/lib/rbconfig
[4] http://bugs.ruby-lang.org/issues/show/4239
[5] https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps

[Mamoru TASAKA]

Hello, again:

Vít Ondruch wrote, at 12/19/2011 09:43 PM +9:00:
> > Maybe ri directory should be moved to %_libdir/ri for now?
>
> Are you referring to my TODO [2]?

Exactly.
> Since this is really tricky.
> I agree that, if I claim that the RI documentation is platform specific, it should go into the %{_libdir},
> on the other side this is bug IMO and I believe that it was also agreed by upstrem.

I don't think ri documents should be arch-dependent, either. The problem is that
currently they really are. Someone can say "so for now they must be moved to
%_libdir until bugs gets fixed", others can say it need not.
> > build.log just shows:
> >
> > compiling main.c
> > compiling dmydln.c
> > compiling dmyencoding.c
> > compiling version.c
> >
> > or so, It is hard to check from this log if Fedora specific compilation flags are
> > passed correctly or not. Please make build.log more verbose so that we can
> > see what commands are actually executed during build.
>
> You are right that build of 1.8.7 was more verbose. However I can't see any difference in configuration or make flags. I'll try to take a look into it but I can't promise.
> > Isn't COPY="cp -p" needed also on %install? Also
> >
> > "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults"
> > in %spec file should be replaced by "cp -p".
>
> Is it required at all? It is not used even in %install of 1.8.7, but there might be different reason.
> However there is guideline [5], so it is probably good idea.

Please check if timestamps on installed files are correctly kept
(showing verbose build log will also make it easier to check this).
> > include/ruby/ contains origuruma.h, however origuruma is separately
> >
> > packaged on Fedora.
> > http://koji.fedoraproject.org/koji/packageinfo?packageID=5432
> > Can ruby use system-widely provided origuruma?
> > If not, what prevents it?
>
> This is though. I remember this lengthy discussion [4] about (not only) oniguruma and from that,

This discussion seems to be about using origuruma with ruby 1.8.x.
> I had the feeling that the upstream version is not compatible with Ruby.
> Moreover, I checked the latest sources from Fedora and from Ruby and they differs.
> I cannot imagine to patch Ruby to support the upstream library, although we can try
> to open request upstream? What do you think?

Well,
- First of all I don't know where origuruma upstream is working. If they (oniguruma
   upstream) make changes on origuruma bundled in ruby tarball, they should also
   update origuruma tarball and release new one.
- Bundling such external software like origuruma is almost forbidden on Fedora
   (see https://bugzilla.redhat.com/show_bug.cgi?id=470696 : why rubygem-passenger
    cannot be in Fedora currently) and we should advise ruby upstream to use external
   oniguruma (or to add support to use external oniguruma).

Regards,
Mamoru

[Vít Ondruch]

Dne 19.12.2011 16:35, TASAKA Mamoru napsal(a):
> Hello, again:
>
> Vít Ondruch wrote, at 12/19/2011 09:43 PM +9:00:
> > > Maybe ri directory should be moved to %_libdir/ri for now?
> >
> > Are you referring to my TODO [2]?
>
> Exactly.
> > Since this is really tricky.
> > I agree that, if I claim that the RI documentation is platform 
> > specific, it should go into the %{_libdir},
> > on the other side this is bug IMO and I believe that it was also 
> > agreed by upstrem.
>
> I don't think ri documents should be arch-dependent, either. The 
> problem is that
> currently they really are. Someone can say "so for now they must be 
> moved to
> %_libdir until bugs gets fixed", others can say it need not.
> > > build.log just shows:
> > >
> > > compiling main.c
> > > compiling dmydln.c
> > > compiling dmyencoding.c
> > > compiling version.c
> > >
> > > or so, It is hard to check from this log if Fedora specific 
> > > compilation flags are
> > > passed correctly or not. Please make build.log more verbose so that 
> > > we can
> > > see what commands are actually executed during build.
> >
> > You are right that build of 1.8.7 was more verbose. However I can't 
> > see any difference in configuration or make flags. I'll try to take a 
> > look into it but I can't promise.
> > > Isn't COPY="cp -p" needed also on %install? Also
> > >
> > > "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults"
> > > in %spec file should be replaced by "cp -p".
> >
> > Is it required at all? It is not used even in %install of 1.8.7, but 
> > there might be different reason.
> > However there is guideline [5], so it is probably good idea.
>
> Please check if timestamps on installed files are correctly kept
> (showing verbose build log will also make it easier to check this).
> > > include/ruby/ contains origuruma.h, however origuruma is separately
> > >
> > > packaged on Fedora.
> > > http://koji.fedoraproject.org/koji/packageinfo?packageID=5432
> > > Can ruby use system-widely provided origuruma?
> > > If not, what prevents it?
> >
> > This is though. I remember this lengthy discussion [4] about (not 
> > only) oniguruma and from that,
>
> This discussion seems to be about using origuruma with ruby 1.8.x.
> > I had the feeling that the upstream version is not compatible with Ruby.
> > Moreover, I checked the latest sources from Fedora and from Ruby and 
> > they differs.
> > I cannot imagine to patch Ruby to support the upstream library, 
> > although we can try
> > to open request upstream? What do you think?
>
> Well,
> First of all I don't know where origuruma upstream is working. If
>
> they (oniguruma
>   upstream) make changes on origuruma bundled in ruby tarball, they 
> should also
>   update origuruma tarball and release new one.
> Bundling such external software like origuruma is almost forbidden
>
> on Fedora
>   (see https://bugzilla.redhat.com/show_bug.cgi?id=470696 : why 
> rubygem-passenger
>    cannot be in Fedora currently) and we should advise ruby upstream 
> to use external
>   oniguruma (or to add support to use external oniguruma).

I asked ruby-core about this matter, if you like to join discussion: 
http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/41721?41672-41...

Vit
> Regards,
> Mamoru
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

I have pushed to my GitHub account updated version of .spec file which 
should reflect the most of your comments.

Dne 19.12.2011 13:43, Vít Ondruch napsal(a):
> Dne 17.12.2011 19:26, TASAKA Mamoru napsal(a):
> > build.log just shows:
> >
> > compiling main.c
> > compiling dmydln.c
> > compiling dmyencoding.c
> > compiling version.c
> >
> > or so, It is hard to check from this log if Fedora specific 
> > compilation flags are
> >   passed correctly or not. Please make build.log more verbose so that 
> > we can
> >   see what commands are actually executed during build.
>
> You are right that build of 1.8.7 was more verbose. However I can't 
> see any difference in configuration or make flags. I'll try to take a 
> look into it but I can't promise.

I found the option, so the build.log should be verbose as it used to be.
> > Isn't COPY="cp -p" needed also on %install? Also
> > "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults"
> > in %spec file should be replaced by "cp -p".
>
> Is it required at all? It is not used even in %install of 1.8.7, but 
> there might be different reason. However there is guideline [5], so it 
> is probably good idea.

I kept the install section without the "cp -p". The installation is done 
more or less by tool/rbinstall.rb and it seems the script does not honor 
the COPY variable. Moreover I checked the time-stamps and they look ok.
> > Consider to move mkmf.rb to ruby-devel:
> >
> > <mock-chroot>[root@localhost /]# rpm -q ruby
> > ruby-1.9.3.0-2.fc17.i686
> > <mock-chroot>[root@localhost /]# rpm -q ruby-devel
> > package ruby-devel is not installed
> > <mock-chroot>[root@localhost /]# ruby -e "require 'mkmf'"
> > mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
>
> Actually this is interesting idea. Never thought about it.

I created ticket for this issue for the record 
https://github.com/voxik/ruby.spec/issues/2
> > rubygems rpm contains "bigdecimal-1.1.0.gemspec
> >
> > io-console-0.3.gemspec
> >   json-1.5.4.gemspec minitest-2.5.1.gemspec"??
> > At least these components should have its own subpackage rpms.
> > Also, for example the latest minitest is 2.9.1. rubygems (or
> >
> > rubygem-minitest
> >     built from ruby.... too complicated) should use latest minitest
> >   (and also please re-check components bundled in ruby - I hope
> >    ruby upstream will again unbundle these components ... this is
> >    again too complicated ..)

https://github.com/voxik/ruby.spec/issues/3
> > include/ruby/ contains origuruma.h, however origuruma is separately
> > packaged on Fedora.
> > http://koji.fedoraproject.org/koji/packageinfo?packageID=5432
> > Can ruby use system-widely provided origuruma?
> > If not, what prevents it?
>
> This is though. I remember this lengthy discussion [4] about (not 
> only) oniguruma and from that, I had the feeling that the upstream 
> version is not compatible with Ruby. Moreover, I checked the latest 
> sources from Fedora and from Ruby and they differs. I cannot imagine 
> to patch Ruby to support the upstream library, although we can try to 
> open request upstream? What do you think?

Do you still consider this as a blocker after upstream response [1]? 
Should I try to clarify or obtain exception from FPC just to be sure?

Vit

[1] 
http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/41721?41672-41...

[Vít Ondruch]

Hi Rubyists,

I have updated my testing repository with our latest version of Ruby. 
Here is short changelog:

* Bundled gems moved into dedicated directories and subpackages.
* Create and own RubyGems directories for binary extensions.
* Fix build with GCC 4.7.

Please let me know if you find something awkward.

Vit

Dne 4.10.2011 16:23, Vít Ondruch napsal(a):
> Hello,
>
> I have prepared testing repository with Ruby 1.9.3 rev 33347 (i.e. bit
> newer version then RC1). You can enable it by downloading repo file [1]
> into your /etc/yum.repos.d directory. You can later install the Ruby
> package by issuing:
>
> # sudo yum install  ruby rubygems-1.8.10-rc1.1.fc17
>
> Please note that installation of fully versioned rubygems is *mandatory*
> ATM and you have to *uninstall rubygems* package prior installing this
> test release to avoid version conflicts. This will be fixes as soon as
> final release of Ruby will be available.
>
> Vit
>
> [1] http://vondruch.fedorapeople.org/ruby_1.9.3.repo
> _______________________________________________
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig