Package Details: parmetis 4.0.3.p2-1

Git Clone URL: https://aur.archlinux.org/parmetis.git (read-only)
Package Base: parmetis
Description: A parallel graph partitioning library
Upstream URL: http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview
Licenses: custom
Submitter: jedbrown
Maintainer: jedbrown
Last Packager: jedbrown
Votes: 21
Popularity: 0.164970
First Submitted: 2008-05-15 20:41
Last Updated: 2016-02-11 01:02

Latest Comments

jedbrown commented on 2016-02-11 01:04

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

@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

Great, thanks :)

jedbrown commented on 2015-10-19 19:03

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

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

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=(http://glaros.dtc.umn.edu/gkhome/fetch/sw/parmetis/parmetis-4.0.3.tar.gz)
sha256sums=('f2d9a231b7cf97f1fee6e8c9663113ebf6c240d407d3c118c55b3633d6be6e5f')

alen12345 commented on 2015-08-27 13:16

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

eleftg commented on 2015-08-12 14:37

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

@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

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

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

jedbrown commented on 2014-02-25 01:15

Background: 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 can think of it as if I (as AUR maintainer) were carrying those patches manually.

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

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

Xyne commented on 2014-02-24 22:52

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: http://xyne.archlinux.ca/tmp/pkgbuilds/

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

@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

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: http://xyne.archlinux.ca/tmp/parmetis/
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.

Xyne commented on 2013-01-03 08:44

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

You can get it here: http://xyne.archlinux.ca/tmp/parmetis/
There's no need to bump the $pkgrel because the resulting package is identical.

Thanks for maintaining this!

Xyne commented on 2013-01-03 08:38

Hi,

You should not include empty arrays and variables in the PKGBUILD.External variables ($srcdir, $pkgdir") should also be quoted to avoid unwanted word expansion.

I have uploaded an updated PKGBUILD: http://xyne.archlinux.ca/tmp/parmetis/
There's no need to bump the $pkgrel because the resulting package is the same.

Thanks for maintaining this!

myles commented on 2012-08-29 10:34

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

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

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

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

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

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

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

done

jacopo_c commented on 2012-05-16 09:42

You should add openmpi between dependencies

jedbrown commented on 2011-08-11 18:53

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

Anonymous comment on 2011-08-06 11:27

Not working anymore. Please change:

source=(http://glaros.dtc.umn.edu/gkhome/fetch/sw/parmetis/ParMetis-$pkgver.tar.gz)
to
source=(http://glaros.dtc.umn.edu/gkhome/fetch/sw/parmetis/OLD/ParMetis-$pkgver.tar.gz)

Thanks!

kragacles commented on 2011-06-15 20:19

Great! Thanks much.

jedbrown commented on 2011-06-15 17:32

Thanks wizzrobe. Open MPI bug report https://svn.open-mpi.org/trac/ompi/ticket/2812

jedbrown commented on 2011-06-15 17:06

The compiler seg-faults for me on this package, but works fine for the sister package parmetis-mpich2. I suspect it relates to some environment issue, but don't have time to investigate right now. Please post if you see this too.

kragacles commented on 2011-06-15 17:03

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: https://bbs.archlinux.org/viewtopic.php?id=117493

Just splitting the build and package sections solves it. I posted a simple fixed PKGBUILD here: http://pastie.org/2073220

kragacles commented on 2011-06-15 16:23

Just noticed Parmetis 3.2.0 came out in April

kragacles commented on 2011-06-15 16:22

I see parmetis 3.2.0 came out in April.

jedbrown commented on 2010-06-22 12:54

update builds shared libs and installs METIS headers