Arch Linux User Repository

Hi. adopted and made a rework. now fixed my problems when build

• uses gentoo patch
• enable test (and filter the python ones due a circular dependency probem)
• use openmpi compilers

i have filled a bug for promote landing in official repos https://bugs.archlinux.org/task/73775

greetings

Hi,

I don't use this package, since med has been moved to community. I resign from its maintainership.

[ 13%] Building C object src/hdfi/CMakeFiles/_hdfi.dir/_MEDattributeNumWrByName.c.o
In file included from /usr/include/H5public.h:32,
                 from /usr/include/hdf5.h:22,
                 from /tmp/makepkg/med-openmpi/src/med-4.1.0/include/med.h:22,
                 from /tmp/makepkg/med-openmpi/src/med-4.1.0/src/hdfi/_MEDattributeNumWrByName.c:20:
/tmp/makepkg/med-openmpi/src/med-4.1.0/src/hdfi/_MEDattributeNumWrByName.c: In function '_MEDattributeNumWrByName':
/tmp/makepkg/med-openmpi/src/med-4.1.0/src/hdfi/_MEDattributeNumWrByName.c:71:10: error: too few arguments to function 'H5Oget_info3'
   71 |     if ( H5Oget_info( pid, &_oinfo ) <0) {
      |          ^~~~~~~~~~~
In file included from /usr/include/H5Apublic.h:22,
                 from /usr/include/hdf5.h:23,
                 from /tmp/makepkg/med-openmpi/src/med-4.1.0/include/med.h:22,
                 from /tmp/makepkg/med-openmpi/src/med-4.1.0/src/hdfi/_MEDattributeNumWrByName.c:20:
/usr/include/H5Opublic.h:497:15: note: declared here
  497 | H5_DLL herr_t H5Oget_info3(hid_t loc_id, H5O_info2_t *oinfo, unsigned fields);
      |               ^~~~~~~~~~~~
make[2]: *** [src/hdfi/CMakeFiles/_hdfi.dir/build.make:118: src/hdfi/CMakeFiles/_hdfi.dir/_MEDattributeNumWrByName.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:975: src/hdfi/CMakeFiles/_hdfi.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

Ah that might be it. Thanks @Nim65s!

I just upgraded from 4.0.0 to 4.1.0, following community/med. So I guess that fix was upstream :)

Thanks @frankspace. I just rebuilt to check and this time it created all three files. Previously it just created the other two. Not sure what's going on, but it seems fine now. Sorry for the noise!

For whatever it's worth, I just compiled the latest version of this (med-openmpi 4.1.0-1), and for me at least, it does actually install /usr/lib/libmed.so, /usr/lib/libmed.so.11, and /usr/lib/libmed.so.11.0.1.

Yeah apparently not @Nim65s. import Meshpart complained about missing libmed.so.11 specifically. I can get the precise error message if you want, but I installed med instead, and the absence of that file was one difference I noticed.

There is /usr/lib/libmed.so and /usr/lib/libmed.so.11.0.0. Isn't it enough ?

By the way, I handed over the med package to @xyproto so that he could include it in community, so there are no reason for me to keep maintaining med-openmpi. If anybody wants to adopt it, don't hesitate to ask :)

I had some problems with freecad and this package. med correctly installs /usr/lib/libmed.so.11, but this package med-openmpi does not. Without this file, I cannot import MeshPart.

Is replaces=('med') correct for this package? Or would just conflicts and provides be enough (e.g. this is an alternative and either med or med-openmpi can be chosen but not both together)? My understanding is replaces means the med package is obsolete (and presumably should be removed from AUR now that this exists as a replacement), and the replaces flags is there to ensure everybody is automatically updated to this new replacement package med-openmpi. The wiki describes it as being "An array of obsolete packages that are replaced by the package" and points out pacman "will immediately replace an installed package upon encountering another package with the matching replaces", and suggests using only conflicts and provides if it's just an alternate version.

One of the unofficial user repositories, andontie-aur, includes prebuilt packages for both med and med-openmpi now and as such my pacman wants to automatically replace med with med-openmpi. Is that intended / the correct approach with med-openmpi vs med?

Thanks @jedbrown. I applied that to med & med-openmpi.

This is currently broken with hdf5-1.12 from community. This gist applies the patch I developed for PETSc, which has been using it for the past several weeks.

https://gist.github.com/jedbrown/527ef81ff59a0dccf833da40fdd15a47

The code that compiles Python files looks broken (maybe a wrong path is hardcoded somewhere, or we failed at configuring that properly) for me too. I think that it doesn't really matter, as those file will be compiled on the fly by the Python interpreter as soon as they well be needed.

Anyway, I am only using this package as a dependency of freecad, which works equally well with med and med-openmpi… But if someone have an actual issue at runtime, please provide a reproducible way to see that.

I don't have a way to test med-openmpi easily, but I get these errors when trying to package med-openmpi in a clean chroot: https://gist.github.com/valandil/6655fc178f5ffbabc1d1862375f7f845.

Does the package work for you?

Also, FWIW, I had to build in a clean chroot to sidestep the issue I described in an ealier comment.

Fixed, thanks !

FWIW, here's the proposed diff:

diff --git a/PKGBUILD b/PKGBUILD
index 11019b3..08ad911 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -15,10 +15,7 @@ url="https://www.salome-platform.org/downloads"
 license=('LGPL')
 depends=('hdf5-openmpi' 'tk' 'python')
 makedepends=('gcc-fortran' 'swig' 'openmpi' 'cmake')
-provides=('med')
 arch=('x86_64')
-conflicts=('med')
-replaces=('med')
 source=("http://files.salome-platform.org/Salome/other/${_pkgname}-${pkgver}.tar.gz")
 sha256sums=('a474e90b5882ce69c5e9f66f6359c53b8b73eb448c5f631fa96e8cd2c14df004')

@@ -36,6 +33,9 @@ build() {
 #}

 package_med-openmpi() {
+  provides=('med')
+  conflicts=('med')
+  replaces=('med')
   cd ${_pkgname}-${pkgver}
   make DESTDIR=${pkgdir} install

The provides, conflicts and replaces variables should be set in the package_med-openmpi() function, not at the top of the PKGBUILD. Otherwise, both packages will inherit these. Only med-openmpi actually provides med, not med-openmpi-docs.

And yes, the patch files to when I was maintainint that package haha. They are definitely old.

I haven't tested my proposed change because I keep getting this compilation error:

[ 41%] Building Fortran object src/CMakeFiles/medfwrap.dir/MEDiteratorsF.f.o
/home/valandil/software/aur-PKGBUILDs/med-openmpi/src/med-4.0.0/src/MEDiteratorsF.f:15:56:

   15 |      &  MED_OCTA12, MED_PYRA13, MED_PENTA15, MED_PENTA18, MED_HEXA20,
      |                                                        1
Error: Symbol ‘med_penta18’ must be a PARAMETER in DATA statement at (1)
make[2]: *** [src/CMakeFiles/medfwrap.dir/build.make:63: src/CMakeFiles/medfwrap.dir/MEDiteratorsF.f.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:167: src/CMakeFiles/medfwrap.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

I don't know how to make med-openmpi and med-openmpi-docs not conflict with each other, while still ensure that med conflict with med-openmpi… Does anyone have an idea ?

:: med-openmpi-docs and med-openmpi are in conflict (med). Remove med-openmpi? [y/N]

Also, the obsolete patch files can be removed.