Spec URL: https://github.com/fangq/fedorapkg/blob/iso2mesh/octave-iso2mesh.spec SRPM URL: https://kwafoo.coe.neu.edu/~fangq/share/temp/octave-iso2mesh-1.9.1-1.fc30.src.rpm Description: Iso2Mesh is a MATLAB/Octave-based mesh generation toolbox, designed for easy creation of high quality surface and tetrahedral meshes from 3D volumetric images. It contains a rich set of mesh processing scripts/programs, working either independently or interacting with external free meshing utilities. Iso2Mesh toolbox can directly convert a 3D image stack, including binary, segmented or gray-scale images such as MRI or CT scans, into quality volumetric meshes. This makes it particularly suitable for multi-modality medical imaging data analysis and multi-physics modeling. Above all, iso2mesh is open-source. You can download it for free. You are also allowed to extend the toolbox for your own research and share with other users. Iso2Mesh is cross-platform and is compatible with both MATLAB and GNU Octave (a free MATLAB clone). Fedora Account System Username: fangq
rpmlint output for srpm: ------------------------------------------------------------------------------ $rpmlint /home/fangq/rpmbuild/SRPMS/octave-iso2mesh-1.9.1-1.fc30.src.rpm octave-iso2mesh.src: W: spelling-error Summary(en_US) volumetric -> cliometric octave-iso2mesh.src: W: spelling-error %description -l en_US volumetric -> cliometric octave-iso2mesh.src: W: spelling-error %description -l en_US modality -> morality, mortality 1 packages and 0 specfiles checked; 0 errors, 3 warnings. ------------------------------------------------------------------------------ rpmlint output for rpm: ------------------------------------------------------------------------------ rpmlint /home/fangq/rpmbuild/RPMS/noarch/octave-iso2mesh-1.9.1-1.fc30.noarch.rpm octave-iso2mesh.noarch: W: spelling-error Summary(en_US) volumetric -> cliometric octave-iso2mesh.noarch: W: spelling-error %description -l en_US volumetric -> cliometric octave-iso2mesh.noarch: W: spelling-error %description -l en_US modality -> morality, mortality octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalmesh octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalpoly octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsimp2 octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsurf octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/cork octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/jmeshlib octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix octave-iso2mesh.noarch: E: arch-independent-package-contains-binary-or-object /usr/share/octave/packages/iso2mesh-1.9.1/bin/tetgen1.5 octave-iso2mesh.noarch: W: dangerous-command-in-%preun mv 1 packages and 0 specfiles checked; 8 errors, 4 warnings. ------------------------------------------------------------------------------
This packaging request can be found in https://pagure.io/neuro-sig/NeuroFedora/issue/146 This package is configured as a "semi-noarch" package according to the comments in http://bugzilla.redhat.com/show_bug.cgi?id=1385257#c5 https://pagure.io/koji/issue/19 > "Sometimes the content in a package can be run anywhere, but some underlying dependency is only > available on a subset of arches" this suites this package quite well - most scripts can function without the binary dependencies in the bin/ folder, thus deserves the noarch designation. If I set the package BuildArch to anything other than noarch, rpmbuild will fail because something in macros.octave does not seem to support arch dependent files, this seems to be related to this bug https://bugzilla.redhat.com/show_bug.cgi?id=1413450
I'm looking at the spec now. Each spec should only build one software. Here, the spec is building 4 different tools? (tetgen is already in Fedora, by the way, so it must be used as a BuildRequires or Requires as required: https://apps.fedoraproject.org/packages/tetgen) This spec should be limited to iso2mesh, and if the others are dependencies, they must be packaged separately. (I know this means more reviews, but the point is that each tool must be installable on its own also.)
@Ankur, thanks for the review. see my replies below. > Here, the spec is building 4 different tools? No. the spec is for building iso2mesh only - the tools you saw are used internally by iso2mesh and are not meant for shared by other packages (or directly called by users). several of these utilities were modified/customized version specifically for iso2mesh (such as the CGAL tools and cork); other utilities were included in iso2mesh because the meshing result is sensitive to these utilities versions, if I let user to call system-installed tools, such as tetgen, the meshing output will not be reproducible across computers. I also want to mention that these tools are only used by about 5-10% of the functions in iso2mesh. They are dependencies, but weak dependencies. > tetgen is already in Fedora, by the way, so it must be used as a BuildRequires or Requires as required I can remove tetgen from iso2mesh package and add a link in its place to use the system installed tetgen, but the risk is that iso2mesh output will not be deterministic. > if the others are dependencies, they must be packaged separately. (I know this means more reviews, but the point is that each tool must be installable on its own also.) again, my purpose of including these utilities inside iso2mesh is to ensure that the meshing output is reproducible (many utilities generate very different output from version to version, such as CGAL and tetgen); also such inclusion was permitted under their respective open-source licenses. It is fine if someone want to package these tools as separate packages, but 1) the tools that iso2mesh used are either modified, or older versions, 2) I am not the upstream author of these utilities , for example, I am not the author of cork (upstream repo: https://github.com/gilbo/cork), iso2mesh uses a modified version in my fork (https://github.com/fangq/cork). So, if we package my fork as the official package, I am not sure how to accommodate the upstream development in the future. I do want to mention that iso2mesh currently contains a copy of jsonlab and jnifti (used by a couple of file io functions). Because "pkg load" in octave can't check/load dependencies, AFAIK, so I think including a copy of these toolboxes in iso2mesh is a more portable approach, despite some redundancy.
(In reply to Qianqian Fang from comment #4) > @Ankur, thanks for the review. see my replies below. > > > Here, the spec is building 4 different tools? > > No. the spec is for building iso2mesh only - the tools you saw are used > internally by iso2mesh and are not meant for shared by other packages (or > directly called by users). OK, so they're "private". That's fine then. Could we add comments to the spec to say so please, just for the benefit of other package maintainers who would probably end up asking the same questions as me otherwise? :) > > several of these utilities were modified/customized version specifically for > iso2mesh (such as the CGAL tools and cork); other utilities were included in > iso2mesh because the meshing result is sensitive to these utilities > versions, if I let user to call system-installed tools, such as tetgen, the > meshing output will not be reproducible across computers. OK, but we can specify versioned dependencies, would that work? Of course, it depends on whether or not the Fedora packages are carrying the version you need. Fedora generally carries the latest versions, though---and that in a way helps us remind developers to update their code bases too: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ Bundling is no longer forbidden in Fedora, but if at all possible, it should be avoided: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling > > I also want to mention that these tools are only used by about 5-10% of the > functions in iso2mesh. They are dependencies, but weak dependencies. Sure, they can be specified as weak deps if needed also: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/ > > > > tetgen is already in Fedora, by the way, so it must be used as a BuildRequires or Requires as required > > I can remove tetgen from iso2mesh package and add a link in its place to use > the system installed tetgen, but the risk is that iso2mesh output will not > be deterministic. Is there a way of checking this maybe? Is there a testsuite, for example? The version of tetgen in Fedora is 1.5.x. > > > if the others are dependencies, they must be packaged separately. (I know this means more reviews, but the point is that each tool must be installable on its own also.) > > again, my purpose of including these utilities inside iso2mesh is to ensure > that the meshing output is reproducible (many utilities generate very > different output from version to version, such as CGAL and tetgen); also > such inclusion was permitted under their respective open-source licenses. Sure, I understand that, but please see comments I've made before. > > It is fine if someone want to package these tools as separate packages, but > 1) the tools that iso2mesh used are either modified, or older versions, 2) I > am not the upstream author of these utilities , for example, I am not the > author of cork (upstream repo: https://github.com/gilbo/cork), iso2mesh uses > a modified version in my fork (https://github.com/fangq/cork). So, if we > package my fork as the official package, I am not sure how to accommodate > the upstream development in the future. I've looked at cork---upstream is inactive, has been for a while, and from the README, it really does not look like they'll actively maintain the project in the future either. I've built it using your patches, and I had to tweak the Makefile to get it to generate shared libraries also---static libraries are discouraged: https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries https://ankursinha.fedorapeople.org//cork/ If that will do, I can submit it for review? > > > I do want to mention that iso2mesh currently contains a copy of jsonlab and > jnifti (used by a couple of file io functions). Because "pkg load" in octave > can't check/load dependencies, AFAIK, so I think including a copy of these > toolboxes in iso2mesh is a more portable approach, despite some redundancy. I'll have to check this up. Maybe we can speak to the Octave maintainer on the sci-tech mailing list to see what the best way of handling these are? https://lists.fedoraproject.org/admin/lists/scitech.lists.fedoraproject.org/
Remove ExclusiveArch: %{ix86} x86_64 BuildArch: noarch and: %global _binaries_in_noarch_packages_terminate_build 0 %global debug_package %{nil} - Build errors: CMake Error at CMakeLists.txt:5 (project): No CMAKE_CXX_COMPILER could be found. Tell CMake where to find the compiler by setting either the environment variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. -- Configuring incomplete, errors occurred! Add gcc-c++ as a BR - Build fails then: -- Build files have been written to: /builddir/build/BUILD/iso2mesh-1.9.1/tools/tetgen make -C tetgen --no-print-directory g++ -O0 -c predicates.cxx g++ -O3 -o tetgen tetgen.cxx predicates.o -lm cp: cannot stat 'cgalmesh/mesh_3D_image': No such file or directory make: *** [commons/Makefile_common.mk:71: copybin] Error 1 Digging around, I found: -- NOTICE: The examples mesh_3D_image.cpp and mesh_3D_image_variable_size.cpp need CGAL_ImageIO to be configured with ZLIB support, and will not be compiled. Thus BR zlib-devel + %octave_pkg_build /var/tmp/rpm-tmp.SoTVjv: line 38: fg: no job control You need to: BuildRequires: octave-devel - Use set_build_flags to get debuginfos: %build %set_build_flags
@Robert-Andre, thanks for the feedback. I updated the spec file with the changes you suggested https://github.com/fangq/fedorapkg/commit/8f85a65af6a745f8358833aedbbe6c5df7f36eb9 but now the package cannot be built any more on my fc30 vm. I am getting the same error I got previously https://pagure.io/neuro-sig/NeuroFedora/issue/146#comment-602139 which was previously resolved by forcing BuildArch to noarch. https://pagure.io/neuro-sig/NeuroFedora/issue/146#comment-602191 are you able to reproduce this error? if not, can you let me know what is your testing environment? thanks
As I said in the other ticket, please test the build against rawhide instead of f30. (fedpkg --release f32 ... should do it) I ran a test build, and if succeeds for all architectures other than arm: https://koji.fedoraproject.org/koji/taskinfo?taskID=38115425
Probably related to bug https://bugzilla.redhat.com/show_bug.cgi?id=1733898 and https://src.fedoraproject.org/rpms/octave/c/c32f37ff6c776af9486f4f128b2a87e1055e420a?branch=master So it should work on F31 and F32 but fail below?
It should work on F30 by redefining octave_tar_suffix after octave_pkg_build: %octave_pkg_build %global octave_tar_suffix any-none
@FranciscoD and @eclipseo, my spec file is updated according to your feedback https://github.com/fangq/fedorapkg/commit/72e3319103a36a1d9aa7f99052fb09646ca19863 @FranciscoD: the error on arm was caused by exhausted memory when compiling cgal tools. newer versions of CGAL library seems to require a min memory to build. I previously saw this error on the fc30 vm if I allocate 2GB memory, but it goes away when setting a higher memory. I can either list arm under ExcludeArch or find a flag to increase the memory (if possible). Regarding cork, if it helps, the merged patch to the upstream inactive repo can be found in this pull request https://github.com/gilbo/cork/pull/32 For your cork package spec file, it looks good to me. let me know if you want me to drop cork/tetgen from my source list and add a link to these packages (or it is ok for my to keep a private copy). also, I am wondering if there is any policy against using exe packer (such as upx) to compress binary files during %build? the generated cgal binaries are quite bulky using the newer libraries, if I call "upx -9 bin/cgal*", I can drop the bin file sizes by 10x (also make file faster to load). do you want me to add that compression command (and also add upx in BuildRequires)?
- Problem installing the package: DEBUG util.py:593: Error: DEBUG util.py:593: Problem: conflicting requests DEBUG util.py:593: - nothing provides CGAL needed by octave-iso2mesh-1.9.1-1.fc32.x86_64 DEBUG util.py:595: (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) CGAL.spec 5.0 has now this comment: # CGAL-5.0 is now a header-only library, with dependencies. It no # longer has any binary to build, but cannot be noarch because of # arch-specific dependencies It doesn't provide a CGAL binary anymore. - Own these directories: %{octpkgdir}/doc/ %{octpkgdir}/bin/ [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/share/octave/packages/iso2mesh-1.9.1/bin, /usr/share/octave/packages/iso2mesh-1.9.1/doc - Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 1382400 bytes in 31 files. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_documentation Make a separate doc noarch subpackage containing the sample/ dir - [!]: Rpath absent or only used for internal libs. Note: See rpmlint output Remove Rpath from bin/meshfix octave-iso2mesh.x86_64: E: binary-or-shlib-defines-rpath /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix ['/builddir/build/BUILD/iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/lib'] I think the best path to do this is to patch out: link_directories( ${LINK_DIRECTORIES} ${CMAKE_CURRENT_SOURCE_DIR}/contrib/JMeshLib/lib ) from meshfix CMakeLists.txt #meshfix-remove-rpath.patch diff -up a/CMakeLists.txt.orig b/CMakeLists.txt --- a/CMakeLists.txt.orig 2019-10-01 18:39:42.000000000 +0200 +++ b/CMakeLists.txt 2019-10-07 20:06:44.072901788 +0200 @@ -8,10 +8,6 @@ include_directories( contrib/OpenNL3.2.1/src contrib/jrs_predicates ) -link_directories( - ${LINK_DIRECTORIES} - ${CMAKE_CURRENT_SOURCE_DIR}/contrib/JMeshLib/lib -) file(GLOB meshfix_h include/*.h) set(meshfix_src contrib/jrs_predicates/jrs_predicates.c Patch0: meshfix-remove-rpath.patch […] %prep %setup -q -b 1 -n %{octpkg}-%{version} %setup -q -T -D -b 2 -n meshfix-1.2.1 %patch0 -p1 %setup -q -T -D -b 3 -n %{octpkg}-%{version} (See http://ftp.rpm.org/max-rpm/s1-rpm-inside-macros.html for %setup flags, -T -D is necessary to avoid multiple unzipping of Source0) Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package installs properly. Note: Installation errors (see attachment) See: https://docs.fedoraproject.org/en-US/packaging-guidelines/ - Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 1382400 bytes in 31 files. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_documentation ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [!]: Rpath absent or only used for internal libs. Note: See rpmlint output [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) 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. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "GPL (v3 or later)", "*No copyright* Q Public License (v1.0) GNU General Public License GNU Lesser General Public License", "BSD (unspecified)", "*No copyright* BSD (unspecified)", "*No copyright* GNU Lesser General Public License", "AGPL (v3 or later)", "GNU Lesser General Public License (v3 or later)", "GPL (v2 or later)", "BSD 3-clause "New" or "Revised" License", "Expat License". 306 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/octave- iso2mesh/review-octave-iso2mesh/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/share/octave/packages/iso2mesh-1.9.1/bin, /usr/share/octave/packages/iso2mesh-1.9.1/doc [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: 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. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: Package does not own files or directories owned by other packages. [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]: Dist tag is present. [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 does not use a name that already exists. [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: [x]: Uses parallel make %{?_smp_mflags} macro. [-]: 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). [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [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]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. [!]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 10352640 bytes in /usr/share octave-iso2mesh-1.9.1-1.fc32.x86_64.rpm:10352640 See: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: octave-iso2mesh-1.9.1-1.fc32.x86_64.rpm octave-iso2mesh-debuginfo-1.9.1-1.fc32.x86_64.rpm octave-iso2mesh-debugsource-1.9.1-1.fc32.x86_64.rpm octave-iso2mesh-1.9.1-1.fc32.src.rpm octave-iso2mesh.x86_64: W: spelling-error Summary(en_US) volumetric -> cliometric octave-iso2mesh.x86_64: W: spelling-error %description -l en_US volumetric -> cliometric octave-iso2mesh.x86_64: W: spelling-error %description -l en_US modality -> morality, mortality octave-iso2mesh.x86_64: E: binary-or-shlib-defines-rpath /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix ['/builddir/build/BUILD/iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/lib'] octave-iso2mesh.x86_64: W: dangerous-command-in-%preun mv octave-iso2mesh.src: W: spelling-error Summary(en_US) volumetric -> cliometric octave-iso2mesh.src: W: spelling-error %description -l en_US volumetric -> cliometric octave-iso2mesh.src: W: spelling-error %description -l en_US modality -> morality, mortality 4 packages and 0 specfiles checked; 1 errors, 7 warnings.
@eclipseo, I made the following changes according to your above comments: changeset 1: https://github.com/fangq/fedorapkg/commit/c6574e3ec3b41240fb4f3aecd35f19889932a802 this addresses the CGAL header-only mode dependency, meshfix patch that you created, -D -T flags in setup, and ownership of doc/ and bin/ changeset 2: https://github.com/fangq/fedorapkg/commit/bbd84a88cdad40dfd82b7634c27c5943cd9fc9e2 split the samples into a separate sub-package iso2mesh-demos. the current spec file can be found at https://github.com/fangq/fedorapkg/tree/iso2mesh the updated spec file builds fine on f30. I did not test it on rawhide (not sure how to do it) regarding the CGAL-5.0 dependency issue. let me know if your preference on tetgen1.5 - whether to use it as dependency and create link in my bin/ folder, or use the embedded version for stability.
- Typo: #else → %else - Make the new subpackage noarch Package approved, please fix the aforementioned issue before import.
thanks, the mentioned issues are fixed https://github.com/fangq/fedorapkg/commit/94aa38ef29203635d7f62117f1b660e3e50610d8 https://github.com/fangq/fedorapkg/blob/iso2mesh/octave-iso2mesh.spec I have two minor questions: 1. I changed the below line BuildArch: i686 x86_64 aarch64 ppc64le s390x to ExcludeArch: armv7hl is this ok? or explicitly setting BuildArch is preferred? 2. Installing the main package, and I noticed the below files/folders, I think these are related to the executables under the the bin folder. are these files desirable? if not, how do I get rid of them? [fangq@localhost fedorapkg]$ rpm -ql octave-iso2mesh /usr/lib/.build-id /usr/lib/.build-id/4d /usr/lib/.build-id/4d/cba156e0259c317936d0c1ade115ec4d3aba4e /usr/lib/.build-id/5c /usr/lib/.build-id/5c/82b58fba63341b50ecb9979c58f6b9d4743d34 /usr/lib/.build-id/88 /usr/lib/.build-id/88/d267d7db7b09c94bb0f24ce5299be052f2a8b4 /usr/lib/.build-id/97 /usr/lib/.build-id/97/27a7c7d6d6a38355950e0f5690fa552d557cda /usr/lib/.build-id/d8 /usr/lib/.build-id/d8/7848c94ba78111893400d8923783cca5718277 /usr/lib/.build-id/d9 /usr/lib/.build-id/d9/d9f70ad320e7b8e1a2e3b50fc4a6f60c20e286 /usr/lib/.build-id/e7 /usr/lib/.build-id/e7/9bc8e41ef0ab97dc306d128d04de0d0cf97f1a /usr/lib/.build-id/ef /usr/lib/.build-id/ef/f3e81fa24fff8c68dd79394962ac7f8c1fc8fe
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/octave-iso2mesh
just want to report a problem when building the package (but I have found a solution). using the above spec file, when I ran fedpkg build, the job failed initially - I tried both rawhide and f30, both failed, here are the logs https://koji.fedoraproject.org/koji/taskinfo?taskID=38151144 https://koji.fedoraproject.org/koji/taskinfo?taskID=38152397 looking at the build.log file, both seemed to returned an error when cgal is linking the first target, although no explicit error message was printed. I realized that this may be caused by the large memory footprint needed for compiling/linking cgal binaries (which crashed the arm target previously in Ankur's test). But when I ran the spec file in my f30 vm, it did work. then I realized that this might be a problem due to %make_build, which is basically running multiple make in parallel - because compiling cgal codes needs a lot of memory, running multiple makes might have exhausted the vm's memory and caused the failure. so, I reverted the %make_build line back to "make" to use sequential compilation, https://src.fedoraproject.org/rpms/octave-iso2mesh/c/7971faf3a3dcf4df956474630566a0e150196008?branch=master this time, the build succeeded https://koji.fedoraproject.org/koji/buildinfo?buildID=1397854 so, I will leave the make there and added a comment above it. https://src.fedoraproject.org/rpms/octave-iso2mesh/c/3135659947bea0410ed4a3dd0cc56e3798549094?branch=master -------------------------------------------- PS: hold on a second, it looks like f31 and f32 worked, but f29 and f30 failed https://koji.fedoraproject.org/koji/packageinfo?packageID=30110 reading the build.log files, I see two causes 1. on f29, the error appears to be package "gcc-g++" was not available to install, see https://kojipkgs.fedoraproject.org//work/tasks/4014/38154014/root.log DEBUG util.py:593: No matching package to install: 'gcc-g++' 2. on f30, even though the task summary says "see root.log" for more info, but the actual error was in build.log, where the cgal compilation failed as it did initially using %make_build. I am not sure any more. suggestions are appreciated
ok, fixing the typo (gcc-g++ -> gcc-c++) fixed the f29 and f30 build errors. perhaps this was also the cause for the initial error. I am going to revert the %make_build flag and see what happens. I tried to rebuild f32/f31 packages using "fedpkg build --skip-nvr-check" but both failed and returned an error "Build already exists". How can I force rebuilding? the spec files were patched.
FEDORA-2019-79f3a89b27 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-79f3a89b27
octave-iso2mesh-1.9.1-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-79f3a89b27
I love to see iso2mesh packaged in Fedora, but there have been error in this review. Even rpmlint can see them: [lrineau@bonnard]~% rpm -q octave-iso2mesh; rpmlint octave-iso2mesh octave-iso2mesh-1.9.1-1.fc30.x86_64 octave-iso2mesh.x86_64: E: devel-dependency gmp-devel octave-iso2mesh.x86_64: W: spelling-error Summary(en_US) volumetric -> cliometric octave-iso2mesh.x86_64: W: spelling-error %description -l en_US volumetric -> cliometric octave-iso2mesh.x86_64: W: spelling-error %description -l en_US modality -> morality, mortality octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalmesh octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalpoly octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsimp2 octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsurf octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/cork octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/jmeshlib octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share /usr/share/octave/packages/iso2mesh-1.9.1/bin/tetgen1.5 octave-iso2mesh.x86_64: W: dangerous-command-in-%preun mv 1 packages and 0 specfiles checked; 9 errors, 4 warnings. Plus: tetgen is already packaged in Fedora. Should I fill new bugs for that? Qianqian Fang: I am willing to help with those issues, if you agree.
@Laurent, thanks for chiming in. I just tested octave-iso2mesh on f30 in updates-testing repo, the installation and execution was fine. regarding your comments 1. the arch-dependent-file-in-usr-share will be triggered as long as the octave package contains a mex file (like in octave-zmat and octave-mcxlab that I just created/pushed), or in this case, bundled executables. I currently don't see other workaround for removing this error; the earlier two reviewers, Ankur Sinha and Robert-André Mauchin seemed to be ok with that too. 2. regarding tetgen, please see Comment 4 and Comment 5 for the discussions. These are internal tools and are not intend to be called outside of iso2mesh. I prefer to bundle these tools as much as possible to allow a mesh reproduced across platforms, and does not reply on the versions of a tool installed on a user's system (wish I could do the same for cgal, but it is too big to be bundled internally). Many of my other tools (such as mmc: http://mcx.space/#mmc) rely on a reproducible mesh to run examples correctly. Also, bundling this utility is allowed by their respective licenses. if you are ok with these, I am going to push updates to and f29/f31. f30/rawhide already contains the built package.
@Laurent, regarding my question in the cgal-discuss mailing list, it turned out that the large executable sizes were results of debug info in the generated executables. Fortunately, rpm automatically stripped these big executables files and export the extracted the debug info into a separate package called octave-iso2mesh-debuginfo...rpm and octave-iso2mesh-debugsource-...rpm; the final executables after stripping are not that big, so I will leave the building script as is for now.
(In reply to Laurent Rineau from comment #21) > I love to see iso2mesh packaged in Fedora, but there have been error in this > review. Even rpmlint can see them: > > [lrineau@bonnard]~% rpm -q octave-iso2mesh; rpmlint octave-iso2mesh > octave-iso2mesh-1.9.1-1.fc30.x86_64 > octave-iso2mesh.x86_64: E: devel-dependency gmp-devel > octave-iso2mesh.x86_64: W: spelling-error Summary(en_US) volumetric -> > cliometric > octave-iso2mesh.x86_64: W: spelling-error %description -l en_US volumetric > -> cliometric > octave-iso2mesh.x86_64: W: spelling-error %description -l en_US modality -> > morality, mortality > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalmesh > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalpoly > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsimp2 > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsurf > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cork > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/jmeshlib > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/tetgen1.5 > octave-iso2mesh.x86_64: W: dangerous-command-in-%preun mv > 1 packages and 0 specfiles checked; 9 errors, 4 warnings. > > > Plus: tetgen is already packaged in Fedora. > > Should I fill new bugs for that? > > Qianqian Fang: I am willing to help with those issues, if you agree. This is where bundling gets ugly. :( So, bundling tetgen etc if fine if necessary, but the binaries should not be in /usr/share. That violates the FHS as rpmlint points out. Can they be moved to an arch specific directory, preferably %{_libdir}/isomesh/... (so they remain private and do not clash with the system tetgen libraries + binaries), which will expand to /usr/lib/isomesh/ and /usr/lib64/isomesh according to the architecture of the machine? Please also specify that these are bundled by iso2mesh. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling refers to libraries, so maybe we'll need to speak to the FPC about bundling binaries. Provides: bundled(tetgen) ... (In reply to Qianqian Fang from comment #22) > @Laurent, thanks for chiming in. > > I just tested octave-iso2mesh on f30 in updates-testing repo, the > installation and execution was fine. > > regarding your comments > > 1. the arch-dependent-file-in-usr-share will be triggered as long as the > octave package contains a mex file (like in octave-zmat and octave-mcxlab > that I just created/pushed), or in this case, bundled executables. I > currently don't see other workaround for removing this error; the earlier > two reviewers, Ankur Sinha and Robert-André Mauchin seemed to be ok with > that too. Please see above. > > 2. regarding tetgen, please see Comment 4 and Comment 5 for the discussions. > These are internal tools and are not intend to be called outside of > iso2mesh. I prefer to bundle these tools as much as possible to allow a mesh > reproduced across platforms, and does not reply on the versions of a tool > installed on a user's system (wish I could do the same for cgal, but it is > too big to be bundled internally). Many of my other tools (such as mmc: > http://mcx.space/#mmc) rely on a reproducible mesh to run examples > correctly. Also, bundling this utility is allowed by their respective > licenses. I understand this, but as I did say in my comments---do we have an idea of how sensitive iso2mesh is to tetgen? What is required of tetgen to ensure reproducibility? If tetgen on different platforms yields different results, does that mean that all tools that rely on tetgen are always affected and will always bundle it?
(In reply to Laurent Rineau from comment #21) > I love to see iso2mesh packaged in Fedora, but there have been error in this > review. Even rpmlint can see them: > > [lrineau@bonnard]~% rpm -q octave-iso2mesh; rpmlint octave-iso2mesh > octave-iso2mesh-1.9.1-1.fc30.x86_64 > octave-iso2mesh.x86_64: E: devel-dependency gmp-devel You should remove the dependency to 'gmp-devel'. The dependency to 'gmp' will be found automatically once the binaries are correctly installed according to Fedora's rules. > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalmesh > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalpoly > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsimp2 > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsurf > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cork > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/jmeshlib > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/tetgen1.5 All those "tools" should be in /usr/libexec/iso2mesh/ instead of /usr/share/octave/packages/iso2mesh-1.9.1/bin/. The mex files should be able to run the tools. If you want to be lazy, just move the tools into /usr/libexec/iso2mesh/ and package symbolic links in /usr/share/octave/packages/iso2mesh-1.9.1/bin/. (In reply to Qianqian Fang from comment #22) > 2. regarding tetgen, please see Comment 4 and Comment 5 for the discussions. > These are internal tools and are not intend to be called outside of > iso2mesh. I prefer to bundle these tools as much as possible to allow a mesh > reproduced across platforms, and does not reply on the versions of a tool > installed on a user's system (wish I could do the same for cgal, but it is > too big to be bundled internally). Many of my other tools (such as mmc: > http://mcx.space/#mmc) rely on a reproducible mesh to run examples > correctly. Also, bundling this utility is allowed by their respective > licenses. All right. The guidelines at https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling says 'SHOULD' and not 'MUST'. As for CGAL, as CGAL is a header-only library of C++ templates, you just have to be careful when the package is rebuilt.
And the License declaration of the package is wrong. As the package bundles other software, the licensing is complicated. (In reply to Robert-André Mauchin from comment #12) > [x]: License field in the package spec file matches the actual license. > Note: Checking patched sources after %prep for licenses. Licenses > found: "Unknown or generated", "GPL (v3 or later)", "*No copyright* Q > Public License (v1.0) GNU General Public License GNU Lesser General > Public License", "BSD (unspecified)", "*No copyright* BSD > (unspecified)", "*No copyright* GNU Lesser General Public License", > "AGPL (v3 or later)", "GNU Lesser General Public License (v3 or > later)", "GPL (v2 or later)", "BSD 3-clause "New" or "Revised" > License", "Expat License". 306 files have unknown license. Detailed > output of licensecheck in /home/bob/packaging/review/octave- > iso2mesh/review-octave-iso2mesh/licensecheck.txt Here we can see that the license checker has detected a lot of licenses (including AGPLv3+ and GPLv2), so the package cannot be just GPLv3+.
> So, bundling tetgen etc if fine if necessary, but the binaries should not be in /usr/share. That violates the FHS as rpmlint points out. Can they be moved to an arch specific directory, preferably %{_libdir}/isomesh/... (so they remain private and do not clash with the system tetgen libraries + binaries), which will expand to /usr/lib/isomesh/ and /usr/lib64/isomesh according to the architecture of the machine? ok, if I want to put those in %{_libdir}/isomesh/ and create symbolic links under iso2mesh/bin, do you mind showing me how to do it? my latest spec file can be found here, would be great if you can send me a pull request, thanks https://github.com/fangq/fedorapkg/tree/iso2mesh > Here we can see that the license checker has detected a lot of licenses (including AGPLv3+ and GPLv2), so the package cannot be just GPLv3+. all the licenses included in this software are GPLv3+ compatible, except AGPLv3+, which is stricter, although it is also listed under GPL compatible licenses https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses which means I can declare all of them under the GPLv3+ license as a full package. If I have to distinguish GPLv3+ and AGPLv3+, please suggest how to do it. I want to make sure that AGPLv3+ only covers tetgen, but not other part of the software (which are covered under GPLv3+).
You're right, Tetgen is AGPLv3 amd JMeshLib is GPLv2, but I didn't understand it was into the resulting binary: AGPL (v3 or later) ------------------ iso2mesh-1.9.1/tools/tetgen/LICENSE GPL (v2 or later) ----------------- iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/binTree.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/clusterGraph.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/dijkstraGraph.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/edge.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/graph.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/heap.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/j_mesh.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/jmesh.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/jqsort.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/list.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/matrix.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/point.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/tin.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/triangle.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/include/vertex.h iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/JMESH/jmesh.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/MESH_STRUCTURE/checkAndRepair.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/MESH_STRUCTURE/edge.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/MESH_STRUCTURE/io.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/MESH_STRUCTURE/point.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/MESH_STRUCTURE/tin.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/MESH_STRUCTURE/triangle.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/MESH_STRUCTURE/vertex.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/binTree.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/clusterGraph.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/dijkstraGraph.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/graph.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/heap.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/jqsort.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/list.cpp iso2mesh-1.9.1/tools/meshfix/contrib/JMeshLib/src/PRIMITIVES/matrix.cpp iso2mesh-1.9.1/tools/meshfix/include/detectIntersections.h iso2mesh-1.9.1/tools/meshfix/include/epsilonSampling.h iso2mesh-1.9.1/tools/meshfix/include/exttrimesh.h iso2mesh-1.9.1/tools/meshfix/include/holeFilling.h iso2mesh-1.9.1/tools/meshfix/include/simplification.h iso2mesh-1.9.1/tools/meshfix/include/sparseLSystem.h iso2mesh-1.9.1/tools/meshfix/src/detectIntersections.cpp iso2mesh-1.9.1/tools/meshfix/src/epsilonSampling.cpp iso2mesh-1.9.1/tools/meshfix/src/holeFilling.cpp iso2mesh-1.9.1/tools/meshfix/src/simplification.cpp iso2mesh-1.9.1/tools/meshfix/src/smoothing.cpp iso2mesh-1.9.1/tools/meshfix/src/sparseLSystem.cpp iso2mesh-1.9.1/tools/meshfix/src/uniform.cpp They should be added to the License: field > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalmesh > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalpoly > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsimp2 > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cgalsurf > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/cork > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/jmeshlib > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/meshfix > octave-iso2mesh.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/octave/packages/iso2mesh-1.9.1/bin/tetgen1.5 >All those "tools" should be in /usr/libexec/iso2mesh/ instead of >/usr/share/octave/packages/iso2mesh-1.9.1/bin/. The mex files should be >able to run the tools. If you want to be lazy, just move the tools into >/usr/libexec/iso2mesh/ and package symbolic links in /usr/share/octave >/packages/iso2mesh-1.9.1/bin/. I concir, these error did not show up in my rpmlint output as seen above. They shouldn't be in %_datadir, most likely in bindir or libexecdir.
(In reply to Qianqian Fang from comment #27) > > > Here we can see that the license checker has detected a lot of licenses (including AGPLv3+ and GPLv2), so the package cannot be just GPLv3+. > > all the licenses included in this software are GPLv3+ compatible, except > AGPLv3+, which is stricter, although it is also listed under GPL compatible > licenses > > https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses > > which means I can declare all of them under the GPLv3+ license as a full > package. If I have to distinguish GPLv3+ and AGPLv3+, please suggest how to > do it. I want to make sure that AGPLv3+ only covers tetgen, but not other > part of the software (which are covered under GPLv3+). You need to add a comment explaining the breakdown # Main package: GPLv3+ # JMeshLib: GPLv2 # Tetgen: AGPLv3+ License: GPLv3+ and GPLv2 and AGPLv3+
FEDORA-2019-33bd7a597c has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-33bd7a597c
FEDORA-2019-fec9adc180 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fec9adc180
(In reply to Robert-André Mauchin from comment #29) > You need to add a comment explaining the breakdown > > # Main package: GPLv3+ > # JMeshLib: GPLv2 > # Tetgen: AGPLv3+ > License: GPLv3+ and GPLv2 and AGPLv3+ JMeshLib is GPLv2+.
octave-iso2mesh-1.9.1-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fec9adc180
@Ankur, @Robert-Andre and @Laurent, thank you all for the comments and help on creating this package. the latest spec file can be found on the src git site: https://src.fedoraproject.org/rpms/octave-iso2mesh/blob/master/f/octave-iso2mesh.spec In the -3 version of this initial package, all the above mentioned issues were addressed, including - thanks for Rob's patch, the binaries are now moved to /usr/libexec, and some of the license issues found by @Laurent - per early discussions on setting octave-pkg-level dependency to get better modulation, I was able to get help from Mike Miller from the octave mailing list, and made the following patch https://src.fedoraproject.org/rpms/octave-iso2mesh/c/2a98febb8e720aa03fc2f87f8744a379f4fe69db?branch=master basically, rpm takes care of the rpm-package level dependency, and Depends in DESCRIPTION file also load dependencies in octave; because this is possible now, I have removed the duplicate functions from jsonlab and jnifti from iso2mesh - the gmp-devel dependency was removed, but I don't understand why rpmlint calls this an error (the binaries clearly needs this library) - per Ankur's comment earlier, it does no harm to explicitly define such dependency despite overlapping, but seems rpmlint treats this as an conflict. - the licenses of sub-tools are clarified in the comments the below are no longer an issue any more, but I want to keep a note here - I changed %make_build to make because it failed building the package on f31/f32; I later on reverted it to "%make_build" again, and that change once again failed the builds - the last line before failing is linking the cgal binaries. So, it is clear there is some issue using %make_build (i.e. SMP parallel building) with cgal targets, @Laurent, is this a known issue for CGAL? The log for one of the failed task can be found here https://src.fedoraproject.org/rpms/octave-iso2mesh/c/2a98febb8e720aa03fc2f87f8744a379f4fe69db?branch=master - now I put arm as ExcludeArch, because @Ankur had a failed build on arm, and the error was "virtual memory exhausted" for CGAL, see https://koji.fedoraproject.org/koji/taskinfo?taskID=38115425 , if we have a way to build on arm, I will drop the ExcludeArch, but this is not a priority I am going to close this ticket for now, thanks again. feel free to reopen if any issue appears.
sorry, for the failed %make_build log, please see the below link instead https://koji.fedoraproject.org/koji/taskinfo?taskID=38209438
FEDORA-2019-a94d821b53 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a94d821b53
FEDORA-2019-09a3e14f40 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-09a3e14f40
FEDORA-2019-63ea1f8fbf has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-63ea1f8fbf
octave-iso2mesh-1.9.1-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a94d821b53
octave-iso2mesh-1.9.1-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-09a3e14f40
octave-iso2mesh-1.9.1-3.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-63ea1f8fbf
(In reply to Qianqian Fang from comment #34) > @Ankur, @Robert-Andre and @Laurent, thank you all for the comments and help > on creating this package. > > the latest spec file can be found on the src git site: > https://src.fedoraproject.org/rpms/octave-iso2mesh/blob/master/f/octave- > iso2mesh.spec > > In the -3 version of this initial package, all the above mentioned issues > were addressed, including > > - thanks for Rob's patch, the binaries are now moved to /usr/libexec, and > some of the license issues found by @Laurent > > - per early discussions on setting octave-pkg-level dependency to get better > modulation, I was able to get help from Mike Miller from the octave mailing > list, and made the following patch > https://src.fedoraproject.org/rpms/octave-iso2mesh/c/ > 2a98febb8e720aa03fc2f87f8744a379f4fe69db?branch=master > basically, rpm takes care of the rpm-package level dependency, and Depends > in DESCRIPTION file also load dependencies in octave; because this is > possible now, I have removed the duplicate functions from jsonlab and jnifti > from iso2mesh > > - the gmp-devel dependency was removed, but I don't understand why rpmlint > calls this an error (the binaries clearly needs this library) - per Ankur's > comment earlier, it does no harm to explicitly define such dependency > despite overlapping, but seems rpmlint treats this as an conflict. > > - the licenses of sub-tools are clarified in the comments > > > the below are no longer an issue any more, but I want to keep a note here > > - I changed %make_build to make because it failed building the package on > f31/f32; I later on reverted it to "%make_build" again, and that change once > again failed the builds - the last line before failing is linking the cgal > binaries. So, it is clear there is some issue using %make_build (i.e. SMP > parallel building) with cgal targets, @Laurent, is this a known issue for > CGAL? The log for one of the failed task can be found here > > https://src.fedoraproject.org/rpms/octave-iso2mesh/c/ > 2a98febb8e720aa03fc2f87f8744a379f4fe69db?branch=master That is fine. If the tool does not support parallel make, you can use simple make (with -j1). > > - now I put arm as ExcludeArch, because @Ankur had a failed build on arm, > and the error was "virtual memory exhausted" for CGAL, see > https://koji.fedoraproject.org/koji/taskinfo?taskID=38115425 , if we have a > way to build on arm, I will drop the ExcludeArch, but this is not a priority The guidelines require you to file a bug. Please do that if you haven't done so yet: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_support > > I am going to close this ticket for now, thanks again. feel free to reopen > if any issue appears.
(In reply to Qianqian Fang from comment #34) > @Ankur, @Robert-Andre and @Laurent, thank you all for the comments and help > on creating this package. > > the latest spec file can be found on the src git site: > https://src.fedoraproject.org/rpms/octave-iso2mesh/blob/master/f/octave- > iso2mesh.spec > > In the -3 version of this initial package, all the above mentioned issues > were addressed, including > > - thanks for Rob's patch, the binaries are now moved to /usr/libexec, and > some of the license issues found by @Laurent Great, thanks! > - the gmp-devel dependency was removed, but I don't understand why rpmlint > calls this an error (the binaries clearly needs this library) - per Ankur's > comment earlier, it does no harm to explicitly define such dependency > despite overlapping, but seems rpmlint treats this as an conflict. Actually, I wonder why octave-iso2mesh requires any -devel package at runtime? Does the octave plugin need to build C/C++ sources at runtime? > - now I put arm as ExcludeArch, because @Ankur had a failed build on arm, > and the error was "virtual memory exhausted" for CGAL, see > https://koji.fedoraproject.org/koji/taskinfo?taskID=38115425 , if we have a > way to build on arm, I will drop the ExcludeArch, but this is not a priority Oops. The use of the Mesh_3 package from CGAL might need a lot of RAM to build, in debug mode. Maybe if the arch is arm, you could remove `-g` from the compilation flags. That reduces a lot the RAM necessary to build.
octave-iso2mesh-1.9.1-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
octave-iso2mesh-1.9.1-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
octave-iso2mesh-1.9.1-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.