Bug 166414 - Review Request: grace (Numerical Data Processing and Visualization Tool)
Review Request: grace (Numerical Data Processing and Visualization Tool)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
David Lawrence
http://plasma-gate.weizmann.ac.il/Grace/
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-08-20 15:34 EDT by José Matos
Modified: 2011-06-01 11:11 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-10 06:45:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kevin: fedora‑cvs+


Attachments (Terms of Use)
diff for the spec file (2.37 KB, patch)
2005-09-03 14:18 EDT, Patrice Dumas
no flags Details | Diff
in gracerc path for fdf2fit should be in bin not auxiliary (444 bytes, patch)
2005-09-03 14:22 EDT, Patrice Dumas
no flags Details | Diff
file explaining the licence agreement for cephes (1.88 KB, text/plain)
2005-09-03 16:19 EDT, Patrice Dumas
no flags Details
the licence of cephes (192 bytes, text/plain)
2005-09-03 16:20 EDT, Patrice Dumas
no flags Details
spec file diff (licence and config in /etc) (2.11 KB, patch)
2006-01-09 09:53 EST, Patrice Dumas
no flags Details | Diff

  None (edit)
Description José Matos 2005-08-20 15:34:38 EDT
Spec Name or Url: http://www.fc.up.pt/pessoas/jamatos/grace.spec
SRPM Name or Url: http://www.fc.up.pt/pessoas/jamatos/grace-5.1.18-1.src.rpm
Description: 
Grace is a Motif application for two-dimensional data visualization.
Grace can transform the data using free equations, FFT, cross- and
auto-correlation, differences, integrals, histograms, and much more. The
generated figures are of high quality.  Grace is a very convenient tool
for data inspection, data transformation, and and for making figures for
publications.
Comment 1 Ed Hill 2005-08-20 16:00:49 EDT
Hi Jose, I took a quick look at grace and, though it did build, rpmlint throws 
up a number of complaints:

W: grace devel-file-in-non-devel-package /usr/share/grace/auxiliary/convcal.c
W: grace dangling-symlink /usr/share/grace/bin /usr/bin
W: grace symlink-should-be-relative /usr/share/grace/bin /usr/bin
W: grace devel-file-in-non-devel-package /usr/share/grace/examples/tmc.c
E: grace non-executable-script /usr/share/grace/doc/shiftdata.sh 0644
W: grace non-conffile-in-etc /etc/profile.d/grace.csh
E: grace non-executable-script /etc/profile.d/grace.csh 0644
W: grace non-conffile-in-etc /etc/profile.d/grace.sh
E: grace non-executable-script /etc/profile.d/grace.sh 0644
E: grace no-prereq-on chkfontpath
E: grace no-prereq-on chkfontpath

W: grace-devel dangling-symlink /usr/share/grace/lib /usr/lib
W: grace-devel symlink-should-be-relative /usr/share/grace/lib /usr/lib
W: grace-devel dangling-symlink /usr/share/grace/include /usr/include
W: grace-devel symlink-should-be-relative /usr/share/grace/include /usr/include
Comment 2 José Matos 2005-08-20 16:31:14 EDT
Thanks Ed,      
    yes I am aware of rpmlint output. By parts;      
      
dangling-symlink warnings:     
The upstream package insists in having a structure like this:     
     
path_to_package:     
  bin     
  include     
  lib     
  ...     
     
The symbolic links allow us to keep that structure and to follow the usual     
structure for packaging.     
     
/etc/profile.d/ warnings:    
All files in there will be read from other files, so there is no need for them    
to executable.    
    
devel-file-in-non-devel-package   
  those are examples, I am not sure if their number justify another   
subpackage.   
  
 no-prereq-on chkfontpath 
 this seems bogus as  chkfontpath is only used at install time, there is no 
need to require it chkfontpath at building time, or there is? 
 
