Package Details: python-graph-tool 2.44-1

Git Clone URL: https://aur.archlinux.org/python-graph-tool.git (read-only, click to copy)
Package Base: python-graph-tool
Description: A Python module for manipulation and statistical analysis of graphs
Upstream URL: https://graph-tool.skewed.de
Keywords: graphs networks science
Licenses: LGPL3
Conflicts: python3-graph-tool
Provides: python3-graph-tool
Replaces: python3-graph-tool
Submitter: muellner
Maintainer: count0
Last Packager: count0
Votes: 29
Popularity: 0.165484
First Submitted: 2013-11-24 19:22 (UTC)
Last Updated: 2022-01-02 19:37 (UTC)

Latest Comments

count0 commented on 2022-01-02 19:38 (UTC)

@rommedahl Fixed, thanks!

rommedahl commented on 2021-12-29 01:04 (UTC)

Hi, after install I got an error when loading, but it seemed to be resolved when I installed python-gobject. Perhaps it should be put as a dependency?

count0 commented on 2021-10-29 12:30 (UTC)

@akstrfn Fixed!

akstrfn commented on 2021-09-09 09:27 (UTC)

There is a bug in pkg. makepkg defined CXXFLAGS are discarded so the following fix is necessary export CXXFLAGS="$CXXFLAGS -flto=auto -fno-fat-lto-objects"

count0 commented on 2021-06-26 19:12 (UTC)

@npfeiler Fixed. Thanks!

npfeiler commented on 2021-06-26 17:51 (UTC)

actually, using " -flto=auto -fno-fat-lto-objects" is probably best it reduces compilation time as well as memory usage

npfeiler commented on 2021-06-25 13:23 (UTC)

-flto=jobserver doesn’t work for me, -flto=auto does (and would imply jobserver if that worked)

count0 commented on 2021-01-09 23:21 (UTC)

Fixed!

lahwaacz commented on 2021-01-09 19:28 (UTC)

Compiling version 2.36-1 fails for me:

uncertain/graph_blockmodel_latent_closure_mcmc.cc:26:10: fatal error: graph_blockmodel_latent_layers_mcmc.hh: No such file or directory
   26 | #include "graph_blockmodel_latent_layers_mcmc.hh"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

count0 commented on 2020-10-22 19:55 (UTC)

Fixed!

Phhere commented on 2020-10-19 07:38 (UTC)

Dependency python3-scipy needs to be renamed to python-scipy or just scipy

user20159 commented on 2020-04-03 20:04 (UTC)

Just to give some figures: Building this with 8 threads required at the maximum around 35GB of RAM on my machine. Building with one thread maxed out at around 5-6GB. So PKGBUILD contains -j 1 for a reason :)

count0 commented on 2020-03-01 22:31 (UTC)

@LukeLR this is a bug in boost 1.72 in fact. The current version now has a simple workaround.

user20159 commented on 2020-02-25 09:13 (UTC)

There is an upstream bug filed for this at https://git.skewed.de/count0/graph-tool/issues/629. Any ideas?

user20159 commented on 2020-02-19 08:11 (UTC) (edited on 2020-02-19 08:12 (UTC) by user20159)

@count0 Thanks, I thought I hadn't upgraded any packages after compilation of python-graph-tool, but apparently I did a pacman -Syu without thinking about it.

However, when compiling now, I get the following error:

graph_cairo_draw.cc: In function ‘boost::python::api::object cairo_draw(graph_tool::GraphInterface&, boost::any, boost::any, boost::any, bool, boost::python::dict, boost::python::dict, boost::python::dict, boost::python::dict, double, int64_t, boost::python::api::object)’:
graph_cairo_draw.cc:1868:34: error: ‘CoroGenerator’ was not declared in this scope
 1868 |     return boost::python::object(CoroGenerator(dispatch));
      |                                  ^~~~~~~~~~~~~
In file included from graph_cairo_draw.cc:43:
/usr/lib/python3.8/site-packages/cairo/include/py3cairo.h: At global scope:
/usr/lib/python3.8/site-packages/cairo/include/py3cairo.h:268:1: warning: ‘int import_cairo()’ defined but not used [-Wunused-function]
  268 | import_cairo(void)
      | ^~~~~~~~~~~~
