Package Details: parmetis 4.0.3.p4-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: 27
Popularity: 0.140566
First Submitted: 2008-05-15 20:41
Last Updated: 2018-12-06 20:31

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

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