Package Details: parmetis 4.0.3.p9-1

Git Clone URL: https://aur.archlinux.org/parmetis.git (read-only, click to copy)
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: 32
Popularity: 0.002468
First Submitted: 2008-05-15 20:41 (UTC)
Last Updated: 2023-01-26 20:34 (UTC)

Latest Comments

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

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: 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 (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: 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.

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

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