Package Details: parmetis 4.0.3.p7-1

Git Clone URL: (read-only, click to copy)
Package Base: parmetis
Description: A parallel graph partitioning library
Upstream URL:
Licenses: custom
Submitter: jedbrown
Maintainer: jedbrown
Last Packager: jedbrown
Votes: 31
Popularity: 0.004754
First Submitted: 2008-05-15 20:41 (UTC)
Last Updated: 2021-12-19 06:15 (UTC)

Latest Comments

sigvald commented on 2020-03-26 13:56 (UTC) (edited on 2020-03-26 13:57 (UTC) by sigvald)

@a.kudelin's solution worked for me, although Haawda's solution, using the :: syntax, sounds preferrable. Thank you for maintaining this package @jedbrown (not being sarcastic).

greyltc commented on 2020-03-23 23:01 (UTC)

poke @jedbrown fix this please

a.kudelin commented on 2020-03-22 13:41 (UTC)

Please, take this PKGBUILD into account:
There some cleanup was carried out and fixed an error with non-existing source directory.

xantares commented on 2020-03-21 13:44 (UTC)

ping @jedbrown please update

haawda commented on 2020-03-20 16:19 (UTC)

Please avoid downloading a tarball without the package name in it. makepkg has a special :: syntax to avoid this in the source array.


bartus commented on 2020-03-18 14:13 (UTC)

@jedbrown: You forgot to update hash value when popping tag.

Xwang commented on 2020-03-17 20:23 (UTC)

I confirm that Roken solution works.

Roken commented on 2020-03-17 19:35 (UTC) (edited on 2020-03-17 19:35 (UTC) by Roken)

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.

Xwang commented on 2020-03-17 17:09 (UTC)

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

Xwang commented on 2020-03-17 17:07 (UTC)

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

ChrisTX commented on 2018-09-20 21:06 (UTC)

@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.

sigvald commented on 2018-09-20 15:28 (UTC)

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.

ChrisTX commented on 2018-09-20 13:57 (UTC)

@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 . 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.

sigvald commented on 2018-06-21 12:40 (UTC) (edited on 2018-06-21 13:41 (UTC) by sigvald)

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/ section .tdata mismatches non-TLS definition in /usr/lib/ 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 <>
# Contributor: George Eleftheriou <eleftg>
# Contributor: Sigvald Marholm <>

pkgdesc="A parallel graph partitioning library"
arch=('i686' 'x86_64')

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}

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

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.

sigvald commented on 2018-06-20 19:54 (UTC) (edited on 2018-06-20 19:57 (UTC) by sigvald)

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


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.

sigvald commented on 2018-06-20 19:31 (UTC) (edited on 2018-06-20 19:56 (UTC) by sigvald)

I get

==> ERROR: Failure while downloading <>

I believe the correct source is:


jedbrown commented on 2016-02-11 01:04 (UTC)

That's a new build requirement, but doesn't affect the package. Fixed without incrementing pkgrel because anyone that has already built it doesn't benefit from a reinstall.

Calucinho commented on 2016-02-11 00:51 (UTC)

@jedbrown, there is a small syntax error in PKGBUILD which makes the build fail. The license should be inside an array. To fix change license="custom" to license=("custom")

paugre commented on 2015-10-19 19:22 (UTC)

Great, thanks :)

jedbrown commented on 2015-10-19 19:03 (UTC)

Please reinstall metis. The current version is 5.1.0.p1-2, and includes the gklib headers.

paugre commented on 2015-10-19 18:18 (UTC)

OK, so I'm running into the same issue... risking to look stupid, but where can I get those gklib headers from?

Calucinho commented on 2015-09-01 01:20 (UTC)

