Hi Alessio, I've now fixed and tested gnunet-qr, so it should work now.
Thanks for reporting! -Christian On Mon, 2019-12-16 at 12:14 +0100, Christian Grothoff wrote: > On 12/16/19 9:31 AM, Alessio Vanni wrote: > > I created the QR code before testing out the changes I made, i.e. > > the > > same day as I sent the mail you were replying to. > > > > At a quick glance, comparing the documentation with the actual > > function > > call, it seems that the call to `GNUNET_OS_start_process' becomes > > the > > equivalent to calling "gnunet-namestore gnunet://gns/..." from the > > command line. I tried doing just that (using the command line) and > > gnunet-namestore completely discards the URI, likely because it > > expects > > it as a value to one of the supported options. Maybe that's the > > problem? > > Yes, it seems gnunet-namestore changed and expects the uri after a -u > argument. However, gnunet-qr doesn't support passing arguments other > than the URI yet. So we need to change: > > diff --git a/src/namestore/namestore.conf.in > b/src/namestore/namestore.conf.in > index b5fb45abc..e6cc74aec 100644 > --- a/src/namestore/namestore.conf.in > +++ b/src/namestore/namestore.conf.in > @@ -36,7 +36,7 @@ TEMPORARY_TABLE = NO > ASYNC_COMMIT = NO > > [uri] > -gns = gnunet-namestore > +gns = gnunet-namestore -u > > > [fcfsd] > > plus adding logic in gnunet-qr to tokenize the configuration option > and > pass "gnunet-namestore" and "-u" to exec separately. > > I'll try to fix this tomorrow, unless someone beats me to it ;-) >
