Bug 167253

Summary: Review Request: cernlib - CERN library and associated binaries
Product: [Fedora] Fedora Reporter: Patrice Dumas <pertusus>
Component: Package ReviewAssignee: José Matos <jamatos>
Status: CLOSED NEXTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, k.georgiou
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://cernlib.web.cern.ch/cernlib/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-22 09:16:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 163779    

Description Patrice Dumas 2005-08-31 22:09:03 UTC
SRPM Name or Url: http://www.environnement.ens.fr/docs/fc-srpms/cernlib-2005-1.src.rpm
Description: 

CERN program library is a large collection of general purpose libraries
and modules maintained and offered on the CERN. Most of these programs
were developed at CERN and are therefore oriented towards the needs of a
physics research laboratory that is general mathematics, data analysis,
detectors simulation, data-handling etc... applicable to a wide range
of problems.

The devel packages are parallel installable, but not the helper
scripts from the utils subpackage.

Comment 1 Patrice Dumas 2005-08-31 22:24:40 UTC
This is a very big package and I have a few comments.

I used lots of things from the debian packages. There are a lot of information
at the cernlib on debian faq page: 
http://borex.princeton.edu/~kmccarty/faq.html

The debian patches allowing for dynamic libraries creation haven't been applied. 

The cernlib almost build with gfortran but still fails because of unimplemented
f2c intrinsics. Patches to build with gortran are included and applied anyway.

Patches that solved security issues that have been applied in the previous
cernlib release have been kept, to help people packaging the previous release if
they want to.

The libraries should be parallel installable with each years release, and I
think this is a important feature for some potential users of the cernlib that
relies on older and stable software  still being available. 

The helper build scripts are not paralell installable so I added them to a
separate package I called cernlib-utils. rpmlint complains about that package
depending on a devel package but it seems right to me. It also give
E: cernlib-utils script-without-shellbang /etc/profile.d/cernlib-2005.sh
but the other scripts in /etc/profile.d/ don't have shellbangs.

The source doesn't match the upstream source for some tarballs, as files with
licences incompatible with the GPL are removed. See the debian files for more
information and the comments in the specfile on how to regenerate the modified
sources.

More information in the included cernlib.README 

 

Comment 2 José Matos 2005-09-09 17:39:29 UTC
Compiling the package using mock on x86_64 the compilation fails, where the 
last lines are: 
 
g77 -o pawX11 -O -fno-automatic -fno-second-underscore -fugly-complex  -Wl,-E   
-L/builddir/build/BUILD/cernlib-2005/2005/src/lib 0pamain.o      `cernlib 
pawli 
b graflib/X11 packlib mathlib kernlib`  \ 
 || rm -f pawX11 
/usr/bin/ld: cannot find -lX11 
-L/usr/X11R6/lib 

Comment 3 Patrice Dumas 2005-09-10 17:49:24 UTC
This one should solve that issue

http://www.environnement.ens.fr/docs/fc-srpms/cernlib-2005-2.src.rpm

Comment 4 José Matos 2005-09-11 14:37:30 UTC
Now it compiles with mock in x86_64 but I get: 
 
$ for i in *.rpm; do echo $i; rpmlint $i; echo ; done 
cernlib-2005-2.src.rpm 
W: cernlib strange-permission mkdirhier 0755 
W: cernlib patch-not-applied Patch25: 048-log-to-var-log-not-tmp 
W: cernlib patch-not-applied Patch26: 049-fix-kuesvr-security-hole 
W: cernlib patch-not-applied Patch27: 050-make-secure-comis-tmpdir 
W: cernlib patch-not-applied Patch28: 051-fix-miscellaneous-tmp-uses 
W: cernlib patch-not-applied Patch12: 018-move-kernlib-to-toplevel 
W: cernlib patch-not-applied Patch14: 027-use-tmpfile-not-mktemp 
W: cernlib patch-not-applied Patch36: cernlib-gfortran.diff 
 
cernlib-debuginfo-2005-2.x86_64.rpm 
 
cernlib-devel-2005-2.x86_64.rpm 
 
cernlib-packlib-2005-2.x86_64.rpm 
 
