SPEC: SRPM: A complete OpenCascade based MESH framework. This package can not be included in Fedora because it links with the non-free package OCE. rpmlint output: $ rpmlint *.rpm smesh.src: W: invalid-license GPL+ with exception smesh.src: W: invalid-url Source0: smesh-5.1.2.2-svn54.tar.gz smesh.x86_64: W: invalid-license GPL+ with exception smesh.x86_64: E: incorrect-fsf-address /usr/share/doc/smesh-5.1.2.2/LICENCE.lgpl.txt smesh-debuginfo.x86_64: W: invalid-license GPL+ with exception smesh-devel.x86_64: W: invalid-license GPL+ with exception smesh-devel.x86_64: W: no-documentation smesh-doc.noarch: W: invalid-license GPL+ with exception 5 packages and 0 specfiles checked; 1 errors, 7 warnings. All warnings are rpmlint being pedantic and I have reported the wrong FSF address error upstream.
Whoops! Forgot to copy in the links: SPEC: http://dl.dropbox.com/u/34775202/smesh.spec SRPM: http://dl.dropbox.com/u/34775202/smesh-5.1.2.2-1.svn54.fc15.src.rpm
It seems to me, the license is LGPLv2. The license text is cut in a weird way: // This library is free software; you can redistribute it and/or // modify it under the terms of the GNU Lesser General Public // License as published by the Free Software Foundation; either // version 2.1 of the License. I think you'll have to BR cmake. Just some cosmetic issues: - You could popd in the end - You could put the doxygen BR next to the other BRs, because BRs are not specific for sub-packages - You could add "-b somedescription~" to your %patch calls - f2c alrealy requires f2c-libs, so you could omit the latter - You could ask upstream to work on the hundreds of compilation warnings
(In reply to comment #2) > It seems to me, the license is LGPLv2. The license text is cut in a weird way: > > // This library is free software; you can redistribute it and/or > // modify it under the terms of the GNU Lesser General Public > // License as published by the Free Software Foundation; either > // version 2.1 of the License. Yeah, I used "licensecheck" which didn't pick up the v2. Fixed. > I think you'll have to BR cmake. Yeah, the strange part is not having it didn't keep a mock build from working. cmake must be in the standard build environment now. Fixed. > Just some cosmetic issues: > > - You could popd in the end Eh :) Since it resets the dir between sections I usually don't bother :) > - You could put the doxygen BR next to the other BRs, because BRs are not > specific for sub-packages Yeah, sometimes it's can be useful to a packager to know if a BR is needed for a specific sub-package, but -doc is pretty obvious. Fixed. > - You could add "-b somedescription~" to your %patch calls I added one for the second patch. I've already gotten a verbal confirmation that the first will be upstreamed. As long as one of them has a -b they won't clobber each other, right? > - f2c alrealy requires f2c-libs, so you could omit the latter Fixed. > - You could ask upstream to work on the hundreds of compilation warnings I'm not sure how active it is. I'm only packaging this as a requirement for FreeCAD which so far seems to "work" as is. But I'll at least let upstream know about the warnings. Richard
SPEC: http://dl.dropbox.com/u/34775202/smesh.spec SRPM: http://dl.dropbox.com/u/34775202/smesh-5.1.2.2-2.svn54.fc16.src.rpm
Builds ok on my F16. Minor issue: changelog not matching release number $ rpmlint smesh-5.1.2.2-2.svn54.fc16.i686.rpm smesh.i686: W: incoherent-version-in-changelog 5.1.2.2-1.svn54 ['5.1.2.2-2.svn54.fc16', '5.1.2.2-2.svn54'] smesh.i686: W: invalid-license GPLv2 with exception smesh.i686: E: incorrect-fsf-address /usr/share/doc/smesh-5.1.2.2/LICENCE.lgpl.txt 1 packages and 0 specfiles checked; 1 errors, 2 warnings. I was thinking about giving GEOM a try as well using this spec file and cmake patches with a view of packaging pythonocc, if you haven't planned to do so already? Cosmetic issue: the comment on the first line of CMakeLists.txt should probably say #SMESH, I presume upstream just copied the GEOM one...
(In reply to comment #5) > Builds ok on my F16. > > Minor issue: changelog not matching release number Whoops! Does it count that I *thought* about updating it? :) > $ rpmlint smesh-5.1.2.2-2.svn54.fc16.i686.rpm > smesh.i686: W: incoherent-version-in-changelog 5.1.2.2-1.svn54 > ['5.1.2.2-2.svn54.fc16', '5.1.2.2-2.svn54'] > smesh.i686: W: invalid-license GPLv2 with exception > smesh.i686: E: incorrect-fsf-address > /usr/share/doc/smesh-5.1.2.2/LICENCE.lgpl.txt > 1 packages and 0 specfiles checked; 1 errors, 2 warnings. > > I was thinking about giving GEOM a try as well using this spec file and cmake > patches with a view of packaging pythonocc, if you haven't planned to do so > already? Nope! I'm strictly packaging this as a FreeCAD dependency (which they currently bundle). > Cosmetic issue: the comment on the first line of CMakeLists.txt should probably > say #SMESH, I presume upstream just copied the GEOM one... I'll let them know.
(In reply to comment #6) > Nope! I'm strictly packaging this as a FreeCAD dependency (which they currently > bundle). Yeah, pythonocc also bundle SMESH and the recent patches in svn came from them I think. Interested in co-maintaining GEOM? (I don't have the hugest packaging nor cmake experience.)
(In reply to comment #7) > (In reply to comment #6) > > Nope! I'm strictly packaging this as a FreeCAD dependency (which they currently > > bundle). > > Yeah, pythonocc also bundle SMESH and the recent patches in svn came from them > I think. Probably, I sent them (the FreeCAD modifications), including some nice cmake tweaks to the smesh maintainer to make packaging easier. > Interested in co-maintaining GEOM? (I don't have the hugest packaging nor cmake > experience.) Sure! I'll review it for you as well. Let me know if you need any help with the packaging. Keep in mind since smesh links against OCE, which is currently non-free, GEOM will have to be non-free as well. There is talk of OCC (the parent of the OCE fork) moving to a more GPL compatible license. When/If that happens, OCE, SMESH, and GEOM would be able to move to Fedora proper. Richard
I used lovely "fedora-review" for most of this! Why is the license still filled with "GPLv2 with exceptions"? Do you inherit that from OCE? Patches should have an upstream ticket or a comment. Package Review ============== Key: - = N/A x = Pass ! = Fail ? = Not evaluated ==== C/C++ ==== [x]: MUST ldconfig called in %post and %postun if required. [x]: MUST Package does not contain any libtool archives (.la) [x]: MUST Package does not contain kernel modules. [x]: MUST Package contains no static executables. [x]: MUST Rpath absent or only used for internal libs. [x]: MUST Package is not relocatable. [x]: MUST Development .so files in -devel subpackage, if present. [x]: MUST Fedora optflags are used. ==== Generic ==== [x]: MUST Package successfully compiles and builds into binary rpms on at least one supported primary architecture. -- f16-x86_64 [x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: MUST Buildroot is not present Note: Unless packager wants to package for EPEL5 this is fine [x]: MUST Package contains no bundled libraries. [!]: MUST Changelog in prescribed format. -- Misses latest entry [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) Note: Clean would be needed if support for EPEL is required [x]: MUST Macros in Summary, %description expandable at SRPM build time. [x]: MUST Package requires other packages for directories it uses. [x]: MUST Package uses nothing in %doc for runtime. [x]: MUST Package is not known to require ExcludeArch. [x]: MUST Permissions on files are set properly. [x]: MUST Package does not contain duplicates in %files. [x]: MUST Spec file lacks Packager, Vendor, PreReq tags. [x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. Note: rm -rf would be needed if support for EPEL5 is required [x]: MUST If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [!]: MUST License field in the package spec file matches the actual license. -- See top [x]: MUST License file installed when any subpackage combination is installed. [x]: MUST Package consistently uses macros (instead of hard-coded directory names). [x]: MUST Package meets the Packaging Guidelines. [x]: MUST Package is named according to the Package Naming Guidelines. [x]: MUST Package does not generates any conflict. /usr/include/utilities.h is brave nevertheless! [x]: MUST Package obeys FHS, except libexecdir and /usr/target. [-]: MUST Package must own all directories that it creates. [x]: MUST Package does not own files or directories owned by other packages. [x]: MUST Package installs properly. [-]: MUST Package requires pkgconfig, if .pc files are present. (EPEL5) Note: Only applicable for EL-5 [-]: MUST Requires correct, justified where necessary. [x]: MUST Rpmlint output is silent. ==== SHOULD ==== [-] Query upstream if no license text is included [-] Scriptlets are sane, if used [x] Subpackages other than -devel should require base package (versioned) [-] Contain man pages, where they make sense
(In reply to comment #9) > I used lovely "fedora-review" for most of this! > > Why is the license still filled with "GPLv2 with exceptions"? Do you inherit > that from OCE? Yes. This verbage was given to me by Kevin Kofler and I definitely defer to his judgement in this area. Hopefully OCC will change their license sooner rather than later so this can go in Fedora. > Patches should have an upstream ticket or a comment. Patches have been emailed to the upstream maintainer on 12/21/2011. > Package Review > ============== > [!]: MUST Changelog in prescribed format. -- Misses latest entry Sorry, I updated it locally but haven't uploaded a new spec and srpm yet. Will do shortly. > [!]: MUST License field in the package spec file matches the actual license. See above. Richard
New SPEC: http://dl.dropbox.com/u/34775202/smesh.spec I fixed the changelog but I figured a new SRPM would be redundant at this point.
OK, if Kevin said so, I'm sure it's fine. Please mention in the spec file that you mailed the patches, package APPROVED.
(In reply to comment #12) > Please mention in the spec file that you mailed the patches, package APPROVED. Added! Thanks for the review! Thanks, Richard
New Package CVS Request ======================= Package Name: smesh Short Description: OpenCascade based MESH framework Owners: hobbes1069@gmail.com Branches: F-15 F-16 InitialCC: Cvsextras Commits: yes
Forgot to mention in the CVS request. This belongs in non-free due to OCE as a dependency.
I'm getting and ACL error when trying to commit: **** Access denied: hobbes1069 is not in ACL for rpms/smesh/devel cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first!
All builds completed.
Package Change Request ====================== Package Name: SMESH New Branches: EL-6 Updated EPEL Owners: hobbes1069@gmail.com
This package was made with lower case, please check your request next time.
Fixing bug summary SMESH->smesh to stop confusion.