Spec URL: http://kwizart.fedorapeople.org/SPECS/OpenCASCADE.spec SRPM URL: http://rpms.kwizart.net/fedora/8/SRPMS/OpenCASCADE-6.2.0-2.fc8.kwizart.src.rpm Description: The OpenCASCADE framework This package is needeed for FreeCAD (among others). It is reported to build on F-8 (tested x86_64), and fails in F-9 There is some bison generated files to fix (see debuginfo extraction) and see if some files are needed from the original sources at runtime. (from samples tools doc data). This "early" Review Request is primary aimed to bring every packagers interested in maintaining this package (and others for FreeCAD) to coordinate the efforts..
I am in contact with the Debian packager - their effort is at http://lyre.mit.edu/~powell/opencascade/ Set blocking FE_LEGAL as the status of the license is unclear - after consulting with Spot I have moved it to the legal list https://www.redhat.com/archives/fedora-legal-list/2008-July/msg00037.html.
Another issue could be with the included "triangle" library (ros/src/Trianle).
OpenCascade license is non-free. Given that Debian has been trying to resolve the license issues with upstream and not having any luck, I'm not hopeful. However, if you'd like me to explain the specific problems, I can do so.
So, what should happen with this ticket? I'm guessing we'll just have to close it CANTFIX along with the FreeCAD review unless that package can somehow be made not to depend on this one.
I noticed that Debian now ships opencascade in their "main" section, not in "non-free" anymore: http://packages.debian.org/source/sid/opencascade From Debian's changelog.txt: opencascade (6.3.0.dfsg.1-1) unstable; urgency=low [Denis Barbier] * New Upstream Version. (closes: #501128) * Upstream replaced Triangle by a free implementation, thus external-triangle.patch is removed as well as dependencies against libtriangle-dev. * Remove ros/src/FontMFT/*.mft files, these font files have no sources. (As a side effect, closes: #487116) * All non-free bits have thus been removed, and opencascade is moved from non-free into main. The controversial "explanatory" paragraph which contradicted the terms of the license (by requiring modifications to be sent to the initial developer) is not present in the LICENSE file. (It's still present on the website though. See http://www.opencascade.org/getocc/license/ ) See the *.copyright file from Debian: http://packages.debian.org/changelogs/pool/main/o/opencascade/opencascade_6.3.0.dfsg.1-3/libopencascade-dev.copyright
Good news. Seems that it's time to re-open this ticket.
It should still be checked by Spot, because there were some discussions on the OCC Forums about the details of the licensing terms and Debian's move into "main" alone is not relevant for Fedora.
I will update to 6.3.0 in few days so it can be seen by FE-Legal
(In reply to comment #7) > It should still be checked by Spot, because there were some discussions on the > OCC Forums about the details of the licensing terms and Debian's move into > "main" alone is not relevant for Fedora. http://www.opencascade.org/org/forum/thread_15859/
Even without the preamble, the OCTPL is non-free for the reasons listed in the thread link in Comment #9: Section 7 says: You may choose to offer, *on a non-exclusive basis*, and to charge a fee for any warranty, support, maintenance, liability obligations or other rights consistent with the scope of this License with respect to the Software to the recipients of the Software .... Except for the part delimited in asterisks, this would be free though annoying. But limiting this permission to "a non-exclusive basis" is bizarre. Why can't someone choose to offer support exclusively to customer A but not any other customer? A fair number of FOSS licenses have these upstream indemnification clauses, but we don't think we've ever seen one limited to "non-exclusive" offerings of support and so forth. Moreover, if you read sections 6 and 7 together, you get the sense that they're taking "may choose to offer" in a very literal sense, implying that 'you only have the following very limited permission to offer services surrounding the software' -- contrast that with, say, GPLv2 which says "you may at your option offer warranty protection in exchange for a fee" -- this is intended to clarify what ought to be obvious. In other words, in OpenCASCADE any sort of services offering relating to the software is, in their view, a forbidden 'additional term' unless it's covered under section 7.
Thanks for pointing out the real problem of this license. Closing as CANTFIX again.
It's worth noting that I've again attempted to open a dialog with the OpenCASCADE development team about relicensing this so we can include it in Fedora. If anything comes from this, I will post it here.
For the record: I'm interested in opencascade as it seems to be used by openmoko developers. With Fedora 12, we already have 60% environment for openmoko hardware development. https://fedorahosted.org/fedora-electronic-lab/ticket/55
It seems OpenCASCADE is included in debian, see http://packages.debian.org/source/sid/opencascade Apparently, they could resolve the license issues. Could this ticket be reopened so we could include OpenCASCADE in Fedora? I successfully modified a src.rpm of OpenCASCADE from OpenSUSE to adapt it to Fedora, I could provide it for anyone interested.
(In reply to comment #14) > It seems OpenCASCADE is included in debian, see > http://packages.debian.org/source/sid/opencascade > > Apparently, they could resolve the license issues. No. The problem Spot pointed out in comment #10 is still there.
The simple solution, as I see it, is to implore the OpenCASCADE's maintainers to add "or LGPL" to their licensing scheme. The option to distribute under the already similar LGPL terms would fix this issue. GNU/Linux users need a quality CAD solution. Badly. If FreeCAD can be distributed under legitimate Free terms, that brings the community a bit closer to it.
Links above point to where OpenCASCADE has been requested to change their license before, but they are unwilling: http://www.opencascade.org/org/forum/thread_15859/?forum=3 If you can think of a promising new strategy, I'm all for trying.
Well no, if my idea has already been tried, then I totally don't know what to do next. It's just that my frustration with this situation (all the licensing BS getting in the way of a harmonious solution for the community, including the case of the FSF not being pragmatic about LibreDWG) has frustrated me enough to make me want to post here. Nothing much to do now, though. There is no shortage of licenses more permissive than GPL that have FSF and Fedora approval. This is an example of the kind of disaster that happens when programmers take the homebrew route ... not getting included in distributions at all!
For what it's worth, here are Richard Stallman's comments on the Open Cascade license from a recent email exchange. I quote exactly: " Based on a quick read-through, I think it is a free software license, but I am not sure. Section 4 comes very close to the edge when it says If you distribute or sublicense the Software (as modified by You or on Your behalf as the case may be), You cause such Software to be licensed as a whole, at no charge, to all third parties, under the terms and conditions of the License, making in particular available to all third parties the source code of the Software;<br /> In effect, this says that if you distribute a modified version once to anyone you must publish it. I think we looked at various similar sorts of license conditions to decide where to draw the line. But that was ten years ago, and I am not immediately sure what our conclusions imply about this case. This is not at all like the LGPL. This is a kind of copyleft license. All additions to the code must be under the same license. It is incompatible with the GNU GPL, Section 4 is incompatible with the GNU GPL because its reqyuirements about change logs are more strict than the GPL's requirements. The practices this license requires for change log data are good practices, and we generally do them anyway, but nonetheless the licenses are incompatible. Section 7 is incompatible with the GNU GPL because of the requirement You must obtain the recipient's agreement that any such Additional Terms are offered by You alone, since that forbids practices permitted by the GPL. If this is the case, linking code uder the GPL with code under this iccense would be copyright violation of the GPL. Thus, putting GPL-covered codeand code under this license into one program is a violation of one or both of the licenses. If that is what Freedad does, it is licensing limbo. " Someone who understands licensing better than myself can do with this information what they must.
While it is interesting to see RMS's stance on this, the FSF has previously determined this license to be non-free.
(In reply to comment #20) > While it is interesting to see RMS's stance on this, the FSF has previously > determined this license to be non-free. He's taken me up on the offer to contact them. It's highly unlikely they'll switch licenses, but they might be persuaded to alter their license just enough to make it compatible.
(In reply to comment #21) > (In reply to comment #20) > > While it is interesting to see RMS's stance on this, the FSF has previously > > determined this license to be non-free. > > He's taken me up on the offer to contact them. It's highly unlikely they'll > switch licenses, but they might be persuaded to alter their license just > enough to make it compatible. A couple of months ago this issue was dredged up again in the FreeCAD CAM forum, when the developer of some excellent GPLv3-licensed tool path generator libraries abstained from relicensing LGPL in order to be OCCTPL compatible. IMO this dealt a big blow to the otherwise very promising CAM plugin currently under development, though the plugin devs will most likely find acceptable TPG libs elsewhere. The most frustrating part of the controversy was the feeling that the blame was on the TPG library author. The community has simply given up hope on fixing the OCCTPL problem, and I received a scathing reply upon suggesting the software that needed relicensing was OCC, not the GPLv3 libraries. My fault for opening up old wounds, but this is a lame status quo to have arrived at. I can't tell exactly what you're plotting, but admire your fresh initiative and cross my fingers you'll succeed. I co-maintain OCE and FreeCAD packages on RPMFusion because they can't be accepted into Fedora, and I for one will gladly aid any promising effort to end this problem. John
(In reply to comment #22) > A couple of months ago this issue was dredged up again in the FreeCAD CAM > forum, when the developer of some excellent GPLv3-licensed tool path > generator libraries abstained from relicensing LGPL in order to be OCCTPL > compatible. IMO this dealt a big blow to the otherwise very promising CAM > plugin currently under development, though the plugin devs will most likely > find acceptable TPG libs elsewhere. > > The most frustrating part of the controversy was the feeling that the blame > was on the TPG library author. The community has simply given up hope on > fixing the OCCTPL problem, and I received a scathing reply upon suggesting > the software that needed relicensing was OCC, not the GPLv3 libraries. My > fault for opening up old wounds, but this is a lame status quo to have > arrived at. That's not a happy situation. What truly mucked the whole situation up was Open Cascade's licensing arrogance. > I can't tell exactly what you're plotting, but admire your fresh initiative > and cross my fingers you'll succeed. I co-maintain OCE and FreeCAD packages > on RPMFusion because they can't be accepted into Fedora, and I for one will > gladly aid any promising effort to end this problem. > > John Basically, I'm plotting the sorting out of this mess, and maybe whatever I can do will play some role in that. I thank you immensely for maintaining OCE and FreeCAD, even if it's third party. But you would be super cool in my book if you also found time to maintain LibreCAD, which covers 2D functions. QCad (which it's forked from, and the only kind of CAD software in the Fedora repository) is abandonware. But maybe that's too much to ask.
As of OCC release 6.7.0 and by extension OCE release 0.15, it is now LGPLv2 licensed. My intent is to start a new Review Request for OCE since it's a separately maintained fork but due to the historical legal issues with licensing I wanted to get feedback here prior to doing so.
Tom Callaway has given his blessing [1] on the fedora-legal list. My feedback: YAY!!! Of course I'll help with the OCE new package process. Please CC: me on any ticket. Thanks! [1] https://lists.fedoraproject.org/pipermail/legal/2013-December/002345.html
Any objection to me submitting a new review request?
Have you get in touch with Eric Smith? Avoid duplicate works.
(In reply to Christopher Meng from comment #27) > Have you get in touch with Eric Smith? Avoid duplicate works. No, should I? A little more detail or a link would be helpful for me to understand what you mean.
Check the link in comment 25 IIUC.
Thanks, I read the email but didn't catch the author of it, just Tom's response. I just sent him an email, we'll see what he says.
SPEC: http://hobbes1069.fedorapeople.org/OCE.spec SRPM: http://hobbes1069.fedorapeople.org/OCE-0.15-1.fc19.src.rpm The koji scratch build is currently still running, hopefully there are no issues. http://koji.fedoraproject.org/koji/taskinfo?taskID=6531993 While I don't see how it matters I figured it might be worth mentioning that version 0.13 is currently in RPM non-free. Since I have no plans to build 0.15 there, there should not be any upgrade path issues.
The license is LGPLv2.1, with a special exception [1]. Setting blocks FE_LEGAL to double-check the License: tag. (Please see below, and comment 25 above.) Since the OCCT license is unacceptable to Fedora, does the exception have any additional meaning as far as what software it may be combined with, or should this software simply be treated as LGPLv2.1 as far as Fedora packaging is concerned? Should the License: tag read just "LGPLv2" or "LGPLv2 with exceptions"? There is a promising project to create a CAM module for FreeCAD. They are considering combining some GPLv3 libraries. Doing so would violate this software license, correct? Also, the file "OCCT_LGPL_EXCEPTION.txt" should be added to %files as %doc. Thanks! [1] https://github.com/tpaviot/oce/blob/master/OCCT_LGPL_EXCEPTION.txt
SPEC: http://hobbes1069.fedorapeople.org/OCE.spec SRPM: http://hobbes1069.fedorapeople.org/OCE-0.15-2.fc19.src.rpm Yup! Fixed the license... Missed the exception part the first time around.
(In reply to John Morris from comment #32) > The license is LGPLv2.1, with a special exception [1]. Setting blocks > FE_LEGAL to double-check the License: tag. (Please see below, and comment > 25 above.) > > Since the OCCT license is unacceptable to Fedora, does the exception have > any additional meaning as far as what software it may be combined with, or > should this software simply be treated as LGPLv2.1 as far as Fedora > packaging is concerned? Should the License: tag read just "LGPLv2" or > "LGPLv2 with exceptions"? LGPLv2 with exceptions. This exception is the old QT exception wording from when they were LGPLv2. > There is a promising project to create a CAM module for FreeCAD. They are > considering combining some GPLv3 libraries. Doing so would violate this > software license, correct? No, because LGPLv2 permits conversion to GPLv2+. Lifting FE-Legal.
Richard, did you get a response from Eric Smith on your Feb. 13th email? I sent an email asking about his plans for OCC/OCE on Feb. 9th (with you in the CC: list), and haven't heard back. Anything else blocking this? What's the next step? Shall I start the review?
You'd better start a new bug and mark this one as duplicate, since this bug's owner is Nicolas. Also, please remove all group tags, not only the one in the main package. Thank you.
Is there a problem with me taking over? Typically the any BZ's filed after the first are marked as duplicate of the first. I have been maintaining OCE on RPM Fusion for a couple of years now so he is fully aware of what I'm doing and has not commented so I assume it is acceptable.
I'll do the review on this bug w/in the next few days unless told otherwise. Thanks!
I'm also interested in seeing this reviewed, not least because it is a salome dependency.
Ping!
Taking for review. Full review below. Main points: ** MUST Items: ** [!]: Provides: bundled(gnulib) in place as required. Note: [x]: Package contains no bundled libraries without FPC exception. -> gnulib ok, add this link to spec: https://fedorahosted.org/fpc/ticket/174, see http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [!]: Package must own all directories that it creates. -> Require: hicolor-icon-theme [!]: Only use %_sourcedir in very specific situations. Note: %_sourcedir/$RPM_SOURCE_DIR is used. See https://fedoraproject.org/wiki/Packaging:RPM_Source_Dir See also OCE.src:183: E: use-of-RPM_SOURCE_DIR OCE-foundation.x86_64: W: shared-lib-calls-exit /usr/lib64/libTKernel.so.8.0.0 exit.5 OCE-foundation.x86_64: W: shared-lib-calls-exit /usr/lib64/libTKAdvTools.so.8.0.0 exit.5 -> See for instance https://bugzilla.redhat.com/attachment.cgi?id=329912 ** SHOULD Items: ** [!]: Packages should try to preserve timestamps of original installed files. -> Could install %SOURCEx files with -p [x]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in OCE- foundation , OCE-modeling , OCE-ocaf , OCE-visualization , OCE-draw , OCE-devel -> Are automatic, but might be a good to make them explicit Also: OCE-devel.x86_64: W: no-dependency-on OCE/OCE-libs/libOCE OCE.src:303: W: macro-in-comment %{version} ** Extra Items: ** [?]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 4249600 bytes in /usr/share -> Guess 4MB is okay Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== C/C++: [!]: Provides: bundled(gnulib) in place as required. Note: Sources not installed [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Header files in -devel subpackage, if present. [x]: ldconfig called in %post and %postun if required. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. [x]: License file installed when any subpackage combination is installed. [!]: Package must own all directories that it creates. -> Require: hicolor-icon-theme Note: Directories without known owners: /usr/share/icons/hicolor/256x256/apps, /usr/share/icons/hicolor/64x64/apps, /usr/share/icons/hicolor/128x128, /usr/share/icons/hicolor/128x128/apps, /usr/share/icons/hicolor/48x48/apps, /usr/share/icons/hicolor/64x64, /usr/share/icons/hicolor/48x48, /usr/share/icons/hicolor/256x256, /usr/share/icons/hicolor [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. -> gnulib ok, add this link to spec: https://fedorahosted.org/fpc/ticket/174, see http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [!]: Only use %_sourcedir in very specific situations. Note: %_sourcedir/$RPM_SOURCE_DIR is used. See https://fedoraproject.org/wiki/Packaging:RPM_Source_Dir [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: gtk-update-icon-cache is invoked in %postun and %posttrans if package contains icons. Note: icons in OCE-draw [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 71680 bytes in 10 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: 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. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop- file-validate if there is such a file. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package do not use a name that already exist [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in OCE- foundation , OCE-modeling , OCE-ocaf , OCE-visualization , OCE-draw , OCE-devel -> Are automatic, but might be a good to make them explicit [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Scriptlets must be sane, if used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [?]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [!]: Packages should try to preserve timestamps of original installed files. -> Could install %SOURCEx files with -p [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: Dist tag is present (not strictly required in GL). [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [?]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 4249600 bytes in /usr/share -> Guess 4MB is okay [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: OCE-foundation-0.15-2.fc21.x86_64.rpm OCE-modeling-0.15-2.fc21.x86_64.rpm OCE-ocaf-0.15-2.fc21.x86_64.rpm OCE-visualization-0.15-2.fc21.x86_64.rpm OCE-draw-0.15-2.fc21.x86_64.rpm OCE-devel-0.15-2.fc21.x86_64.rpm OCE-0.15-2.fc21.src.rpm OCE-foundation.x86_64: W: invalid-license LGPLv2 with exception OCE-foundation.x86_64: W: shared-lib-calls-exit /usr/lib64/libTKernel.so.8.0.0 exit.5 OCE-foundation.x86_64: W: shared-lib-calls-exit /usr/lib64/libTKAdvTools.so.8.0.0 exit.5 OCE-foundation.x86_64: E: non-executable-script /usr/share/oce-0.15/src/DrawResources/tdoc 0644L /bin/sh OCE-foundation.x86_64: E: non-executable-script /usr/share/oce-0.15/src/DrawResources/mkdoc 0644L /bin/csh OCE-foundation.x86_64: E: non-executable-script /usr/share/oce-0.15/src/DrawResources/idoc 0644L /bin/sh OCE-modeling.x86_64: W: invalid-license LGPLv2 with exception OCE-modeling.x86_64: W: no-documentation OCE-ocaf.x86_64: W: invalid-license LGPLv2 with exception OCE-ocaf.x86_64: W: no-documentation OCE-visualization.x86_64: W: invalid-license LGPLv2 with exception OCE-visualization.x86_64: W: no-documentation OCE-draw.x86_64: W: invalid-license LGPLv2 with exception OCE-devel.x86_64: W: no-dependency-on OCE/OCE-libs/libOCE OCE-devel.x86_64: W: invalid-license LGPLv2 with exception OCE.src: W: invalid-license LGPLv2 with exception OCE.src:183: E: use-of-RPM_SOURCE_DIR OCE.src:303: W: macro-in-comment %{version} 7 packages and 0 specfiles checked; 4 errors, 14 warnings. Rpmlint (installed packages) ---------------------------- # rpmlint OCE-modeling OCE-devel OCE-foundation OCE-draw OCE-ocaf OCE-visualization (none): E: no installed packages by name OCE-modeling (none): E: no installed packages by name OCE-devel (none): E: no installed packages by name OCE-foundation (none): E: no installed packages by name OCE-draw (none): E: no installed packages by name OCE-ocaf (none): E: no installed packages by name OCE-visualization 0 packages and 0 specfiles checked; 0 errors, 0 warnings. # echo 'rpmlint-done:' Requires -------- OCE-modeling (rpmlib, GLIBC filtered): /sbin/ldconfig libPTKernel.so.8()(64bit) libTKBO.so.8()(64bit) libTKBRep.so.8()(64bit) libTKBin.so.8()(64bit) libTKBinL.so.8()(64bit) libTKBool.so.8()(64bit) libTKCAF.so.8()(64bit) libTKCDF.so.8()(64bit) libTKG2d.so.8()(64bit) libTKG3d.so.8()(64bit) libTKGeomAlgo.so.8()(64bit) libTKGeomBase.so.8()(64bit) libTKHLR.so.8()(64bit) libTKIGES.so.8()(64bit) libTKLCAF.so.8()(64bit) libTKMath.so.8()(64bit) libTKMesh.so.8()(64bit) libTKPLCAF.so.8()(64bit) libTKPShape.so.8()(64bit) libTKPrim.so.8()(64bit) libTKSTEP.so.8()(64bit) libTKSTEP209.so.8()(64bit) libTKSTEPAttr.so.8()(64bit) libTKSTEPBase.so.8()(64bit) libTKService.so.8()(64bit) libTKShHealing.so.8()(64bit) libTKShapeSchema.so.8()(64bit) libTKStdLSchema.so.8()(64bit) libTKStdSchema.so.8()(64bit) libTKTopAlgo.so.8()(64bit) libTKV3d.so.8()(64bit) libTKXCAF.so.8()(64bit) libTKXSBase.so.8()(64bit) libTKXml.so.8()(64bit) libTKXmlL.so.8()(64bit) libTKernel.so.8()(64bit) libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) libtbb.so.2()(64bit) rtld(GNU_HASH) OCE-devel (rpmlib, GLIBC filtered): OCE-foundation(x86-64) OCE-modeling(x86-64) OCE-ocaf(x86-64) OCE-visualization(x86-64) libFWOSPlugin.so.8()(64bit) libPTKernel.so.8()(64bit) libTKAdvTools.so.8()(64bit) libTKBO.so.8()(64bit) libTKBRep.so.8()(64bit) libTKBin.so.8()(64bit) libTKBinL.so.8()(64bit) libTKBinTObj.so.8()(64bit) libTKBinXCAF.so.8()(64bit) libTKBool.so.8()(64bit) libTKCAF.so.8()(64bit) libTKCDF.so.8()(64bit) libTKDCAF.so.8()(64bit) libTKDraw.so.8()(64bit) libTKFeat.so.8()(64bit) libTKFillet.so.8()(64bit) libTKG2d.so.8()(64bit) libTKG3d.so.8()(64bit) libTKGeomAlgo.so.8()(64bit) libTKGeomBase.so.8()(64bit) libTKHLR.so.8()(64bit) libTKIGES.so.8()(64bit) libTKLCAF.so.8()(64bit) libTKMath.so.8()(64bit) libTKMesh.so.8()(64bit) libTKMeshVS.so.8()(64bit) libTKNIS.so.8()(64bit) libTKOffset.so.8()(64bit) libTKOpenGl.so.8()(64bit) libTKPCAF.so.8()(64bit) libTKPLCAF.so.8()(64bit) libTKPShape.so.8()(64bit) libTKPrim.so.8()(64bit) libTKSTEP.so.8()(64bit) libTKSTEP209.so.8()(64bit) libTKSTEPAttr.so.8()(64bit) libTKSTEPBase.so.8()(64bit) libTKSTL.so.8()(64bit) libTKService.so.8()(64bit) libTKShHealing.so.8()(64bit) libTKShapeSchema.so.8()(64bit) libTKStdLSchema.so.8()(64bit) libTKStdSchema.so.8()(64bit) libTKTObj.so.8()(64bit) libTKTObjDRAW.so.8()(64bit) libTKTopAlgo.so.8()(64bit) libTKTopTest.so.8()(64bit) libTKV3d.so.8()(64bit) libTKVRML.so.8()(64bit) libTKViewerTest.so.8()(64bit) libTKVoxel.so.8()(64bit) libTKXCAF.so.8()(64bit) libTKXCAFSchema.so.8()(64bit) libTKXDEDRAW.so.8()(64bit) libTKXDEIGES.so.8()(64bit) libTKXDESTEP.so.8()(64bit) libTKXMesh.so.8()(64bit) libTKXSBase.so.8()(64bit) libTKXSDRAW.so.8()(64bit) libTKXml.so.8()(64bit) libTKXmlL.so.8()(64bit) libTKXmlTObj.so.8()(64bit) libTKXmlXCAF.so.8()(64bit) libTKernel.so.8()(64bit) OCE-foundation (rpmlib, GLIBC filtered): /sbin/ldconfig libTKernel.so.8()(64bit) libc.so.6()(64bit) libdl.so.2()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) libtbbmalloc.so.2()(64bit) rtld(GNU_HASH) OCE-draw (rpmlib, GLIBC filtered): /bin/sh libGL.so.1()(64bit) libTKBO.so.8()(64bit) libTKBRep.so.8()(64bit) libTKBool.so.8()(64bit) libTKCAF.so.8()(64bit) libTKCDF.so.8()(64bit) libTKDCAF.so.8()(64bit) libTKDraw.so.8()(64bit) libTKFeat.so.8()(64bit) libTKFillet.so.8()(64bit) libTKG2d.so.8()(64bit) libTKG3d.so.8()(64bit) libTKGeomAlgo.so.8()(64bit) libTKGeomBase.so.8()(64bit) libTKHLR.so.8()(64bit) libTKIGES.so.8()(64bit) libTKLCAF.so.8()(64bit) libTKMath.so.8()(64bit) libTKMesh.so.8()(64bit) libTKMeshVS.so.8()(64bit) libTKNIS.so.8()(64bit) libTKOffset.so.8()(64bit) libTKOpenGl.so.8()(64bit) libTKPrim.so.8()(64bit) libTKSTEP.so.8()(64bit) libTKSTEPBase.so.8()(64bit) libTKSTL.so.8()(64bit) libTKService.so.8()(64bit) libTKShHealing.so.8()(64bit) libTKTObj.so.8()(64bit) libTKTopAlgo.so.8()(64bit) libTKV3d.so.8()(64bit) libTKVRML.so.8()(64bit) libTKViewerTest.so.8()(64bit) libTKVoxel.so.8()(64bit) libTKXCAF.so.8()(64bit) libTKXDEIGES.so.8()(64bit) libTKXDESTEP.so.8()(64bit) libTKXSBase.so.8()(64bit) libTKXSDRAW.so.8()(64bit) libTKernel.so.8()(64bit) libX11.so.6()(64bit) libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) libtcl8.5.so()(64bit) libtk8.5.so()(64bit) rtld(GNU_HASH) OCE-ocaf (rpmlib, GLIBC filtered): /sbin/ldconfig libPTKernel.so.8()(64bit) libTKBO.so.8()(64bit) libTKBRep.so.8()(64bit) libTKBinL.so.8()(64bit) libTKCAF.so.8()(64bit) libTKCDF.so.8()(64bit) libTKG2d.so.8()(64bit) libTKG3d.so.8()(64bit) libTKGeomBase.so.8()(64bit) libTKLCAF.so.8()(64bit) libTKMath.so.8()(64bit) libTKPCAF.so.8()(64bit) libTKPLCAF.so.8()(64bit) libTKPShape.so.8()(64bit) libTKShapeSchema.so.8()(64bit) libTKStdLSchema.so.8()(64bit) libTKTObj.so.8()(64bit) libTKTopAlgo.so.8()(64bit) libTKV3d.so.8()(64bit) libTKXmlL.so.8()(64bit) libTKernel.so.8()(64bit) libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) rtld(GNU_HASH) OCE-visualization (rpmlib, GLIBC filtered): /sbin/ldconfig libGL.so.1()(64bit) libGLU.so.1()(64bit) libTKBRep.so.8()(64bit) libTKG2d.so.8()(64bit) libTKG3d.so.8()(64bit) libTKGeomAlgo.so.8()(64bit) libTKGeomBase.so.8()(64bit) libTKHLR.so.8()(64bit) libTKMath.so.8()(64bit) libTKMesh.so.8()(64bit) libTKService.so.8()(64bit) libTKShHealing.so.8()(64bit) libTKTopAlgo.so.8()(64bit) libTKV3d.so.8()(64bit) libTKernel.so.8()(64bit) libX11.so.6()(64bit) libc.so.6()(64bit) libfreeimage.so.3()(64bit) libfreetype.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgl2ps.so.1()(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) rtld(GNU_HASH) Provides -------- OCE-modeling: OCE-modeling OCE-modeling(x86-64) libTKBO.so.8()(64bit) libTKBRep.so.8()(64bit) libTKBinXCAF.so.8()(64bit) libTKBool.so.8()(64bit) libTKFeat.so.8()(64bit) libTKFillet.so.8()(64bit) libTKG2d.so.8()(64bit) libTKG3d.so.8()(64bit) libTKGeomAlgo.so.8()(64bit) libTKGeomBase.so.8()(64bit) libTKHLR.so.8()(64bit) libTKIGES.so.8()(64bit) libTKMesh.so.8()(64bit) libTKOffset.so.8()(64bit) libTKPrim.so.8()(64bit) libTKSTEP.so.8()(64bit) libTKSTEP209.so.8()(64bit) libTKSTEPAttr.so.8()(64bit) libTKSTEPBase.so.8()(64bit) libTKSTL.so.8()(64bit) libTKShHealing.so.8()(64bit) libTKTopAlgo.so.8()(64bit) libTKVRML.so.8()(64bit) libTKXCAF.so.8()(64bit) libTKXCAFSchema.so.8()(64bit) libTKXDEIGES.so.8()(64bit) libTKXDESTEP.so.8()(64bit) libTKXMesh.so.8()(64bit) libTKXSBase.so.8()(64bit) libTKXmlXCAF.so.8()(64bit) OCE-devel: OCE-devel OCE-devel(x86-64) OCE-foundation: OCE-foundation OCE-foundation(x86-64) libTKAdvTools.so.8()(64bit) libTKMath.so.8()(64bit) libTKernel.so.8()(64bit) OCE-draw: OCE-draw OCE-draw(x86-64) application() application(opencascade-draw.desktop) libTKDCAF.so.8()(64bit) libTKDraw.so.8()(64bit) libTKTObjDRAW.so.8()(64bit) libTKTopTest.so.8()(64bit) libTKViewerTest.so.8()(64bit) libTKXDEDRAW.so.8()(64bit) libTKXSDRAW.so.8()(64bit) OCE-ocaf: OCE-ocaf OCE-ocaf(x86-64) libFWOSPlugin.so.8()(64bit) libPTKernel.so.8()(64bit) libTKBin.so.8()(64bit) libTKBinL.so.8()(64bit) libTKBinTObj.so.8()(64bit) libTKCAF.so.8()(64bit) libTKCDF.so.8()(64bit) libTKLCAF.so.8()(64bit) libTKPCAF.so.8()(64bit) libTKPLCAF.so.8()(64bit) libTKPShape.so.8()(64bit) libTKShapeSchema.so.8()(64bit) libTKStdLSchema.so.8()(64bit) libTKStdSchema.so.8()(64bit) libTKTObj.so.8()(64bit) libTKXml.so.8()(64bit) libTKXmlL.so.8()(64bit) libTKXmlTObj.so.8()(64bit) OCE-visualization: OCE-visualization OCE-visualization(x86-64) libTKMeshVS.so.8()(64bit) libTKNIS.so.8()(64bit) libTKOpenGl.so.8()(64bit) libTKService.so.8()(64bit) libTKV3d.so.8()(64bit) libTKVoxel.so.8()(64bit) Source checksums ---------------- https://github.com/tpaviot/oce/archive/29a47efd7b37b11dcf7aabc9d4e725be5eb0c9ed/OCE-0.15.tar.gz : CHECKSUM(SHA256) this package : 9b2d8607615dcb542c0b4a220f3a0549e80cf68ea9574799b2e7c5f6cf8b814a CHECKSUM(SHA256) upstream package : 9b2d8607615dcb542c0b4a220f3a0549e80cf68ea9574799b2e7c5f6cf8b814a Generated by fedora-review 0.5.1 (bb9bf27) last change: 2013-12-13 Command line :/usr/bin/fedora-review -b 458974 -o--enable-plugin=tmpfs Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Shell-api, C/C++ Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG
Sandro, thanks for taking this. I'm extremely embarrassed to have volunteered but not to have found the time to perform the review. Richard, I still hope to help review FreeCAD and its other deps, once this package is done, so please CC: me on the review requests when the time comes. Apologies to everyone for holding this up. John
(In reply to Sandro Mani from comment #41) > Taking for review. Full review below. Main points: > > ** MUST Items: ** > [!]: Provides: bundled(gnulib) in place as required. > Note: > [x]: Package contains no bundled libraries without FPC exception. > -> gnulib ok, add this link to spec: > https://fedorahosted.org/fpc/ticket/174, see > http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Will fix. > [!]: Package must own all directories that it creates. > -> Require: hicolor-icon-theme I used to do this but in discussion either on another review request or on the devel mailing list it was determined that RPM can handle this so is overkill to require it. > [!]: Only use %_sourcedir in very specific situations. > Note: %_sourcedir/$RPM_SOURCE_DIR is used. > See https://fedoraproject.org/wiki/Packaging:RPM_Source_Dir > See also OCE.src:183: E: use-of-RPM_SOURCE_DIR This is for copying all the icons to the right place, I'm using a bash for loop which means grabbing them directly rather than using the macros... I'm open to suggestions here. > OCE-foundation.x86_64: W: shared-lib-calls-exit > /usr/lib64/libTKernel.so.8.0.0 exit.5 > OCE-foundation.x86_64: W: shared-lib-calls-exit > /usr/lib64/libTKAdvTools.so.8.0.0 exit.5 > -> See for instance https://bugzilla.redhat.com/attachment.cgi?id=329912 Already reported upstream. Some fixed, other they think is OK due to specific use cases. https://github.com/tpaviot/oce/issues/490 > ** SHOULD Items: ** > [!]: Packages should try to preserve timestamps of original installed files. > -> Could install %SOURCEx files with -p Will fix. > [x]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in OCE- > foundation , OCE-modeling , OCE-ocaf , OCE-visualization , OCE-draw , > OCE-devel > -> Are automatic, but might be a good to make them explicit Hmm... I was letting the sonames drive the dependencies, I would rather leave it that way if that's OK. > Also: OCE-devel.x86_64: W: no-dependency-on OCE/OCE-libs/libOCE There is no OCE base package so this is expected. > OCE.src:303: W: macro-in-comment %{version} A library was dropped that I had commented out instead of removing, now gone. > > ** Extra Items: ** > [?]: Large data in /usr/share should live in a noarch subpackage if package > is > arched. > Note: Arch-ed rpms have a total of 4249600 bytes in /usr/share > -> Guess 4MB is okay Yeah, I don't really want to create another subpackage if it can be avoided. Thanks, Richard
Concerning the RPM_SOURCE_ISSUE: since it greatly increases the spec legibility I'd say we can consider it an exception as noted in https://fedoraproject.org/wiki/Packaging:RPM_Source_Dir, so ok.
Concerning the base package requirements: I'm not sure how to interpret [1] "When a subpackage requires the base package, it must do so using a fully versioned arch-specific (for non-noarch packages) dependency Requires: %{name}%{?_isa} = %{version}-%{release}" The result of having the requires autogenerated is basically the same, except that they are not fully versioned. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
(In reply to Sandro Mani from comment #45) > Concerning the base package requirements: I'm not sure how to interpret [1] > > "When a subpackage requires the base package, it must do so using a fully > versioned arch-specific (for non-noarch packages) dependency > Requires: %{name}%{?_isa} = %{version}-%{release}" > > The result of having the requires autogenerated is basically the same, > except that they are not fully versioned. While it may be technically questionable, it seems overboard to replicate something that RPM is already handling for you. To correct it I would have to manually check the requires of the subpackages for ones that are not provided within the package and then find what package provides them. Then I would have to keep this updated for new releases. The lack of versioned requires doesn't bother me since it's all coming from the same source archive and upstream does a good job of bumping the soversion when ABI incompatible changes are made.
OK, fine for me!
Ok, I have fixed the reference for the bundling exception in my spec file and can post new SPEC and SRPM if needed. I was looking at fixing "-p" for the source files but really these are all things I personally created so that drawexe has icons, a desktop file, etc., and are not part of the source archive so I don't think preserving the timestamps are meaningful. This seems to address everything so please let me know if anything else remains unaddressed.
Ok, approved!
New Package SCM Request ======================= Package Name: OCE Short Description: OpenCASCADE Community Edition Owners: hobbes1069 Branches: f20 InitialCC:
New Package SCM Request ======================= Package Name: OCE Short Description: OpenCASCADE Community Edition Owners: hobbes1069 Branches: f20 el6 epel7 InitialCC: Hopefully I caught this in time!
Requested package name OCE doesn't match bug summary OpenCASCADE, please correct.
Git done (by process-git-requests).
OCE-0.15-3.fc20.1,smesh-5.1.2.2-10.svn55.fc20,freecad-0.13-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/OCE-0.15-3.fc20.1,smesh-5.1.2.2-10.svn55.fc20,freecad-0.13-6.fc20
freecad-0.13-6.el6,smesh-5.1.2.2-10.svn55.el6,OCE-0.15-3.el6.1 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/freecad-0.13-6.el6,smesh-5.1.2.2-10.svn55.el6,OCE-0.15-3.el6.1
Package OCE-0.15-3.fc20.1, smesh-5.1.2.2-10.svn55.fc20, freecad-0.13-6.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing OCE-0.15-3.fc20.1 smesh-5.1.2.2-10.svn55.fc20 freecad-0.13-6.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6805/OCE-0.15-3.fc20.1,smesh-5.1.2.2-10.svn55.fc20,freecad-0.13-6.fc20 then log in and leave karma (feedback).
freecad-0.13-7.fc20, OCE-0.15-3.fc20.1, smesh-5.1.2.2-10.svn55.fc20 has been pushed to the Fedora 20 stable repository.
smesh-5.1.2.2-10.svn55.el6, OCE-0.15-3.el6.1 has been pushed to the Fedora EPEL 6 stable repository.