Bug 166414

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

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? 
 

(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

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

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.

Created attachment 118422 [details]
diff for the spec file

Created attachment 118423 [details]
in gracerc path for fdf2fit should be in bin not auxiliary

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.

Created attachment 118425 [details]
file explaining the licence agreement for cephes

Created attachment 118426 [details]
the licence of cephes

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. 

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

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?

(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 
  

Now you should add:

Requires: nedit

Doh, you are rigth. :-)  
 
http://www.fc.up.pt/pessoas/jamatos/fedora-extras/grace.spec   
http://www.fc.up.pt/pessoas/jamatos/fedora-extras/grace-5.1.18-6.src.rpm 
 
New version with thix fixed.- 

The srpm leads to 404 not found...

Oops, wrong copy and paste. 
Now it is fixed. 

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.

Can't we include pdf support via pdflib-lite?  This is how it is build on 
biorpms. 

No. PDFlib has an incompatible license with FE. :/

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

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.

I mean I agree about them being ignorable.

Why not just move the files those locations rather than symlink at all?

Are you sure about pdflib?  I am using pdflib-lite, which has IIRC more 
liberal licensing than pdflib. 
 

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?

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

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.

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

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.

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

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

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.

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. 

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.

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

Created attachment 122948 [details]
spec file diff (licence and config in /etc)

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. 
 

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.  

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.

For FC-3 I get 
 
Job failed on arch x86_64 
... 
No Package Found for gcc-gfortran 

(In reply to comment #42)
> No Package Found for gcc-gfortran 

Read comment 41 again :).  It's gcc4-gfortran, not gcc-gfortran on FC3.

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

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.

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. 

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

cvs done.

Request for a new RHEL 6 EPEL branch

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.

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