cernlib-utils-2005-2.x86_64.rpm 
E: cernlib-utils devel-dependency cernlib-devel 
W: cernlib-utils no-documentation 
E: cernlib-utils script-without-shellbang /etc/profile.d/cernlib-2005.sh 
 
geant321-2005-2.x86_64.rpm 
E: geant321 devel-dependency cernlib-devel 
W: geant321 no-documentation 
 
kuipc-2005-2.x86_64.rpm 
E: kuipc devel-dependency cernlib-devel 
W: kuipc no-documentation 
 
paw-2005-2.x86_64.rpm 
 
Could you comment these warnings, please? 

Comment 5 Patrice Dumas 2005-09-11 15:06:07 UTC
W: cernlib strange-permission mkdirhier 0755

mkdirhier is a shell script so should be executable

W: cernlib patch-not-applied Patch25: 048-log-to-var-log-not-tmp
W: cernlib patch-not-applied Patch26: 049-fix-kuesvr-security-hole
W: cernlib patch-not-applied Patch27: 050-make-secure-comis-tmpdir
W: cernlib patch-not-applied Patch28: 051-fix-miscellaneous-tmp-uses
W: cernlib patch-not-applied Patch14: 027-use-tmpfile-not-mktemp

Security patches applied in the upstream package, but kept here for reference if
somebody waants to use that spec file template to package an older cernlib
release. It could be a good idea to release more than one cernlib version.

W: cernlib patch-not-applied Patch12: 018-move-kernlib-to-toplevel

this breaks the build, but in my opinion should be applied at some point in the
future.

W: cernlib patch-not-applied Patch36: cernlib-gfortran.diff

patch to use gfortran instead of g77.

cernlib-utils-2005-2.x86_64.rpm
E: cernlib-utils devel-dependency cernlib-devel
The cernlib utils requires a cernlib-devel package so I don't see what is the
probleme. 

W: cernlib-utils no-documentation
not an issue.

E: cernlib-utils script-without-shellbang /etc/profile.d/cernlib-2005.sh
rpmlint error

geant321-2005-2.x86_64.rpm
E: geant321 devel-dependency cernlib-devel
the geant package is only a script used to compile a program with the cernlib
library, so it really depends on cernlib-devel

kuipc-2005-2.x86_64.rpm
E: kuipc devel-dependency cernlib-devel
This one also needs the cernlib library, because it is also used to help
compiling something so requires the cernlib library.




Comment 6 José Matos 2005-09-11 16:32:20 UTC
My remark is mainly oriented towards you previous claim in message #1: 
"Patches to build with gortran are included and applied anyway." 
 
Yet looking to the spec file one patch is not applied. 
 
Regarding all other rpmlint warnings I am convinced. :-)  
  
Notice that %install misses  
rm -rf $RPM_BUILD_ROOT  
  
at its beginning.  
  
One other small note, I think that the description of cernlib-devel should  
mention something regarding its purpose. The usual in any devel paclage. ;-)  
  
The only issue that remains before approving this package it is to verify the 
source integrity, something that will take me some work because of the 
specifics of this package (non free parts in the original source). 
  

Comment 7 Patrice Dumas 2005-09-11 16:58:30 UTC
Oups it was a mistake... The gfortran patch isn't applied, otherwise it wouldn't
build.

I don't really understand your remark about the purpose missing in the devel
package. The description is:

"CERN program library is a large collection of general purpose libraries
and modules maintained and offered on the CERN. Most of these programs
were developed at CERN and are therefore oriented towards the needs of a
physics research laboratory that is general mathematics, data analysis,
detectors simulation, data-handling etc... applicable to a wide range
of problems."

Do you mean that there should be a note saying that these are the static
libraries and headers? I though it needn't be said as there are no shared
libraries... I'll add it anyway.

I'll add the rm -rf $RPM_BUILD_ROOT at the beginning of %install.

