Bug 451744 (root)

Summary: Review Request: root - The CERN analyzer for high to medium energy physics
Product: [Fedora] Fedora Reporter: juanucleus <juanucleus>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: antonio.bulgheroni, cwickert, fatkasuvayu, fedora-package-review, fonts-bugs, itamar, jdorff, jochen, josephsmidt, k.georgiou, kingbiotech, lemenkov, mattias.ellert, mmahut, mycae, notting, oget.fedora, pertusus, richardfearn, terjeros, tomspur, wart
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-08 20:28:45 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    

Description juanucleus@gmail.com 2008-06-16 21:55:21 EDT
This is my first package submitted for review.  I am looking for a sponsor.

Spec URL: http://www.jlab.org/~cornejo/fedora/root/root.spec
SRPM URL: http://www.jlab.org/~cornejo/fedora/root/root-5.19.04-1.fc9.src.rpm
Description:
The ROOT system provides a set of OO 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 histograming methods
in 1, 2 and 3 dimensions, curve fitting, function evaluation, minimisation,
graphics and visualization 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 builtin 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 PC's. 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.

After running rpmlint on the 3 main package ( source, main, and devel), both source and the main package produced no output, and devel produced these warnings:

root-devel.x86_64: W: no-documentation
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/include/stdcxxfunc.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/include/stdfunc.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/include/posix.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/include/ipc.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/list.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/exception.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/vectorbool.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/queue.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/climits.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/multimap.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/stdexcept.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/complex.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/stack.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/valarray.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/multiset.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/set.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/map.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/multimap2.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/vector.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/deque.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/stl/map2.dll
root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/lib/posix/mktypes

Some issues:
1) The name is very generic, simply called root in upstream.  I understand that system administrators may be weary of installing and running a program called root.  Specially since it includes 3 daemons: rootd, xrootd, and prootd, which a system admin might not like seeing running.  Name can be changed, and I am open to suggestions.

2) One of the included features of ROOT is the internal C/C++ interpreter called CINT.  CINT uses, as shared libraries, DLL's.  As of now I do not understand why, but these produce the majority of the warnings in rpmlint.  From the packaging mailing list two suggestions were brought up:
    a) Change the stripping script so that it includes files ending in .dll
    b) Change CINT so that it can read .so files, even dll.so similar to how wine handle's DLL's.

3) Based on my experience from running and using ROOT, I strongly suspect that CINT requires the .h files to function properly.  I recall receiving a lot of errors when these were not present, particularly when I was forced to compile the code inside of root to get templates to work.  So ideally, one will also need to install the -devel package along with the main package.  If I include it, it produces an error in rpmlint.  I have to admit, that I don't know how to approach this problem.

4) Not an issue, but I will mention it upfront. Upstream includes the MS TrueType fonts and some binary dll files, which I've removed and documented.  It is from my experience that Fedora already includes the necessary fonts to properly display any GUI that root produces.

5) The main component of ROOT is terminal based, though, during use various GUIs do pop up.  One is also free to code in GUI using the ROOT API.  Does this constitute as a GUI and as such a proper .desktop file must be written and included?

6) This is almost a plain ROOT build, missing most of the extra plug-ins that ROOT includes.  One of the main features I guess are the Qt bindings, as well as the MySQL drivers.  I will be more than happy to include these, and encourage their inclusion.  I was just eager to get, at the very least, a fully working copy of ROOT into Fedora.  Though, if the review goes well, I will look into properly packaging and including all plug-in components.

Thank you all for your time.  I hope that ROOT may be made fit for inclusion in Fedora, and that it may be helpful for others.
Comment 1 Patrice Dumas 2008-06-18 09:03:44 EDT
I get this on 
$ rpm -Uvh ~/tmp/root-5.19.04-1.fc9.src.rpm 
   1:root                   warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
########################################### [100%]
error: unpacking of archive failed on file
/home/dumas/RPM-fc/SOURCES/root_v5.19.04-clean.source.tar.gz;485906b9: cpio: read

And rpm2cpio | cpio -i also fails.
Comment 2 juanucleus@gmail.com 2008-06-18 12:13:59 EDT
Patrice:
   My apologies for this, I do not know what the issue was.  I changed the name
of the source file to prevent the use of a dash and this seems to have done the
trick.  These are the new spec and source files:

Spec URL: http://www.jlab.org/~cornejo/fedora/root/r2/root.spec
SRPM URL: http://www.jlab.org/~cornejo/fedora/root/r2/root-5.19.04-2.fc9.src.rpm

By the way, this is for all.  There is also a good API documentation available,
which I have not yet packed because of the exceedingly large size.  It's
something like 200+ MB.  Should I attempt to pack this, or just point people to
the appropriate on-line source?

Also, right now I am packaging the development branch, but that's because the
production version (5.20.00) should be out on the 25th of this month.

