gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with gnunet-qr


From: Alessio Vanni
Subject: Re: Problems with gnunet-qr
Date: Mon, 16 Dec 2019 09:31:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

I accidentally sent this reply only to Christian, but it should be sent
to the list too.  Apologies to Christian for the double mail.  (Will I
ever be able to reply to this list without messing up?)

Christian Grothoff <address@hidden> writes:

> OMG. That shouldn't even look like that. We have a special function for
> verbose that should be used. Fixed in Git Master.
>
> I've initialized the sigpipe now. 
>

Thanks!
I'll update as soon as possible.

> Eh, good question. The URL format did not really change, but we did
> change the crypto _last week_. So if you created the QR code two weeks
> ago, that would not work with this week's code. That said, I didn't try
> this recently at all. Schanzen: we probably should test this, clearly
> gnunet-qr was not working as intended before...

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?

As a final note, the experiment I attempted involved two identities
under my control: I created the QR code for one of them and then tried
to import it in the namestore of the other identity.  Intuitively I'd
think it shouldn't cause any issue, but just in case here it is.

Thanks,
A.V.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]