Bug 588435

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.

Updated to 1.1.4 and dropped ruby from the name of the package.  Now it is just 
 rubygem-libxml  IAW Fedora Ruby standards.

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?

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.


http://github.com/admiyo/MySpecs/commit/5a8c981cda075ee7c416f334999440b0fc7a921f

Had to change the dependecy to get it to build correctly.  BUild is Confirmed to work by jmrodri

http://github.com/admiyo/MySpecs/commit/5d836e04db8077254c2b61d6623d138d57acd1bd

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:

http://magoazul.com/wip/SPECS/rubygem-libxml-ruby.spec

produces proper debuginfo etc.

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

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.

Matthew, do you want to leave this bug open for your spec, or start a new one?

(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.

If review is needed, please also post the URL of srpm.

I rebuilt his RPM from the spec file.  Here is the resulting srpm

http://admiyo.fedorapeople.org/buildr-repo/rubygem-libxml-ruby-1.1.4-2.young.src.rpm

@Adam:
- 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:
  http://rubyforge.org/tracker/index.php?func=detail&aid=28198&group_id=494&atid=1971

  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)

What is the status of this bug?

Mamoru,

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

(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.

So who is going to import this package?

(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

Some notes:

* Build failure
  - Build fails on F-12/ppc64 (at least)
    http://koji.fedoraproject.org/koji/taskinfo?taskID=2243323

    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:
----------------------------------------------------------------------
%prep
%setup -q -c -T

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

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

%build
# try again
pushd ./%{geminstdir}

find . -name \*.o -or -name \*.so | xargs rm -f
ruby setup.rb config
ruby setup.rb setup
popd
----------------------------------------------------------------------
    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
    subpackage.

* 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).

What is the status of this bug?

(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> - 1.1.4-3
- Fake out the installer and clean build extension from scratch (#588435).
- Exclude ext/ sources (#588435).

Should I postpone reviewing this for now?

(In reply to comment #21)
> Should I postpone reviewing this for now?    

I think so. 

I've posted

http://rubyforge.org/pipermail/libxml-devel/2010-June/001514.html

but no feedback yet.

Hopefully someone steps up to maintain it upstream.

What's the status of this review?

This initially started as a dependency for rubygem-buildr. It is no longer
needed for that. We can cancel this review.