Comment 8 José Matos 2005-09-11 17:19:33 UTC
(In reply to comment #7) 
> Oups it was a mistake... The gfortran patch isn't applied, otherwise it 
wouldn't 
> build. 
 
  OK, that makes sense. 
 
> I don't really understand your remark about the purpose missing in the devel 
> package. The description is: 
[...]  
> Do you mean that there should be a note saying that these are the static 
> libraries and headers? I though it needn't be said as there are no shared 
> libraries... I'll add it anyway. 
 
  I am sorry. To understand what I meant please look to the description of 
different libraries and its devel package. For example zlib: 
 
+ zlib 
Zlib is a general-purpose, patent-free, lossless data compression 
library which is used by many different programs. 
 
+ zlib-devel 
The zlib-devel package contains the header files and libraries needed 
to develop programs that use the zlib compression and decompression 
library. 
 
  So what I propose to zlib-devel description is something like: 
he zlib-devel package contains the header files and libraries needed 
to develop programs that use the cernlib library... 
 
  You get the feeling. :-) 
 
  I hope it is clear now. 
 
> I'll add the rm -rf $RPM_BUILD_ROOT at the beginning of %install. 
 
  OK. 
 

Comment 9 José Matos 2005-09-11 17:30:56 UTC
I' sorry for the previous message typos. I suggest for cernlib-devel  
description:  
  
The cernlib-devel package contains the header files and libraries needed  
to develop programs that use the cernlib library...  

Comment 10 Patrice Dumas 2005-09-11 17:46:08 UTC
there is no cernlib main package, so the full description must be present
somewhere, so I added it to the cernlib-devel package. I have added a sentence
similar with yours.

Comment 11 Patrice Dumas 2005-09-11 19:07:43 UTC
Please have a look at:

http://www.environnement.ens.fr/docs/fc-srpms/cernlib-2005-3.src.rpm

Comment 12 José Matos 2005-09-12 09:41:46 UTC
I like it. :-) 
 
There is one last remark (I am sorry for being so picky :-) ), there is 
a line in the spec file: 
 
# extracted from 001-enable-shared-libs 
 
Yet you don't seem to build shared libraries. 
 
What I propose is for this package to follow the convention of all other 
library packages. Place the documentation in the main package, as well as 
the shared libraries, and place the included files and the static libraries 
in the devel package. 
 
You already do the later, I suggest to do also the former. Even although we 
don't ship shared libraries now I expect us to ship them later. This would 
provides us with a natural evolution and it follows the same scheme that 
is used in both Core and Extras packages. 
 
Does this makes sense? 

Comment 13 Patrice Dumas 2005-09-12 10:14:31 UTC
(In reply to comment #12)

> # extracted from 001-enable-shared-libs 
>  
> Yet you don't seem to build shared libraries. 

Yes, but in the debian package shared libraries are built. However in the patch
they mixed things for shared libraries, and removal of reference to not
distributed files, due to licencing issues. As I didn't want to distribute
shared libraries because I think it goes too far from upstream and I am not
enough skilled to reviw their patch with confidence, I had to extract the part
of the patch that does the removal of reference to files with licencing issues.

> You already do the later, I suggest to do also the former. Even although we 
> don't ship shared libraries now I expect us to ship them later. This would 
> provides us with a natural evolution and it follows the same scheme that 
> is used in both Core and Extras packages. 

That's exactly what I did. But as there is no documentation nor shared libraries
the main package is empty (contains no file). Whenever the shared libraries are
built then we could fill the main package. There is no doc because they aren't
free. 



Comment 14 José Matos 2005-09-12 12:09:21 UTC
(In reply to comment #13) 
> As I didn't want to distribute 
> shared libraries because I think it goes too far from upstream 
 
  The support is already there from upstream. As far as I have read the 
patches in the debian package they simply use that ability already provided 
upstream. 
 
# DP: Actually implement the rules to create shared libraries. 
 
> and I am not 
> enough skilled to reviw their patch with confidence, I had to extract the 
> part of the patch that does the removal of reference to files with licencing 
> issues. 
 
  Please put that patch back. I promise to review it carefully. :-) 
  
> That's exactly what I did. But as there is no documentation nor shared 
> libraries the main package is empty (contains no file). Whenever the 
> shared libraries are built then we could fill the main package. There 
> is no doc because they aren't free. 
 
  Again I was not completely clear here, when I said docs I meant %docs. :-) 
 
  Static libraries are always a liability, they increase the code size and 
