You are here

Feed aggregator

0004762: "summary" field

Bug reports - Mon, 11/07/2016 - 15:49
Contracts have this field in toplevel, and the wallet does not accept it yet.
Categories: GNUnet

0003800: Error handling

Bug reports - Mon, 11/07/2016 - 15:45
The case 200 is done. We need to manage a payment not well ended, or a redirect we may get from the merchant, or a well ended payment but not acknowledged by the merchant. To be designed and implemented.
Categories: GNUnet

0004585: docker machine keeps dying

Bug reports - Mon, 11/07/2016 - 08:57
.. therefore breaking the autoclicking performed by buildbot-driven selenium
Categories: GNUnet

0004761: H_contract in fulfillment URL?

Bug reports - Sun, 11/06/2016 - 20:04
The question was whether it is 100% necessary or not to include H_contract in fulfillment URL.<br /> <br /> Reporting as bug just not let it go in oblivion.
Categories: GNUnet

0004760: gnunet-gtk HEAD not compatible with current gnunet HEAD

Bug reports - Fri, 11/04/2016 - 17:19
Emerging gnunet-gtk currently fails like this (courtesy of msoon):<br /> <br /> 2016-11-01 mtem sagt: undefined reference to `GNUNET_CLIENT_service_test'
Categories: GNUnet

0004379: error handling: exportable proof for e.g. double spending

Bug reports - Thu, 11/03/2016 - 20:51
When payments fail and it is not a transient error, the wallet needs to provide the user with a way to extract the information regarding the claim the merchant made.
Categories: GNUnet

0004454: fault injection for all GNU Taler APIs

Bug reports - Thu, 11/03/2016 - 16:59
All HTTP endpoints that are not directly viewed in the browser should (via a configuration setting?) sometimes return one of the transient error code.<br /> <br /> Probably it is better to not implement this in the services directly, but in some layer between them and nginx.<br /> <br /> Having a non-zero probability of getting transient errors even for components that are completely functional forces us (and other developers) to write code that is resistant against these failures, by using appropriate error handling strategies.
Categories: GNUnet

0004759: Fake errors needed

Bug reports - Thu, 11/03/2016 - 15:21
Bugs as <a href="https://gnunet.org/bugs/view.php?id=4732">0004732</a> need errors to be correctly tested, so the exchange should<br /> provide some way of generating errors. Moreover, some of them should not occur<br /> always, as otherwise we can't test other stuff. I suggest a mix of config values<br /> and URL parameters, like:<br /> <br /> [exchange]<br /> ..<br /> debug = "true";<br /> ..<br /> <br /> and a URL like /track/transfer?wtid=x&error=yes. So if 'debug' is set, then the<br /> exchange will return a conflict for wtid 'x'; if 'debug' is not set, then this is<br /> just a malformed URL (so we keep production exchange safe).
Categories: GNUnet

0004758: unix socket not created by python script

Bug reports - Thu, 11/03/2016 - 12:38
When the bank is launched by 'taler-bank-manage serve-uwsgi', the expected<br /> unix domain sockets in /tmp are not created. If instead the bank is launched with:<br /> <br /> uwsgi --emperor <PFX>/share/taler-bank/vassals-unix/<br /> <br /> then the sockets are correctly created.
Categories: GNUnet

0004757: gnunet-publish keeps terminal busy if using -P

Bug reports - Wed, 11/02/2016 - 23:19
According to the documentation that already comes with gnunet-publish, if I create a namespace and use it with -P option, I'm allowed to update shares when needed (in case I forget some metadata, keyword or file content).<br /> <br /> And since our documentation on this process no longer reflects the actual namespace creation steps, I decided to ask on IRC for where to create such namespace. So I was told to use gnunet-identity's -C option to do so. I did:<br /> <br /> $ gnunet-identity -C adfeno-shares<br /> <br /> And then, `gnunet-identity -d` does list the ego "adfeno-shares" there, along with a set of characters in the right side.<br /> <br /> I also asked what must be done to associate such ego to a namespace, and was told that it's already done by gnunet-identity.<br /> <br /> So I went ahead and tried to use gnunet-publish, like so:<br /> <br /> $ gnunet-publish -P adfeno-shares -t 1 -N 2 "Xera - Llume"<br /> <br /> Note: Llume is a music album from Xera. In this case, it's a directory containing the audio tracks as .opus files.<br /> <br /> To my surprise, however, the last command (gnunet-publish with -P option) keeps the current terminal busy, not even accepting Ctrl + C or termination signal. It only accepts kill signal.<br /> <br /> Despite this, gnunet-publish tells me that the publication of the directory was successful and gives me the gnunet-download syntax to try out.<br /> <br /> If, however, I remove -P, -t, and -N, gnunet-publish does the publication and exits when finished, although this might not allow me to make future updates to the content published.<br /> <br /> I have attached an strace of `gnunet-publish -P "adfeno-shares" -t 1 -N 2 "Xera - Llume"`.
Categories: GNUnet

0004756: Adapt testcases to #4568

Bug reports - Wed, 11/02/2016 - 21:06
Testcases that relies on the Python bank need to specify the new "admin" TCP<br /> port when depositing money at the bank.
Categories: GNUnet

0004755: no error code in conflicting track-transaction

Bug reports - Wed, 11/02/2016 - 20:07
The returned JSON has no "code" field, in contrast to its track-transaction counterpart.
Categories: GNUnet

0003700: gnunet-transport -in is not reporting all of the connections and sometimes none

Bug reports - Wed, 11/02/2016 - 17:57
Here is the output of several runs of 'gnunet-transport -in' in quick succession:<br /> <br /> <a href="mailto:gnunet@gnunet">gnunet@gnunet</a>:~$ gnunet-transport -in<br /> Peer `09F3': tcp tcp.0.188.193.8.164:58341<br /> Peer `9QXF': udp udp.0.131.254.145.10:2086<br /> Peer `3V8C': tcp tcp.0.92.225.37.123:46484<br /> Peer `64TF': udp udp.0.79.229.106.18:2086<br /> Peer `7HGS': tcp tcp.0.88.6.41.77:57334<br /> Peer `CVZP': tcp tcp.0.68.186.248.198:48629<br /> Peer `DSTJ': udp udp.0.131.159.74.67:2086<br /> Peer `DZ8N': tcp tcp.0.93.103.95.89:42475<br /> Peer `F1DK': tcp tcp.0.46.186.11.176:54506<br /> Peer `GN10': tcp tcp.0.216.139.213.94:60910<br /> Peer `GN10': tcp tcp.0.104.167.105.252:38432<br /> Peer `QNH8': tcp tcp.0.92.244.6.132:32825<br /> <a href="mailto:gnunet@gnunet">gnunet@gnunet</a>:~$ gnunet-transport -in<br /> Peer `09F3': tcp tcp.0.188.193.8.164:58341<br /> Peer `3V8C': tcp tcp.0.92.225.37.123:46484<br /> Peer `64TF': udp udp.0.79.229.106.18:2086<br /> Peer `9QXF': udp udp.0.131.254.145.10:2086<br /> Peer `7HGS': tcp tcp.0.88.6.41.77:57334<br /> Peer `CVZP': tcp tcp.0.68.186.248.198:48629<br /> Peer `DSTJ': udp udp.0.131.159.74.67:2086<br /> Peer `GN10': tcp tcp.0.216.139.213.94:60910<br /> <a href="mailto:gnunet@gnunet">gnunet@gnunet</a>:~$ gnunet-transport -in<br /> <a href="mailto:gnunet@gnunet">gnunet@gnunet</a>:~$ gnunet-transport -in<br /> Peer `09F3': tcp tcp.0.188.193.8.164:58341<br /> Peer `3V8C': tcp tcp.0.92.225.37.123:46484<br /> Peer `64TF': udp udp.0.79.229.106.18:2086<br /> Peer `7HGS': tcp tcp.0.88.6.41.77:57334<br /> Peer `9QXF': udp udp.0.131.254.145.10:2086<br /> Peer `CVZP': tcp tcp.0.68.186.248.198:48629<br /> Peer `DSTJ': udp udp.0.131.159.74.67:2086<br /> Peer `DZ8N': tcp tcp.0.93.103.95.89:42475<br /> Peer `F1DK': tcp tcp.0.46.186.11.176:54506<br /> Peer `GN10': tcp tcp.0.216.139.213.94:60910<br /> Peer `GN10': tcp tcp.0.104.167.105.252:38432<br /> Peer `QNH8': tcp tcp.0.92.244.6.132:32825<br /> <br /> I don't think the connections are coming and going that quickly as 'gnunet-transport -m' doesn't show that much activity.
Categories: GNUnet

0004568: listen on different socket for administrative interface

Bug reports - Mon, 10/31/2016 - 15:00
Otherwise it's easy to accidentally expose the administrative interface. This is bad since the administrative APIs, by design, don't use authentication.<br /> <br /> For the administrative interface, HTTP over unix domain socket seems especially handy.
Categories: GNUnet
Subscribe to GNUnet aggregator