Mohammed Morsi wrote, at 07/29/2010 10:16 AM +9:00:
On 07/26/2010 03:53 PM, Mamoru Tasaka wrote:
> Hello, all:
> - F14 feature freeze is tomorrow !
> - Mohammed's ruby srpm was almost complete (as far as I tried using):
> I slightly modified Mohammed's srpm and imported into rawhide build tree.
> Now it is available on
> A summary of changes from Mohammed's ruby-126.96.36.1999-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.
Thanks for this Mamoru, just went through and rebuilt your srpm, and have a couple of
Thank you for feedback.
Some rpmlint output:
$ rpmlint /home/mmorsi/rpmbuild/SRPMS/ruby-188.8.131.529-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?
- 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)
> 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 /
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
obsoletes and provides ruby-mode? Also since our package Obsoletes ruby-doc
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
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
> 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
(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
I'm just wondering why the complexity for the iconv stuff. Unless I missed something
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
- Actually as shown in build.log, actually some files are in EUC-JP (not ISO-8859-1) and
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
- Some texts have 'EUC-JP' string in them, and after changing encoding, such
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,
causes some unexpected behavior)
Also I can't help but feel that we should put some of this stuff in the source %prep
not in the %install section, and would be interested in seeing what (if anything) the
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
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
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
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.