add the burden of security risks. That is why I insist here, please don't be 
discouraged by my comments. 
 
I really appreciate the work you have been 
done with this package. My research field lies between mathematics 
and physics so I will be really happy to have cernlib in FE. :-) 

Comment 15 Patrice Dumas 2005-09-12 19:50:05 UTC
I have downloaded the new cernlib patch set, and they splitted the patch
themselves. 

Implementing shared libs is not one patch. There are many patches for the shared
libs targets setup, others that move files around, create dummy files to avoid
issues with binary dependencies, and cernlib and gxint scripts rewrite. It is
not just one patch, but more than 20 ! If you want to review those patches feel
free to do so...

About the security risk the utilities bundled with the cernlib should be
upgraded with the cernlib itself. In my opinion other programs linked against
the cern library won't be used for networking or interaction with the system,
but for maths and generic fortran usage, so I don't think there is a real
security risk. Regarding the size, there is no shared libraries, so no
additionnal space.

My overall point of view it that there are too much changes in the debian
patchset and at that point such changes should be worked out with the upstream
so I am happy if it just works.

Comment 16 José Matos 2005-09-13 09:14:57 UTC
> My overall point of view it that there are too much changes in the debian 
> patchset and at that point such changes should be worked out with the 
> upstream so I am happy if it just works. 
 
That is fair. So let us first get this package in Extras and then work to 
get the shared libraries on. 
 
The only problem that I have now is that I am not able to use the procedure 
described to get new sources without the non-free copyright that match yours. 
 
I have downloaded the sources from CERN yesterday and I run 
cernlib-remove-deadpool there. I don't get the same sources that you have. 
 
The sources that differ are: 
src_car.tar.gz 
src_geant321.tar.gz 
src_graflib.tar.gz 
src_mclibs.tar.gz 
src_packlib.tar.gz 
src_pawlib.tar.gz 
 

Comment 17 Patrice Dumas 2005-09-14 21:21:41 UTC
Yes, it seems that packing the same files twice leads to different archives. So
I believe the only way to check the sources is to untar and do a recursive diff.

Comment 18 José Matos 2005-10-24 18:25:19 UTC
I am sorry for not taking care of this before. 
 
I don't understand what you mean when you say that packaging this twice 
leads to different archives. 
 
I have followed the described procedure and I get the same md5sum no matter 
what the platform I am using. So I don't understand how you get a different 
check sum. 
 
If we sort this issue, I will make a full review. The package seems in the 
right shape to be included I just want to be sure to confirm this step. 

Comment 19 Patrice Dumas 2005-10-25 07:27:37 UTC
If you make an archive of the same directories twice you'll get different
archive files. Here is a session that demonstrate that fact:

[dumas@haydn ~]$ cd tmp/
[dumas@haydn tmp]$ mkdir dir
[dumas@haydn tmp]$ touch dir/file
[dumas@haydn tmp]$ tar czvf dir.tgz dir
dir/
dir/file
[dumas@haydn tmp]$ mv dir.tgz dir1.tgz
[dumas@haydn tmp]$ tar czvf dir.tgz dir
dir/
dir/file
[dumas@haydn tmp]$ cmp dir.tgz dir1.tgz
dir.tgz dir1.tgz differ: char 5, line 1

So after running cernlib-remove-deadpool you won't have the same archives but
you should have the exact same files in the archives.

Comment 20 José Matos 2005-11-14 23:36:05 UTC
Some short notes: 
 
 * change environnement to environment in the spec file, not now just after 
the approval. :-) 
 
 * the difference in the tar files is probably due to the different atimes 
from files. 
 
 * a warning related to the requirement of xorg-x11-devel that will be changed 
soon on development 
 
 

