Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 514931 - Please build ruby-RMagick for EPEL 5
Summary: Please build ruby-RMagick for EPEL 5
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ruby-RMagick
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-31 15:20 UTC by Robert Scheck
Modified: 2009-08-18 00:23 UTC (History)
5 users (show)

Fixed In Version: 1.15.17-2.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-02 17:24:17 UTC
Type: ---
Embargoed:
j: fedora-cvs+


Attachments (Terms of Use)

Description Robert Scheck 2009-07-31 15:20:24 UTC
Description of problem:
There's no ruby-RMagick for RHEL 5 in EPEL 5 available, but we can't simply
rebuild a version from an active Fedora branch, because they somehow require 
ImageMagick >= 6.3, while RHEL 5 is shipping ImageMagick 6.2.x. This makes
us needing to package ruby-RMagick 1.x for EPEL 5 rather 2.x as in Fedora.

I've made my proposal for that branch review-like, because it is not the same
package. Maybe you can review it - otherwise switch the component to "Package 
Review". I would maintain the EPEL 5 branch, you could get co-maintainer. Is
this a deal?

Spec URL: http://labs.linuxnetz.de/bugzilla/ruby-RMagick.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/ruby-RMagick-1.15.17-1.src.rpm
Description:
RMagick is an interface between the Ruby programming language and the
ImageMagick and GraphicsMagick image processing libraries.

Comment 1 Mamoru TASAKA 2009-07-31 16:09:15 UTC
Currently I have no interenst in EPEL, so I appreciate it if
you would maintain ruby-RMagick (and my other packages!) on EPEL
(and on Fedora!).

I would check your package later. Thank you for submitting this
bug report in advance.

Comment 2 Mamoru TASAKA 2009-08-01 16:17:07 UTC
Well,

* ruby(abi)
  - All ruby related packages must have "Requires: ruby(abi) = 1.8"
    ( And I usually recomend to add also "BuildRequires: ruby(abi) = 1.8"
      for consistency ).

