few notes
- system copy of the ANN library (from the ann package) must be used instead of the copy in contrib/ANN
- sources contains mpeg encoder which is a patented thing
- contrib/tetgen contains a non-commercial only clause
- the contrib dir contains stuff that could/should exists as separate packages

Dan, many thanks for comments.

> - system copy of the ANN library (from the ann package)
> must be used instead of the copy in contrib/ANN

Ok. I'll work on it.

> - sources contains mpeg encoder which is a patented thing

Ok. Got the issue. I'll just remove mpeg - it does not affect core functionality.

> - contrib/tetgen contains a non-commercial only clause

Metis has also similar non-commercial only clause. I disabled them both in CMake configure. Is it not enough? Should I remove them completely from sources?

> - the contrib dir contains stuff that could/should exists as separate packages

Ok. I'll re-check it. Could you advice which packages require attention?

I wrote patches and made some changes to Spec.

Regarding the issues mentioned:
- ANN library - fixed by patch, using system ANN now
- MPEG - disabled just as Tetgen and Metis

Regarding contrib directory. It contains:
- ANN - unmodified ANN - replaced with system copy of ANN
- bamg - modified bamg
- Chaco - modified Chaco
- DiscreteIntegration - separate sub-module of Gmsh itself
- Fl_Tree - modified Fl_Tree widget for FLTK UI
- gmm - unmodified GMM - replaced with system copy of GMM
- kbipack - separate sub-module of Gmsh itself
- MathEx - unmodified MathEx, part of SSCILIB - Fedora does not ship SSCILIB
- Metis - disabled in our build
- mpeg_encode - disabled in our build
- NativeFileChooser - modified NativeFileChooser widget for FLTK UI
- Netgen - modified Netgen
- Tetgen - disabled in our build

Contrib dir summary:
- ANN, gmm - replaced with system copies
- Metis, mpeg_encode, Tetgen - disabled
- DiscreteIntegration, kbipack - sub-modules of Gmsh itself
- bamg, Chaco, Fl_Tree, NativeFileChooser, Netgen - modified, derived works
- MathEx - unmodified, not in Fedora


New spec: http://dl.dropbox.com/u/4532412/RPMS/gmsh.spec
New SRPM: http://dl.dropbox.com/u/4532412/RPMS/gmsh-2.5.0-5.fc16.src.rpm

Summary of changes:
* Mon Nov 14 2011 Alexey Vasyukov <vasyukov> - 2.5.0-5
- Disable MPEG support because of patent issues
- Add patch to use system ANN instead of built-in one
- Add patch to use system GMM instead of built-in one
- Update CMake soname patch to avoid hardcoded numbers

+ rpmlint output (incorrect-fsf-address, spurious-executable-perm, shared-lib-calls-exit) reported upstream


The questions:

#1 There are 3 'bad' components - MPEG with patent issues plus Tetgen and Metis with non-commercial only clause. I disabled them now with CMake options. Is it enough or should I remove support for them completely from sources?

#2 How to deal with contrib dir correctly? I guess, I should package MathEx (SSCILIB) separately and leave derived works (dirs bamg/, Chaco/, Fl_Tree/, NativeFileChooser/, Netgen/) in contribs. Is it so?

Any comments and/or suggestions?