Comment 21 José Matos 2005-11-15 09:40:53 UTC
Needs work: 
* Missing SMP flags. If it doesn't build with it, please add a comment 
  (wiki: PackagingGuidelines#parallelmake) 
* Spec file: some paths are not replaced with RPM macros 
  (wiki: QAChecklist item 7) 
* Build failed in mock 
 
It is easy to spot the problem, since you created the src.rpm blas and 
lapack have changed and no longer have the devel part 
 
The fix is simply to replace them in BuildRequires with their devel 
counterpart. 
 
I have noticed that in the build log I see lots of cases like this: 
 
Makefile:454: archive/hadjust.d: No such file or directory 
 
and 
 
Argument #4 of `hptit' is one type at (2) but is some other type at (1) [info 
-f g77 M GLOBALS] 
 
or 
 
Argument #2 of `ucopy' is one precision at (2) but is some other precision at 
(1) [info -f g77 M GLOBALS] 
 
Those are warnings and they don't block the package building but some of them 
look scary. :-) 
 
If have full review that I will send soon. 

Comment 22 Patrice Dumas 2005-11-15 11:32:45 UTC
(In reply to comment #20)
> Some short notes: 
>  
>  * change environnement to environment in the spec file, not now just after 
> the approval. :-) 

I don't really understand that point...

>  * the difference in the tar files is probably due to the different atimes 
> from files. 

Yep.

>  * a warning related to the requirement of xorg-x11-devel that will be changed 
> soon on development 

Ok. I currently test the builds on FC4, I'll adjust to devel when needed.

Comment 23 Paul Howarth 2005-11-15 11:36:35 UTC
(In reply to comment #22)
> (In reply to comment #20)
> > Some short notes: 
> >  
> >  * change environnement to environment in the spec file, not now just after 
> > the approval. :-) 
> 
> I don't really understand that point...

I think it means "you can fix that spelling error after importing into cvs; no
need to create a new spec for review".



Comment 24 Patrice Dumas 2005-11-15 11:53:46 UTC
(In reply to comment #21)
> Needs work: 
> * Missing SMP flags. If it doesn't build with it, please add a comment 
>   (wiki: PackagingGuidelines#parallelmake) 

It breaks the libraries build, I added them when possible and added a comment too. 

I'll post a new srpm which contains other minor fixes (add a profile.d csh
script and provide saner defaults in the cernlib script) soon.

> * Spec file: some paths are not replaced with RPM macros 
>   (wiki: QAChecklist item 7) 

Which ones? I can't find them?

> * Build failed in mock 
>  
> It is easy to spot the problem, since you created the src.rpm blas and 
> lapack have changed and no longer have the devel part 
>  
> The fix is simply to replace them in BuildRequires with their devel 
> counterpart. 

Thanks. It is fixed, and I'll retry a mock build soon.

> I have noticed that in the build log I see lots of cases like this: 
>  
> Makefile:454: archive/hadjust.d: No such file or directory 

Yep, I don't know what it means and it seems harmless.

> Argument #4 of `hptit' is one type at (2) but is some other type at (1) [info 
> -f g77 M GLOBALS] 

I don't know for this one.
  
> Argument #2 of `ucopy' is one precision at (2) but is some other precision at 
> (1) [info -f g77 M GLOBALS] 

This is not an issue, as ucopy accept as argument the storage length. So it may
accomodate different precisions as long as the different precisions have a fixed
relative storage size, and this is the case in f77 (a double is 2 times real
storage). So the compiler should do the right thing, even though it is not very
clean. I didn't had a look to the precise code, though.

> Those are warnings and they don't block the package building but some of them 
> look scary. :-) 

Yep, but as long as the build proceed and leads to the right executable, even
though not very optimized I think it's enough, given that the upstream isn't
willing to change much.

I forgot to mention that the RPM optflags are not used during the build. I have
added a comment in the spec file.

Comment 25 Patrice Dumas 2005-11-15 11:56:05 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #20)
> > > Some short notes: 
> > >  
> > >  * change environnement to environment in the spec file, not now just after 
> > > the approval. :-) 
> > 
> > I don't really understand that point...
> 
> I think it means "you can fix that spelling error after importing into cvs; no
> need to create a new spec for review".

I hadn't seen that environnement was different from environment :-). Thanks for
the clarification.


Comment 26 José Matos 2005-11-15 12:15:48 UTC
All your comments are fair remarks.   
   
