Bug 542990

Summary: Review Request: root - Numerical data analysis framework
Product: [Fedora] Fedora Reporter: Mattias Ellert <mattias.ellert>
Component: Package ReviewAssignee: Steve Traylen <steve.traylen>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: andreas.petzold, dominik, fatkasuvayu, fedora-package-review, gholms, henriquecsj, jamatos, jdorff, juanucleus, k.georgiou, michael.ughetto, notting, pahan, richardfearn, steve.traylen, supercyper1, tomspur
Target Milestone: ---Flags: steve.traylen: fedora‑review+
kevin: fedora‑cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: root-5.28.00-1.el5.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-01 15:21:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 602791    
Bug Blocks: 608332    
Attachments:
Description Flags
rpmlint output for root-5.26.00b-3 none

Description Mattias Ellert 2009-12-01 07:21:59 EST
Spec URL: http://www.grid.tsl.uu.se/review/root.spec
SRPM URL: http://www.grid.tsl.uu.se/review/root-5.24.00b-1.fc12.src.rpm

Description:
The ROOT system provides a set of object oriented frameworks with all
the functionality needed to handle and analyse large amounts of data
in a very efficient way. Having the data defined as a set of objects,
specialised storage methods are used to get direct access to the
separate attributes of the selected objects, without having to touch
the bulk of the data. Included are histogramming methods in 1, 2 and 3
dimensions, curve fitting, function evaluation, minimisation, graphics
and visualisation classes to allow the easy setup of an analysis
system that can query and process the data interactively or in batch
mode.

Thanks to the built in CINT C++ interpreter the command language, the
scripting, or macro, language and the programming language are all
C++. The interpreter allows for fast prototyping of the macros since
it removes the time consuming compile/link cycle. It also provides a
good environment to learn C++. If more performance is needed the
interactively developed macros can be compiled using a C++ compiler.

The system has been designed in such a way that it can query its
databases in parallel on MPP machines or on clusters of workstations
or high-end PCs. ROOT is an open system that can be dynamically
extended by linking external libraries. This makes ROOT a premier
platform on which to build data acquisition, simulation and data
analysis systems.

Koji scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=1839820

The ppc64 build fails with a segfault - so ExcludeArch is used

rpmlint output:

Root uses the CINT runtime C++ interpreter and therefore needs access to its classed header files at runtime, so the headers are not devel files, even though rpmlint complains about them.

Root also uses short snippets of C++ code in its configuration files that is parsed by the CINT interpreter to do its plugin initialisation. The presence of these C++ source files in the packages is not a packaging error, but rpmlint complains about these too.

All the documentation is in the doc package so most of the other rpms complain about missing documentation.

Filtering out the "no-documentation" and "devel-file-in-non-devel-package" warnings, the following rpmlint output remains:

[ellert@ellert ~]$ rpmlint rpmbuild/RPMS/*/*root-* | sed -e /no-documentation/d -e /devel-file-in-non-devel-package/d
root-doc.noarch: W: hidden-file-or-dir /usr/share/doc/root-5.24.00b/test/RootShower/.rootshowerrc
root-doc.noarch: W: file-not-utf8 /usr/share/doc/root-5.24.00b/test/tstring.cxx
root-core.x86_64: E: rpath-in-buildconfig /usr/bin/root-config lines ['42']
root-proofd.x86_64: W: incoherent-init-script-name proofd ('root-proofd', 'root-proofdd')
root-rootd.x86_64: W: incoherent-init-script-name rootd ('root-rootd', 'root-rootdd')
79 packages and 0 specfiles checked; 1 errors, 2542 warnings.

The rpath-in-buildconfig error is just a simple string match picked up by rpmlint. Root was configured with --disable-rpath, and the root-config script generated by configure does the right thing:

[ellert@ellert root]$ root-config --has-rpath
no

[ellert@ellert root]$ root-config --libs
-L/usr/lib64/root -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lz -pthread -lm -ldl -rdynamic

The string with the rpath is present in the root-config file, but is only printed out when root's configure was run without --disable-rpath. So there is no need to patch the script.
Comment 1 Peter Lemenkov 2009-12-01 10:05:34 EST
*** Bug 451744 has been marked as a duplicate of this bug. ***
Comment 2 Mattias Ellert 2010-01-13 10:32:29 EST
Updated to version 5.26.00:

Spec URL: http://www.grid.tsl.uu.se/review/root.spec
SRPM URL: http://www.grid.tsl.uu.se/review/root-5.26.00-1.fc12.src.rpm
Comment 3 Mattias Ellert 2010-02-02 03:29:41 EST
Updated to version 5.26.00a:

Spec URL: http://www.grid.tsl.uu.se/review/root.spec
SRPM URL: http://www.grid.tsl.uu.se/review/root-5.26.00a-1.fc12.src.rpm
Comment 4 Chen Lei 2010-02-18 12:54:35 EST
Hi Mattias,
I make a scrutiny into your spec file, it's so sophisticated ^_^. 
I have some problems about your spec.
1.Did html.C generate all documention removed by patch10 to patch15?

2.What is the purpose of list libPyROOT.so twice? python binding normally can only be used in python program, thus only need to be included in python_sitearch.

3.There seems some dynamic libraries are plugins actually, they don't have devel files.
See http://packages.debian.org/source/sid/root-system
Comment 5 Mattias Ellert 2010-02-19 02:57:28 EST
(In reply to comment #4)
> Hi Mattias,
> I make a scrutiny into your spec file, it's so sophisticated ^_^. 
> I have some problems about your spec.
> 1.Did html.C generate all documention removed by patch10 to patch15?

The patches removes pieces of the documentation markup that causes errors during documentation generation. They cause errors like:

*** Interpreter error recovered ***
Error in <TDocMacroDirective::HandleDirective_Macro>: Error processing macro MAC
RO_TGraph2D_3!

or:

Error: illegal pointer to class object para 0x0 1367  MACRO_TParallelCoord_1.Cex
ec:7:
Error: illegal pointer to class object grade 0x0 1368  MACRO_TParallelCoord_1.Ce
xec:8:
Error: illegal pointer to class object para 0x0 1367  MACRO_TParallelCoord_1.Cex
ec:9:
Error: illegal pointer to class object para 0x0 1367  MACRO_TParallelCoord_1.Cex
ec:10:
Error: illegal pointer to class object para 0x0 1367  MACRO_TParallelCoord_1.Cex
ec:11:
Error: illegal pointer to class object age 0x0 1368  MACRO_TParallelCoord_1.Cexe
c:12:

> 2.What is the purpose of list libPyROOT.so twice? python binding normally can
> only be used in python program, thus only need to be included in
> python_sitearch.

No, the Python interface in libPyROOT.so works both ways. You can load in Python to call root from Python, but you can also load it in root to call Python from root.

> 3.There seems some dynamic libraries are plugins actually, they don't have
> devel files.
> See http://packages.debian.org/source/sid/root-system    

Most of roots libraries do double duty as plugins and dynamic libraries. It is difficult to distinguish if one of them is a plugin only. And some library that in one version of root is only a plugin can in the next version suddenly start being used as a dynamic library too. And a library that inside root is only a plugin can be used as a dynamic library by someone that develop their own software against the root libraries.

Also, since root uses the C++ interpreter CINT it needs access to it's headers at runtime. So the headers can not be split off to devel packages without making the runtime and devel packages depend on each other - and then what is the use of doing the split. So in my mind there are no devel files at all, and hence I have not split off any devel packages.
Comment 6 Chen Lei 2010-02-21 12:37:30 EST
Hi Mattias,


Thanks for your patience, I just start to learn Root and not know it well.
The root Framework seems extremely huge and sophisticated, maybe you need announce it on #fedora-devel-list to see if any sponsers are intersted or familier to root.
Comment 7 Mattias Ellert 2010-03-24 15:24:33 EDT
Updated to version 5.26.00b:

Spec URL: http://www.grid.tsl.uu.se/review/root.spec
SRPM URL: http://www.grid.tsl.uu.se/review/root-5.26.00b-1.fc12.src.rpm

This version also
- enables dcache support since the dcap library is now available in Fedora.
- disables the compilation of the bundled sources of the unuran library and links to the unuran library in Fedora instead.
Comment 8 Henrique "LonelySpooky" Junior 2010-04-01 22:12:25 EDT
Amazing software.
Comment 9 Suvayu 2010-04-01 22:35:25 EDT
(In reply to comment #8)
> Amazing software.    

True but equally amazingly difficult to package. Hence I appreciate Mattias' efforts more than I can express in one comment.

I am trying to get a bit more familiar with ROOT and rpmbuild before I can lend a hand. ;)
Comment 10 José Matos 2010-04-08 14:35:21 EDT
FWIW I am a sponsor and I am looking to have this project packaged for Fedora.

Without a deep look into the package what do you think it needs to be done in root before this package is approved?

On the other hand do not forget that in order to be sponsored you need to show your knowlege and control of the packaging guidelines as it can be seen here:

http://fedoraproject.org/wiki/PackageMaintainers/Join

I have signaled (bookmarked) this package as soon as the review request has made but I have been busy with real life. Sorry.
Comment 11 Mattias Ellert 2010-04-08 14:51:03 EDT
(In reply to comment #10)
> On the other hand do not forget that in order to be sponsored you need to show
> your knowlege and control of the packaging guidelines as it can be seen here:

There seems to be a misunderstanding here - I am not a new packager looking for a sponsor. I already maintain several packages in Fedora. This review does not, and never did have, a block on FE-NEEDSPONSOR.
Comment 12 José Matos 2010-04-08 15:05:22 EDT
I am sorry, my mistake then. :-)

On retrospective I misunderstood the word sponsor in one of the messages above and I did not check the flag, mea culpa.

In any case I am interested into helping this package to be in shape to be in Fedora.
Comment 13 Jimmy Dorff 2010-04-16 09:50:46 EDT
The 5.26.00b src rpm from Mattias is working great for my Physics users!
Comment 14 Garrett Holmstrom 2010-04-16 12:16:26 EDT
(In reply to comment #13)
> The 5.26.00b src rpm from Mattias is working great for my Physics users!    

A slightly modified version of that one seems to work fine for us on Scientific Linux as well.
Comment 15 Dominik 'Rathann' Mierzejewski 2010-05-14 18:01:12 EDT
Unfortunately it's crashing for me after:
TBrowser b
in the root shell. Is it crashing for anyone else as well?
Comment 16 Mattias Ellert 2010-05-19 03:54:39 EDT
(In reply to comment #15)
> Unfortunately it's crashing for me after:
> TBrowser b
> in the root shell. Is it crashing for anyone else as well?    

Starting a TBrowser works without problems for me with both Fedora 12 and Fedora 13. Make sure you have a clean environment where you don't have paths to some other root installation in PATH or LD_LIBRARY_PATH and that ROOTSYS in not defined. If the problem persists, please provide a backtrace.
Comment 17 Mattias Ellert 2010-05-19 04:09:42 EDT
Updated version:

Spec URL: http://www.grid.tsl.uu.se/review/root.spec
SRPM URL: http://www.grid.tsl.uu.se/review/root-5.26.00b-2.fc13.src.rpm

This version contains the following backports from the root svn trunk

 - Treat linker scripts correctly during library detection in configure. This is necessary in order to build root on Fedora 13.

 - Add libdpm to the list of libraries to search for an rfio implementation. The new specfile enables rfio support and adds dpm-devel as a new build dependency.
Comment 18 Steve Traylen 2010-06-05 14:05:55 EDT
For the root-xrootd package it's using  net/xrootd/src/xrootd/* ?
I think http://xrootd.slac.stanford.edu/ as an upstream should possibly
be a separate package instead.

And a trivial one, there are a load of $(install) that could benefit from
a "-p".
Comment 19 Steve Traylen 2010-06-06 16:09:03 EDT
Hi, src/tmva looks to be both used and is BSD.

With http://tmva.sourceforge.net/ as up stream.

Generally there is quite a bit of code from other places, some of this 
is not being used for sure such as 

core/pcre/src/pcre-7.8.tar.gz

so while not a requirement to remove these kind of things it would certainly
make the review easier if this unused stuff could be removed in %setup
or even earlier.
Comment 20 Mattias Ellert 2010-06-10 15:17:56 EDT
(In reply to comment #18)
> For the root-xrootd package it's using  net/xrootd/src/xrootd/* ?
> I think http://xrootd.slac.stanford.edu/ as an upstream should possibly
> be a separate package instead.

OK, makes sense. Review for xrootd submitted - bug 602791.

(In reply to comment #19)
> Hi, src/tmva looks to be both used and is BSD.
> 
> With http://tmva.sourceforge.net/ as up stream.

I have added a License tag to the root-tmva package.

I consider this to be different from a bundled dependency. It is rather an external module that is merged with the main distribution.

This is similar to other frameworks such as perl, where some external modules are distributed as part of the main perl package.

> Generally there is quite a bit of code from other places, some of this 
> is not being used for sure such as 
> 
> core/pcre/src/pcre-7.8.tar.gz
> 
> so while not a requirement to remove these kind of things it would certainly
> make the review easier if this unused stuff could be removed in %setup
> or even earlier.    

In the new specfile I remove all the unused bundled sources.

http://www.grid.tsl.uu.se/review/root-5.26.00b-3.fc12.src.rpm
http://www.grid.tsl.uu.se/review/root.spec
Comment 21 Steve Traylen 2010-06-26 17:48:38 EDT
Created attachment 427144 [details]
rpmlint output for root-5.26.00b-3

Putting the rpmlint output as an attachment for the review as it's humongous.

I'll summarise it for the review.

Also, scratch build okay: 

http://koji.fedoraproject.org/koji/taskinfo?taskID=2274688
Comment 22 Mattias Ellert 2010-07-14 01:33:54 EDT
Updated to version 5.26.00c:

Spec URL: http://www.grid.tsl.uu.se/review/root.spec
SRPM URL: http://www.grid.tsl.uu.se/review/root-5.26.00c-1.fc12.src.rpm
Comment 23 Steve Traylen 2010-07-21 16:26:26 EDT
Review: root: https://bugzilla.redhat.com/show_bug.cgi?id=542990
Date:   Jun 26th 2010.
Mock Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2274688, F14 works.

* FAIL: rpmlint output

See attachment above for full output, this is the summary for each
of the errors/warnings.

1) SPECS/root.spec:23: W: macro-in-comment %{version}
  this is okay since the comment is actually a recipie
  to create a versioned tar ball.

2) root.src: W: spelling-error %description -l en_US histogramming -> histogram, deprogramming, reprogramming
   To me it makes sense to change it just to histogram.

3) root-cint.x86_64: W: devel-file-in-non-devel-package /usr/include/root/CallFunc.h
   As you explained and I agree root completly breaks the normal runtime/devel split 
   basically and these .h files are needed runtime.

4) root-proofd.x86_64: W: incoherent-init-script-name proofd ('root-proofd', 'root-proofdd')
   root-rootd.x86_64: W: incoherent-init-script-name rootd ('root-rootd', 'root-rootdd')
   Fine the service is called proofd and rootd

5) root-python.x86_64: W: private-shared-object-provides 
   /usr/lib64/python2.6/site-packages/libPyROOT.so libPyROOT.so.5.26()(64bit)
   This can be fixed via a filter or something presumably.

6) root-core.x86_64: E: rpath-in-buildconfig /usr/bin/root-config lines ['42']
Well explained above.

* PASS: Named according to the Package Naming Guidelines.
* PASS: spec file name same as  base package %{name}.
Yes but I wish it wasn't called root - confusing but anyway. :-)

* PASS: Packaging Guidelines.
* PASS: Approved license in .spec file.
  - LGPLv2+ 
  - doc package is  GPLv2+ and BSD
  - fftw, unuran, mathmore,  GPLv2+
* NOTCOMPLETE: License on Source code.

* PASS: Include LICENSE file or similar if it exist.

* FAIL: Written in American English.
histogramming is not a word.

* PASS: Spec file legible. 
* PASS: Included source must match upstream source.
* PASS: Build on one architecture.
See mock build.

* FAIL: Not building on an architecture must highlighted.
Although you have ExcludeArch:	ppc64 there is no explanation
as to why. Should there be a bug somewhere at least?

Also you cint you on build on %{ix86} x86_64 but no explanation
why.

* PASS: Build dependencies must be listed in BuildRequires.
Mock build
* PASS: Handle locales properly. 
No locales
* PASS: ldconfig must be called on shared libs.
* PASS: No bundled copies of system libraries.
* PASS: Package must state why relocatable if relocatable.
Not relocatable.
* PASS: A package must own all directories that it creates
* PASS:  No duplicate files in %files listings. 
* PASS:  Permissions on files must be set properly. %defattr
* PASS:  %clean section contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
It does.
* PASS:  Each package must consistently use macros.
* PASS:  The package must contain code, or permissable content.
* PASS:  Large documentation files must go in a -doc subpackage.  
There is a doc package.
* PASS:  %doc  must not affect the runtime of the application. 
* PASS:  Header files must be in a -devel package.
So this is special case, header files are really runtime for cint.
* PASS:  Static libraries must be in a -static package.
None
* PASS:  Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'
* PASS:  devel packages must require the exact base package
* PASS:  No .la libtool archives
* PASS:  GUI apps should have %{name}.desktop file
%{_datadir}/applications/root.desktop
* PASS:  No files or directories already owned by other packages. 
* PASS:  %install must run rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
* PASS:  All filenames in rpm packages must be valid UTF-8.

Summary:
1) Correct histograming spelling.
2) Try and remove the provides of libPyROOT.so.5.26()(64bit)
3) I'm sure it says on the fedora pages some where to  use
   sed rather than dos2unix but can't find it now.

4) Explanation for the excludearch of ppc.
5) Explanation for %{ix86} x86_64 and -cint package.

I just want to look some more through the source for licensing.
Comment 24 Mattias Ellert 2010-07-24 17:57:36 EDT
(In reply to comment #23)
> Summary:
> 1) Correct histograming spelling.

Histogramming is spelt correctly (with two m's - just like programming).

This is a proper English word - it is present participle form of the verbified noun. Verbification of nouns is common practice in the English language, and the fact that the spellcheck dictionary doesn't know about this particular case doesn't make it incorrect. Google gives 34,000 hits for the word.

> 2) Try and remove the provides of libPyROOT.so.5.26()(64bit)

As explained above (comment #5) libPyROOT is a bidirectional interface, that works both from Python to root and from root to Pyhton. There is a potential legitimate use case for someone wanting to use the root to Python interface in an application that uses the root libraries to link to this library. If such an application was put in an rpm it would require this provides. It is therefore not proper to filter it out.

> 3) I'm sure it says on the fedora pages some where to  use
>    sed rather than dos2unix but can't find it now.

This used to be true, but the guidelines have changed. They now read:
http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors

"This error occurs because of DOS line breaks in a file. Fix it in the %prep section with sed or dos2unix."

> 4) Explanation for the excludearch of ppc.

It is exclude arch ppc64 - 32 bit ppc works. The ppc64 build segfaults during an invocation of cint.

I didn't find any good documentation for this so I filed a bug report (referenced in the new spec file). The reply from upstream was that it is a known issue and they have no intent to fix it.

> 5) Explanation for %{ix86} x86_64 and -cint package.

It is cintex that is intel only. The cint package is OK.

This is documented in the configure file. ./configure will turn off cintex if you try to enable it on something else than ix86 and x86_64, giving a warning about "incompatible Cintex architecture". So even if you tried to enable it configure wouldn't let you.

I have added a comment to the spec file that references a relevant comment in an existing bug report.


New version:

http://www.grid.tsl.uu.se/review/root-5.26.00c-2.fc12.src.rpm
http://www.grid.tsl.uu.se/review/root.spec
Comment 25 Steve Traylen 2010-07-29 07:43:38 EDT
Licensing:

1) the roofit subpackage looks to be BSD.

http://roofit.sourceforge.net/license.txt

2) There's some based on BSD in core.

core/editline/src/builtins.cxx:// full license (BSD).
core/editline/src/builtins.h:// full license (BSD).
core/editline/src/strlcpy.cxx:// full license (BSD).

3) cint/* Is this MIT?
Comment 26 Mattias Ellert 2010-07-29 16:18:08 EDT
Thank you for the thorough investigation!

New version:

http://www.grid.tsl.uu.se/review/root-5.26.00c-3.fc12.src.rpm
http://www.grid.tsl.uu.se/review/root.spec
Comment 27 Steve Traylen 2010-07-30 10:49:32 EDT
APPROVED.
Comment 28 Chen Lei 2010-07-30 10:59:31 EDT
root fails to build on ppc64, but upstream claims root support ppc64. It'll be better to report this problem to upstream.
Comment 29 Chen Lei 2010-07-30 11:00:16 EDT
Notes:

RHEL6 only provides ppc64 for ppc machine.
Comment 30 Mattias Ellert 2010-07-30 11:29:29 EDT
(In reply to comment #28)
> root fails to build on ppc64, but upstream claims root support ppc64. It'll be
> better to report this problem to upstream.    

The failing build on ppc64 has already been reported upstream at the specific request of the reviewer (see comment #24).

Upstream makes no claim that ppc64 works. On the contrary they claim they will not fix the ppc64 build and they suggest doing a 32 bit build on ppc64.

https://savannah.cern.ch/bugs/index.php?70542
Comment 31 Mattias Ellert 2010-07-30 11:34:19 EDT
Thank you for the review, Steve! It was a challenge....

New Package CVS Request
=======================
Package Name: root
Short Description: Numerical data analysis framework
Owners: ellert
Branches: F-12 F-13 F-14 EL-5 EL-6
InitialCC:
Comment 32 Chen Lei 2010-07-30 11:46:04 EDT
(In reply to comment #30)
> (In reply to comment #28)
> > root fails to build on ppc64, but upstream claims root support ppc64. It'll be
> > better to report this problem to upstream.    
> The failing build on ppc64 has already been reported upstream at the specific
> request of the reviewer (see comment #24).
> Upstream makes no claim that ppc64 works. On the contrary they claim they will
> not fix the ppc64 build and they suggest doing a 32 bit build on ppc64.
> https://savannah.cern.ch/bugs/index.php?70542    

It's stange, linux/ppc64 is listed under Supported Architectures. 

See http://root.cern.ch/drupal/content/supported-architectures
Comment 33 Kevin Fenzi 2010-07-30 16:04:43 EDT
cvs done.
Comment 34 Fedora Update System 2010-07-31 14:44:08 EDT
root-5.26.00c-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/root-5.26.00c-3.fc13
Comment 35 Fedora Update System 2010-07-31 14:44:14 EDT
root-5.26.00c-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/root-5.26.00c-3.fc12
Comment 36 Fedora Update System 2010-07-31 14:44:21 EDT
root-5.26.00c-3.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/root-5.26.00c-3.fc14
Comment 37 Andreas Petzold 2010-08-01 13:25:03 EDT
As a minimal test I'm trying to build and run the ROOT test suite. I'm getting  error messages (below) when running make. Looks like the root-cint rpm is missing the files from the prec_stl directory, which in ROOT source install is located in $ROOTSYS/cint/cint/lib/.

g++  -O2 -Wall -fPIC -pthread -m32 -I/usr/include/root -c Event.cxx
Generating dictionary EventDict.cxx...
rootcint -f EventDict.cxx -c Event.h EventLinkDef.h
Error: cannot open file "prec_stl/vector"  /usr/lib/root/cint/cint/stl/_vector:15:
Error: cannot open file "prec_stl/string"  /usr/lib/root/cint/cint/stl/_string:20:
Error: Symbol stringfTarget is not defined in current scope  /usr/include/root/TSchemaHelper.h:19:
Error: Symbol stringfSourceClass is not defined in current scope  /usr/include/root/TSchemaHelper.h:20:
Error: Symbol stringfSource is not defined in current scope  /usr/include/root/TSchemaHelper.h:21:
Error: Symbol stringfCode is not defined in current scope  /usr/include/root/TSchemaHelper.h:22:
Error: Symbol stringfVersion is not defined in current scope  /usr/include/root/TSchemaHelper.h:23:
Error: Symbol stringfChecksum is not defined in current scope  /usr/include/root/TSchemaHelper.h:24:
Error: Symbol stringfInclude is not defined in current scope  /usr/include/root/TSchemaHelper.h:25:
Error: Symbol stringfAttributes is not defined in current scope  /usr/include/root/TSchemaHelper.h:28:
Error: Symbol vector<TSchemaHelper>fReadRules is not defined in current scope  /usr/include/root/TGenericClassInfo.h:63:
Error: Symbol vector<TSchemaHelper>fReadRawRules is not defined in current scope  /usr/include/root/TGenericClassInfo.h:64:
Error: cannot open file "prec_stl/iterator"  /usr/lib/root/cint/cint/stl/_iterator:14:
Error: no such template iterator<std::bidirectional_iterator_tag,TObject*,std::ptrdiff_t,constTObject**,constTObject*&> /usr/include/root/TObjArray.h:115:
Error: no such template iterator<std::bidirectional_iterator_tag,TObject*,std::ptrdiff_t,constTObject**,constTObject*&> /usr/include/root/TRefArray.h:117:
Error: cannot open file "prec_stl/algorithm"  /usr/lib/root/cint/cint/stl/_algorithm:14:
Warning: Error occurred during reading source files
Warning: Error occurred during dictionary source generation
!!!Removing EventDict.cxx EventDict.h !!!
Error: rootcint: error loading headers...
make: *** [EventDict.cxx] Error 1
Comment 38 Andreas Petzold 2010-08-01 13:33:15 EDT
I suggest adding a separate package for the ROOT test suite. It's now buried in the 600+MB root-doc package. The test suite is very useful in spotting installation problems and running basic benchmarks.
Comment 39 Garrett Holmstrom 2010-08-01 14:31:52 EDT
(In reply to comment #38)
> I suggest adding a separate package for the ROOT test suite. It's now buried in
> the 600+MB root-doc package. The test suite is very useful in spotting
> installation problems and running basic benchmarks.    

It might also be worth it to run at least part of the test suite in a %check step during rpm building.
Comment 40 Fedora Update System 2010-08-01 15:21:50 EDT
root-5.26.00c-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 41 Chen Lei 2010-08-01 21:48:40 EDT
(In reply to comment #38)
> I suggest adding a separate package for the ROOT test suite. It's now buried in
> the 600+MB root-doc package. The test suite is very useful in spotting
> installation problems and running basic benchmarks.    

It'll better to remove test suite in root-doc to save space for end users, normally we can add %check to run test suite.
Comment 42 Fedora Update System 2010-08-02 18:22:13 EDT
root-5.26.00c-4.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/root-5.26.00c-4.fc14
Comment 43 Fedora Update System 2010-08-02 20:35:38 EDT
root-5.26.00c-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 44 Fedora Update System 2010-08-02 21:02:00 EDT
root-5.26.00c-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 45 Fedora Update System 2010-08-02 22:16:13 EDT
root-5.26.00c-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 46 Andreas Petzold 2010-08-04 05:18:08 EDT
IMHO root is more or less unusable until the problem mentioned in #c38 is fixed. Should I open a new bug reort for this?
Comment 47 Steve Traylen 2010-08-04 05:38:02 EDT
It's easiest to open a new bug for sure. I would say.
Comment 48 Andreas Petzold 2010-08-04 09:31:32 EDT
Sorry, I've missed the update to root-5.26.00c-4 which is supposed to fix the problem mentioned in comment #37 . I'll test it asap.
Comment 49 Andreas Petzold 2010-08-04 09:32:33 EDT
(In reply to comment #46)
> IMHO root is more or less unusable until the problem mentioned in #c38 is
> fixed. Should I open a new bug reort for this?    

sorry, wrong comment number. Of course I ment #c37.
Comment 50 Fedora Update System 2010-08-11 03:29:10 EDT
root-5.26.00c-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 51 Fedora Update System 2010-08-11 03:31:20 EDT
root-5.26.00c-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 52 Fedora Update System 2011-01-14 18:01:22 EST
root-5.28.00-1.el5.1 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/root-5.28.00-1.el5.1
Comment 53 Fedora Update System 2011-01-30 12:26:35 EST
root-5.28.00-1.el5.1 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.