Thank you all.
Comment 3 Patrice Dumas 2008-06-29 05:36:21 EDT
Missing buildRequires, at least:

libGL-devel libGLU-devel
postgresql-devel mysql-devel
krb5-devel
fftw-devel
python-devel
qt4-devel
ftgl-devel
gcc-gfortran
python-devel

Some may not really needed because they are in turn dependencies of
other BuildRequires.

The internal libAfterImage is used, there is this:
WARNING: System libAfterImage is too new, using built-in
this should be fixed. A libafterimage library is shipped which is
clearly wrong.

Also there is a minicern library, instead the system cern library, in
cernlib-utils
should be used. Then the 2 apps depending on the cernlib could be 
in a separate package.

It would be nice if you could remove the in-source 3rd party library
directories before doing the build, to be sure that they are not used.

There are 2 files installed not packaged:
   /usr/bin/g2root
   /usr/bin/h2root

The libraries should have a soname, you should add --enable-soversion

Currently the programs don't start because the shared libraries are not found 
by the dynamic loader. To correct that you should add a file in /etc/ld.so.conf.d

The fedora build flags are not used.

Some binary names are too generic in my opinion, namely:
root, roots, genmap, xrd

How is the python ROOT module used? Shouldn't it be in the python 
directories? And similar with genreflex. And there is also a 
/usr/lib/root/writer.py
which looks dubious. How is it used? In any case it should certainly be 
below %_datadir (or in the python dirs).

A separate package should be done for the (x)emacs stuff, there are
guidelines for that.

Many files and directories that are in %_sysconfdir doesn't look 
like configuration, like 
/etc/root/html/
/etc/root/RadioNuclides.txt
/etc/root/gdb-backtrace.sh
/etc/root/valgrind-root.supp 
/etc/root/root.mimes
/etc/root/proof/

Most should certainly be in %_datadir

Is 
/etc/root/vmc/
really needed? If needed it certainly should be in %_datadir and in -devel.

Are the files in 
/usr/share/root/plugins/
used at runtime? (they are in root-devel)

According to the doc, it seems that the files in /etc/profile.d are
not needed.

root-config may also be useful at runtime to have programs find the 
paths/arch, at least it is used in root.sh (though it is not useful for
linux).

I am not sure that the root icons should be in 
/usr/share/icons/
this directory is for icon themes conforming with freedesktop.
It should certainly better be in /usr/share/root/icons

At least a .desktop file is missing for root, and maybe more.

What is the difference between root and root.exe?

in the root.mime file, external applications should use xdg-open.

Because of the loader issue above I cannot test, but I'd like to
have an example showing when the cint header files are needed.