Regarding the raised issues:   
   
  - There are several places where you use cernlib explicitly, where in others   
you refer to %{name}, that happens in several places. I would prefer %{name}   
everywhere.   
   
There is one last issue for me. You don't build the cernlib package, instead   
you transfer all its responsabilities to cernlib-devel. I think that the best 
would be  the creation of both packages, as it is the norm in all Fedora 
libraries. I don't think there is any good reason where to not follow the 
rules. 
   
You could package most of the documentation there and then later place there   
the dynamic libraries. Then you require cernlib for cernlib-devel. Then   
everyone will be happy. :-)   
 

Comment 27 Patrice Dumas 2005-11-15 14:52:18 UTC
In fact I used cernlib everywhere except at 2 places where I used %{name} (not
counting the Buildroot). So I removed the use of %{name}, I find the specfile
more readable with cernlib instead of %{name}, and now it is consistent.

The new srpm is there (with the typo corrected ;-):

http://www.environnement.ens.fr/perso/dumas/fc-srpms/cernlib-2005-4.src.rpm

-=-
Regarding the split in cernlib/cernlib-devel, it is a bit dubious and some
packages in fedora don't ship a main package but only a -devel package (libcaca,
libnet). Moreover I asked on a thread what to do in that case and the answer was
to provide only one package, either a main package providing the -devel package
or  provide a devel package only. The thread is there: 

https://www.redhat.com/archives/fedora-extras-list/2005-August/msg01463.html

For the cernlib, most %doc files could be in the main cernlib package but I
don't think it is worth doing a package for those files. I have added a comment. 

In fact the main cernlib package is built, but is empty. As soon as there is
something in (i.e. as soon as there is a %file section for the main package) it
should appear so I believe it is better to wait for files that belong to the
main package to appear instead of having a package that has only 6 files in %doc
with mostly copyright information. If you really insist I will do the main
package with the 6 doc files, but I'd prefer not.

Comment 28 Patrice Dumas 2005-11-15 17:50:35 UTC
it builds fine in mock for FC 4

Comment 29 José Matos 2005-11-16 23:06:56 UTC
Review for release 4: 
* RPM name is OK 
* Source file is the same as upstream, or was modified to comply 
with the license. 
* Builds fine in mock 
 
* rpmlint 
W: cernlib strange-permission mkdirhier 0755 
W: cernlib patch-not-applied Patch25: 048-log-to-var-log-not-tmp 
W: cernlib patch-not-applied Patch26: 049-fix-kuesvr-security-hole 
W: cernlib patch-not-applied Patch27: 050-make-secure-comis-tmpdir 
W: cernlib patch-not-applied Patch28: 051-fix-miscellaneous-tmp-uses 
W: cernlib patch-not-applied Patch12: 018-move-kernlib-to-toplevel 
W: cernlib patch-not-applied Patch14: 027-use-tmpfile-not-mktemp 
W: cernlib patch-not-applied Patch36: cernlib-gfortran.diff 
W: cernlib strange-permission mkdirhier 0755 
W: cernlib patch-not-applied Patch25: 048-log-to-var-log-not-tmp 
W: cernlib patch-not-applied Patch26: 049-fix-kuesvr-security-hole 
W: cernlib patch-not-applied Patch27: 050-make-secure-comis-tmpdir 
W: cernlib patch-not-applied Patch28: 051-fix-miscellaneous-tmp-uses 
W: cernlib patch-not-applied Patch12: 018-move-kernlib-to-toplevel 
W: cernlib patch-not-applied Patch14: 027-use-tmpfile-not-mktemp 
W: cernlib patch-not-applied Patch36: cernlib-gfortran.diff 
E: cernlib-utils devel-dependency cernlib-devel 
W: cernlib-utils no-documentation 
E: cernlib-utils script-without-shellbang /etc/profile.d/cernlib-2005.sh 
E: cernlib-utils devel-dependency cernlib-devel 
W: cernlib-utils no-documentation 
E: cernlib-utils script-without-shellbang /etc/profile.d/cernlib-2005.csh 
E: cernlib-utils script-without-shellbang /etc/profile.d/cernlib-2005.sh 
E: geant321 devel-dependency cernlib-devel 
W: geant321 no-documentation 
E: geant321 devel-dependency cernlib-devel 
W: geant321 no-documentation 
E: kuipc devel-dependency cernlib-devel 
W: kuipc no-documentation 
E: kuipc devel-dependency cernlib-devel 
W: kuipc no-documentation 
 