Comment 3 Paul Howarth 2005-08-21 14:17:47 EDT
(In reply to comment #2)
>  no-prereq-on chkfontpath 
>  this seems bogus as  chkfontpath is only used at install time, there is no 
> need to require it chkfontpath at building time, or there is? 

chkfontpath is used in your %post and %postun scripts. Therefore I think you
should have:

Requires(post): chkfontpath
Requires(postun): chkfontpath
rather than just:
Requires: chkfontpath

I think that's what rpmlint is alluding to.

If the desktop file specifies a MIME type (I don't know if it does), you'd need
to run update-desktop-database too - see the scriptlets page at
http://fedoraproject.org/wiki/ScriptletSnippets


Comment 4 José Matos 2005-08-21 17:22:10 EDT
(In reply to comment #3)   
>    
> chkfontpath is used in your %post and %postun scripts. Therefore I think you   
> should have:   
>    
> Requires(post): chkfontpath   
> Requires(postun): chkfontpath   
> rather than just:   
> Requires: chkfontpath   
> 
> I think that's what rpmlint is alluding to.   
   
  You are right, of course, I have fixed that in the new version.   
  
http://www.fc.up.pt/pessoas/jamatos/grace.spec 
http://www.fc.up.pt/pessoas/jamatos/grace-5.1.18-2.src.rpm 
 
> If the desktop file specifies a MIME type (I don't know if it does), you'd   
need   
> to run update-desktop-database too - see the scriptlets page at   
> http://fedoraproject.org/wiki/ScriptletSnippets   
 
  No it does not. Thanks for the advice I will remember next I have a case 
like that.   
Comment 5 Patrice Dumas 2005-09-03 14:17:14 EDT
Some remarks/suggestions

* convcal.c is not an example file but a source file so it seems better not to 
  package it
* the library is LGPL and not GPL
* Xbae has a BSD licence that should be included
* man pages are duplicated in doc directory and at their normal place
* doc/ and examples/ are better in %doc than in /usr/share/grace
* the path to fdf2fit in gracerc seems wrong to me, it should be in bin/ not in
auxiliary/
* I think it is better to add the netcdf directory --with-extra-ldpath than to
hardcode the netcdf library, such that if the netcdf library is turned into a
dynamic library things will still be right.

I attach a diff for the spec file implementing thoses suggestions, and a patch.
Comment 6 Patrice Dumas 2005-09-03 14:18:24 EDT
Created attachment 118422 [details]
diff for the spec file
Comment 7 Patrice Dumas 2005-09-03 14:22:55 EDT
Created attachment 118423 [details]
in gracerc path for fdf2fit should be in bin not auxiliary
Comment 8 Patrice Dumas 2005-09-03 16:17:39 EDT
There is no licence information for cephes and on the website it doesn't seems
to be free software. However the debian maintainer contacted the author who
accepted to relicence the code for the projects. So I propose to include the two
files I attach in the srpm.
Comment 9 Patrice Dumas 2005-09-03 16:19:24 EDT
Created attachment 118425 [details]
file explaining the licence agreement for cephes
Comment 10 Patrice Dumas 2005-09-03 16:20:42 EDT
Created attachment 118426 [details]
the licence of cephes
Comment 11 José Matos 2005-09-08 13:16:42 EDT
Patrice,  
  thanks for your comments, I will look to them and I will try to incorporate 
the changes you proposed in a new version of the spec file soon. 
Comment 12 José Matos 2005-09-09 06:01:02 EDT
New version: 
 
http://www.fc.up.pt/pessoas/jamatos/fedora-extras/grace.spec 
http://www.fc.up.pt/pessoas/jamatos/fedora-extras/grace-5.1.18-4.src.rpm 
 
* Fri Sep  9 2005 Jose Matos <jamatos@fc.up.pt> - 5.1.18-4 
- Add license to cephes library as well as the original mail where permission 
is given. 
- Move permission of profile.d files from 644 to 755. 
 
Comment 13 Patrice Dumas 2005-09-13 03:24:04 EDT
The buildroot is not the preferred one.

gedit is specified as an editor, but the package containing gedit isn't
required. The issue with gedit is that it requires the gnome stuff in turn. I
think that the default editor should be an editor similar with gedit but with
fewer dependencies. I don't know which editor suits that purpose (I use vi but I
think it is a bad choice...). Maybe nedit?
Comment 14 José Matos 2005-09-13 06:19:13 EDT
(In reply to comment #13)  
> The buildroot is not the preferred one.  
  
  You are right, fixed now.  
  
> gedit is specified as an editor, but the package containing gedit isn't  
> required. The issue with gedit is that it requires the gnome stuff in turn.  
> I think that the default editor should be an editor similar with gedit but  
> with fewer dependencies. I don't know which editor suits that purpose  
> (I use vi but I think it is a bad choice...). Maybe nedit?  
  
  Well thought, the advantage of nedit is that it requires motif as well so  
we minimise the dependencies as you suggested. :-)  
  
  New versions available: 
 
http://www.fc.up.pt/pessoas/jamatos/fedora-extras/grace.spec  
http://www.fc.up.pt/pessoas/jamatos/fedora-extras/grace-5.1.18-5.src.rpm 
  
Comment 15 Patrice Dumas 2005-09-14 01:49:39 EDT
Now you should add:

Requires: nedit

Comment 17 Patrice Dumas 2005-09-20 10:51:00 EDT
The srpm leads to 404 not found...
Comment 18 José Matos 2005-09-20 11:03:18 EDT
Oops, wrong copy and paste. 
Now it is fixed. 
Comment 19 Ed Hill 2005-10-10 13:30:48 EDT
Hi folks,

Heres a quick-ish review:

needswork:
 - rpmlint complains about soft links:

   W: grace dangling-symlink /usr/share/grace/bin /usr/bin
   W: grace symlink-should-be-relative /usr/share/grace/bin /usr/bin
   ...
   W: grace-devel dangling-symlink /usr/share/grace/include 
      /usr/include
   W: grace-devel symlink-should-be-relative /usr/share/grace/include
      /usr/include

   which could be converted to relative links which would remove half
   of the warnings

OK:
 - source matches upstream
 - naming and spec look good
 - license looks OK and is in %doc
 - builds in mock on FC4
 - runs without segfaulting
 - code not content OK
 - desktop-file-install looks OK

and I don't see any blockers.  Since Patrice seems to have done most 
of the actual review work I think he deserves to be the reviewer!  We've
discussed on the extras mailing list how to get the bugzilla permissions
for that so he should be able to do it.

And if Patrice can't be the formal reviewer then someone please ping me 
this coming weekend and I'll approve it.
Comment 20 Neal Becker 2005-10-10 13:47:39 EDT
Can't we include pdf support via pdflib-lite?  This is how it is build on 
biorpms. 
Comment 21 Tom "spot" Callaway 2005-10-10 14:01:22 EDT
No. PDFlib has an incompatible license with FE. :/
Comment 22 José Matos 2005-10-10 14:05:49 EDT
(In reply to comment #19)   
> Hi folks,   
>    
> Heres a quick-ish review:   
>    
> needswork:   
>  - rpmlint complains about soft links:   
>    
>    W: grace dangling-symlink /usr/share/grace/bin /usr/bin   
>    W: grace symlink-should-be-relative /usr/share/grace/bin /usr/bin   
>    ...   
>    W: grace-devel dangling-symlink /usr/share/grace/include    
>       /usr/include   
>    W: grace-devel symlink-should-be-relative /usr/share/grace/include   
>       /usr/include   
>    
>    which could be converted to relative links which would remove half   
>    of the warnings   
   
  Are you implying that /usr/bin and /usr/include could not be present in   
a system where we are installing the package? :-)  
  
  I think that those warnings are bogus and should be ignored.  
    
> and I don't see any blockers.  Since Patrice seems to have done most    
> of the actual review work I think he deserves to be the reviewer!  We've   
> discussed on the extras mailing list how to get the bugzilla permissions   
> for that so he should be able to do it.   
  
  That is fair. :-)  
  
> And if Patrice can't be the formal reviewer then someone please ping me    
> this coming weekend and I'll approve it.   
   
  I will do it if necessary. Thanks. 
Comment 23 Michael A. Peters 2005-10-10 14:25:11 EDT
I agree about the rpmlint warnings.
Relative path symlinks could break with a change to %_bindir or %_datadir unless
you scripted a way to take both as arguements and create a relative path.

Full path symlinks would not break as long as %_bindir is used when the link is
made.
Comment 24 Michael A. Peters 2005-10-10 14:25:52 EDT
I mean I agree about them being ignorable.
Comment 25 Tom "spot" Callaway 2005-10-10 14:53:52 EDT
Why not just move the files those locations rather than symlink at all?
Comment 26 Neal Becker 2005-10-10 15:00:11 EDT
Are you sure about pdflib?  I am using pdflib-lite, which has IIRC more 
liberal licensing than pdflib. 
 
Comment 27 Michael A. Peters 2005-10-10 15:25:56 EDT
I should do a closer inspection - but the included fonts look like what is
already packaged in Core in the urw-fonts package - which is in the xfs fontpath
already.

Do they need to be packaged here, or would simply

Requires: urw-fonts

suffice?
Comment 28 Michael A. Peters 2005-10-10 15:30:53 EDT
(In reply to comment #26)
> Are you sure about pdflib?  I am using pdflib-lite, which has IIRC more 
> liberal licensing than pdflib. 
>  

Here is information on pdflib-lite

http://www.pdflib.com/purchase/license-lite.html

I think it is worth asking the lawyers - because it looks like it could be
included to me.

-=-
# PDFlib Lite can be used for free if you are an open source developer. This
means that you must disclose the full source code of your project, and make it
available under an OSI-approved open source license (see www.opensource.org).
Note that "full source code" includes all components of the project, not only
those which are directly attached to PDFlib Lite.
# PDFlib Lite can be used for free if you are a private user.
# PDFlib Lite can be used for free if you are a research user.

# PDFlib Lite source code may be redistributed. If modifications have been made
these must be clearly marked as such.
# PDFlib Lite may be redistributed in binary (compiled) form provided the
license, documentation, and programming samples are also included.
Alternatively, the documentation may be made available for free download instead
of including it.
Comment 29 Michael A. Peters 2005-10-10 15:59:16 EDT
Upon closer inspection - the fonts in this package are in fact just a subset of
the fonts provided by urw-fonts. Font names match when viewed in a font viewer,
filenames match exactly as well.
Comment 30 Tom "spot" Callaway 2005-10-10 17:04:04 EDT
(In reply to comment #28)
> (In reply to comment #26)
> > Are you sure about pdflib?  I am using pdflib-lite, which has IIRC more 
> > liberal licensing than pdflib. 
> >  
> 
> Here is information on pdflib-lite
> 
> http://www.pdflib.com/purchase/license-lite.html

But you can't use it in a commercial setting. Thus it is a "non-commercial use
only" license, which is not permissable for Fedora Extras. If it was dual
licensed with the pdflib-lite license and something without a use restriction...
(e.g. mysql), but it isn't.

Sorry... I know it would be mighty useful.
Comment 31 Michael A. Peters 2005-10-10 17:06:28 EDT
In playing with a little - it does run without the bin and lib symlinks.
It does not run without the type directory in fonts, but does if that is
symlinked to /usr/share/fonts/default/Type1

It *would be nice* if it didn't expect the fonts to be within its datadir
directory but could find the fonts it wants through fontconfig or xfs.
Comment 32 Patrice Dumas 2005-10-18 04:44:43 EDT
(In reply to comment #24)
> I mean I agree about them being ignorable.

I think that they should be left only if there is a use for those symlinks.I
don't think the symlinks to lib and include are usefull. However, from a glance
at the code it seems possible that the symlink to bin is usefull to find the
grace executable itself when started from the library.

The other symlinks may be important if it is customary to use the GRACE_HOME
variable when linking against the grace library and with the include files _and_
the grace library and include files are not in the system dirs, but it isn't the
case as they are in the system dirs. 

What are your opinions on that?
Comment 33 Patrice Dumas 2005-10-18 04:56:30 EDT
(In reply to comment #31)
> In playing with a little - it does run without the bin and lib symlinks.
> It does not run without the type directory in fonts, but does if that is
> symlinked to /usr/share/fonts/default/Type1

I think doing that symlink would be better than using the fonts provided with
grace as there are more fonts in the urw package.

> It *would be nice* if it didn't expect the fonts to be within its datadir
> directory but could find the fonts it wants through fontconfig or xfs.

Somebody should report that upstream...
Comment 34 Patrice Dumas 2005-10-18 05:05:50 EDT
There are some config files in GRACE_HOME, that breaks the FHS. I think there
should be a grace directory in %_sysconfdir, and gracerc, templates,
gracerc.user, fonts/FontDataBase should be copied to that directory and
symlinked from the  GRACE_HOME directory.
Comment 35 José Matos 2005-10-24 14:36:44 EDT
My question regarding grace process is: Do I need to fix all the raised issues 
at once or is it possible to get grace in Extras and then fix those issues? 
 
I do prefer to have incremental steps instead of going and the way in a big 
jump. 
 
It becomes then easier to report some of those issues upstream. 
Comment 36 Patrice Dumas 2005-10-25 03:38:51 EDT
I think that the issue raised by my comment #34 should be taken into account
before importing grace, because it may be problematic for those who mount
/usr/share read-only. The comment #32 and comment #33 issues could be handled
after import into extras. So please put the config files in /etc and I'll do the
final formal review and accept the package.
Comment 37 Patrice Dumas 2006-01-09 09:52:45 EST
I made a patch to put conf files in /etc. 
I also modified the license such that it is only GPL and not BSD/GPL as BSD/GPL
could be interpreted as if it was dual licenced and it is not the case. I added
a comment to explain that Xbae is BSD and cephes is LGPL.

With that patch applied here is the review:

- rpmlint gives:
W: grace dangling-symlink /usr/share/grace/bin /usr/bin
W: grace symlink-should-be-relative /usr/share/grace/bin /usr/bin
W: grace-devel dangling-symlink /usr/share/grace/lib /usr/lib
W: grace-devel symlink-should-be-relative /usr/share/grace/lib /usr/lib
W: grace-devel dangling-symlink /usr/share/grace/include /usr/include
W: grace-devel symlink-should-be-relative /usr/share/grace/include /usr/include

this should be ignored
- package name follows the guidelines
- spec file is grace.spec
- package meets the packaging guidelines
- licences are compatible with fedora extras, licence files are included
- licence (GPL) matches the package licence
- spec is in legible american english
- sources match upstream
- builds in FC-4 mock
- right BuildRequires
- no shared libs
- not relocatable
- owns all the non FHS directories
- no duplicate in %files
- correct defattr
- rm -rf %{buildroot} in %clean
- consistent use of rpm macros
- no need to split doc to another package
- docs don't affect runtime
- headers and static libs in a devel subpackage
- use a fully versionned Requires for base package in devel package
- desktop file is present

APPROVED
Comment 38 Patrice Dumas 2006-01-09 09:53:59 EST
Created attachment 122948 [details]
spec file diff (licence and config in /etc)
Comment 39 José Matos 2006-01-09 11:37:31 EST
Thanks, imported it into cvs with the patch applied. 
 
I will order a build for FC4 and FC3 and rework the X dependencies for devel. 
 
Comment 40 José Matos 2006-01-10 06:45:29 EST
Package built successfully in FC-4. It failed in FC-3 since gfortran 
is not available there and in devel because of xorg new packaging scheme. 
 
I will fix those now.  
Comment 41 Dominik 'Rathann' Mierzejewski 2006-01-10 07:02:45 EST
Of course it is available.

$ yum list '*fortran'
[...]
gcc4-gfortran.i386                       4.0.0-0.41.fc3         updates-released

Good to see this in extras.
Comment 42 José Matos 2006-01-10 14:54:01 EST
For FC-3 I get 
 
Job failed on arch x86_64 
... 
No Package Found for gcc-gfortran 
Comment 43 Ville Skyttä 2006-01-10 15:07:23 EST
(In reply to comment #42)
> No Package Found for gcc-gfortran 

Read comment 41 again :).  It's gcc4-gfortran, not gcc-gfortran on FC3.
Comment 44 José Matos 2006-01-12 06:28:39 EST
It is very difficult to see something that we don't want to see. ;-) 
 
In the case of FC-3 there are two options, either require gcc4-gfortran 
or the solution that I prefer use g77 and require (for building) gcc-g77, 
removing at the same time the line that says that the fortran compiler is 
gfortran. 
 
This is not rocket science. :-) 
Comment 45 Deji Akingunola 2006-01-12 21:55:43 EST
I've succesfully built the devel branch with mock; you only need to replace
xorg-x11-devel with libXpm-devel in the spec's BR. All other X libraries needed
were already being pulled in by other BRs.
Comment 46 José Matos 2006-01-13 12:26:39 EST
Thank you. That was precisely the kind of analysis I was trying to do. 
In this case it was easy due to the number of X components required. :-) 
 
I ordered a build, so now grace should be available also for devel. 
Comment 47 José Matos 2009-03-05 14:42:48 EST
Request for a new EL-4 branch.

New Package CVS Request
=======================
Package Name: grace
Short Description: Numerical Data Processing and Visualization Tool
Owners: jamatos
Branches: EL-4
Comment 48 Kevin Fenzi 2009-03-05 15:58:14 EST
cvs done.
Comment 49 Andy Feldt 2011-04-21 15:43:41 EDT
Request for a new RHEL 6 EPEL branch
Comment 50 José Matos 2011-06-01 07:10:00 EDT
Andy, are you Fedora packager?

If so you could drive this build since at the moment I am very busy and I mostly work with Fedora not *EL.
Comment 51 Andy Feldt 2011-06-01 11:11:43 EDT
José,

No, I am not a Fedora packager.  Nor am I a RHEL packager.
Just a system manager whose users use grace for plotting.

However, I did find that I could take the srpm for grace
from RHEL5 and run rpmbuild --rebuild  on it on a RHEL6
system and it created the .el6. packages without any
tweaking.  (At least for the x86_64 arch which is all
I care about.)

So, it is quite easy to create the rpms for the RHEL6
epel repo...

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