(In reply to comment #3)
> #1 There are 3 'bad' components - MPEG with patent issues plus Tetgen and Metis
> with non-commercial only clause. I disabled them now with CMake options. Is it
> enough or should I remove support for them completely from sources?

Yes.  See http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code

> #2 How to deal with contrib dir correctly? I guess, I should package MathEx
> (SSCILIB) separately and leave derived works (dirs bamg/, Chaco/, Fl_Tree/,
> NativeFileChooser/, Netgen/) in contribs. Is it so?

You would need exceptions from the Fedora Packaging Committee if you cannot remove these.  See:
https://fedoraproject.org/wiki/No_Bundled_Libraries

(In reply to comment #4)
> Yes.  See
> http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code
>

Got it. Many thanks, I didn't find this page myself. I'll address the issue asap.

> You would need exceptions from the Fedora Packaging Committee if you cannot
> remove these.  See:
> https://fedoraproject.org/wiki/No_Bundled_Libraries

General idea is clear, but I am not sure if we can apply these recommendations directly. I'll double check the code in contrib trying to follow these guidelines as close as possible and come back with fix proposal.

It's been six months; was there ever any progress here?

Hi all. Summary for both remaining issues:

1. Prohibited code

Solved as recommended on http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code

Script: https://dl.dropbox.com/u/4532412/RPMS/gmsh-generate-tarball.sh
Updated spec: https://dl.dropbox.com/u/4532412/RPMS/gmsh.spec

2. Bundled libs

The situation is not clear. Gmsh contains bamg, Chaco, Fl_Tree, NativeFileChooser and Netgen. However, they are significantly modified to work with gmsh code. I'd say, mathematical algorithms implementations are copied but their usage and interfaces are changed.

So, there is no option to create simple patch to replace these libs with system copies as I did for ANN and gmm. It will require deep modification of gmsh itself.

Any ideas how we should address it?

You can request a bundling exemption from the packaging committee if you like.  http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions has the details.  Be sure to answer all of the relevant questions in as much detail as possible.  We'll pretty much reject requests out of hand if they don't include enough detail.

Haven't seen a bundling request filed yet.

Hi there! 

Is anybody working on this package atm? I picked up the spec amd SPRM files from comment 3 and 7 and started to integrate the latest release of gmsh. It would be nice to work together on the package to get it accepted in fedora. However, if nobody else is interested in this package any more, I would like to pick it up and to proceed further and ask for a bundle exception and for reopening/continuing the review process.

Cheers
Andre

Hello Andre.

I tried to build gmsh 2.6.1 recently. Summary:
- It mostly works
- Patches 1-3 should be updated to work with new sources. It is important since these patches make gmsh to use systems copies of ANN and GMM.

Plus additionally this one-liner is required to detemine libdir correctly:

--- gmsh-2.5.0-source/CMakeLists.txt.old        2012-10-17 12:47:11.010138601 +0400
+++ gmsh-2.5.0-source/CMakeLists.txt    2012-10-17 12:47:38.149134433 +0400
@@ -976,7 +976,7 @@
 # mark targets as optional so we can install them separately if needed
 # (e.g. "make lib" or "make shared" followed by "make install/fast")
 install(TARGETS gmsh DESTINATION ${GMSH_BIN} OPTIONAL)
-install(TARGETS lib shared DESTINATION lib OPTIONAL)
+install(TARGETS lib shared DESTINATION ${LIB_INSTALL_DIR} OPTIONAL)
 install(FILES ${GMSH_API} DESTINATION include/gmsh)
 install(FILES ${WELCOME_FILE} DESTINATION ${GMSH_DOC} RENAME README.txt)
 install(FILES ${LICENSE_FILE} DESTINATION ${GMSH_DOC})

I can update patches and spec in few days. I just need to test them reasonably.

If you can review the sources in contrib/* in details - it would be great. My current understanding is that there is no option to use system copies of libs. However, may be smth changed in gmsh 2.6 compared with 2.5. I havn't looked into sources of 2.6 that detailed.

Regards,
Alexey

I checked contrib/ for gmsh 2.6. In addition to modules described in https://bugzilla.redhat.com/show_bug.cgi?id=753577#c3 there are few new ones to review. We need to check (a) the license, (b) if we can/should replace them with system copies of the libraries.

1. blossom/

It contains the source code for concorde97 and MATCH (which contains the Blossom IV code)

Cite from original README.txt:
> As a special exception granted by Prof. Bill Cook, the code in this
> directory can be used within the Gmsh system for both academic and
> non-academic use. Note that this exception to the standard license is
> granted only for use within the Gmsh system: see the original email
> exchange below:
[skip]

2. HighOrderMeshOptimizer/

Looks like it a separate module of gmsh itself. Need to double-check it.

3. lbfgs/

Some sources from ALGLIB project - http://www.alglib.net/

4. mmg3d/

MMG3D from http://www.math.u-bordeaux1.fr/~cdobrzyn/logiciels/mmg3d.php

5. rtree/

One header with C++ templated RTree implementation.

6. Salome/

Few source files extracted from Salome sources

7. voro++/

3rd party library - http://math.lbl.gov/voro++/

(In reply to comment #12)
> 1. blossom/
> 
> It contains the source code for concorde97 and MATCH (which contains the
> Blossom IV code)
> 
> Cite from original README.txt:
<snip license text>

This license appears to be non-free. Blocking FE-LEGAL for guidance.

Is this library absolutely required to use this software?

> 5. rtree/
> 
> One header with C++ templated RTree implementation.

This might fall under the copylib exception.

> > 1. blossom/
[snip]
> This license appears to be non-free. Blocking FE-LEGAL for guidance.

Exactly

> 
> Is this library absolutely required to use this software?
> 

I guess not. Most probably, we can just remove it together with MPEG, Tetgen and Metis (see https://bugzilla.redhat.com/show_bug.cgi?id=753577#c3)

I'll check it live asap. 

> > 5. rtree/
> > 
> > One header with C++ templated RTree implementation.
> 
> This might fall under the copylib exception.

Ok

(In reply to comment #11)

Hi Alexey!

> Hello Andre.
> 
> I tried to build gmsh 2.6.1 recently. Summary:
> - It mostly works
> - Patches 1-3 should be updated to work with new sources. It is important
> since these patches make gmsh to use systems copies of ANN and GMM.

I already worked a little bit on your patches earlier this week and adapted them to gmsh 2.6.1, which required only a few modifications. If you want, you can download them from

http://dl.dropbox.com/u/28662456/gmsh-cmake-soname.patch
http://dl.dropbox.com/u/28662456/gmsh-api-demo-pathes.patch
http://dl.dropbox.com/u/28662456/gmsh-use-system-ann.patch
http://dl.dropbox.com/u/28662456/gmsh-use-system-gmm.patch

But I only adapted them and did not recreate them so the 
time stamps and source paths in the patch header are still 
the old one. Not sure whether this is okay or whether some
"patch policy" requires recreation against the new source directory? 

> 
> Plus additionally this one-liner is required to detemine libdir correctly:
> 
> --- gmsh-2.5.0-source/CMakeLists.txt.old        2012-10-17
> 12:47:11.010138601 +0400
> +++ gmsh-2.5.0-source/CMakeLists.txt    2012-10-17 12:47:38.149134433 +0400
> @@ -976,7 +976,7 @@
>  # mark targets as optional so we can install them separately if needed
>  # (e.g. "make lib" or "make shared" followed by "make install/fast")
>  install(TARGETS gmsh DESTINATION ${GMSH_BIN} OPTIONAL)
> -install(TARGETS lib shared DESTINATION lib OPTIONAL)
> +install(TARGETS lib shared DESTINATION ${LIB_INSTALL_DIR} OPTIONAL)
>  install(FILES ${GMSH_API} DESTINATION include/gmsh)
>  install(FILES ${WELCOME_FILE} DESTINATION ${GMSH_DOC} RENAME README.txt)
>  install(FILES ${LICENSE_FILE} DESTINATION ${GMSH_DOC})

Ah, great, I stumbled about the wrong LIB_INSTALL_DIR yesterday.

> 
> I can update patches and spec in few days. I just need to test them
> reasonably.
> 
> If you can review the sources in contrib/* in details - it would be great.
> My current understanding is that there is no option to use system copies of
> libs. However, may be smth changed in gmsh 2.6 compared with 2.5. I havn't
> looked into sources of 2.6 that detailed.

I will have a look at it today.
Best,
Andre

Hi!

Just for your information, I updated gmsh-cmake-soname.patch in my public dropbox folder. Your LIB_INSTALL_DIR related line was added and I renamed the static library name as well (just for consistency).

When I tried to run it I had to modify the cmake command in the spec file by adding the LIB_INSTALL_DIR variable resulting in the following cmake call

cmake . \
      -DCMAKE_C_FLAGS:STRING="%{optflags}" \
      -DCMAKE_CXX_FLAGS:STRING="%{optflags}" \
      -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \
      -DLIB_INSTALL_DIR:PATH=%{_libdir} 

Otherwise the LIB_INSTALL_DIR variable was empty and I got at
CMake Error at CMakeLists.txt:1161 (install):
  install TARGETS given no ARCHIVE DESTINATION for static library target
  "lib".

Cheers,
Andre

(In reply to comment #12)

Hi Alexey!
I had a look at the newly added contrib section you posted in comment #12,
here is a short summary of my "investigations":

> I checked contrib/ for gmsh 2.6. In addition to modules described in
> https://bugzilla.redhat.com/show_bug.cgi?id=753577#c3 there are few new ones
> to review. We need to check (a) the license, (b) if we can/should replace
> them with system copies of the libraries.
> 
> 1. blossom/

As remarked in 

https://bugzilla.redhat.com/show_bug.cgi?id=753577#c13

this appears to be non-free. I could build the gmsh rpm with 
-DCMAKE_ENABLE_BLOSSOM:BOOL="OFF".

> 
> 2. HighOrderMeshOptimizer/
> 
> Looks like it a separate module of gmsh itself. Need to double-check it.

We should probably ask upstream :)

> 
> 3. lbfgs/
> 
> Some sources from ALGLIB project - http://www.alglib.net/

License is GPLv2+ according to
http://www.alglib.net/download.php

> 
> 4. mmg3d/
> 
> MMG3D from http://www.math.u-bordeaux1.fr/~cdobrzyn/logiciels/mmg3d.php

This is licensed under GPLv3 according to
http://www.math.u-bordeaux1.fr/~cdobrzyn/logiciels/download/LICENCE.txt

> 
> 5. rtree/
> 
> One header with C++ templated RTree implementation.
> 
> 6. Salome/
> 
> Few source files extracted from Salome sources

LGPLv2 according to 
http://www.salome-platform.org/downloads/license 

> 
> 7. voro++/
> 
> 3rd party library - http://math.lbl.gov/voro++/

http://math.lbl.gov/voro++/download/

Modified BSD (http://math.lbl.gov/voro++/download/). The license text  is also
part of the gmsh/contrib/voro++ source. 

The voro++ source in gmsh is pristine voro++ 0.4.4 plus one tiny bug fix according to a diff I did. Newest upstream  of voro++ is 0.4.5 including this patch.

So some possible actions
- remove blossom
- clarify HighOrderMeshOptimizer is part of gmsh
- check whether lbfgs, Salome and mmg3d are modified and if not 
  what to do about it (bundling vs. packaging) since the sources are not  
  available as packages in fedora(AFAIK). 

What do you think? Are there any more actions need to be taken?
I will write upstream and ask about these contrib sources in gmsh. 

Cheers,
Andre

Hello Andre.

Action plan looks absolutely reasonable for me.

We are to update this script as well - https://dl.dropbox.com/u/4532412/RPMS/gmsh-generate-tarball.sh According with http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code we need to remove blossom completely, not just disable it.

And in theory we need to package libs from contrib/ separately. :-)

Regards,
Alexey

As noted previously, the Blossom license is non-free due to the use restriction. It is unclear whether that restriction also applies to distribution outside of a gmsh context, and since there is already infrastructure setup to remove other code bits, please also remove the Blossom code from the gmsh source.

Hi!

A small update on the contrib sources after being in contact with upstream:

- HighOrderMeshOptimizer 
  gmsh module under heavy development, license has not been chosen yet.

- lbfgs: same code as upstream

- mmg3d: basically same code as upstream with few patches to make  it compile on Windows/Mac. Guess we don't need these ones :)

- Salome: modified to make it compile with open cascade. Patches might be incorporated already in the Salome sources. But what about license of open cascade? I can find it only in the rpmfusion non-free repo, probably for a reason?

And FYI, here is a citation of the upstream reply to whether gmesh functionality will be severely reduced by not linking against open cascade:
"Yes: not linking with opencascade means that Gmsh will not be able to import CAD models in STEP, IGES or BRep formats."

Best,
Andre

(In reply to comment #20)
> Hi!
> 
> A small update on the contrib sources after being in contact with upstream:
> 
> - HighOrderMeshOptimizer 
>   gmsh module under heavy development, license has not been chosen yet.

This may be acceptable since they have the same upstream and upstream doesn't intend for it to be a shared library.  They will, of course, need to select a license acceptable for Fedora first, though.  ;-)

> - lbfgs: same code as upstream
> 
> - mmg3d: basically same code as upstream with few patches to make  it
> compile on Windows/Mac. Guess we don't need these ones :)

These need to be packaged separately and gmsh patched to use the shared libraries then.

> - Salome: modified to make it compile with open cascade. Patches might be
> incorporated already in the Salome sources. But what about license of open
> cascade? I can find it only in the rpmfusion non-free repo, probably for a
> reason?

OpenCASCADE's non-freeness is described in detail here:
http://lists.fedoraproject.org/pipermail/legal/2011-September/001713.html

> And FYI, here is a citation of the upstream reply to whether gmesh
> functionality will be severely reduced by not linking against open cascade:
> "Yes: not linking with opencascade means that Gmsh will not be able to
> import CAD models in STEP, IGES or BRep formats."

Hmm, gmsh might do better in rpmfusion-nonfree then.  If gmsh will have to be stripped down so much to be useless to most end users, there's really no point in shipping it in Fedora proper.

Note that the bundled library policy still applies over at RPMFusion, so that will still need to be resolved.

(In reply to T.C. Hollingsworth from comment #21)
> 
> OpenCASCADE's non-freeness is described in detail here:
> http://lists.fedoraproject.org/pipermail/legal/2011-September/001713.html
> 
> > And FYI, here is a citation of the upstream reply to whether gmesh
> > functionality will be severely reduced by not linking against open cascade:
> > "Yes: not linking with opencascade means that Gmsh will not be able to
> > import CAD models in STEP, IGES or BRep formats."
> 
> Hmm, gmsh might do better in rpmfusion-nonfree then.  If gmsh will have to
> be stripped down so much to be useless to most end users, there's really no
> point in shipping it in Fedora proper.

Note that Open CASCADE has recently been relicenced as LGPL: http://www.opencascade.org/getocc/download/loadocc/

(In reply to Bruno Postle from comment #22)
[skip]
> Note that Open CASCADE has recently been relicenced as LGPL:
> http://www.opencascade.org/getocc/download/loadocc/

Yes, and that's really good. As far as I understand, Eric Smith is going to package OpenCASCADE for Fedora - http://thread.gmane.org/gmane.linux.redhat.fedora.legal/2090

So, we can review other issues and update their status. If nothing bad (from legal point of view) happened recently with gmsh, we have only technical issues to work on. (Plus wait until OpenCASCADE becomes available in Fedora repos.)

I'll try to review the latest gmsh upstream sources in the next few days.

*** Bug 1063525 has been marked as a duplicate of this bug. ***

As agreed with Mukundan (nonamedotc on FAS) I'm posting here a complete list of current modules in contrib/ and their status. I skip the modules that should be removed completely due to patent issues. Hopefully, this post will make current status clear for everybody who may be interested in gmsh in Fedora.

Already in Fedora:
* ANN (patches for using system ANN already accepted by gmsh upstream)
* gmm (patches for using system gmm already accepted by gmsh upstream)

Unmodified compared with upstream, not in Fedora, just should be packaged separately:
* mmg3d  (see https://bugzilla.redhat.com/show_bug.cgi?id=1065541)
* MathEx
* lbfgs
* voro++ (see https://bugzilla.redhat.com/show_bug.cgi?id=1065542)

Modified compared with upstream, should be investigated:
* bamg
* Chaco
* Netgen

Most probably, sub-modules of gmsh, need to double check it:
* DiscreteIntegration
* kbipack
* mobile
* onelab

Few source files extracted from third-party projects, should be investigated:
* rtree
* Salome

Here is a working package:

Spec URL: http://smani.fedorapeople.org/review/gmsh.spec
SRPM URL: http://smani.fedorapeople.org/review/gmsh-2.8.4-1.fc21.src.rpm


Everything in contrib was unbundled except for:
- Bamg: part of freefem++, modified source code
- Chaco: http://www.cs.sandia.gov/~bahendr/chaco.html - no fedora package, modified source code, see contrib/Chaco/README.txt
- DiscreteIntegration: gmsh internal module
- HighOrderMeshOptimizer: gmsh internal module
- kbipack: Source not available on the net anymore
- onelab: gmsh internal module
- rtree: single header file from http://superliminal.com/sources/sources.htm

The only one which could realistically also be unbundled is Bamg I suppose, but that would require the freefem++ package to be reworked to ship the bamg headers. (The freefem++ package should probably get reworked anyways since many of the features disabled in that package can now be enabled since the packages have since been included in Fedora, or are about to be).

Is there a good reason not to build with MPI support?

Also it's probably worth building a non-graphical version for batch running on
cluster nodes which may not have the libraries.

> Is there a good reason not to build with MPI support?
Indeed, why not.

> Also it's probably worth building a non-graphical version for batch running on
cluster nodes which may not have the libraries.
Could be an idea. I'd need to check whether the the same gmsh library can be used by the gui and non-gui variants of the executable. An other option would be to have the user write some appropriate custom code and use the gmsh library directly for such cases.

Spec URL: http://smani.fedorapeople.org/review/gmsh.spec
SRPM URL: http://smani.fedorapeople.org/review/gmsh-2.8.4-2.fc21.src.rpm

%changelog
* Thu Jun 19 2014 Sandro Mani <manisandro> - 2.8.3-2
- Link executable against library
- Compile with mpi support

I will take this.

Blocks: 177841 --- Is this still the case?

Not if I take over, though probably should open a new bug and close this one as duplicate... Will do in a sec.

*** This bug has been marked as a duplicate of bug 1111388 ***

(In reply to Sandro Mani from comment #28)
> Could be an idea. I'd need to check whether the the same gmsh library can be
> used by the gui and non-gui variants of the executable. An other option
> would be to have the user write some appropriate custom code and use the
> gmsh library directly for such cases.

FWIW, the doc has an example of running in batch somewhere.

Removing FE-NEEDSPONSOR from the closed review tickets.