* ImageMagick Dependency
  - Due to bug 500565 (i.e due to the function 
    static void test_Magick_version(void) in ext/RMagick/rmmain.c),
    when ruby-RMagick is rebuilt with ImageMagick 6.2.8.0, RMagick
    will require ImageMagick 6.2.8.X

    ( i.e. even if the soname of the library in ImageMagick won't change 
           between 6.2.8.X and 6.2.9.Y, RMagick rebuilt with ImageMagick
           6.2.8.X won't work with ImageMagick 6.2.9.Y (by default) ). 

* htmldoc
  - Would you explain why you pass "--disable-htmldoc" to configure?
    ( By the way it seems that creating html documents also fixes
      shebangs automatically )
  ! By the way as far as I am correct "BR: libwmf" is needed when creating
    html documents, would you check that?

* configure v.s. setup.rb
  - Well, I think if "configure -> make" is used to compile RMagick,
    "make install" or so should be used to install files.

    If you use "ruby setup.rb install", perhaps "ruby setup.rb config/setup"
    or so is preferable instead of "configure -> make".

Comment 3 Robert Scheck 2009-08-02 12:45:46 UTC
(In reply to comment #2)
> * ruby(abi)
>   - All ruby related packages must have "Requires: ruby(abi) = 1.8"
>     ( And I usually recomend to add also "BuildRequires: ruby(abi) = 1.8"
>       for consistency ).

Well, that doesn't work on EPEL 5, because there's no ruby(abi) provided.

$ rpm -q ruby
ruby-1.8.5-5.el5_3.7
$

$ rpm -q --provides ruby | grep "ruby(abi)"
$

As the ruby ABI anyway won't change on RHEL 5 during its lifetime, I don't
see a need for this. If it makes you happy, I can add a "ruby = 1.8.5" as a
hard requirement, but seems to be unnecessary.

> * ImageMagick Dependency
>   - Due to bug 500565 (i.e due to the function 
>     static void test_Magick_version(void) in ext/RMagick/rmmain.c),
>     when ruby-RMagick is rebuilt with ImageMagick 6.2.8.0, RMagick
>     will require ImageMagick 6.2.8.X
> 
>     ( i.e. even if the soname of the library in ImageMagick won't change 
>            between 6.2.8.X and 6.2.9.Y, RMagick rebuilt with ImageMagick
>            6.2.8.X won't work with ImageMagick 6.2.9.Y (by default) ). 

Well, ImageMagick is from RHEL thus never will get incompatible upgraded and
there never will be a version upgrade, just security backports. If ImageMagick
would get upgraded on RHEL, that would anyway break many things. I can add a
hard dependency to "ImageMagick = 6.2.8.0", if that makes you happy. Next RHEL
will anyway need ruby-RMagick 2.x.

> * htmldoc
>   - Would you explain why you pass "--disable-htmldoc" to configure?
>     ( By the way it seems that creating html documents also fixes
>       shebangs automatically )
>   ! By the way as far as I am correct "BR: libwmf" is needed when creating
>     html documents, would you check that?

Building documentation fails, that verdana.ttf or arial.ttf is required but
not available on the system. It's looking for /usr/share/fonts/defaults/
TrueType/<fontname>, if I remember the path correctly. Nothing at Fedora is
seemingly providing that.

> * configure v.s. setup.rb
>   - Well, I think if "configure -> make" is used to compile RMagick,
>     "make install" or so should be used to install files.
> 
>     If you use "ruby setup.rb install", perhaps "ruby setup.rb config/setup"
>     or so is preferable instead of "configure -> make".  

Maybe I did something wrong, but that way I was not able to build the package.
There's a *.h.in and another *.in for example which only gets handled by the
./configure, otherwise the build poorly failed for me.

Comment 4 Mamoru TASAKA 2009-08-02 16:26:20 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > * ruby(abi)
> >   - All ruby related packages must have "Requires: ruby(abi) = 1.8"
> >     ( And I usually recomend to add also "BuildRequires: ruby(abi) = 1.8"
> >       for consistency ).
> 
> Well, that doesn't work on EPEL 5, because there's no ruby(abi) provided.
> 
> $ rpm -q ruby
> ruby-1.8.5-5.el5_3.7
> $
> 
> $ rpm -q --provides ruby | grep "ruby(abi)"
> $

Well,
$ rpm -qp --provides ruby-libs-1.8.5-5.el5_2.6.i386.rpm 2>/dev/null | grep abi
ruby(abi) = 1.8

> > * ImageMagick Dependency
> >   - Due to bug 500565 (i.e due to the function 
> >     static void test_Magick_version(void) in ext/RMagick/rmmain.c),
> >     when ruby-RMagick is rebuilt with ImageMagick 6.2.8.0, RMagick
> >     will require ImageMagick 6.2.8.X
> > 
> >     ( i.e. even if the soname of the library in ImageMagick won't change 
> >            between 6.2.8.X and 6.2.9.Y, RMagick rebuilt with ImageMagick
> >            6.2.8.X won't work with ImageMagick 6.2.9.Y (by default) ). 
> 
> Well, ImageMagick is from RHEL thus never will get incompatible upgraded and
> there never will be a version upgrade, just security backports. If ImageMagick
> would get upgraded on RHEL, that would anyway break many things. I can add a
> hard dependency to "ImageMagick = 6.2.8.0", if that makes you happy. Next RHEL
> will anyway need ruby-RMagick 2.x.

Well, actually I don't know well about RHEL's policy (I don't have
RHEL or CentOS), however for this I will leave it to you.

> 
> > * htmldoc
> >   - Would you explain why you pass "--disable-htmldoc" to configure?
> >     ( By the way it seems that creating html documents also fixes
> >       shebangs automatically )
> >   ! By the way as far as I am correct "BR: libwmf" is needed when creating
> >     html documents, would you check that?
> 
> Building documentation fails, that verdana.ttf or arial.ttf is required but
> not available on the system. It's looking for /usr/share/fonts/defaults/
> TrueType/<fontname>, if I remember the path correctly. Nothing at Fedora is
> seemingly providing that.

Ah, actually this is a bug in RHEL ImageMagick (6.2.8.0-4.el5_1.1),
/usr/lib/ImageMagick-6.2.8/config/type.xml contains
<include file="type-windows.xml" /> , this is the culprit.
(I just remembered that with Fedora 7 or 8 ImageMagick ruby-RMagick
 htmldoc didn't build due to the same reason...)
Perhaps RHEL won't update ImageMagick due to this reason, so
for now I will accept --without-htmldoc

> 
> > * configure v.s. setup.rb
> >   - Well, I think if "configure -> make" is used to compile RMagick,
> >     "make install" or so should be used to install files.
> > 
> >     If you use "ruby setup.rb install", perhaps "ruby setup.rb config/setup"
> >     or so is preferable instead of "configure -> make".  
> 
> Maybe I did something wrong, but that way I was not able to build the package.
> There's a *.h.in and another *.in for example which only gets handled by the
> ./configure, otherwise the build poorly failed for me.  
Okay.

Please add ruby(abi) dependency.

----------------------------------------------------------------
  This package (ruby-RMagick) for EL-5 is approved by mtasaka
----------------------------------------------------------------

Comment 5 Robert Scheck 2009-08-02 16:45:07 UTC
Thank you very much for the review. I'll add ruby(abi) after the import.


Package Change Request
======================
Package Name: ruby-RMagick
New Branches: EL-5
Owners: robert

Comment 6 Jason Tibbitts 2009-08-02 16:56:40 UTC
CVS done.

Comment 7 Robert Scheck 2009-08-02 17:24:17 UTC
Package: ruby-RMagick-1.15.17-2.el5 Tag: dist-5E-epel-testing-candidate
Status: complete Built by: robert

Comment 8 Fedora Update System 2009-08-02 17:24:49 UTC
ruby-RMagick-1.15.17-2.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/ruby-RMagick-1.15.17-2.el5

Comment 9 Fedora Update System 2009-08-18 00:23:35 UTC
ruby-RMagick-1.15.17-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.


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