Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    John Black
    @Fierozen
    With version 1.0.9 of pyethapp, I am getting the following during startup: File "/pyrlp/pydevp2p/devp2p/discovery.py", line 573, in start nodes = [Node.from_uri(x) for x in self.app.config['discovery']['bootstrap_nodes']] KeyError: 'bootstrap_nodes'
    Ulrich Petri
    @ulope
    @Fierozen: Please re-try with a fresh virtualenv
    John Black
    @Fierozen
    Well, actually, I'm running the Dockerfile. I agree though that it seems like it could be prior runs contaminating the data in the volume. But even on a different machine, with a brand new virtual machine and container, I get that error.
    heikoheiko
    @heikoheiko
    @chfast are you are heare already :)
    Paweł Bylica
    @chfast
    Just joined
    Paweł Bylica
    @chfast
    Does pydevp2p support IGD/UPnP?
    heikoheiko
    @heikoheiko
    no
    but, we are accepting patches :)
    Paweł Bylica
    @chfast
    Can you suggest good UPnP package for Python?
    heikoheiko
    @heikoheiko
    ideally a module should work with pypy and py3.
    Paweł Bylica
    @chfast
    Ping: ethereum/pydevp2p#24
    Paweł Bylica
    @chfast
    ethereum/pydevp2p#25 ?
    Paweł Bylica
    @chfast
    I managed to start devp2p on Windows.
    However I have some issues possibly with gevent. Some test fails with:
    +++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++
    
    ~~~~~~~~~~~~~~~~~~~~~~~~~~ Stack of <unknown> (5176) ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      File "c:\MinGW\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\threadpool.py", line 196, in _worker
        task = task_queue.get()
      File "c:\MinGW\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\_threading.py", line 435, in get
        self.not_empty.wait()
      File "c:\MinGW\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\_threading.py", line 151, in wait
        waiter.acquire()
    
    ~~~~~~~~~~~~~~~~~~~~~~~~~~ Stack of MainThread (1060) ~~~~~~~~~~~~~~~~~~~~~~~~~~
      File "c:\MinGW\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\hub.py", line 643, in run
        loop.run()
    
    +++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++
    heikoheiko
    @heikoheiko
    @ms83 ? any idea?
    Paweł Bylica
    @chfast
    Is it possible that gevent deadlocks?
    heikoheiko
    @heikoheiko
    can you paste the full logs. (i.e. run with py.test -s). currently i don't even know which test fails.
    Paweł Bylica
    @chfast
    tomorrow
    Paweł Bylica
    @chfast

    So @heikoheiko @ms83 the thing is like this:
    Running

    $ py.test devp2p/tests/test_kademlia_protocol.py
    ============================= test session starts =============================
    platform win32 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1
    rootdir: C:\MinGW\msys\1.0\home\chfast\Projects\golem\pydevp2p, inifile:
    plugins: catchlog-1.2.1, timeout-1.0.0
    collected 12 items
    
    devp2p\tests\test_kademlia_protocol.py ..X.X.X.....
    
    ===================== 9 passed, 3 xpassed in 9.16 seconds =====================

    is ok.

    But running full test suite is not ok. Seems like earlier tests interferes with gevent in later tests...

    $ py.test -s
    ============================= test session starts =============================
    platform win32 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1
    rootdir: C:\MinGW\msys\1.0\home\chfast\Projects\golem\pydevp2p, inifile:
    plugins: catchlog-1.2.1, timeout-1.0.0
    collecting 0 itemsC:\MinGW\msys\1.0\home\chfast\Projects\golem\pydevp2p\devp2p\crypto.py:37: UserWarning: could not import c_secp256k1, fallback to bitcointools
      warnings.warn('could not import c_secp256k1, fallback to bitcointools')
    collected 75 items
    
    devp2p\tests\test_crypto.py ........
    devp2p\tests\test_discovery.py ....test bootstrap from=<Node(c42b774e)> to=<Node(3b9ad1d4)>
    test bootstrap from=<Node(562f2f68)> to=<Node(3b9ad1d4)>
    test bootstrap from=<Node(7841181a)> to=<Node(3b9ad1d4)>
    test bootstrap from=<Node(1213a1b9)> to=<Node(3b9ad1d4)>
    test bootstrap from=<Node(2cc3f4d3)> to=<Node(3b9ad1d4)>
    test find_node from=<Node(c42b774e)>
    test find_node from=<Node(562f2f68)>
    test find_node from=<Node(7841181a)>
    test find_node from=<Node(1213a1b9)>
    test find_node from=<Node(2cc3f4d3)>
    5
    5
    5
    5
    5
    5
    .
    devp2p\tests\test_ecies.py ..........
    devp2p\tests\test_go_handshake.py .header (0, 0)
    packet_type 0
    frame {'client_version_string': 0, 'version': 3, 'remote_pubkey': 'v-\xd8\xa0cn\x07\xa5K1\x16\x9e\xba\x0cz \xa1\xac\x1e\xf6\x85\x96\xf1\xf2\x83\xb5\xc6v\xba\xe4\x06J\xbf\xcc\xe2G\x99\xd0\x9fg\xe3\x92c-?\xfd\xc1.=d0\xdc\xb0\xea\x19\xc3\x184?\xfaz\xaet\xd4', 'listen_port': 0, 'capabilities': (('a', 0), ('b', 2))}
    .
    devp2p\tests\test_go_signature.py ..
    devp2p\tests\test_kademlia.py ........
    devp2p\tests\test_kademlia_protocol.py ..
    +++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++
    
    ~~~~~~~~~~~~~~~~~~~~~~~~~~ Stack of <unknown> (5808) ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      File "c:\mingw\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\threadpool.py", line 196, in _worker
        task = task_queue.get()
      File "c:\mingw\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\_threading.py", line 435, in get
        self.not_empty.wait()
      File "c:\mingw\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\_threading.py", line 151, in wait
        waiter.acquire()
    
    ~~~~~~~~~~~~~~~~~~~~~~~~~~ Stack of MainThread (824) ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      File "c:\mingw\msys\1.0\home\chfast\.virtualenvs\eth\lib\site-packages\gevent\hub.py", line 643, in run
        loop.run()
    
    +++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++

    The same issue I had with "full app" tests so I removed them for now.

    Paweł Bylica
    @chfast
    This dependency git+https://github.com/ulope/secp256k1-py#egg=secp256k1 really sucks.
    heikoheiko
    @heikoheiko
    this is only temporary until we got our patch merged.
    Paweł Bylica
    @chfast
    It looks the patch has been merged. Thanks for all the effort.
    Aiman Baharna
    @aiman

    Installing pydevp2p is broken on Ubuntu 14.04 LTS, which also breaks pyethapp... It cannot install secp256k1

    $ pip install devp2p==0.7.0
    ...
    Downloading/unpacking secp256k1 (from devp2p==0.7.0)
      Downloading secp256k1-0.12.0.tar.gz (144kB): 144kB downloaded
      Running setup.py (path:/tmp/pip_build_root/secp256k1/setup.py) egg_info for package secp256k1
        Your setuptools version (3.3) is too old to correctly install this package. Please upgrade to a newer version.
        Complete output from command python setup.py egg_info:
        Your setuptools version (3.3) is too old to correctly install this package. Please upgrade to a newer version.

    ...but devp2p==0.6.2 works fine.

    heikoheiko
    @heikoheiko
    @czepluch ----^
    Jacob Stenum Czepluch
    @czepluch
    @aiman Have you tried updating setuptools as suggested?
    Aiman Baharna
    @aiman

    @czepluch Thanks for looking in to this.

    Upgrading setuptools is certainly one approach, but it is a rather extreme solution!

    I would expect that most Python packages will work out of the box for the current LTS version of most distros. Are the benefits of requiring a new setuptools version really worth breaking the ability to install the package easily on the LTS version of major distros? I'm not convinced of that. I think having to upgrade setuptools should be an option of last resort.

    Besides, upgrading setuptools systemwide is not a good idea. Most people will get python-setuptools from their distro's package manager. And it is unwise to use sudo pip to upgrade a Python package installed using the distro package manager. This can lead to a broken system. In addition, at least on Ubuntu pip will now detect this situation and refuse to upgrade setuptools in the first instance.

    What this means is that I am forced to use a virtualenv to install pyethapp. But this is not great because it complicates deployment when using containers, where there is no need to use a virtualenv.

    As for actually using a virtualenv to install pydevp2p, installation fails due to a new problem:

    (venv)$ pip install devp2p==0.7.0
    ...
         /bin/mkdir -p '/home/docker/venv/build/secp256k1/build/temp.linux-x86_64-2.7/include'
         /usr/bin/install -c -m 644 /home/docker/venv/build/secp256k1/libsecp256k1/include/secp256k1.h /home/docker/venv/build/secp256k1/libsecp256k1/include/secp256k1_recovery.h '/home/docker/venv/build/secp256k1/build/temp.linux-x86_64-2.7/include'
         /bin/mkdir -p '/home/docker/venv/build/secp256k1/build/temp.linux-x86_64-2.7/lib/pkgconfig'
         /usr/bin/install -c -m 644 libsecp256k1.pc '/home/docker/venv/build/secp256k1/build/temp.linux-x86_64-2.7/lib/pkgconfig'
        make[1]: Leaving directory `/home/docker/venv/build/secp256k1/build/temp.linux-x86_64-2.7'
        error: [Errno 2] No such file or directory
    ...
    Command /home/docker/venv/bin/python -c "import setuptools, tokenize;__file__='/home/docker/venv/build/secp256k1/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-rDGr8l-record/install-record.txt --single-version-externally-managed --compile --install-headers /home/docker/venv/include/site/python2.7 failed with error code 1 in /home/docker/venv/build/secp256k1
    Storing debug log for failure in /home/docker/.pip/pip.log

    Full log available at http://hastebin.com/siyomowiqa.vhdl

    Jacob Stenum Czepluch
    @czepluch
    Thank you for detailed explanation and view points. I do agree that this should only be a last resort. I must admit that I am a bit busy at the moment and won't have time to look further into this before tomorrow evening. Maybe @ulope can help you in the meantime. If not, I will come back to you tomorrow. I hope you can wait until then.
    Aiman Baharna
    @aiman
    Thank you @czepluch. It will be good to fix this issue in due course. But there is no need to rush it. I put together a Dockerfile to reproduce the issue I am seeing with the virtualenv. http://hastebin.com/yazecehebi.vala
    Jacob Stenum Czepluch
    @czepluch
    @aiman thank you!
    Ulrich Petri
    @ulope
    @aiman I'll be looking into this tomorrow. We need a "relatively" new setuptools in order for the automatic building of libsecp256k1 to work. I don't know of the top of my head if it can work with 14.04's setuptools version. Having said that using a virtualenv is strictly the most reliable way to get a properly working installation. I'll be looking into the failure you're getting in the doker case tomorrow as well.
    Jacob Stenum Czepluch
    @czepluch
    +1
    Ulrich Petri
    @ulope
    @aiman: One mystery solved. Your docker example fails to build because it's missing pkg-config (I agree though that the error message isn't helpful at all, will fix that)
    Aiman Baharna
    @aiman
    @ulope The pkg-config dependency makes sense. After installing it, building and installing secp256k1 succeeds!
    Ulrich Petri
    @ulope
    @aiman: Good to hear. I've just submitted a PR (ludbb/secp256k1-py#8) to lower the setuptools requirement to 3.3. Once that's accepted it should build on 14.04 out of the box
    Aiman Baharna
    @aiman
    Excellent news @ulope! By the way I tried the version from your fork ulope/secp256k1-py version and it compiles and installs just fine out of the box. Thank you for your help.
    Paweł Bylica
    @chfast
    Do you plan do add Windows support?
    alitaoo
    @alitaoo
    Hi, I'm testing devp2p examples and I have some problems to make test_discovery.py work. I always have "num nodes 0". Any idea why? It's a problem of boostrap?
    Augusto Hack
    @hackaugusto
    Hi @alitaoo could you please send a paste/gist with the output?
    alitaoo
    @alitaoo
    ali@ubuntu:/home/alitaoo/pydevp2p/devp2p/tests$ python test_discovery.py
    this node is
    2da47499d52d9161a778e4c711e22e8651cb90350ec066452f9516d1d11eb465d1ec42bb27ec6cd4488b8b6a1a411cb5ef83c16cbb8bee194624bb65fef0f7fd
    remote node is <Node(24f904a8)>
    START & TEST BOOTSTRAP
    TEST FIND_NODE
    num nodes 0
    num nodes 0
    num nodes 0
    num nodes 0
    num nodes 0
    num nodes 0
    num nodes 0
    num nodes 0
    num nodes 0
    num nodes 0
    nodes in routing
    nodes we are waiting for pongs
    enode://24f904a876975ab5c7acbedc8ec26e6f7559b527c073c6e822049fee4df78f2e9c74840587355a068f2cdb36942679f7a377a6d8c5713ccf40b1d4b99046bba0@5.1.83.226:30303
    I do not know if it's matter but I do have a public interface and no firewall
    Augusto Hack
    @hackaugusto
    My bad, I meant with debug logging enabled https://github.com/ethereum/pydevp2p/blob/master/devp2p/tests/test_discovery.py#L284
    alitaoo
    @alitaoo
    ha let see :)
    alitaoo
    @alitaoo
    DEBUG:p2p.discovery.kademlia    pinging remote=<Node(24f904a8)> local=<Node(2da47499)>
    DEBUG:p2p.discovery     >>> ping remoteid=<Node(24f904a8)>
    DEBUG:p2p.discovery     >>> message address=Address(5.1.83.226:30303)
    DEBUG:p2p.discovery     sending to=Address(5.1.83.226:30303) size=129
    CRITICAL:p2p.discovery  udp write error errno=22 reason=Invalid argument
    CRITICAL:p2p.discovery  waiting for recovery
    :)
    I think this is the part that fails
    Augusto Hack
    @hackaugusto
    Thank you :), will have a look
    alitaoo
    @alitaoo
    The error 22 comes from config_discovery['listen_host'] = '127.0.0.1'. When I set it to my public interface I have no more the critical message. Everything seems ok, but I still have 0 node