ruby 1.8.7p299 is now rawhide build tree

[Mamoru Tasaka]

Hello:

Mohammed Morsi wrote, at 07/29/2010 10:16 AM +9:00:
> On 07/26/2010 03:53 PM, Mamoru Tasaka wrote:
>> Hello, all:
>>
>> As
>> - F14 feature freeze is tomorrow !
>> - Mohammed's ruby srpm was almost complete (as far as I tried using):
>> http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm
>>
>> I slightly modified Mohammed's srpm and imported into rawhide build tree.
>> Now it is available on
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=186570
>>
>> A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13:
>> - Some cleanups
>> - Make -irb, -rdoc subpackage noarch
>> - Make dependencies between arch-dependent subpackages isa specific
>> - Improve sample documentation gathering
>>
>> I hope the imported new ruby won't break things (so much).
>> I appreciate all peoples' contributing to ruby 187 packages.
>>
>> Regards,
>> Mamoru
>>
> Thanks for this Mamoru, just went through and rebuilt your srpm, and have a couple of comments:

Thank you for feedback.

> Some rpmlint output:
> $ rpmlint /home/mmorsi/rpmbuild/SRPMS/ruby-1.8.7.299-4.fc13.src.rpm
>
>  > ruby.src: W: no-cleaning-of-buildroot %install
>  > ruby.src: W: no-buildroot-tag
> Are the result of removing "BuildRoot" and "rm -rf $RPM_BUILD_ROOT " as per the
> following guidelines, and can be ignored correct?
>
> http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag

- Yes, BuildRoot tag, cleaning %buildroot at %install are no longer needed.

>  > ruby.src:264: W: mixed-use-of-spaces-and-tabs (spaces: line 264, tab: line 1)
> You have a tab on the "-mindepth 1 \" line in the spec, this should be removed.

- Actually I removed a space on this line. Now rpmlint warns that spaces are
   used in %changelog section, however I won't modify old %changelog entry for this
   (we can consider moving the old %changelog entry out of the spec file as you did)

> $ rpmlint /home/mmorsi/rpmbuild/RPMS/x86_64/ruby-1.8.7.299-4.fc13.x86_64.rpm
>  > ruby.x86_64: W: obsolete-not-provided ruby-mode
>  > ruby.x86_64: W: obsolete-not-provided ruby-docs
> In my latest spec I got around these by adding a 'Provides' for both ruby-mode / ruby-docs,
> where as you explicitly state "no Provides here". Is this the correct approach to do so?
> Eg if the emacs package provides the ruby-mode functionality, shouldn't it be that package that
> obsoletes and provides ruby-mode? Also since our package Obsoletes ruby-doc shouldn't
> it provide it as well?

- In this case corresponding Provides should not be added.
   - Adding "Provides: ruby-mode" in emacs is confusing. as "emacs" and "ruby" have
     little relation, and so it is not desired for maintainability.
   - Now no package "actually" provides what was in ruby-doc.

>  > ruby.x86_64: E: wrong-script-interpreter /usr/share/doc/ruby-1.8.7.299/sample/mpart.rb ./ruby
> I had gotten around this by adding the following to my spec (in the section the other
> interpreter paths get corrected)
> sed -i -e 's/^#!\s*\.\/ruby/#! \/usr\/bin\/ruby/' sample/mpart.rb

- Fixed.

> $ rpmlint /home/mmorsi/rpmbuild/RPMS/x86_64/ruby-tcltk-1.8.7.299-4.fc13.x86_64.rpm
>  > ruby-tcltk.x86_64: E: non-executable-script /usr/lib/ruby/1.8/tkextlib/pkg_checker.rb 0644L /usr/bin/env
> I got around this by removing the shebang from the top of the file like so.
> sed -i -e '/^#!.*/,1D' ext/tk/lib/tkextlib/pkg_checker.rb

- Instead I marked this file executable because this script can actually be executed.
   Now this script reports some errors, however as this script says "Shown status may be wrong"
   (and as I don't know how to fix the reported errors) I leave it for now...

> ===
>
> AFAIK all the other rpmlint warnings can be ignored. Just going through the spec file itself,
> I'm just wondering why the complexity for the iconv stuff. Unless I missed something major,
> I just went through the files rpmlint was stating weren't utf-8 and ran "iconv -f iso8859-1 -t utf-8"
> on them to take care of the issue. No need for any sed'ing. Did I oversimplify the issue?

- Actually as shown in build.log, actually some files are in EUC-JP (not ISO-8859-1) and some
   are in ISO-8859-1.
   - EUC-JP encoding is commonly used in (UNIX) Japanese texts (even now).
   Unfortunately rpmlint cannot detect EUC-JP encoding (which is Japanese specific),
   and sometimes rpmlint reports 'it is under ISO-8859-1', and sometimes rpmlint says nothing.

- Some texts have 'EUC-JP' string in them, and after changing encoding, such strings
   must also be changed
   (On some ruby scripts this is critical because if trying to execute such scripts
    which are converted from EUC-JP to UTF-8 but still contain "EUC-JP" string, this
    causes some unexpected behavior)

>
> Also I can't help but feel that we should put some of this stuff in the source %prep section,
> not in the %install section, and would be interested in seeing what (if anything) the guidelines
> say about this. Regardless these last couple are not big issues, I wouldn't have a problem with the
> Ruby rpms going in without them being resolved.


> BTW I tested this latest RPM in a VM and am happy to say via some light surface testing:
> rake, rack, rails, rspec, and gem work out of the box, and the puppet, rails, and deltacloud
> test/spec suites work in the same manner as they do against 1.8.6.

Thank you for testing. By the way, if rails 2.3.8 is ready, would you upgrade Fedora's rails
related packages to 2.3.8 for rawhide/F-14 for now?


- Fixing encoding or using massive "sed" on files only for sample files which are actually
   to be installed (i.e. executing this under tmp-ruby-docs) is much safer than executing
   these in %prep, so I think we need not move this to %prep.

Committed in -5.

Regards,
Mamoru