Can be ignored, all of them were justified messages sent to this report. 
 
* package mets the package guiding lines 
* the different licenses are allowed for Extras, the text is included 
where available in the original source and they are stated in the 
license field. 
 
* the spec file is readable, and written in American English 
 
* the BuildRequires are correct and are necessary 
* the package only contains static libraries, work in progress (OK) 
 
* packages own all directories they create 
* permissions are set correctly 
* headers and static libraries are in the -devel package 
 
* subpackages require the base package 
 
Approved. 
 
PS: Don't forget %{?dist} in release after import. 

Comment 30 Patrice Dumas 2005-11-22 09:16:56 UTC
After some effort I managed to get the cernlib to build on ppc, so there are
builds for FC-3 (i386 and x86_64) and FC-4 (x386 and ppc). f771 segfaults on
x86_64 on FC-4 so I excluded that arch.

There are no builds in devel as there is an issue with modular X:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173530

If I have time I'll try to update the patches to the 2005 debian cernlib
patchset in the devel branch while trying to cope with modular X. So don't hold
your breath for the devel branch and keep an eye on the cvs commits...

Comment 31 Alfredo Ferrari 2005-11-23 09:47:39 UTC
Hi
somebody pointed me at this package claiming that it distributes some parts of
FLUKA included in GEANT321 without authorization and under an improper license.
Indeed this is the case: several routines and include files are present. The
FLUKA parts included in GEANT321 were never released under GPL/LGPL/BSD or
similar, neither licensed to be freely redistributed.
Their intellectual property originally belong to INFN (the Italian Institute for
Nuclear and Particle Physics) and when CERNLIB was relicensed under GPL it did
not include (obviously) those parts contributed by other Institutions under
different conditions.
In particular, from http://cernlib.web.cern.ch/cernlib/conditions.html

"(C) Copyright CERN except where explicitly stated otherwise. Permission to use
and/or redistribute this work is granted under the terms of the GNU General
Public License. FLUKA routines included in GEANT3 are joint copyright of INFN
and CERN and are not licensed under the GPL: permission to use and/or
redistribute outside GEANT3 should be negotiated. The software and documentation
made available under the terms of this license are provided with no warranty."

The same statement is reported in the copyright file included in your packaged
CERNLIB, together with the statement that the relevant FLUKA files have been
excised out of Debian distribution. It could be a qui-pro-quo about which files
belong to FLUKA, since part of them was in the "fluka" directory and part in the
"peanut" directory, in particular the routines:

fdevap fdnopt fdpree flkdt1 flkdt2 flkdt3 flkdt4 flkdt5 flkdt6 flkdt7
bimsel cosleg fekfnc fpfrnc fradnc frhinc frhonc nclvin nclvst nucnuc 
nwisel peanut pfnclv phdset phdwll pioabs prepre rstsel sbcomp sigfer 
umofin xinneu xinpro

and the include files: 

aadat.inc auxpar.inc balanc.inc bamjcm.inc cmsres.inc comcon.inc corinc.inc
corinc.inc dblprc.inc decayc.inc decayc2.inc depnuc.inc dimpar.inc eva0.inc
eva1.inc fheavy.inc finlsp.inc finlsp2.inc finlsp3.inc finpar.inc
finpar2.inc finuc.inc finuc2.inc finuct.inc hadflg.inc hadpar.inc
higfis.inc inpdat.inc inpdat2.inc inpflg.inc iounit.inc isotop.inc
labcos.inc mapa.inc metlsp.inc nucdat.inc nucgeo.inc nuclev.inc nucpar.inc
paprop.inc parevt.inc parnuc.inc part.inc part2.inc part3.inc reac.inc
redver.inc resnuc.inc split.inc xsepar.inc