make[4]: *** [Makefile:582: graph_cairo_draw.lo] Error 1
make[4]: Leaving directory '/home/user/AUR/python-graph-tool/src/graph-tool-2.29/src/graph/draw'
make[3]: *** [Makefile:809: all-recursive] Error 1
make[3]: Leaving directory '/home/user/AUR/python-graph-tool/src/graph-tool-2.29/src/graph'
make[2]: *** [Makefile:422: all-recursive] Error 1
make[2]: Leaving directory '/home/user/AUR/python-graph-tool/src/graph-tool-2.29/src'
make[1]: *** [Makefile:599: all-recursive] Error 1
make[1]: Leaving directory '/home/user/AUR/python-graph-tool/src/graph-tool-2.29'
make: *** [Makefile:486: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Is it just me, or is there a compatibility issue with boost 1.72?

count0 commented on 2020-02-18 15:39 (UTC)

@LukeLR, this error just means you need to re-compile graph-tool after installing a new version of Boost.

user20159 commented on 2020-02-18 14:33 (UTC)

I have the recent version 1.72 of boost and boost-libs installed. However, import graph_tool fails with the following error:

>>> import graph_tool
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/site-packages/graph_tool/__init__.py", line 114, in <module>
    dl_import("from . import libgraph_tool_core as libcore")
  File "/usr/lib/python3.8/site-packages/graph_tool/dl_import.py", line 61, in dl_import
    exec(import_expr, local_dict, global_dict)
  File "<string>", line 1, in <module>
ImportError: libboost_iostreams.so.1.71.0: cannot open shared object file: No such file or directory

Shouldn't graph_tool therefore depend on boost-libs=1.71 instead? I have just submitted the package boost171 in AUR to fullfill this task. Using this package, graph_tool works. Or is there a better solution?

michalT commented on 2019-06-25 12:48 (UTC)

Great, thanks a lot

count0 commented on 2019-06-25 12:31 (UTC)

@michaIT This has been fixed now!

michalT commented on 2019-06-25 11:59 (UTC)

Compilation of graph-tool fails on GCC 9.1.0 in graph_blockmodel_dynamics_epidemics.lo. This bug was reported upstream as https://git.skewed.de/count0/graph-tool/issues/591 and solved by commit https://git.skewed.de/count0/graph-tool/commit/c3a5066bc256e5d7ed450f89b324e84eb42fb511

count0 commented on 2018-10-16 18:41 (UTC)

@jg-you Both issues have been patched. @akstrfn The dependencies have been fixed.

jg-you commented on 2018-10-12 21:51 (UTC)

Release 2.27 no longer compiles (with up-to-date versions of GCC) due to the bug solved upstream in the development version https://git.skewed.de/count0/graph-tool/issues/509.

Fix available at: https://git.skewed.de/count0/graph-tool/commit/aa39e4a6b42d43fac30c841d176c75aff92cc01a

The PKGBUILD should be patched accordingly.

Running from git directly until then.

jg-you commented on 2018-08-13 21:42 (UTC) (edited on 2018-08-14 02:29 (UTC) by jg-you)

graph-tool 2.27 has a bug that prevents the import of the draw submodule. The bug is already fixed in the git version of the module, but not in the latest release.

The bug is due to the use of a protected word ('async') as a variable name, on line 1185 and 1247 of src/graph_tool/draw/gtk_draw.py. Since the bug is so small, I suggest that a patch should be added to the PKGBUILD until there's an upstream fix.

Since its only a few lines, the patch is perhaps better done with sed. Here's a command that fixes it.

sed -i \
-e 's/async=False/sync=True/'\
-e "s/async \: bool (optional, default\: \`\`False\`\`)/sync \: bool (optional, default\: \`\`True\`\`)/"\
-e "s/If \`\`True\`\`, run/If \`\`False\`\`, run/"\
-e "s/if async\:/if sync\:/" $srcdir/graph-tool-$pkgver/src/graph_tool/draw/gtk_draw.py

akstrfn commented on 2018-06-18 12:09 (UTC) (edited on 2018-06-19 13:53 (UTC) by akstrfn)

Shouldn't boost be in makedepends and boost-lib in depends?

Also namcap shows that there is overlinking in almost all shared libraries i.e. W: Unused shared library. I have --as-needed in my makepkg ld_flags and graph tool has it in configure so I have no idea why.

Update: I tested and it looks like it works without boost and with boost-lib (as it should). I also got an error module 'gi' have no attribute 'require version' which I resolved by installing python-gobject.

count0 commented on 2018-06-18 09:52 (UTC)

@akstrfn Done.

akstrfn commented on 2018-06-18 08:23 (UTC)

@count0 you should also update .SRCINFO

count0 commented on 2018-06-17 09:39 (UTC)

@lahwaacz This has been fixed.

lahwaacz commented on 2018-06-17 08:15 (UTC)

The python3-numpy provides disappeared from the official repositories, so the dependency should be updated to python-numpy.

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/python-numpy&id=e0c1e445f6196a0bebeb1bc0a8e6c5ba479e7f9e

count0 commented on 2018-06-12 09:48 (UTC)

The GCC compilation issue has been fixed.

count0 commented on 2018-06-12 09:47 (UTC)

The compilation issue with GCC 8 has been fixed.

paulmelis commented on 2018-06-12 08:45 (UTC)

With GCC 8 there's a compile error: https://git.skewed.de/count0/graph-tool/issues/468. Needs the commit mentioned in that issue at the bottom

manuel.osdoba commented on 2018-06-10 12:32 (UTC) (edited on 2018-06-10 12:32 (UTC) by manuel.osdoba)

If your PKGBUILD refers to python-graph-tool 2.26 and you already upgraded to use gcc 8.1.1 then you have to apply the patch https://git.skewed.de/count0/graph-tool/commit/9bd68ef9df7cadb2ca537037a425664ce14dc220.diff

Or you use my compiled packages https://drive.google.com/drive/folders/0B_2Um0ComJq7WUFGdGlRNTB4QW8

count0 commented on 2018-02-22 11:50 (UTC)

@cocconat If boost is updated, the package needs to be recompiled, there is no way around it.

This is not a bug, it is simply how shared libraries work.

cocconat commented on 2018-02-22 11:39 (UTC)

Hi, after boost update to 1.66.0 [1] the python module 'graph_tool' breaks:

ImportError: libboost_iostreams.so.1.63.0: cannot open shared object file

I tried to downgrade boost without success, I tried to update graph-tool, but no update available.

I don't want to disinstall and rebuild couse it requires hours of compilation and my ram prevent me from parallel compilation.

Please help

[1] https://www.archlinux.org/packages/?q=boost

ktw commented on 2017-12-11 15:06 (UTC)

@fortea relevancy aside, thank you! Your solution worked for me

lahwaacz commented on 2017-10-29 16:34 (UTC)

@fortea This is the Arch User Repository, not Manjaro User Repository, so Manjaro-specific problems are not relevant here.

fortea commented on 2017-10-29 16:21 (UTC)

In Manjaro 17.0.6 with Linux 4.11.12-1 and GCC 7.2.0 it fails to compile src/graph/topology/graph_similarity.lo with the message below. I solved using commands from the dockerfile provided by the official developers, so the following: curl -o PKGBUILD https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=python-graph-tool makepkg PKGBUILD --install --needed CXXFLAGS="-mtune=generic -O3 -pipe -flto=4 -ffunction-sections -fdata-sections" LDFLAGS="-Wl,--gc-sections" ______________________________________________________________________________ make[4]: ingresso nella directory "/tmp/pamac-build-sapo/python-graph-tool/src/graph-tool-2.25/src/graph/topology" CXX graph_similarity.lo {standard input}: Assembler messages: {standard input}:618370: Warning: end of file not at end of a line; newline inserted {standard input}:618850: Error: bad register name `%rd' {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive g++: internal compiler error: Ucciso (program cc1plus) _______________________________________________________________________________ hasta la victoria, fortea

ananyab commented on 2017-03-31 13:48 (UTC)

Thank you for confirming it atleast! I was (luckily) able to compile graph-tool with a swap partition in ~110 mins and a peak RAM usage of ~9GB. CPU usage dipped very low during the peak usage, but the compilation pulled through :) I'm posting my observations here so someone doesn't give up the compilation (if one has 8GB RAM+swap). And its delightful to know that the RAM usage can and will be reduced, good luck devs!

count0 commented on 2017-03-31 10:30 (UTC)

@ananyab: Memory usage during compilation has spiked in the newest release. This is planned to be improved in the next one.

ananyab commented on 2017-03-31 04:35 (UTC)

Yes, I do compile with `make -j 1` (because that's the default in the PKGBUILD). I also notice that only one 1 CPU core is used.

lahwaacz commented on 2017-03-30 14:31 (UTC)

@ananyab: Do you compile with "make -j1"? Obviously parallel compilation on N threads takes up to N-times more memory.

ananyab commented on 2017-03-30 14:24 (UTC)

@count0 Is the pre-compiled binary distribution coming? In your old comment (here, dated 2015-10-27) you mentioned compilation strictly takes below 3GB RAM (along with official wiki), but compilation exceeded 8GB on my i5-7200U 8GB RAM manjaro linux system.

count0 commented on 2017-01-15 19:35 (UTC)

Thanks, Manuel, it is fixed.

manuel.osdoba commented on 2017-01-15 14:52 (UTC)

There is an import issue with latest Python 3.6. Tiago Peixoto fixed that in the python-graph-tool master branch. The extracted patch "0001-Fix-dlopen-flags-problem-with-Python-3.6.patch" on https://drive.google.com/drive/folders/0B_2Um0ComJq7WUFGdGlRNTB4QW8 fixes that problem.

marmistrz commented on 2016-12-27 12:11 (UTC)

Cross-posting: https://bugs.archlinux.org/task/52278

fidbc commented on 2016-11-18 15:59 (UTC)

Issue is fixed in the newest version. Thanks!

qwattash commented on 2016-11-14 19:09 (UTC)

The new version (2.19-1) fixes it. Thank you!

count0 commented on 2016-11-13 07:24 (UTC)

Please try the newest version; the problem should be fixed.

count0 commented on 2016-11-13 07:23 (UTC)

Please try the newest version; the problem should be fixed.

qwattash commented on 2016-11-12 00:20 (UTC)

I'm getting this error while compiling: ./../../boost-workaround/boost/graph/reverse_graph_alt.hpp:292:18: error: no matching function for call to ‘degree(const vertex_descriptor&, const boost::filtered_graph<boost::adj_list<long unsigned int>, graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned char, boost::adj_edge_index_property_map<long unsigned int> > >, graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned char, boost::typed_identity_property_map<long unsigned int> > > >&)’ Does anyone have a similar issue? Using the latest boost 1.62-3

fidbc commented on 2016-11-02 11:35 (UTC)

Hi count0, Build seems to fail with new boost version. Please see [1] for output. Any help trying go work around this will be appreciated. Thanks! [1]: http://pastebin.com/Cy5Ek5EP

helvethor commented on 2016-06-26 19:06 (UTC)

I somehow had to install cairomm manually, but it worked after that. Great work!

ptrxyz commented on 2016-04-20 13:05 (UTC)

You are right, I just went out for lunch and it has finished meanwhile. Sry for the false report. Everything seems fine.

count0 commented on 2016-04-20 12:21 (UTC)

@ptrxyz These warnings are not errors, and they are benign. They come from boost, not graph-tool, and hence cannot be fixed here. Make does not hang, it just takes over an hour to compile. See more information here: https://graph-tool.skewed.de/download If you have a lot of memory, you can speedup the compilation by passing "-jN" to make, with "N" being the number or parallel jobs.

ptrxyz commented on 2016-04-20 11:50 (UTC) (edited on 2016-04-20 11:51 (UTC) by ptrxyz)

This seems to not build correctly. There is no error, but make indefinitely hangs and spits out messages like this over and over again: ... In file included from /usr/include/boost/type_traits/ice.hpp:15:0, from /usr/include/boost/python/detail/def_helper.hpp:9, from /usr/include/boost/python/class.hpp:29, from /usr/include/boost/python.hpp:18, from graph_centrality_bind.cc:18: /usr/include/boost/type_traits/detail/ice_or.hpp:17:71: note: #pragma message: NOTE: Use of this header (ice_or.hpp) is deprecated # pragma message("NOTE: Use of this header (ice_or.hpp) is deprecated") ...

lahwaacz commented on 2016-04-07 18:58 (UTC)

@count0 Indeed, thanks for the notice and the fix.

count0 commented on 2016-04-06 06:37 (UTC)

@lahwaacz The problem you found should be fixed in the current release.

count0 commented on 2016-03-02 21:52 (UTC)

@lahwaacz Well, this module should not be executed, only imported. Since the module itself does not exist until it is finished being imported, any internal reference to "io" refers to the system module. I don't know why the Makefile that was generated in your system is attempting to do that; it certainly does not happen in mine. However, I do acknowledge that naming the submodule io.py was not the best choice. I will change this in the next release.

lahwaacz commented on 2016-03-02 20:04 (UTC) (edited on 2016-03-02 20:07 (UTC) by lahwaacz)

@count0 Actually, the problem seems to be the src/graph_tool/io.py file. Python needs to import the io module implicitly, which will not work when the interpreter is run from src/graph_tool/ since the io.py file overrides it. The py-compile script is run from src/graph_tool/ (according to the Makefile that was generated on my system), hence the error. I think you should rename io.py to something better... See http://stackoverflow.com/q/26569828

count0 commented on 2016-03-02 11:33 (UTC)

@lahwaacz Very weird. Cannot reproduce here. Note that 'BytesIO' is a standard class in the 'io' module. The error does not make sense. I think there is something fishy with your python setup.

lahwaacz commented on 2016-02-26 22:08 (UTC) (edited on 2016-02-26 22:11 (UTC) by lahwaacz)

I'm getting a strange error in the 'make install' phase: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/home/lahwaacz/build/aur4/python-graph-tool/src/graph-tool-2.12/src/graph_tool/io.py", line 27, in <module> ImportError: cannot import name 'BytesIO' ../../py-compile: line 136: 26813 Aborted (core dumped) $PYTHON -c " import sys, os, py_compile, imp files = '''$files''' sys.stdout.write('Byte-compiling python modules...\n') for file in files.split(): $pathtrans $filetrans if not os.path.exists(filepath) or not (len(filepath) >= 3 and filepath[-3:] == '.py'): continue sys.stdout.write(file) sys.stdout.flush() if hasattr(imp, 'get_tag'): py_compile.compile(filepath, imp.cache_from_source(filepath), path) else: py_compile.compile(filepath, filepath + 'c', path) sys.stdout.write('\n')" Makefile:535: recipe for target 'install-graph_tool_centralityPYTHON' failed make[3]: *** [install-graph_tool_centralityPYTHON] Error 134 make[3]: *** Waiting for unfinished jobs....

confusedfla commented on 2016-02-03 03:13 (UTC)

+1 for a precompiled version.

muellner commented on 2016-01-05 22:07 (UTC)

I am disowning the package since the author of graph-tool, Tiago de Paula Peixoto, agreed to maintain the package himself. Please don't adopt the package hastily; Tiago will shortly take care of it.

muellner commented on 2016-01-05 22:07 (UTC)

I am disowning the package since the author of graph-tool, Tiago de Paula Peixoto, agreed to maintain the package himself. Please don't adopt the package hastily; Tiago will shortly take care of it.

muellner commented on 2015-12-29 20:36 (UTC)

Thanks for the report. Fixed.

muellner commented on 2015-12-29 20:35 (UTC)

Thanks for the report. Fixed.

muellner commented on 2015-12-29 13:59 (UTC)

See here: https://aur.archlinux.org/packages/python-graph-tool/ I'm working on this.

Cake commented on 2015-12-29 13:45 (UTC)

I hit the following error when I am installing the package. Any solutions? In file included from /usr/include/c++/5.3.0/memory:79:0, from /usr/include/boost/config/no_tr1/memory.hpp:21, from /usr/include/boost/get_pointer.hpp:14, from /usr/include/boost/python/object/pointer_holder.hpp:11, from /usr/include/boost/python/to_python_indirect.hpp:10, from /usr/include/boost/python/converter/arg_to_python.hpp:10, from /usr/include/boost/python/call.hpp:15, from /usr/include/boost/python/object_core.hpp:14, from /usr/include/boost/python/object.hpp:9, from ./../graph.hh:23, from ./../graph_filtering.hh:21, from graph_hits.cc:18: /usr/include/c++/5.3.0/functional:776:3: note: namespace std::placeholders { } { ^ Makefile:521: recipe for target 'graph_hits.lo' failed make[4]: *** [graph_hits.lo] Error 1 make[4]: Leaving directory '/tmp/yaourt-tmp-kccai/aur-python2-graph-tool/src/graph-tool-2.12/src/graph/centrality' Makefile:731: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/tmp/yaourt-tmp-kccai/aur-python2-graph-tool/src/graph-tool-2.12/src/graph' Makefile:407: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/tmp/yaourt-tmp-kccai/aur-python2-graph-tool/src/graph-tool-2.12/src' Makefile:557: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-kccai/aur-python2-graph-tool/src/graph-tool-2.12' Makefile:465: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

mat69 commented on 2015-12-28 12:30 (UTC)

The code compiled for me when adding find -type f -print0 | xargs -0 sed -i 's/ placeholders:/ std::placeholders:/g' in prepare() of configure.patch before the ./configure command. Though using python-graph-tool failed with the following message: Traceback (most recent call last): File "./test.py", line 8, in <module> from graph_tool.draw import graphviz_draw File "/usr/lib/python3.5/site-packages/graph_tool/__init__.py", line 105, in <module> dl_import("from . import libgraph_tool_core as libcore") File "/usr/lib/python3.5/site-packages/graph_tool/dl_import.py", line 57, in dl_import exec(import_expr, local_dict, global_dict) File "<string>", line 1, in <module> ImportError: /usr/lib/libboost_python.so.1.60.0: undefined symbol: PyClass_Type

mat69 commented on 2015-12-27 17:02 (UTC)

Hi, the package does not compile for me anymore. I guess this has to do with boost 1.6. The compile error is: graph_hits.cc: In function ‘long double hits(graph_tool::GraphInterface&, boost::any, boost::any, boost::any, double, size_t)’: graph_hits.cc:71:44: error: reference to ‘placeholders’ is ambiguous (g, std::bind(get_hits_dispatch(), placeholders::_1, g.get_vertex_index(), ^ In file included from /usr/include/boost/bind/bind.hpp:2247:0, from /usr/include/boost/bind.hpp:22, from /usr/include/boost/python/exception_translator.hpp:10, from /usr/include/boost/python.hpp:28, from graph_hits.cc:20: /usr/include/boost/bind/placeholders.hpp:30:1: note: candidates are: namespace boost::placeholders { } { ^ In file included from /usr/include/c++/5.3.0/memory:79:0, from /usr/include/boost/config/no_tr1/memory.hpp:21, from /usr/include/boost/get_pointer.hpp:14, from /usr/include/boost/python/object/pointer_holder.hpp:11, from /usr/include/boost/python/to_python_indirect.hpp:10, from /usr/include/boost/python/converter/arg_to_python.hpp:10, from /usr/include/boost/python/call.hpp:15, from /usr/include/boost/python/object_core.hpp:14, from /usr/include/boost/python/object.hpp:9, from ./../graph.hh:23, from ./../graph_filtering.hh:21, from graph_hits.cc:18: /usr/include/c++/5.3.0/functional:776:3: note: namespace std::placeholders { } {

count0 commented on 2015-10-27 06:53 (UTC)

I also would welcome a binary package! I would like to point out that the soon-to-be-released version 2.11 manages to reduce the compile time and memory usage substantially, due to some useful C++14 features. It now uses strictly under 3GB with GCC during compilation, and takes around ~75 mins to finish with "make -j1". It is not quite a lightweight compilation, but it is an improvement.

guiniol commented on 2015-10-22 10:52 (UTC)

Definitely interested in a binary package. Especially after having to recompile it because boost was updated.

muellner commented on 2015-10-19 20:39 (UTC)

I share jg-you's desire for a binary package - the compilation process is really straining all resources (CPU + patience). The easiest way to get binary packages would be if graph_tool became elevated from AUR to the community repository. I'll try to bring this up in the right place in the next few days. News will get posted here... In the meantime, feel free to write me a message if you'd welcome a precompiled package, so that I have an estimate when arguing how many users will benefit from it.

jg-you commented on 2015-10-16 03:33 (UTC)

Would there be a way to distribute this package precompiled? This is starting to get out of hand: Making package: python-graph-tool 2.10-1 (Thu Oct 15 14:03:42 EDT 2015) Finished making: python-graph-tool 2.10-1 (Thu Oct 15 23:20:40 EDT 2015) On a i5 2GHz, 4GB machine DDR3 machine.

count0 commented on 2015-09-17 21:53 (UTC)

Just a heads-up that version 2.7 is out. Note the different (simpler) version scheme.

arefindk commented on 2015-05-08 18:47 (UTC)

Thank you @muellner, rebuilding works.

muellner commented on 2015-04-19 19:25 (UTC)

When CGAL is updated, you also need to rebuild graph_tool so that it links to the new library files. The package (source + PKGBUILD) itself is probably fine. Let me know if rebuilding doesn't help. (This applies to all dependencies. Eg. if there is a new version of Boost, you should rebuild graph_tool. Unfortunately, there is no mechanism that I know about that does detect those situations automatically.)

arefindk commented on 2015-04-19 17:17 (UTC)

Please update the package so that it is compliant with updated "cgal".

muellner commented on 2014-09-12 20:31 (UTC)

Fixed.

robcat commented on 2014-09-12 09:07 (UTC)

I've recompiled the package with boost 1.56.0 (current version) and I have this error. >>> import graph_tool Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.4/site-packages/graph_tool/__init__.py", line 101, in <module> dl_import("from . import libgraph_tool_core as libcore") File "/usr/lib/python3.4/site-packages/graph_tool/dl_import.py", line 57, in dl_import exec(import_expr, local_dict, global_dict) File "<string>", line 1, in <module> ImportError: /usr/lib/libboost_python.so.1.56.0: undefined symbol: PyClass_Type

muellner commented on 2014-06-30 22:18 (UTC)

Thanks for the hint. I'll set graphviz as optional when the next graph-tool version is published. I don't do it now since it would only trigger lengthy recompilation for all users.

blackout commented on 2014-06-30 20:26 (UTC)

why is graphviz set as dep.? on the graph-tool page it says optional, deprecated

lahwaacz commented on 2014-06-26 12:43 (UTC)

Compiling in fewer threads than available will lower the memory requirements. Ironically, this should speed up the compilation process if swap is not used.

blackout commented on 2014-06-26 09:41 (UTC)

on my notebook with i7-740 4core+HyperThreading 1.73Ghz Turbo 2.9Ghz it took yaourt -S python-graph-tool 8528,00s user 153,43s system 96% cpu 2:29:44,44 total time to compile it. Furthermore, even with 8Gb RAM you will need a swap :) But all in all great tool and thx daniel

muellner commented on 2014-04-01 18:50 (UTC)

Now that Boost was updated, I triggered recompilation by submitting a new PKGBUILD with incremented release number. Package content is the same as before. ------------------------------------------------------------------------ Dear user, in case you read the previous comments: all known issues are now fixed. You can expect graph_tool to work (again) without any tweaks.

freswa commented on 2014-03-31 09:33 (UTC)

Thanks. My fault. Looked at archlinux.de -.-"

muellner commented on 2014-03-31 09:31 (UTC)

Hi Frederik, the official Arch Linux pages have the same feature as the AUR: There is a small box labeled "Package Actions" on the top right of this page: https://www.archlinux.org/packages/extra/x86_64/boost/ Normally, there is a link "Flag Package Out-of-Date"; now it shows "Flagged out-of-date on 2014-03-31" in red due to the recent report.

freswa commented on 2014-03-31 09:24 (UTC)

Searched the option to mark a arch package as out-of-date. Did not found it and wrote an email to the packer Sven-Hendrik Haase. Please let me know how you've done that. Thanks

muellner commented on 2014-03-31 09:20 (UTC)

Thanks, Frederik! I flagged the Arch Linux "boost" package out of date (quoting you), so that everything should work again without manual intervention as soon as the maintainers react.

freswa commented on 2014-03-31 08:55 (UTC)

You need to rebuild boost with python3.4. Just change the line echo "using python : 3.3 : /usr/bin/python3 : /usr/include/python3.3m : /usr/lib ;" >> ./tools/build/v2/user-config.jam to echo "using python : 3.3 : /usr/bin/python3 : /usr/include/python3.4m : /usr/lib ;" >> ./tools/build/v2/user-config.jam And build boost. I rebuilded graph-tool afterwards. Don't know if this is necessary.

lahwaacz commented on 2014-03-30 10:08 (UTC)

I would suggest to ask upstream: http://graph-tool.skewed.de/mailing I will not be able to help much further as I don't have the resources to rebuild with --enable-debug (even the normal build ate all of my RAM + swap).

muellner commented on 2014-03-30 08:45 (UTC)

Same here. I'm trying to figure out what exactly the problem is. If you have an idea, please tell me.

freswa commented on 2014-03-29 19:23 (UTC)

Same problem for me. If I try to import graph-tool I get a segmentation fault (since linked against python 3.4).

lahwaacz commented on 2014-03-28 21:06 (UTC)

Does the package work with python3.4? It worked for me yesterday with python3.3, but today's rebuild for python3.4 coredumps when importing the module.

muellner commented on 2014-03-28 09:05 (UTC)

@lahwaacz: Thanks! Fixed.

lahwaacz commented on 2014-03-27 22:43 (UTC)

Package does not build, saying that pycairo headers (pycairo/pycairo.h) were not found. This would suggest that the package depends on python2-cairo (at leas for building).

muellner commented on 2014-02-02 21:50 (UTC)

@vsilv: See here http://graph-tool.skewed.de/trac/ticket/116

vsilv commented on 2014-02-02 15:58 (UTC)

I get the error "Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported" Seems like graph-tool is built with the wrong GTK?

muellner commented on 2014-01-01 23:52 (UTC)

Hi frederik, what you suggest seems difficult to implement. Of course, as a human, you recognize that liblua5.1.so.5.1 belongs to an old version of the lua51 package, but I don't know how to figure this out with pacman's own means. Pacman has a record which (currently) installed files belong to which (current) package, but it does not keep track of file changes in new package versions.

freswa commented on 2013-12-25 23:26 (UTC)

pactree -u $packagename shows you all dependencies (recursivly) of the package without the opt-depends (quickly tested by me). You may check if the package that has a "not found" in ldd, has this dependency in pactree -u -> package is required, rebuild. If it is not in pactree -u -> package not required, do nothing. Example: "pactree -u graphviz | grep lua51" shows nothing. So skip the dependency lua51 which might be missing from praphviz. BTW: Nice skript.

muellner commented on 2013-12-19 00:16 (UTC)

Hi frederik, here is a working bash script that does what you suggested: #!/bin/bash dependencies=(cgal graphviz) for i in ${dependencies[@]}; do liblist=(`pacman -Ql $i | grep '\.so\(\..*\)\?$' | cut -d" " -f2-`) for j in ${liblist[@]}; do missing=`ldd $j | fgrep "=> not found"` if [ $? -eq 0 ]; then echo "Package '$i' needs to be recompiled." echo "See the following output line from 'ldd $j':" echo "$missing" exit 1 fi done done When I run it, it reports that the graphviz library /usr/lib/graphviz/lua/gv.so is linked against the nonexistent liblua5.1.so.5.1. However, lua51 is marked as an optional dependency of graphviz here: https://www.archlinux.org/packages/extra/x86_64/graphviz/ Hence, the error seems a false positive. Comments/ideas?

freswa commented on 2013-12-18 17:23 (UTC)

Didn't get your message right. Well yes, this test does not work if there are updates after compilation of graph-tool. But I think it would be a great step forward if we would definitely know at time of compiling whether the build would be successfull. Else we build graph-tool multiple times to get it running. With a test it is one error after any dependency update and after that - one time compile graph-tool. Thats much less work and much less frustrating.

freswa commented on 2013-12-18 17:11 (UTC)

I think a PKGBUILD-buildin check would be better, but since graphtool needs about 45 Minutes to build on a 6 Core HT machine (distributed via distcc) I think it is neccessary to make shure that this build will be successfull now - even if there is a fix in PKBGUILD in the future. As I wrote about a check, I thought of something like this: for i in Dependencies{ Z= pacman -Ql i | grep ".so" X=ldd /usr/lib/$Z | grep "=> not found" if(X is not empty){ print "Package $Z has to be rebuild" } } It's just symbolic code but it may work like this. Also you should interrupt the build process if the loop prints anything... Just my 0,02$

muellner commented on 2013-12-17 17:54 (UTC)

Hi Frederik, what you report is a general problem: when a library is updated, all programs that depend on it need to be recompiled (or re-linked). I tripped over the same issue as you before, but I don't have a good solution. If I include a test in the PKGBUILD for graph-tool, this will only be noticed when graph-tool is compiled. It happens more frequently, however, that CGAL and graph-tool are installed and boost is updated afterwards. There is nothing I can do about it in the AUR package, and yet you will be unable to import the Python module. I believe that this would be a good discussion topic on the Arch Linux forums: suggesting something like a new PKGBUILD variable to indicate library dependencies and to trigger recompilation when a dependency is updated. Regards, Daniel

freswa commented on 2013-12-17 15:54 (UTC)

Hi, may you please provide a check if libCGAL.so is linked against the right libboost_thread.so? If it is linked against a libboost_thread.so, that does not exist anymore, cgal needs to be rebuild. Took me 5 hours of searching, why graph-tool can't load his corelib. Thanks

vtselfa commented on 2013-11-30 17:38 (UTC)

I compiled in a machine with 16GB of ram and 4 cores. With -j4 it started to swap. It needs ~4GB per process to compile. BTW, it crashes with all graphviz related funtions. I think it's because graphviz package is compiled for python2. I tried recompiling graphviz for python3 support but after tunning the ./configure and finnally managing to compile it didn't work.

muellner commented on 2013-11-26 16:10 (UTC)

I compile it on a machine with 8GB RAM and two parallel compiler processes, and on another machine with 16GB and four processes. I recommend using a tool like "top" or "htop" to monitor memory consumption on your computer.

xiongyaohua commented on 2013-11-26 15:35 (UTC)

Hi, muellner Thanks for the instant response. I think you are right. I rebooted into console mode to save memory and disabled the parallel compilation. Now it can go further in the compilation process before the io goes crazy. However it still can not finish. Looks like I need to plug more memory. Could I know how many RAM do you have when compiling this?

muellner commented on 2013-11-26 14:58 (UTC)

Compilation of graph_tool is very memory intensive (close to 4GB as I remember, but I may be wrong by a power of 2). Your description sounds like your computer ran out of memory and started to swap RAM content to disk. Tips: 1) Of course, make sure that the machine where you compile the package has 4GB or more RAM. 2) Check your /etc/makepkg.conf. If it contains a line like MAKEFLAGS="-jX", the build system starts up to X compilation processes simultaneously. Comment it out or change it to "-j1" in this case.

xiongyaohua commented on 2013-11-26 14:50 (UTC)

Hi, I'm trying to build this. Everything goes fine until it starts to compile the "centrality/graph_closeness.lo". Then there is intensive disk io and the desktop becomes unresponsive. I made a "pacman -Syu" before compiling. So all dependencies should be up to date. Anyone have the same problem?

muellner commented on 2013-11-26 12:24 (UTC)

Thanks. Fixed.

vtselfa commented on 2013-11-26 09:18 (UTC)

Is not working for me. ImportError: /usr/lib/libboost_python.so.1.54.0: undefined symbol: PyClass_Type There is a problem in the PKGBUILD configure step: ./configure --enable-openmp --prefix=/usr --docdir="/usr/share/doc/$pkgname" PYTHON=python3 Corrected: ./configure --enable-openmp --prefix=/usr --docdir="/usr/share/doc/$pkgname" --with-boost-python=boost_python3 With this modification seems to work well.

muellner commented on 2013-11-24 19:33 (UTC)

@robcat: Thanks for the hint. I created a new AUR package, python-graph-tool, which replaces the existing python3-graph-tool. Please install the new package, as this will be maintained. I'll leave the old package here for a few months so that users can read about the transition, and finally, I'll ask the AUR team to delete python3-graph-tool.

robcat commented on 2013-11-22 11:07 (UTC)

Shouldn't the package name be python-graph-tool (according to https://wiki.archlinux.org/index.php/Python_Package_Guidelines)?

muellner commented on 2013-09-28 21:10 (UTC)

I cannot reproduce the error. Could you try to find out what exactly goes wrong and report back? Thanks!

enedene commented on 2013-09-28 16:24 (UTC)

==> ERROR: A failure occurred in prepare(). Aborting... ==> ERROR: Makepkg was unable to build python3-graph-tool.