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

0004754: Amount not (completely) shown

Bug reports - Sun, 10/30/2016 - 19:03
By trying to withdraw from an exchange running on loopback, the wallet<br /> does not show the amount withdrawn, but just "0.00 PUDOS (+5.00 PUDOS incoming)",<br /> and keeps showing that forever.<br /> <br /> Apparently, the exchange keeps receiving request, as logs show several lines as the following:<br /> <br /> Oct 30 19:59:33-307852 taler-exchange-httpd-7149 INFO Handling request for URL '/reserve/withdraw'<br /> Oct 30 19:59:33-307894 taler-exchange-httpd-7149 INFO Handling request for URL '/reserve/withdraw'<br /> Oct 30 19:59:33-307908 taler-exchange-httpd-7149 INFO Handling request for URL '/reserve/withdraw'<br /> Oct 30 19:59:33-308111 taler-exchange-httpd-7149 INFO Not returning DKI for ZNBM3FQW, as start time is in the future<br /> <br /> For the bank everything is OK, as I see the green bar "withdrawal approved" after resolving<br /> the CAPTCHA.<br /> <br /> Moreover, the exchange is accessed through a name, like "<a href="http://localexchange"">http://localexchange".</a> [<a href="http://localexchange"" target="_blank">^</a>]
Categories: GNUnet

0004753: Build misbehaviour

Bug reports - Sun, 10/30/2016 - 18:55
When building the wallet with 'make', it gives the following error:<br /> <br /> node_modules/gulp/bin/gulp.js tsconfig<br /> <br /> /home/marcello/wallet-webex/gulpfile.js:32<br /> const gulp = require("gulp");<br /> ^^^^^<br /> SyntaxError: Use of const in strict mode.<br /> at Module._compile (module.js:439:25)<br /> at Object.Module._extensions..js (module.js:474:10)<br /> at Module.load (module.js:356:32)<br /> at Function.Module._load (module.js:312:12)<br /> at Module.require (module.js:364:17)<br /> at require (module.js:380:17)<br /> at Liftoff.handleArguments (/home/marcello/wallet-webex/node_modules/gulp/bin/gulp.js:116:3)<br /> at Liftoff.<anonymous> (/home/marcello/wallet-webex/node_modules/liftoff/index.js:198:16)<br /> at module.exports (/home/marcello/wallet-webex/node_modules/flagged-respawn/index.js:17:3)<br /> at Liftoff.<anonymous> (/home/marcello/wallet-webex/node_modules/liftoff/index.js:190:9)<br /> at /home/marcello/wallet-webex/node_modules/liftoff/index.js:164:9<br /> Makefile:21: recipe for target 'tsconfig.json' failed<br /> make: *** [tsconfig.json] Error 8<br /> <br /> Note that './configure' also gave what follows:<br /> <br /> Using node v0.10.29<br /> ./configure: line 33: msgmerge: command not found<br /> Warning: msgmerge missing, i18n won't work
Categories: GNUnet

0003594: gnunet-ats prints primary output to stderr

Bug reports - Wed, 10/26/2016 - 19:22
Running <br /> <br /> $ gnunet-ats -na | grep foo<br /> <br /> doesn't work because gnunet-ats decides to write its main output to stderr instead of to stdout where it belongs. Booh!
Categories: GNUnet

0003799: gnunet-publish client hangs after unindex error

Bug reports - Wed, 10/26/2016 - 19:22
The publish-service won't publish files (for some reason as yet undetermined) and the client receives a GNUNET_FS_STATUS_UNINDEX_START which causes it to hang until the user sends SIGINT.<br /> <br /> Then the client receives GNUNET_FS_STATUS_UNINDEX_ERROR which again causes it to hang until a further SIGINT.<br /> <br /> Then the client process ends with a non-zero exit status.
Categories: GNUnet

0004752: should be possible to specify IP address to bind to

Bug reports - Tue, 10/25/2016 - 20:36
Right now, if the backend binds to a TCP port it always binds to all IPs. It would be useful to allow the admin to specify a specific IP address (and probably we should use loopback for the default).
Categories: GNUnet

0004751: reserve balances and garbage collection of denomination keys

Bug reports - Tue, 10/25/2016 - 14:14
When withdrawing from the reserve, we calculate its current balance<br /> by totaling up the existing withdrawals. However, those are tied<br /> to the respecive denomination key. So if a DK is GCed, and the reserve<br /> for which withdrawals with this DK was made still exists, then that<br /> reserve will suddenly again have money in it! (As we forget about the<br /> withdrawals!). So we either need constraints (reserve lifetime << DK<br /> expirations; DK GC only if all reserves have expired), which are awful,<br /> or we need a way to "abbreviate" reserve histories to drop ancient<br /> transactions and replace those by a summary (also ugly, as it violates<br /> the notion that all DBs are 'append-only').<br /> <br /> Maybe fast reserve expiration is the best answer?
Categories: GNUnet

Pages

Subscribe to GNUnet aggregator