Bug 167253
Summary: | Review Request: cernlib - CERN library and associated binaries | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Patrice Dumas <pertusus> |
Component: | Package Review | Assignee: | José Matos <jamatos> |
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | 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
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 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 This one should solve that issue http://www.environnement.ens.fr/docs/fc-srpms/cernlib-2005-2.src.rpm 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? 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. 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). 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. (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. 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... 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. Please have a look at: http://www.environnement.ens.fr/docs/fc-srpms/cernlib-2005-3.src.rpm 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? (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. (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. :-) 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. > 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
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. 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. 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. 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 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. (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. (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". (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. (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. 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. :-) 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. it builds fine in mock for FC 4 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. 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... 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 (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. (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. > 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. 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. It is filled in the debian cernlib database, and I think I'll use the debian cernlib patches. http://bugs.debian.org/340433 Normalize summary field for easy parsing Package Change Request ====================== Package Name: cernlib Updated Fedora CC: kmccarty [ AT ] princeton.edu This is the cernlib debian maintainer. |