Arch Linux User Repository

I confirm that Roken solution works.

I had the same. I modified the PKGBUILD to use petsc-pkg-parmetis-475d8facbb32 then makepkg. This worked fine, installed (pacman -U parmetis-4.0.3.p6-1-x86_64.pkg.tar.xz) and then, for good measure, checked updates again. All fine.

I get an error code 4 which says that the src/petsc-pkg-parmetis-73dab469aa36 folder does not exist. Indeed the name of the folder is petsc-pkg-parmetis-475d8facbb32

I get an error code 4 which says that the petsc-pkg-parmetis-73dab469aa36 file does not exist

@sigvald I doubt that's the culprit, tbh. The p3 patch over the p2 patch seems to have only fixed a minute issue in the build system, it shouldn't really affect the resulting binaries. The p2 patch vs. vanilla is important though for several reasons, among them that vanilla does not set SONAMEs, which causes all kinds of weirdness and breakage if binaries were to be built against it. This is probably one of the reasons Arch ships the PETSc patched version for METIS. If you build unpatched ParMETIS or replace the Arch standard METIS package, this will cause issues with the DNAMEs in binaries compiled against that, as they're entered by the linker as full path.

I'm not sure what causes the problem you're experiencing. I'm using the normal mumps AUR package, which is identical to mumps-par (both provide SCOTCH and ParMETIS partitioning, too), except for that it doesn't package the tests and is up to date with the latest MUMPS version (mumps-par isn't on 5.1.2) and it works absolutely fine for me as is.

So if I understand you correctly, @ChrisTX, if this package were bumped to p3 it should probably work? I settled with the mentioned solution because it worked for me, whereas this package broke mumps-par. Given the patches you mention, I can see this is a better approach, at least if it's to be used with PETSc. Although I have never actually noticed anything of these small difference you mention myself.

@sigvald Arch's package has always been based on the PETSc patched versions of METIS, hence the -p3 part.

This package at any rate is using the older 4.0.3-p2 patch, and the p3 patch corresponding to the METIS version in the official repositories. This may be causing issues. The PETSc package also uses a separate METIS and ParMETIS package, with the ParMETIS package depending on the former - they don't distribute them together.

You can see the actual differences between the versions in the PETSc Git here https://bitbucket.org/petsc/pkg-parmetis/commits/all . As you can see, their patches fix some bugs and even add some features and therefore might be needed over the vanilla version when used together with some packages.

In this sense, I would not recommend making the ParMETIS package to provide METIS, as the upstream and PETSc patched version might diverge and may not be binary compatible, since the PETSc version provides features the vanilla one does not have. To the best of my knowledge, PETSc went with this because the METIS author(s) did not respond to their patches.

However, MUMPS is being used with PETSc and I'm also using MUMPS (but not mumps-par, which is also out of date) with this package.

There's a mismatch between this package and metis from the official repository. This mismatch causes the following error when I'm trying to install mumps-par:

/usr/bin/ld: gk_cur_jbufs: TLS definition in /usr/lib/libparmetis.so section .tdata mismatches non-TLS definition in /usr/lib/libmetis.so section .data

The upstream ParMETIS actually comes bundled with METIS. Using the bundled version of METIS works (and it seems safer, since the author of ParMETIS kind of approves it). Changing the PKGBUILD in this package to the following resolved my problems:

# Maintainer: Jed Brown <jed@59A2.org>
# Contributor: George Eleftheriou <eleftg>
# Contributor: Sigvald Marholm <marholm@marebakken.com>

pkgname=parmetis
pkgver=4.0.3
pkgrel=2
_prefix=/usr
pkgdesc="A parallel graph partitioning library"
url="<http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview>"
arch=('i686' 'x86_64')
license=(custom)
depends=(openmpi)
makedepends=(cmake)
conflicts=(metis)
provides=(metis=5.1.0)
source=(<http://glaros.dtc.umn.edu/gkhome/fetch/sw/parmetis/parmetis>-${pkgver}.tar.gz)
sha256sums=('f2d9a231b7cf97f1fee6e8c9663113ebf6c240d407d3c118c55b3633d6be6e5f')

build() {
  # Build bundled METIS first
  cd "$srcdir/parmetis-${pkgver}/metis"
  make config cc=${_prefix}/bin/mpicc mpicc=${_prefix}/bin/mpicc mpicxx=${_prefix}/bin/mpicxx shared=1 prefix=${_prefix}
  make

  # Then build ParMETIS
  cd ..
  make config cc=${_prefix}/bin/mpicc mpicc=${_prefix}/bin/mpicc mpicxx=${_prefix}/bin/mpicxx shared=1 prefix=${_prefix}
  make
}

package () {
  # Install bundled METIS first
  cd "$srcdir/parmetis-${pkgver}/metis/"
  make install "DESTDIR=$pkgdir"

  # Then install ParMETIS
  cd ..
  make install "DESTDIR=$pkgdir"
}

EDIT: Again, the AUR page insists on putting < and > around links, which doesn't really work well in code. How silly.

For now I changed the following lines in PKGBUILD to this before running 'makepkg -sri':

_pkgver=4.0.3
source=(<http://glaros.dtc.umn.edu/gkhome/fetch/sw/parmetis/parmetis>-${_pkgver}.tar.gz)
sha256sums=('f2d9a231b7cf97f1fee6e8c9663113ebf6c240d407d3c118c55b3633d6be6e5f')

It may be a reason why the source was changed (according to the comments in PKGBUILD) but that link did not work (see previous comment).

EDIT: The < and > around http...parmetis shouldn't be there. It's automatically added by this site.