Bug 588435 - Review Request: rubygem-libxml-ruby - libxml support for ruby
Summary: Review Request: rubygem-libxml-ruby - libxml support for ruby
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FE-DEADREVIEW buildr
TreeView+ depends on / blocked
Reported: 2010-05-03 17:52 UTC by Adam Young
Modified: 2010-12-26 20:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-26 20:29:38 UTC
Type: ---

Attachments (Terms of Use)

Description Adam Young 2010-05-03 17:52:50 UTC
Spec URL: 
SRPM URL: http://admiyo.fedorapeople.org/buildr-repo/rubygem-libxml-ruby-1.1.3-1.young.src.rpm

Description: libxml support for ruby

Comment 1 Mamoru TASAKA 2010-05-03 18:08:43 UTC
1.1.4 is released on 2010-05-02 (according to
http://rubygems.org/gems/libxml-ruby and $ gem list -r libxml-ruby ).
Please upgrade.

Comment 2 Adam Young 2010-05-03 19:43:51 UTC
Updated to 1.1.4 and dropped ruby from the name of the package.  Now it is just 
 rubygem-libxml  IAW Fedora Ruby standards.

Comment 3 Mamoru TASAKA 2010-05-04 04:00:37 UTC
We just always use "rubygem-%{gemname}" consistently even if %gemname
contains "ruby" string (like rubygem-ruby-opengl, rubygem-ruby-net-ldap,
rubygem-sqlite3-ruby). For this package please use "rubygem-libxml-ruby".

Also would you post the new URLs of your spec/srpm every time?

Comment 4 Adam Young 2010-05-06 01:40:45 UTC
CHanged the name back.

Also, now builds using mock.  Since this one contains sources, I had to strip out the debug info.  I need to figure out how the regular rpm build process handles this and mirror it.  But this version builds clean without any rpmmacro modification.


Comment 5 Adam Young 2010-05-06 01:42:13 UTC
Had to change the dependecy to get it to build correctly.  BUild is Confirmed to work by jmrodri@redhat.com


Comment 6 Matthew Kent 2010-05-06 07:49:44 UTC
Oh, I actually had this one prepped for submission but the blocker was some serious issues in the test suite that trigger a segfault in ruby. They also trigger one on 1.8.7p174 on debian so it's not fedora specific. 

The whole test suite looks pretty unmaintained and their bug tracker has more than a few tickets relating to segfaults unfortunately.

I meant to bring this up with upstream to see if they had any plans to fix this up or maintain this lib going forward.

The libraries does seem to work though, I'm running a few apps that depend on it without issue.

If your interested in my spec for reference:


produces proper debuginfo etc.

I'd be willing to co-maintain as well.

Comment 7 Adam Young 2010-05-06 18:45:30 UTC
MAtthew.  THanks.  I cam to the separate conclusiong that the gem install should have been done earlier, although I choseto do it in the %build, which is where I think it makes the most sense.  I can see the argument for doing it in prep, as otherwise prep just creates the top level directory.

It looks like your spec file is a lot more mature than what I have.  I'm more than happy to go with yours and co-maintain.

Comment 8 Adam Young 2010-05-11 16:14:06 UTC
Matthew, do you want to leave this bug open for your spec, or start a new one?

Comment 9 Matthew Kent 2010-05-12 04:21:40 UTC
(In reply to comment #8)
> Matthew, do you want to leave this bug open for your spec, or start a new one?    

We can use this bug if Mr Tasaka wouldn't mind reviewing my spec.

Comment 10 Mamoru TASAKA 2010-05-12 04:29:47 UTC
If review is needed, please also post the URL of srpm.

Comment 11 Adam Young 2010-05-12 20:03:28 UTC
I rebuilt his RPM from the spec file.  Here is the resulting srpm


Comment 12 Mamoru TASAKA 2010-05-13 19:08:48 UTC
- It seems that the spec file inside the srpm in the comment 11
  differs largely from the spec file of Matthew on comment 6,
  and the spec file in the srpm in the comment 11 has not a few
  thing to fix. Would you check it again?

@Adam and Matthew
- Actually test/tc_sax_parser.rb causes segfault and it seems
  that segfault is occuring on libxml-ruby side. I reported this
  issue on:

  Commenting out the line 20 of ./ext/libxml/ruby_xml_parser_context.c
  seems to stop this segfault, however there is still another test
  failure (in the same test file, also commented in the above
  upstream bug)

Comment 13 Mamoru TASAKA 2010-05-21 16:39:29 UTC
What is the status of this bug?

Comment 14 Adam Young 2010-05-21 16:47:10 UTC

Sorry, I was expecting that Matthew would post a corrected SRPM.  I'll rebuild and post one later on today.

Comment 15 Matthew Kent 2010-05-26 06:24:55 UTC
(In reply to comment #14)
> Mamoru,
> Sorry, I was expecting that Matthew would post a corrected SRPM.  I'll rebuild
> and post one later on today.    

Apologies for any confusion - yeah if you could steer this one home as I'm a bit short on time this week.

Comment 16 Mamoru TASAKA 2010-06-06 17:01:02 UTC
So who is going to import this package?

Comment 17 Matthew Kent 2010-06-09 06:43:45 UTC
(In reply to comment #16)
> So who is going to import this package?    

Ok, I can maintain this package.

And thankfully from the mailing list it looks like upstream is going to resume active development/maintenance.

Fresh builds: 

Spec URL: http://magoazul.com/wip/SPECS/rubygem-libxml-ruby.spec
SRPM URL: http://magoazul.com/wip/SRPMS/rubygem-libxml-ruby-1.1.4-2.fc14.src.rpm

Comment 18 Mamoru TASAKA 2010-06-10 20:21:50 UTC
Some notes:

* Build failure
  - Build fails on F-12/ppc64 (at least)

    build.log shows that 
    - the source gem contains uncleaned .o binary rpms
    - "make" process tries to use the .o files to create .so file
      and ppc64 ld cannot recognize the format of such .o objects
    Anyway the cause of this failure is that "make" process tries
    to use pre-compiled .o object and this should be fixed.

    One way to avoid this is like:
%setup -q -c -T

# hack
mkdir -p TMPBIN
pushd TMPBIN
ln -sf /bin/true make
export PATH=$(pwd):$PATH

mkdir -p .%{gemdir}
gem install -V \
  --local \
  --install-dir $(pwd)/%{gemdir} \
  --force --rdoc \

# try again
pushd ./%{geminstdir}

find . -name \*.o -or -name \*.so | xargs rm -f
ruby setup.rb config
ruby setup.rb setup
    Note that even if $PATH is modified at %prep, it is reset
    on %build.

* ext/ directory
  - Well, ext/ directory is actually source files for .so object and
    I don't think this directory should be included even for -doc

* test segfaults
  - Currently I feel that I don't want to approve this package
    unless segfault issue is resolved (I think at least some workaround
    should be applied).

Comment 19 Mamoru TASAKA 2010-06-21 14:30:02 UTC
What is the status of this bug?

Comment 20 Matthew Kent 2010-06-22 06:30:13 UTC
(In reply to comment #19)
> What is the status of this bug?    

Was hoping for some more movement upstream and a new release. Nothing yet. Going to ping them about the segfault you reported. In the mean time here's an updated build:

Spec URL: http://magoazul.com/wip/SPECS/rubygem-libxml-ruby.spec
SRPM URL: http://magoazul.com/wip/SRPMS/rubygem-libxml-ruby-1.1.4-3.fc14.src.rpm

* Mon Jun 21 2010 Matthew Kent <mkent@magoazul.com> - 1.1.4-3
- Fake out the installer and clean build extension from scratch (#588435).
- Exclude ext/ sources (#588435).

Comment 21 Mamoru TASAKA 2010-06-24 19:18:49 UTC
Should I postpone reviewing this for now?

Comment 22 Matthew Kent 2010-06-25 05:25:33 UTC
(In reply to comment #21)
> Should I postpone reviewing this for now?    

I think so. 

I've posted


but no feedback yet.

Hopefully someone steps up to maintain it upstream.

Comment 23 Michael Stahnke 2010-09-13 22:44:18 UTC
What's the status of this review?

Comment 24 Jesus M. Rodriguez 2010-11-18 14:52:32 UTC
This initially started as a dependency for rubygem-buildr. It is no longer
needed for that. We can cancel this review.

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