Dear, I am updating the package gmsh. Currently, the part ’contrib/metis’ is removed with the comment “non-free METIS code”: --8<---------------cut here---------------start------------->8--- (snippet ;; Remove non-free METIS code '(begin (delete-file-recursively "contrib/metis") #t)))) --8<---------------cut here---------------end--------------->8--- However, METIS is licensed Apache v2.0 and note that there is one package ’metis’ (“guix show metis”) but it cannot be used, anyway. The code is here: <https://gitlab.onelab.info/gmsh/gmsh/-/tree/master/contrib/metis> What is wrong with the licensing? Only the header of files? Note that Debian compiles it with METIS: <https://salsa.debian.org/science-team/gmsh/-/blob/master/debian/rules#L37> Nnot checked with other distributions.) I am inclined to enable METIS because it appears to me fine. However, since freedom is essential, it would like another advice and/or comment on. Thank you in advance. All the best, simon ps: I discussed this point upstream: <https://gitlab.onelab.info/gmsh/gmsh/-/issues/1013>
Dear, On Fri, 2 Oct 2020 at 10:07, zimoun <zimon.toutoune@gmail.com> wrote: > --8<---------------cut here---------------start------------->8--- > (snippet > ;; Remove non-free METIS code > '(begin > (delete-file-recursively "contrib/metis") > #t)))) > --8<---------------cut here---------------end--------------->8--- [...] > I am inclined to enable METIS because it appears to me fine. However, > since freedom is essential, it would like another advice and/or comment > on. Gmsh had updated from METIS 4 (non-free) to METIS 5 (free) in commit eaff7f6477fe876991615cfa4b5832bd5f12994b. <https://gitlab.onelab.info/gmsh/gmsh/-/commit/eaff7f6477fe876991615cfa4b5832bd5f12994b> The current Gmsh version 2.16.0 had been released on the Jan. 3rd and the commit updating METIS 4->5 on the Sept., 19th. All the best, simon
Hi Simon, Thank you for working on the Gmsh package. There have been a great many changes since the last update. > I am inclined to enable METIS because it appears to me fine. However, > since freedom is essential, it would like another advice and/or comment > on. There is a distinction between METIS (free) and ParMETIS (non-free) which may have influenced the decision to remove the whole metis directory. As far as I can see Gmsh does not use any files from the ParMETIS library. There is only a parmetis.c file included in the metis directory. However, it is commented out in CMakeLists.txt. Best regards, Paul.
Dear Paul, On Fri, 2 Oct 2020 at 18:26, Paul Garlick <pgarlick@tourbillion-technology.com> wrote: > Thank you for working on the Gmsh package. There have been a great > many changes since the last update. Yeah, the Christophe's talk at last FOSDEM was exciting about the new features in 4.x. ;-) And since the Guix v1.2 is in the pipe... > There is a distinction between METIS (free) and ParMETIS (non-free) > which may have influenced the decision to remove the whole metis > directory. As far as I can see Gmsh does not use any files from the > ParMETIS library. That's what Christophe (Geuzaine) told me. Cool! > There is only a parmetis.c file included in the metis directory. > However, it is commented out in CMakeLists.txt. Here [1] the patch updating Gmsh. Well, I missed this file (the base code changed a lot since last time I was playing with; ~2012-2016), thank you for explaining. To be "Guix compliant", this parametis.c file should be removed, right? [1] <http://issues.guix.gnu.org/issue/43761> All the best, simon
Hi Simon, > There is only a parmetis.c file included in the metis directory. > However, it is commented out in CMakeLists.txt. > To be "Guix compliant", this parametis.c file should be removed, > right? The file is part of METIS and thereby covered by the Apache license. It only provides entry points for ParMETIS, so ignoring it in the build stage, in the way that Gmsh does, seems to be appropriate. However, I notice from the patch that the Guix package metis is included as an input. This means that the whole of the bundled 'contrib/metis' directory could be deleted after all. If I remember correctly CMake gives preference to the 'system' packages ahead of the bundled packages. Best regards, Paul.
Hi Paul, Thank you for the review. On Fri, 2 Oct 2020 at 23:59, Paul Garlick <pgarlick@tourbillion-technology.com> wrote: > The file is part of METIS and thereby covered by the Apache license. > It only provides entry points for ParMETIS, so ignoring it in the build > stage, in the way that Gmsh does, seems to be appropriate. Fine. > However, I notice from the patch that the Guix package metis is > included as an input. This means that the whole of the bundled > 'contrib/metis' directory could be deleted after all. If I remember > correctly CMake gives preference to the 'system' packages ahead of the > bundled packages. Sorry, today was a bad day and I failed in multi-tasking. Well, I have tried to use the Guix package 'metis' instead of the bundled one -- without success about the test suite. Then when sending the patch, I missed the remove (my personal unsafe-threading ;-)). So the package v2 fixes that. But the '(modules ...)' is not necessary anymore. All in all, the patch v3 is the good one. Sorry for the mess. <http://issues.guix.gnu.org/43761#3> All the best, simon