[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with gnunet-qr
From: |
Christian Grothoff |
Subject: |
Re: Problems with gnunet-qr |
Date: |
Tue, 17 Dec 2019 13:16:34 +0100 |
User-agent: |
Evolution 3.30.5-1.1 |
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 ;-)
>