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.
*** Bug 451744 has been marked as a duplicate of this bug. ***
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
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
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
(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.
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.
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.
Amazing software.
(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. ;)
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.
(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.
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.
The 5.26.00b src rpm from Mattias is working great for my Physics users!
(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.
Unfortunately it's crashing for me after: TBrowser b in the root shell. Is it crashing for anyone else as well?
(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.
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.
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".
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.
(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
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
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
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.
(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
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?
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
APPROVED.
root fails to build on ppc64, but upstream claims root support ppc64. It'll be better to report this problem to upstream.
Notes: RHEL6 only provides ppc64 for ppc machine.
(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
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:
(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
cvs done.
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
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
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
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
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.
(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.
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.
(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.
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
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.
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.
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.
IMHO root is more or less unusable until the problem mentioned in #c38 is fixed. Should I open a new bug reort for this?
It's easiest to open a new bug for sure. I would say.
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.
(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.
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
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.