are part of FLUKA and subject to the FLUKA license. I could have well missed
other files.

Since several years FLUKA is a standalone joint INFN-CERN project with a
specific license (see http://www.fluka.org for details) and those parts included
in GEANT321 have been obsoleted as early as 1996. The Debian CERNLIB maintainer
contacted me, as main author, after he noted the different conditions for FLUKA,
 and then he decided not to include those parts in their packages since their
are incompatible with the GPL or similar.

I assume you are not interested in distributing files GPL-incompatible, and
anyway the FLUKA authors are reluctant to let such old stuff go around.

               Best regards
              Alfredo Ferrari




Comment 32 Patrice Dumas 2005-11-23 10:30:29 UTC
(In reply to comment #31)


> in GEANT321 have been obsoleted as early as 1996. The Debian CERNLIB maintainer
> contacted me, as main author, after he noted the different conditions for FLUKA,
>  and then he decided not to include those parts in their packages since their
> are incompatible with the GPL or similar.
> 
> I assume you are not interested in distributing files GPL-incompatible, and
> anyway the FLUKA authors are reluctant to let such old stuff go around.

Indeed that's a mistake. I used the debian 2004 patchset script/file list to
remove files, but it seems that these files are not removed. I'll have a look at it.

Comment 33 Patrice Dumas 2005-11-23 11:05:08 UTC
(In reply to comment #31)

> in GEANT321 have been obsoleted as early as 1996. The Debian CERNLIB maintainer

Maybe you should do the same report to the cernlib maintainer, as it seems that
they are shipping fluka files.



Comment 34 Patrice Dumas 2005-11-23 11:19:20 UTC
> fdevap fdnopt fdpree flkdt1 flkdt2 flkdt3 flkdt4 flkdt5 flkdt6 flkdt7
> bimsel cosleg fekfnc fpfrnc fradnc frhinc frhonc nclvin nclvst nucnuc 
> nwisel peanut pfnclv phdset phdwll pioabs prepre rstsel sbcomp sigfer 
> umofin xinneu xinpro

Ok, it corresponds with 
geant321/block/
geant321/peanut/

There is nothing in these files that says that they are part of fluka and not
GPLed. This is something that should really be fixed upstream (i.e. by the
cernlib maintainers).
 
> and the include files: 
> 
> aadat.inc auxpar.inc balanc.inc bamjcm.inc cmsres.inc comcon.inc corinc.inc
> corinc.inc dblprc.inc decayc.inc decayc2.inc depnuc.inc dimpar.inc eva0.inc
> eva1.inc fheavy.inc finlsp.inc finlsp2.inc finlsp3.inc finpar.inc
> finpar2.inc finuc.inc finuc2.inc finuct.inc hadflg.inc hadpar.inc
> higfis.inc inpdat.inc inpdat2.inc inpflg.inc iounit.inc isotop.inc
> labcos.inc mapa.inc metlsp.inc nucdat.inc nucgeo.inc nuclev.inc nucpar.inc
> paprop.inc parevt.inc parnuc.inc part.inc part2.inc part3.inc reac.inc
> redver.inc resnuc.inc split.inc xsepar.inc

If I'm not wrong such files are not really copyrightable as they correspond with
api and/or short/trivial code. However it would be better if they weren't
included anyway as it doesn't make sense to redistribute api files without the
corresponding libs.

Comment 35 Patrice Dumas 2005-11-23 11:58:33 UTC
I have modified the deadpool.txt file to remove the routines and include files.
I send it to the debian cernlib maintainer too. 

Now I have to modify the source files and the patches to avoid building
inexistant code.

Comment 36 Patrice Dumas 2005-11-23 21:33:28 UTC
It is filled in the debian cernlib database, and I think I'll use the debian
cernlib patches.

http://bugs.debian.org/340433

Comment 37 Christian Iseli 2006-10-18 09:28:01 UTC
Normalize summary field for easy parsing

Comment 38 Patrice Dumas 2007-05-26 19:13:12 UTC
Package Change Request
======================
Package Name: cernlib
Updated Fedora CC: kmccarty [ AT ] princeton.edu

This is the cernlib debian maintainer.