In the init.d files, you should remove references to environment variables.
in  the xrootd there is a @libdir@, but in fact all that relates to
LD_LIBRARY_PATH should be removed. Also there should be example
/etc/sysconfig/*d to show even in a very sketchy way what can go in these
files. It even seems to me than some variales should be mandatorily 
set in these sysconfig files, like XRDUSER. Corresponding users should
be created, there is a related guideline for user and group creation.

Looks like there are many things done in /tmp, it would be nice to be sure
that what is done here is always done with unpredictable names, to avoid
the race in tmp security issue.

There are many dependencies that are not in fedora (like pythia, castor,
globus...) some of which may be free software other aren't. In general I insist
on having all the free software dependencies in fedora, but in that case
this  means really too much. There is one dep already in fedora, unuran, you 
could try to use it.
Comment 4 Axel Thimm 2008-08-02 07:42:02 EDT
Juan & Patrice,

thanks for picking this up! It already looks quite good (submission and review).

Wrt the name: don't change it please, the HEP community is very familiar with
the root name.

Patrice, if we identify the non-free dependencies, maybe we can contact
upstreams and make them adapt their licensing like it happened for ARPACK. It's
is very slow (so this review should not wait for them), but it seems to work.
Comment 5 juanucleus@gmail.com 2008-09-04 14:26:52 EDT
Hi Patrice and Axel,

  Sorry for the long absence, but only a few days after submitting this for review my laptop died, and had to reformat my desktop to RedHat 5 as per our labs standards.  But in any case, I now have a laptop again, and am returning to packaging root.

I don't have a new package to submit yet, but I do have some comments and questions.

Patrice:
The only apparent difference between root and root.exe seems to be that root displays a splash screen and then calls root.exe.

I had originally not included the cernlib requirement because I thought cernlib was not being developed anymore. At least, the last release seems to have been in 2006.  Maybe the root people will update minicern more often then cernlib will get updated.  From my personal preference I'd prefer minicern, but if the Fedora standards require cernlib-utils to be used, I guess I'll make those changes.

I thought unrar was only part of livna.  Is this up for inclusion in F10?

Also, how do I add the fedora flags?  Should I patch the Makefile to include them, or is there a different method to include this into the spec file. The packaging guidelines are not very clear on this matter.

I will be uploading a new package shortly, as soon as I address the issues that Patrice brought up.  I'll be using 5.20.00 as it's been released already.  There is a new development version in the works, but won't be released until December 18, so I've made not attempts to update to that.

--Juan Carlos
Comment 6 Orcan Ogetbil 2008-10-03 18:07:30 EDT
> Also, how do I add the fedora flags?

Replacing

make %{?_smp_mflags}

with

make %{?_smp_mflags} OPTFLAGS="$RPM_OPT_FLAGS"

should do the trick. To understand why, just open the Makefile and search for OPTFLAGS. 

How is this package coming? I am curious about it.

I didn't understand your question about unrar, can you explain?
Comment 7 Patrice Dumas 2008-10-03 18:22:55 EDT
(In reply to comment #5)

> I don't have a new package to submit yet, but I do have some comments and
> questions.
> 
> Patrice:
> The only apparent difference between root and root.exe seems to be that root
> displays a splash screen and then calls root.exe.

Ok.
 
> I had originally not included the cernlib requirement because I thought cernlib
> was not being developed anymore. At least, the last release seems to have been
> in 2006.  Maybe the root people will update minicern more often then cernlib
> will get updated.  From my personal preference I'd prefer minicern, but if the
> Fedora standards require cernlib-utils to be used, I guess I'll make those
> changes.

Indeed, cernlib is dead upstream, but I still maintain it in fedora.
You are right that minicern may be updated more often, but it has very
little coverage compared with cernlib. The fedora policy is to use
only one library to fix bugs everywhere, but minicern is small and
a fork, so it is not obvious what to do. I'd say that as an exception
minicern can be used in root. If there are other advices it'd be 
better.

> I thought unrar was only part of livna.  Is this up for inclusion in F10?

There is an unrar in fedora, but that cannot do all that the
livna one can do.
 
> Also, how do I add the fedora flags?  Should I patch the Makefile to include
> them, or is there a different method to include this into the spec file. The
> packaging guidelines are not very clear on this matter.

They cannot be clear, since it depends on the package. It may
be as simple as using %configure or very complicated, depending
on the package.
Comment 8 Joseph Smidt 2009-01-01 13:24:01 EST
Hello, is there still interest in packaging root?  If so great!  If not I would be willing to continue the packaging process for root.  Thanks.
Comment 9 Orcan Ogetbil 2009-01-31 01:07:31 EST
Joseph, please go ahead. If the initial submitter returns, you guys can cooperate in the future.
Comment 10 Kostas Georgiou 2009-02-12 08:12:24 EST
I have a spec file that I use locally (we are an HEP group) but it's by no means ready to be included in fedora.

From what I remember some of the problems are:
* The M$ fonts have to go, we need to find suitable replacements and patch the code
* Licesing could be an issue with other parts of root beyond the fonts, getting some advice from the legal team is probably a good idea
* Some libraries are unversioned (xrootd, proofd. If I remember correctly)
* Most of the servers use no authentication in their default setup so the configs need to be changed to default to some "strong" authentication, people shouldn't end up exporting their homes without authentication just because they started a service.
* I've been packaging cint (the c++ interpreter) on it's own subpackage since it can be usefull outside of root, the latest version of root doesn't build the binary anymore though and it looks like upstream is starting to use cint on it's own (http://root.cern.ch/drupal/content/cint). It might be worthwhile to check if root can use the "external" cint to avoid code duplication.
* find a solution for libafterimage
Comment 11 Joseph Smidt 2009-02-15 15:09:01 EST
Hello,

     Just as an update, I have been trying to package 5.22.00. since that is the latest stable version.  The problem has been I can't get it to build.  I have borrowed from Juan's .spec above.  I will be borrowing more once I see what new files, etc... are installed with the new release.

     If anyone has a suggestion how I can get this to build, I will be grateful:

Spec: http://jsmidt.fedorapeople.org/ROOT.spec
Source: http://jsmidt.fedorapeople.org/root_v5.22.00.source.tar.gz
Comment 12 Kostas Georgiou 2009-02-16 10:51:18 EST
Here is the one that I used http://georgiou.fedorapeople.org/tmp/root.spec not perfect but it does build a usable 5.22 root.
Comment 13 Joseph Smidt 2009-02-16 13:19:24 EST
Thanks a lot for that .spec file.  I will go back to work and try to clean everything up.
Comment 14 Joseph Smidt 2009-02-16 21:17:02 EST
Request for comment:  I know this package is not ready to receive a thorough review yet, but it has basics covered: builds, installs, etc with exit 0, no rpmlint issues with the .spec, src and debug files.  It has been modularized, borrowing largely from Kostas above with -devel, -libs, etc packages.

However, as I am still new at packaging, I really could use some helpful feedback at this point.  Here are the needed files:

Spec: http://jsmidt.fedorapeople.org/root.spec
Srpm: http://jsmidt.fedorapeople.org/root-5.22.00-0.2.fc10.src.rpm

On known issue is the man package depends on the -devel package.  I don't know any way around this since unversioned libraries and .h files are needed for root to run properly.

I will start looking into all these issues, but thought I would make a request for comment while I am going about it.  Thanks a lot!

Here are the outputs:

rpmlint root.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

--------------------------------------------------------------

rpmlint root-5.22.00-0.2.fc10.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

--------------------------------------------------------------

 rpmlint root-debuginfo-5.22.00-0.2.fc10.i386.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

-------------------------------------------------------------

rpmlint root-xrootd-5.22.00-0.2.fc10.i386.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

--------------------------------------------------------------

rpmlint root-libs-5.22.00-0.2.fc10.i386.rpm 
root-libs.i386: W: no-documentation
root-libs.i386: W: non-conffile-in-etc /etc/ld.so.conf.d/root-i386.conf
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

--------------------------------------------------------------

(grepping to suppress, for now, hundreds of warnings!)

root-5.22.00-0.2.fc10.i386.rpm | grep E:root.i386: E: script-without-shebang /usr/lib/root/ROOT.py
root.i386: E: script-without-shebang /usr/share/root/icons/bld_listtree.xpm
root.i386: E: script-without-shebang /etc/root/html/header.html
root.i386: E: script-without-shebang /usr/share/root/icons/bld_text.xpm
root.i386: E: script-without-shebang /etc/root/html/ROOT.css
root.i386: E: script-without-shebang /usr/bin/thisroot.csh
root.i386: E: non-executable-script /usr/bin/thisroot.csh 0644
root.i386: E: script-without-shebang /etc/root/html/HELP.html
root.i386: E: script-without-shebang /usr/share/root/icons/bld_canvas.1.xpm
root.i386: E: script-without-shebang /etc/root/html/ROOT.js
root.i386: E: script-without-shebang /usr/bin/thisroot.sh
root.i386: E: non-executable-script /usr/bin/thisroot.sh 0644
root.i386: E: script-without-shebang /etc/root/html/footer.html
root.i386: E: only-non-binary-in-usr-lib

--------------------------------------------------------------


root-cint-5.22.00-0.2.fc10.i386.rpm | grep E:
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/win32api/make.bat
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/include/makehpib
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/wintcldl83/try.bat
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/cintocx/setup.bat
root-cint.i386: E: non-executable-script /usr/lib/root/cint/lib/pthread/setup 0644
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/wintcldl83/setup.bat
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/gl/setup.bat
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/Makefile
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/longlong/make.bat
root-cint.i386: E: zero-length /usr/lib/root/cint/lib/cintocx/Cint-Ocx
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/wintcldl83/wildc.bat
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/lib/qt/setup.bat
root-cint.i386: E: non-executable-script /usr/lib/root/cint/lib/WildCard/setup 0644
root-cint.i386: E: non-executable-script /usr/lib/root/cint/lib/dll_stl/setup 0644
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/stl/_climits
root-cint.i386: E: non-executable-script /usr/lib/root/cint/lib/WildCard/ARCHIVE 0644
root-cint.i386: E: script-without-shebang /usr/lib/root/cint/include/matrixstream.hi
root-cint.i386: E: devel-dependency root-devel

--------------------------------------------------------------------

rpmlint root-docs-5.22.00-0.2.fc10.i386.rpm | grep E:
root-docs.i386: E: wrong-script-end-of-line-encoding /usr/share/doc/root-5.22.00/tutorials/gui/mditestbg.xpm
root-docs.i386: E: wrong-script-end-of-line-encoding /usr/share/doc/root-5.22.00/tutorials/image/mditestbg.xpm

---------------------------------------------------------------------

rpmlint root-proofd-5.22.00-0.2.fc10.i386.rpm 
root-proofd.i386: W: non-conffile-in-etc /etc/root/proof/motd.sample
root-proofd.i386: W: non-conffile-in-etc /etc/root/proof/xpd.groups.sample
root-proofd.i386: W: non-conffile-in-etc /etc/root/proof/proof.conf.sample
root-proofd.i386: W: non-conffile-in-etc /etc/root/proof/cluster.conf.sample
root-proofd.i386: W: non-conffile-in-etc /etc/root/daemons/proofd.xinetd
root-proofd.i386: W: non-conffile-in-etc /etc/root/proof/noproof.sample
root-proofd.i386: W: non-conffile-in-etc /etc/root/proof/xpd.cf.sample
root-proofd.i386: W: non-conffile-in-etc /etc/root/proof/rootnetrc.sample
1 packages and 0 specfiles checked; 0 errors, 8 warnings.

----------------------------------------------------------------------

rpmlint root-rootd-5.22.00-0.2.fc10.i386.rpm 
root-rootd.i386: W: non-conffile-in-etc /etc/root/daemons/rootd.xinetd
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
Comment 15 Terje Røsten 2009-03-08 15:43:35 EDT
Some comments (some of these are not new, see comment #3 and #6)

add smp flags to make (the build is slow anyway), use optflags ->

replace with:

make %{?_smp_mflags}

with

make %{?_smp_mflags} OPTFLAGS="%{optflags}"

A build in koji in rawhide (F11) fails with:

 /etc/profile.d/qt.sh: No such file or directory

I guess this is because qt is now qt4 while /etc/profile.d/qt.sh is
in the qt3-devel package. 

A F10 koji was successfull, however ppc64 failed for some reason:
(that was with the make changes).

 http://koji.fedoraproject.org/koji/taskinfo?taskID=1230019
Comment 16 Jochen Schmitt 2009-03-09 11:41:12 EDT
I a a look to the package and find out that the build doesn't honor the $RPM_OPT_FLAGS.

In additional, if the main package need the .h and .so files from the devel subpackage then there is no need to create a seperate devel subpackage.
Comment 17 Jochen Schmitt 2009-03-09 11:45:58 EDT
After I have got a rpmls to the main package, I have found a lot of files in /etc/root which sould be better place into /usr/share/root.

And as last the main package contains fonts files, which is not allow by the packaging guideline. Fonts has to been placed in separates fonts subpackages.
Comment 18 Mattias Ellert 2009-03-19 15:46:00 EDT
(In reply to comment #3)

> There are many dependencies that are not in fedora (like pythia, castor,
> globus...) some of which may be free software other aren't.

There are several globus packages currently submitted for review. You might want to review some of them to get your dependencies satisfied:

bug #453850, bug #453851, bug #453853, bug #453854, bug #453855, bug #453856, bug #453857, bug #453858, bug #453861, bug #453862, bug #453865, bug #467235, bug #467237, bug #467239, bug #478917, bug #478918, bug #478919, bug #478920, bug #478921, bug #478922, bug #478923, bug #478925, bug #478926, bug #478927, bug #478928, bug #478929, bug #478930, bug #478931

The root configure file lists these globus libraries:

   globuslibs="libglobus_gss_assist_$flavour libglobus_gssapi_gsi_$flavour
              libglobus_gsi_credential_$flavour libglobus_common_$flavour
              libglobus_gsi_callback_$flavour libglobus_proxy_ssl_$flavour
              libglobus_gsi_sysconfig_$flavour libglobus_openssl_error_$flavour
              libglobus_gssapi_gsi_$flavour libglobus_gsi_callback_$flavour
              libglobus_oldgaa_$flavour libglobus_gsi_cert_utils_$flavour
              libglobus_openssl_$flavour  libglobus_gsi_proxy_core_$flavour
              libglobus_callout_$flavour  libltdl_$flavour
              libssl_$flavour libcrypto_$flavour"

libglobus_gss_assist > bug #467239
libglobus_gssapi_gsi > bug #467237
libglobus_gsi_credential > bug #453861
libglobus_common > bug #453851
libglobus_gsi_callback, libglobus_globus_oldgaa > bug #453858
libglobus_proxy_ssl > bug #453854
libglobus_gsi_sysconfig > bug #453857
libglobus_openssl_error > bug #453853
libglobus_gsi_cert_utils > bug #453856
libglobus_openssl > bug #453855
libglobus_gsi_proxy_core > bug #453862
libglobus_callout > bug #467235
libltdl > bug #453849 (GPT wrapper for the system version - already approved)
libssl, libcrypto > bug #453850 (GPT wrapper for the system version)

The configure script also looks for the grid-proxy-init binary - this is available in > bug #453865
Comment 19 Thomas Spura 2009-03-21 13:22:35 EDT
Hi,

I just asked on fedora-legal-list about the licence of the fonts within root:

It's not a 'Good Licence', so possibly there is no chance of a positive review!!!

It could be a solution, if we use the X11 Rendering and not the truetypes.

In scientificlinux this package is called 'cernroot'. I like this name, because there is also a cernlibs package in fedora. Consider a rename ;-)

I have tried to build my on root.spec with much more enabled features, but am not yet ready to publish it. I'll do so, if it's finished…



ATM %dir %{_datadir}/root/fonts does not work as a result of the bad licence…
Comment 20 Thomas Spura 2009-03-21 14:12:23 EDT
I'm giving up for now...

This is my fist try to create a .spec.

Earlier, I had anything in one package, and installing and running worked.
Now to fullfil the guidelines, I had tried to create a -devel package, too. This spec is not working anymore, but maybe you can get some usefull parts of it...

http://www.students.uni-mainz.de/spurath/public/fedora/root.spec
Comment 21 juanucleus@gmail.com 2009-03-21 14:40:42 EDT
Hi,

So true type fonts are not allowed at all, or just not the MS ones?

At some point I found the place where the fonts are called, and I patched the code so that it can call the Liberation Fonts instead. It seemed to have worked, and then I just removed the MS fonts from the package.

Is this not an option, according to the legal team?

--Juan Carlos
Comment 22 Thomas Spura 2009-03-21 16:25:45 EDT
(In reply to comment #21)
> So true type fonts are not allowed at all, or just not the MS ones?
> 

The MS ones have a 'Bad Licence'. They are not allowd, any other true type fonts with a 'Good Licence' should be allowd.

> At some point I found the place where the fonts are called, and I patched the
> code so that it can call the Liberation Fonts instead. It seemed to have
> worked, and then I just removed the MS fonts from the package.

perfect ;-)
 
> Is this not an option, according to the legal team?

I did't tell them the context, only asked if the MS licence in the folder of the fonts is a 'Good Licence' -> No.
After removing them, anything else should be allowed (-> completely GPLv2 AFAIK)

  Thomas
Comment 23 Joseph Smidt 2009-03-21 18:23:50 EDT
> At some point I found the place where the fonts are called, and I patched the
> code so that it can call the Liberation Fonts instead. It seemed to have
> worked, and then I just removed the MS fonts from the package.

Do you still have the patch to do this?  This, and building on F11 with the gcc-4.4 compilers is what's holding me up.
Comment 24 Thomas Spura 2009-05-12 19:32:15 EDT
Any update on this?
Comment 25 Mattias Ellert 2009-05-25 22:40:51 EDT
(In reply to comment #18)
> The root configure file lists these globus libraries:
> 
>    globuslibs="libglobus_gss_assist_$flavour libglobus_gssapi_gsi_$flavour
>               libglobus_gsi_credential_$flavour libglobus_common_$flavour
>               libglobus_gsi_callback_$flavour libglobus_proxy_ssl_$flavour
>               libglobus_gsi_sysconfig_$flavour libglobus_openssl_error_$flavour
>               libglobus_gssapi_gsi_$flavour libglobus_gsi_callback_$flavour
>               libglobus_oldgaa_$flavour libglobus_gsi_cert_utils_$flavour
>               libglobus_openssl_$flavour  libglobus_gsi_proxy_core_$flavour
>               libglobus_callout_$flavour  libltdl_$flavour
>               libssl_$flavour libcrypto_$flavour"
> 
> libglobus_gss_assist > bug #467239
> libglobus_gssapi_gsi > bug #467237
> libglobus_gsi_credential > bug #453861
> libglobus_common > bug #453851
> libglobus_gsi_callback, libglobus_oldgaa > bug #453858
> libglobus_proxy_ssl > bug #453854
> libglobus_gsi_sysconfig > bug #453857
> libglobus_openssl_error > bug #453853
> libglobus_gsi_cert_utils > bug #453856
> libglobus_openssl > bug #453855
> libglobus_gsi_proxy_core > bug #453862
> libglobus_callout > bug #467235
> libltdl > bug #453849 (GPT wrapper for the system version)
> libssl, libcrypto > bug #453850 (GPT wrapper for the system version)
> 
> The configure script also looks for the grid-proxy-init binary - this is
> available in > bug #453865  

All done!!!
Comment 26 Orcan Ogetbil 2009-06-10 16:55:43 EDT
May I ask: Who is working on this package? juanucleus? Joseph? Kostas? Thomas? Jochen? I have a feeling that everybody is waiting for someone to step forward.

If anyone points to a SPEC file that we can proceed from, I'd be grateful. There are a few SPEC files posted above but I don't know who want(s) to be the maintainer(s).

Please don't be afraid to raise your hand.
Comment 27 Thomas Spura 2009-06-11 09:04:21 EDT
I'm not yet that familiar with creating SPECs, but am free to help this getting packaged.

Juanucleus patch is needed, in order the true type fonts to replace, because they are not allowed to get shipped in fedora…

That's probably the main reason nothing is habbening here ;-)

     Thomas
Comment 28 Suvayu 2009-06-11 23:33:09 EDT
Hi,

I have been following this bug but I have no experience in packaging. So I posted to the project mailing list. The developers replied back about some of the issues discussed here (e.g. CINT). They also mentioned they will be able to help if someone takes this up with the developer team at rootdev@root.cern.ch or on their bug-tracker at https://savannah.cern.ch/projects/savroot/ .

I am quoting the email below. Maybe this will help someone.

- Suvayu

*** quote begins ***

Hi Suvayu,

a few commentes:
* CINT needs the include files in cint/cint/include at runtime. They are not build time include files (those are in cint/cint/inc) - think of them as something to be put in /usr/share/root.

* ROOT does not use the stand-alone CINT binary; we split them intentionally also to allow package maintainers to produce CINT and ROOT packages without overlap.

* ROOT is part of Debian, so you might want to contact "them" for the design they used. They managed to create ROOT modules like this (output from apt-get install root-<tab>, so some might be bogus):

root-db-client        root-plugin-gl        root-plugin-netx root-plugin-ruby      root-system-bin
root-file-server      root-plugin-hbook     root-plugin-odbc root-plugin-sql       root-system-common
root-fitter           root-plugin-krb5      root-plugin-peac root-plugin-tmva      root-system-doc
root-glviewer         root-plugin-ldap      root-plugin-pgsql root-plugin-unuran    root-system-proofd
root-plugin-asimage   root-plugin-mathmore  root-plugin-proof root-plugin-xml       root-system-rootd
root-plugin-clarens   root-plugin-minuit    root-plugin-python root-plugin-xproof    root-system-xrootd
root-plugin-eve       root-plugin-minuit2   root-plugin-qt root-proofd           root-tail
root-plugin-fftw3     root-plugin-mlp       root-plugin-quadp        root-ttf
root-plugin-fumili    root-plugin-mysql     root-plugin-roofit root-system

* ROOT in Debian is a proof that there are no licensing issues ;-)

* You won't have fun with your build result if you use the fedora default libAfterImage. We use the bleeding edge one all the time, basically because we are one of its main drivers for development. You have been warned :-)

* Christian Holm Christensen <cholm@nbi.dk> is our packaging guru, as you were probably able to tell looking at $ROOTSYS/build/package/rpm/spec.in.

Cheers, Axel.
Comment 29 Thomas Spura 2009-06-12 07:33:20 EDT
I emailed Christian Holm Christensen for changing some parts in the spec-file, in order it is alowed here in fedora…

Just want to say, I am on it again ;-)

The drafts I'm working on now are at:

http://www.students.uni-mainz.de/spurath/public/cernroot/root.spec
http://www.students.uni-mainz.de/spurath/public/cernroot/root_v5.22.00.source.tar.gz


I hope over the weekend my part will be finished, and I'll wait for Christians answer.



Can someone confirm
"* ROOT in Debian is a proof that there are no licensing issues ;-)"
from the last comment?

The fonts should still NOT be allowed in fedora...
Comment 30 Kostas Georgiou 2009-06-12 09:20:34 EDT
Thomas this spec doesn't have any -devel -libs etc. subpackages, it doesn't even deal with the fonts really, it just removes them and adds a requires: root-ttf.

For libAfterImage the version in f10 and in root are both 1.18 so I don't see an issue there.

For the font side now, just removing the ms fonts last time I checked doesn't stop the X interface from working (freetype is used which deals with it) BUT the postscript output was broken since it needs the MS .ttf files. Looking at the code (graf2d/graf/src/TTF.cxx) it looks like the code also looks for free versions for some of the fonts (FreeMono.ttf, ...) so removing the MS ones and replacing them with the free ones should work. The liberation fonts probably provide a better solution so patching the code to add them is a also good idea.
Not sure where we can get symbol.ttf though. I'll try to find someone from the Fonts SIG to have a look at this.
Comment 31 Thomas Spura 2009-06-12 10:41:50 EDT
(In reply to comment #30)
> Thomas this spec doesn't have any -devel -libs etc. subpackages, it doesn't
> even deal with the fonts really, it just removes them and adds a requires:
> root-ttf.

Yes, atm I try to compile with the .spec file provided by the root developer themselves. I'll talk with them to add -devel and so on for unity purpos.
Right now 5.22 and 5.23 won't compile, maybe because of gcc 4.4, they don't seem to use it…

As already mentioned, I'm new to packaging. It will probably take the weekend till I have usefull results and will notice you here again...
Comment 32 Thomas Spura 2009-06-12 13:06:16 EDT
ATM I have some troubles to compile even with the original .spec.

It does not make any sence to continue now, till I get answer from the root devels. Is there anyone else working on this? Maybe we can stick together. Kostas?

Here is the bug I opened upstream
https://savannah.cern.ch/bugs/?func=detailitem&item_id=51747
Comment 33 Nicolas Mailhot 2009-06-13 04:31:42 EDT
(In reply to comment #0)

> 4) Not an issue, but I will mention it upfront. Upstream includes the MS
> TrueType fonts 

The licensing of those fonts does not comply with our guidelines
http://fedoraproject.org/wiki/Packaging:FontsPolicy#Legal_considerations
We basically require the same freedom to distribute and modify of our fonts than of our software.

Also, even if they did, we'd ask to locate the font upstream and package it separately
http://fedoraproject.org/wiki/Packaging:FontsPolicy#Package_layout_for_fonts

Bundling fonts is prohibited. Fonts must be split out cleanly so they can be installed separately and reused by other packages

Also, when a project relies on default fonts from another OS or Linux distribution, you have to ask yourself if the look, feel and metrics of those fonts is required before hunting for the closest substitute. If the software does not rely on some exact font characteristic, reconfiguring it to use Fedora default fonts instead is much preferred.

The Liberation fonts are metrically-equivalent to some MS fonts. However they are *not* our default font, so forcing their use will make your application stand out in Fedora. Also they have a lot less Unicode coverage than Dejavu Fonts.

GNU free fonts are not installed at all by default in Fedora and are not present on liveCDs and other physical distribution media.


http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)#What_if_my_package_bundles_Bitstream_Vera.2C_Arev.2C_DejaVu_LGC_or_another_Bitstream_Vera_font_derivative.3F
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)#What_if_my_package_bundles_FreeSans.2C_Linux_Libertine.2C_Droid_or_Liberation_fonts.3F
A lot of the symbols in symbol.ttf have long been attributed standard unicode values. If this software properly references those symbols by their unicode codepoint (and not the old legacy symbol-specific codepoint) any unicode font with coverage of the associated unicode blocks will work for you (DejaVu includes most common symbols). If this is not good enough for you, you can look at openoffice's opensymbol (and open a bug dejavu-side to request the missing symbol).

Lastly, if you have all those problems, that's probably because this software does not use fontconfig. Fontconfig has been the default font management stack for many years on modern Unixes and anything using X. It will locate for you the most appropriate installed font transparently. Using something else is broken by design nowadays, and you'll have no end of font-related problems till the software is switched to use fontconfig (unlike under windows, the font complement varies from Unix to Unix and release to release, Unix font Unicode coverage is not and won't ever be exactly the same as windows fonts, etc).

The only correct mid-term solution is getting this software ported to fontconfig, usually using a higher-level library like pango-cairo. (and if it manages PDFs is should probably take a look at poppler too)
Comment 34 Kostas Georgiou 2009-06-15 07:48:27 EDT
The software does use fontconfig so the X side is OK AFAIK, the problem is in GL/postscript output.

The major places that ttf files are requested directly that I can see are in:
http://root.cern.ch/viewvc/trunk/graf2d/graf/src/TTF.cxx where freetype is used to load a font by path/name or number (MS with fallback to Free fonts). 
http://root.cern.ch/viewvc/trunk/graf3d/gl/src/TGLText.cxx where ftgl is used to load a font by fontnumber (table uses only MS fonts).
Comment 35 Kostas Georgiou 2009-06-15 08:24:30 EDT
sorry I was wrong root uses freetype but not fontconfig, so as I see it the plan should be
* quick solution: point root to the DejaVu fonts and check that it still works OK
* add fontconfig support
Comment 36 Jason Tibbitts 2009-07-14 14:31:00 EDT
This whole thing seems to be a mess.  The original submitter seems to be long gone and whatever pacakges I can see don't seem to be ready for a review.  I'm going to remove this package from the review queue, but you folks are welcome to keep this ticket open to work on the package.

I would suggest opening a new review ticket when you have a package that's ready to be reviewed, so that the history in this ticket doesn't confuse anyone.
Comment 37 Thomas Spura 2009-07-29 15:54:49 EDT
Continuing the mess ;-)

I've started from scratch and completely deleted the fonts from root. When starting there is an error: 
"""
Couldn't find font "-adobe-helvetica-medium-r-*-*-10-*-*-*-*-*-iso8859-1",
trying "fixed". Please fix your system so helvetica can be found, 
this font typically is in the rpm (or pkg equivalent) package 
XFree86-[75,100]dpi-fonts or fonts-xorg-[75,100]dpi.
/usr/bin/root.exe: error while loading shared libraries: libCore.so.5.24: cannot open shared object file: No such file or directory
"""
Installing of xorg-fonts-[75,100]dpi doesn't work...

I paste here the the url of my actual spec and srpm, after all problems are resolved, I'll open a new review ticket to not confuse anyone as suggested in comment #36 from Jason.



SPEC: http://student.physik.uni-mainz.de/~spurath/fedora/root.spec

SRPM: http://student.physik.uni-mainz.de/~spurath/fedora/root-5.24.00-1.fc11.src.rpm
Comment 38 Thomas Spura 2009-10-08 20:28:45 EDT
I won't work much on this in the near future, because of the problems above…

The one, who wants to continue can start within a new bug report.
-> Closing
Comment 39 Peter Lemenkov 2009-12-01 10:05:34 EST

*** This bug has been marked as a duplicate of bug 542990 ***
Comment 40 Daniel Walsh 2010-04-29 14:06:22 EDT
*** Bug 587358 has been marked as a duplicate of this bug. ***