Today, when I was investigating the installation of sci-libs/gmsh as a supporting package for freecad, I noticed it pulls in sci-libs/med. After looking at the metadata of the ebuild, it became clear, that it's the same package as sci-libs/libmed, which has been in the tree since February, sci-libs/med has been added this month and moved from ::science. I don't think, we need redundant ebuilds for this package.
Same sources but vastly different ebuilds (autotools vs. cmake). sci-libs/med has ${PYTHON_DEPS} without any python eclass?
See also: https://repology.org/project/med/versions Downstreams' package names are quite incoherent, but 'libmed' is clearly in the minority. Most downstreams go for med or med-<something>, and I don't see where the idea for libmed was coming from since no splitting is going on? Considering nothing in the Gentoo ebuild repo is currently using sci-libs/libmed, I think it should be merged into sci-libs/med and replace the existing ebuild, while keeping the latter more accurate DESCRIPTION. LICENSE needs to be checked as well.
Looking at the bug referenced in the initial commit[1] of sci-libs/libmed it looks like it was copied and updated from ::science as well. ::science still has this ebuild in the repo, so this should be deleted as well! I added libmed to my overlay also by using an existing copy in ::cg overlay, because it's needed by freecad (whose re-adding is blocked by several packages). So the naming libmed seems to be there just because of simple copying, no need to keep it like this. The sources have two license files, COPYING and COPYING.LESSER both referring to version 3 of GPL resp. LGPL. The documentation is almost completely in french, which I don't understand, so I can't say anything about a mapping of both licenses to the sources. The LICENSE line used in libmed seems therefore to be more current than the line in med. I suggest keeping the HOMEPAGE line from med, as it's more accurate than the one in libmed. As I've been (proxy-)maintaining the libmed package for about a year, I'd be happy to help with co-maintaining the med package further, if you like. If your ok with it, I'm going to prepare a PR for the changes. While at it, we could also remove the obsolete version 3 ebuilds for the package. [1]https://bugs.gentoo.org/597768
The files in src/ have headers indicating the whole thing is LGPL-3+. I have no clue where GPL is used, besides autotools.
@Matthias You are adding -DH5_USE_16_API to cppflags in med-4.0.0.ebuild. What's the reason for it? Does sci-libs/gmsh need the long outdated hdf-1.6* API? I noticed gmsh will fail to build, if med is built without this flag set. Doesn't gmsh having a way to tell it to use more modern implementations of hdf5?
Looking into this, I noticed the build failure of gmsh isn't related to using the -DH5_USE_16_API option, but it fails to build against the cmake built variant, while it succeeds in building against the autotools built variant, with or without passing the option. I therefore merged libmed into med using autotools, but keeping the USE flag as far as possible. I removed the mpi USE flag, because I didn't find a way to successfully disable mpi support with autotools. I also added a hdf5_16_api USE flag for now, if anybody wants to build against the old HDF5 1.6 API.
Underscores in USE flags are registered for USE_EXPAND.
Also you can't remove that package like that. You need to last rite it with appropriate message, so that users know what's happening.
(In reply to Bernd from comment #6) > but it fails to build against the cmake built variant, while it succeeds in > building against the autotools built variant, with or without passing the Any idea why that is? build.log? Don't upstream want to move to cmake buildsystem, or is it just a dead end?
@Michal thanks for pointing this out. I see these last-rite mails every week, but forget about it, when perparing the PR. I remove the second commit and look into how to do this properly, and also change the USE flag name. @Andreas: Not really an idea. I first was thinking it's about mpi, but then I tried without mpi and it was still failing. A build log of my first try is at http://dpaste.com/2EJ5RSH. I want to look into this further, because I noticed, that a lot of available options aren't actually used by the ebuild, and I hope to get an understanding on why it's failing against a cmake built med. I'd prefer to use cmake as the build system, because I understand it better than autotools. Additionally the autotools scripts of med use a lot of non-standard macros, and seems not to be of best quality. For example, I didn't find a way to disable MPI with med and also disabling fortran isn't straight-forward. The cmake / autotools thing is complicated. The SRC_URI isn't actually located at upstream. Upstream, which is EDF, a french R&D company, doesn't provide a URL to download the sources. The URL given in the README is actually a intranet site at EDF. The people who provide the download, use med library for their own software (Salome-Platform) and work together with the people from EDF. The Salome people also provide the cmake files to build med with it. Upstream officially only supports building with autotools. There has been some investigation on this by the FreeCAD folks, see https://forum.freecadweb.org/viewtopic.php?f=8&t=31095 and https://dev.opencascade.org/index.php?q=node/1217 on a reply from Salome that states their cmake contribution.
A current build log against cmake built libmed without setting USE=mpi is at http://dpaste.com/2E38G86. Looks like gmsh uses automagic deps on mpi.
This is funny, I moved sci-libs/med over from the science overlay because it was listed as a dependency for gmsh. Both ebuilds currently have minor QA issues (that I simply didn't spot during the transition - I unfortunately only have limited time for Gentoo these days). Bernd: Let us combine both packages into one, I do not care much about naming but sci-libs/med seems to be more natural than sci-libs/libmed. Which ebuild would you prefer to use? Due to a duplicated package I opt for a mask and "last-rite" with a rather quick timeline. The package isn't going away. I have opened a bug report to track the issues wrt gmsh pointed out here: https://bugs.gentoo.org/693448
Let me take care of PR 12849, I'll also send the "last rite".
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9b0b284bd806b5673853cfcfdecabc705702961 commit e9b0b284bd806b5673853cfcfdecabc705702961 Author: Bernd Waibel <waebbl@gmail.com> AuthorDate: 2019-09-03 07:13:06 +0000 Commit: Matthias Maier <tamiko@gentoo.org> CommitDate: 2019-09-03 22:34:40 +0000 sci-libs/med: merge libmed into med * Merge sci-libs/libmed into sci-libs/med, to resolve redundancy. * Changed to use autotools instead of cmake, as sci-libs/gmsh does not build against the cmake built variant. * Remove mpi USE flag, as there's no option to disable mpi support when using autotools to build the package. Closes: https://bugs.gentoo.org/693146 Package-Manager: Portage-2.3.74, Repoman-2.3.17 Signed-off-by: Bernd Waibel <waebbl@gmail.com> Signed-off-by: Matthias Maier <tamiko@gentoo.org> ...html.doc-Makefile.am-install-into-htmldir.patch | 50 +++++++++ sci-libs/med/med-4.0.0-r1.ebuild | 119 +++++++++++++++++++++ sci-libs/med/metadata.xml | 15 ++- 3 files changed, 183 insertions(+), 1 deletion(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9a0a78b5c557644630dbe61fc336ade20ac9f486 commit 9a0a78b5c557644630dbe61fc336ade20ac9f486 Author: Matthias Maier <tamiko@gentoo.org> AuthorDate: 2019-09-03 22:26:52 +0000 Commit: Matthias Maier <tamiko@gentoo.org> CommitDate: 2019-09-03 22:34:51 +0000 profiles: mask sci-libs/libmed for removal Bug: https://bugs.gentoo.org/693146 Closes: https://github.com/gentoo/gentoo/pull/12849/files Signed-off-by: Matthias Maier <tamiko@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
@Matthias, I didn't had the time yesterday to addresse the hdf5_16_api naming issue pointed out by Michal. It looks like the now merged commit still has this issue. Should I open a new PR to fix this, or will you address it?
(In reply to Bernd from comment #15) > @Matthias, I didn't had the time yesterday to addresse the hdf5_16_api > naming issue pointed out by Michal. It looks like the now merged commit > still has this issue. Should I open a new PR to fix this, or will you > address it? Is this why sci-libs/med is pulling in sci-libs/hdf5-1.10.5:0/1.10.5 with an dependency conflict of cxx? ( !mpi ) mpi? ( !cxx ) that I can't seem to get out of. Not sure why this needed fixed in such a hurry.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=693fc7ceeb5bb928011abf93460c537fbd8004fe commit 693fc7ceeb5bb928011abf93460c537fbd8004fe Author: Matthias Maier <tamiko@gentoo.org> AuthorDate: 2019-09-05 02:57:50 +0000 Commit: Matthias Maier <tamiko@gentoo.org> CommitDate: 2019-09-05 03:03:36 +0000 sci-libs/med: rename use flag Bug: https://bugs.gentoo.org/693146 Package-Manager: Portage-2.3.75, Repoman-2.3.17 Signed-off-by: Matthias Maier <tamiko@gentoo.org> sci-libs/med/med-4.0.0-r1.ebuild | 4 ++-- sci-libs/med/metadata.xml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
(In reply to Cory Lytle from comment #16) > (In reply to Bernd from comment #15) > > @Matthias, I didn't had the time yesterday to addresse the hdf5_16_api > > naming issue pointed out by Michal. It looks like the now merged commit > > still has this issue. Should I open a new PR to fix this, or will you > > address it? > > Is this why sci-libs/med is pulling in sci-libs/hdf5-1.10.5:0/1.10.5 with an > dependency conflict of cxx? ( !mpi ) mpi? ( !cxx ) that I can't seem to get > out of. > I don't think so. The hdf5-16-api USE flag is only used internally by med and AFAIK hdf5 is built by default with support for 1.6 and 1.8 API. But the issue has probably to do with the inability to disable mpi USE flag with autotools built med. Hdf5 cannot be built with both, cxx and mpi enabled at the same time, see https://bitbucket.hdfgroup.org/projects/HDFFV/repos/hdf5/browse/configure.ac#2480 Which package of yours needs cxx enabled?
(In reply to Bernd from comment #5) > I noticed gmsh will fail to build, if med is built without this flag set. > Doesn't gmsh having a way to tell it to use more modern implementations of > hdf5? First of all gmsh doesn't enable MPI support at all (at least the current version in portage) because option ENABLE_MPI is by default OFF in its CMakeLists.txt. The ebuild doesn't enable that option but it should in according to the value of mpi useflag. I have succeed compiling gmsh using the old libmed ebuild from portage (built with cmake) on a system where mpi is disabled. Using libmed-4.0.0-r1 and hdf5-1.10.5 Can you provide more details to the problem put in evidence also from comment #6? The H5_USE_16_API flag is added unconditionally by both cmake/autotools based build systems of med. I am against having the user forced to enable mpi system-wide. The renaming libmed -> med here proposed instead looks fine.
(In reply to Fabio Rossi from comment #19) > (In reply to Bernd from comment #5) > > > I noticed gmsh will fail to build, if med is built without this flag set. > > Doesn't gmsh having a way to tell it to use more modern implementations of > > hdf5? > > First of all gmsh doesn't enable MPI support at all (at least the current > version in portage) because option ENABLE_MPI is by default OFF in its > CMakeLists.txt. The ebuild doesn't enable that option but it should in > according to the value of mpi useflag. > I never said anything about MPI USE flag with gmsh, always was talking about MPI with respect to med. The "flag" in the quote refers to the H5_USE_16_API flag. > I have succeed compiling gmsh using the old libmed ebuild from portage > (built with cmake) on a system where mpi is disabled. Using libmed-4.0.0-r1 > and hdf5-1.10.5 Can you provide more details to the problem put in evidence > also from comment #6? > I need to reproduce the logs from comments #10 and #11, because their time has run out. I'm going to post new pastes, when this is ready. Which USE flags did you use to build the packages? On my tests, mpi wasn't completely disabled, only med and hdf5 were compiled without it. > The H5_USE_16_API flag is added unconditionally by both cmake/autotools > based build systems of med. Where did you find this in the cmake build system? I haven't found any traces. > > I am against having the user forced to enable mpi system-wide. The renaming > libmed -> med here proposed instead looks fine. Me too, but I didn't find a way to disable it with the autotools based ebuild. I'm currently working on adding more options to the gmsh ebuild, and when it's possible to build gmsh against cmake built med, I would prefer to bring back the cmake based ebuild, as for me it's easier to maintain than the autotools based one.
Ok, so I can build gmsh against cmake built libmed and hdf5 when none of these have MPI support enabled. Enabling MPI support with gmsh, but not libmed or hdf5, build succeeds, but I get a runtime with several libraries upon startup (maybe due to wrong usage): waebbl@artus /mnt/data/code/github/portage-overlays/gentoo-git/sci-libs/gmsh $ mpiexec -n 4 gmsh libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast XRequest.151: GLXBadContext 0x6c00038 XRequest.151: BadValue (integer parameter out of range for operation) 0x0 XRequest.151: GLXBadContext 0x7200038 XRequest.151: BadValue (integer parameter out of range for operation) 0x0 XRequest.151: GLXBadContext 0x6c0006b [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. gmsh: /var/tmp/portage/x11-libs/libX11-1.6.8/work/libX11-1.6.8/src/xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. XRequest.151: GLXBadDrawable 0x7200006 XRequest.151: GLXBadContext 0x720006b [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. gmsh: /var/tmp/portage/x11-libs/libX11-1.6.8/work/libX11-1.6.8/src/xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. XRequest.151: GLXBadContext 0x6e00038 XRequest.151: BadValue (integer parameter out of range for operation) 0x0 XRequest.151: GLXBadContext 0x7000038 XRequest.151: BadValue (integer parameter out of range for operation) 0x0 XRequest.151: GLXBadDrawable 0x7000006 XRequest.151: GLXBadContext 0x700006b [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. gmsh: /var/tmp/portage/x11-libs/libX11-1.6.8/work/libX11-1.6.8/src/xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. XRequest.151: GLXBadDrawable 0x6e00006 XRequest.151: GLXBadContext 0x6e00039 [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. gmsh: /var/tmp/portage/x11-libs/libX11-1.6.8/work/libX11-1.6.8/src/xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. -------------------------------------------------------------------------- mpiexec noticed that process rank 0 with PID 0 on node artus exited on signal 6 (Aborted). -------------------------------------------------------------------------- Building libmed and hdf5 using MPI support and trying to build gmsh using USE="med mpi" fails the build. The build log can be seen at http://dpaste.com/2TWXTW6. But building against med (autotools built) lets gmsh compile. Both, libmed and med were compiled with USE="fortran python", libmed additionally with USE="mpi", while with med, MPI support is currently always enabled. Trying to run the latter gmsh using mpi, also fails with the above error.
(In reply to Bernd from comment #20) > I need to reproduce the logs from comments #10 and #11, because their time > has run out. I'm going to post new pastes, when this is ready. Which USE > flags did you use to build the packages? > > On my tests, mpi wasn't completely disabled, only med and hdf5 were compiled > without it. Ok I have reproduced your problem when med is compiled with USE=mpi as you state in comment #21. The problem for the cmake-based ebuild is the patch libmed-3.3.1-mpi.patch that I introduced for version 3.3.1 to add mpi support to libmed. Unfortunately I don't remember which kind of problem I was facing at that time as now it compiles fine even without it :-) By removing that patch, it is still possible to build med against mpi using cmake and also being compatible with gmsh > > The H5_USE_16_API flag is added unconditionally by both cmake/autotools > > based build systems of med. > > Where did you find this in the cmake build system? I haven't found any > traces. look into the macro MED_FIND_HDF5() inside config/cmake_files/medMacros.cmake. For the autotools it is defined in config/med_check_hdf5.m4 (In reply to Bernd from comment #21) > Ok, so I can build gmsh against cmake built libmed and hdf5 when none of > these have MPI support enabled. > > Enabling MPI support with gmsh, but not libmed or hdf5, build succeeds, but > I get a runtime with several libraries upon startup (maybe due to wrong > usage): The mpi use flag of gmsh is not really enabling mpi, it's missing a definition such as -DENABLE_MPI="$(usex mpi)" in the mycmakeargs array defined in src_configure(). Probably for that reason you get the error trying to execute gmsh with mpiexec I am able to run gmsh (I have only tested starting the interface without other operations) with and without mpi support (fixing of course its ebuild as stated above). > Building libmed and hdf5 using MPI support and trying to build gmsh using > USE="med mpi" fails the build. The build log can be seen at > http://dpaste.com/2TWXTW6. But building against med (autotools built) lets > gmsh compile. Both, libmed and med were compiled with USE="fortran python", > libmed additionally with USE="mpi", while with med, MPI support is currently > always enabled. Trying to run the latter gmsh using mpi, also fails with the > above error. See above I think it's time to open a couple of new bug reports to update med and gmsh ebuilds in portage, see bug #694468 and bug #694470
(In reply to Fabio Rossi from comment #22) > (In reply to Bernd from comment #20) > > > I need to reproduce the logs from comments #10 and #11, because their time > > has run out. I'm going to post new pastes, when this is ready. Which USE > > flags did you use to build the packages? > > > > On my tests, mpi wasn't completely disabled, only med and hdf5 were compiled > > without it. > > Ok I have reproduced your problem when med is compiled with USE=mpi as you > state in comment #21. The problem for the cmake-based ebuild is the patch > libmed-3.3.1-mpi.patch that I introduced for version 3.3.1 to add mpi > support to libmed. Unfortunately I don't remember which kind of problem I > was facing at that time as now it compiles fine even without it :-) By > removing that patch, it is still possible to build med against mpi using > cmake and also being compatible with gmsh > Hmm, I thought I checked removing this patch, because I was already suspecting it to be somewhat related to the issue. But it's working as you're saying. > > (In reply to Bernd from comment #21) > > The mpi use flag of gmsh is not really enabling mpi, it's missing a > definition such as -DENABLE_MPI="$(usex mpi)" in the mycmakeargs array > defined in src_configure(). Probably for that reason you get the error > trying to execute gmsh with mpiexec > It's at least one of the reasons. But even when adding it, I need to add LD_PRELOAD=/usr/lib64/opengl/nvidia/lib/libGL.so before calling it. But it then runs and the message console also tells, it's running on 4 nodes, when called with the -n 4 option to mpiexec. So this looks like it's working. > > I think it's time to open a couple of new bug reports to update med and gmsh > ebuilds in portage, see bug #694468 and bug #694470 I'm going to prepare a PR for bug #694468, adding a few trivial changes from this bug report (description, homepage). For #694470 please also note bug #693448 from comment #12. I've started on improving gmsh and adding some more options, but I need to do some more testing before this is ready. I'm going to attach the ebuild to Matthias' bug for testing.
