Ruby 1.9.3 testing repository

[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 at localhost /]# rpm -q ruby
>> ruby-1.9.3.0-2.fc17.i686
>> <mock-chroot>[root at localhost /]# rpm -q ruby-devel
>> package ruby-devel is not installed
>> <mock-chroot>[root at 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-41738+split-mode-vertical