I am having the same problem as noctlos. I did, however, managed to install parmetis by using a different source and removing the "p-thingy" in the version numbering in the PKGBUILD: pkgver=4.0.3 _pkgver=4.0.3 source=( sha256sums=('f2d9a231b7cf97f1fee6e8c9663113ebf6c240d407d3c118c55b3633d6be6e5f')

alen12345 commented on 2015-08-27 13:16 (UTC)

Sorry for marking as out of date. Please remove the flag and this comment.

eleftg commented on 2015-08-12 14:37 (UTC)

Sorry for the late reply but I'm on holidays... I'm disowning the package so that jedbrown can keep up maintaining it, just like he did before the AUR4 transition

jedbrown commented on 2015-08-11 15:20 (UTC)

@noctlos The new metis maintainer stopped installing gklib headers. I commented there and hopefully it will be resolved with an update to metis. In the meantime, you could use the previous version of metis.

noctlos commented on 2015-08-11 13:26 (UTC)

Fails to build: In file included from /tmp/yaourt-tmp-phandy/aur-parmetis/src/parmetis-4.0.3-p1/headers/GKlib.h:66:0, from /tmp/yaourt-tmp-phandy/aur-parmetis/src/parmetis-4.0.3-p1/libparmetis/./parmetislib.h:19, from /tmp/yaourt-tmp-phandy/aur-parmetis/src/parmetis-4.0.3-p1/libparmetis/xyzpart.c:15: /tmp/yaourt-tmp-phandy/aur-parmetis/src/parmetis-4.0.3-p1/headers/gk_externs.h:20:23: fatal error: gklib_tls.h: No such file or directory compilation terminated. libparmetis/CMakeFiles/parmetis.dir/build.make:57: recipe for target 'libparmetis/CMakeFiles/parmetis.dir/xyzpart.c.o' failed make[3]: *** [libparmetis/CMakeFiles/parmetis.dir/xyzpart.c.o] Error 1 make[3]: Leaving directory '/tmp/yaourt-tmp-phandy/aur-parmetis/src/parmetis-4.0.3-p1/build/Linux-x86_64' CMakeFiles/Makefile2:93: recipe for target 'libparmetis/CMakeFiles/parmetis.dir/all' failed make[2]: *** [libparmetis/CMakeFiles/parmetis.dir/all] Error 2 make[2]: Leaving directory '/tmp/yaourt-tmp-phandy/aur-parmetis/src/parmetis-4.0.3-p1/build/Linux-x86_64' Makefile:119: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/tmp/yaourt-tmp-phandy/aur-parmetis/src/parmetis-4.0.3-p1/build/Linux-x86_64' Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Fix? Help?

jedbrown commented on 2014-02-25 01:37 (UTC)

Thanks, Xyne. I made the changes you suggest. Background in case people wonder about this package: I'm a PETSc developer. Upstream ParMETIS has some critical bugs that our users run into all the time, so we patched them and sent the patches upstream. Upstream doesn't really maintain ParMETIS and usually ignores patches sent by email or via forums. And yet these bugs are serious: memory errors and assertion failures. So we maintain patches. This is all in a legal gray zone due to the insane license, but George knows that we do it and has not objected (he's a reasonable person, but has mostly moved on and doesn't care about maintaining ParMETIS, but also doesn't want to lose control by switching to a decent open source license). Anyway, the p1 is not from "upstream", it is from me and other PETSc developers. You could think of it as if I (as AUR maintainer) were carrying those patches manually. This was my rationale before learning form you that 4.0.3.p1 is a valid version number, which is certainly not worse so I have updated. We don't want to carry these patches, but to change that, the package will either need to be made open source or a viable competitor will have to step up. (Last I checked, PTScotch is too slow to be considered a "viable" alternative.)

Xyne commented on 2014-02-24 22:53 (UTC)

Addendum: by "subversion", I mean the "p1" suffix.

Xyne commented on 2014-02-24 22:52 (UTC)

Hi, Following the changes to the metis package that I posted on the metis page, I have also updated the parmetis PKGBUILD to follow the same versioning scheme. You can find the source tarball in the same directory on my site: If the upstream subversion number is completely incompatible with Pacman's versioning then some sort of conversion system should be devised. Multiple upstream versions should *not* map to a single Pacman version. Whatever you decide to do, the changes should be consistent across metis, parmetis and parmetis-mpich. Again, thanks for maintaining this. Regards, Xyne

jedbrown commented on 2013-01-03 14:18 (UTC)

@Xyne Parmetis really does depend on metis (as of version 4). I've cleaned up the PKGBUILD based on your suggestions.

Xyne commented on 2013-01-03 08:47 (UTC)

Hi, I have uploaded a PKGBUILD with some corrections: * pkgname changed from an array to a string * empty variables removed * quoted $srcdir and $pkgdir variables to prevent word expansion * removed "metis" from dependencies (a package should never depend on and provide the same package) * added "metis" to the conflicts array, assuming that it really does provide metis If the last two points are wrong, remove "metis" from the provides and conflicts array. If it really does depend on metis, add it back to the depends array. You can the PKGBUILD: There's no need to bump the $pkgrel because the resulting package is identical. Thanks for maintaining this! p.s. Sorry if you received this message multiple times via email.

myles commented on 2012-08-29 10:34 (UTC)

aurup parsed html rather than rpc, and so fell foul of a format change not long ago, it is recommended to use burp to upload packages now

jedbrown commented on 2012-07-05 10:35 (UTC)

I had uploaded it using aurup, but strangely, the result wasn't visible here. I tried again with aurup, which completed successfully again, but still didn't show up here, so I uploaded manually. I understand that there is a consistency issue, but we (somewhat necessarily now) maintain the PKGBUILDs for metis and parmetis together. Feel free to email George suggestions about dependencies and packaging.

capitalaslash commented on 2012-07-05 10:28 (UTC)

i'm sorry but i'm not talking about aesthetics here. if metis is built separately and parmetis builds it inside and does not use the external one, configuration issues can arise easily. i agree that this issue should be addressed by the parmetis build tools (the 4.0 version switch has not improved things, i'm very sorry to say). will you update the PKGBUILD in order to list metis as a "depends" and not as a "provides"?

jedbrown commented on 2012-07-05 10:09 (UTC)

Parmetis "make install" does not install Metis. We have been using both with this dependency in PETSc for more than half a year (many users on different platforms) and this approach has been working fine. Talk to George if you think installation should be done differently. (I do, but he has not been responsive about applying patches for real portability issue, so it hasn't seemed worthwhile to press on more aesthetic issues.)

capitalaslash commented on 2012-07-05 09:56 (UTC)

i believe metis is built inside parmetis, the problem is that it not installed along with it. adding metis as an external dependency can be dangerous if the configuration is not consistent.

jedbrown commented on 2012-07-05 09:52 (UTC)

Parmetis depends on Metis since the latest release. I just updated the package to add this dependency.

capitalaslash commented on 2012-07-05 08:10 (UTC)

with this configuration it does not install metis along with parmetis. i've tried to do it myself and i'm able to install libmetis, but i cannot find a clean way to install metis.h. how can you use it without metis?

jedbrown commented on 2012-05-16 12:50 (UTC)


jacopo_c commented on 2012-05-16 09:42 (UTC)

You should add openmpi between dependencies

jedbrown commented on 2011-08-11 18:53 (UTC)

Updated to 4.0, let me know if there are any problems.

commented on 2011-08-06 11:27 (UTC)

Not working anymore. Please change: source=($pkgver.tar.gz) to source=($pkgver.tar.gz) Thanks!

kragacles commented on 2011-06-15 20:19 (UTC)

Great! Thanks much.

jedbrown commented on 2011-06-15 17:32 (UTC)

Thanks wizzrobe. Open MPI bug report

kragacles commented on 2011-06-15 17:03 (UTC)

Noticed parmetis 3.2.0 was released in April. Also, this PKGBUILD no longer works, thanks to mpicc not functioning properly under fakeroot. See these posts for details: Just splitting the build and package sections solves it. I posted a simple fixed PKGBUILD here:

jedbrown commented on 2010-06-22 12:54 (UTC)

update builds shared libs and installs METIS headers