Re: Can't specify different names for config file in project data

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4411924637973170865==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="0CMZ16MS42SCkO1jrIv089PQV1ZQv30Dx"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0CMZ16MS42SCkO1jrIv089PQV1ZQv30Dx
Content-Type: multipart/mixed; boundary="wHhgrmpmsTJ18J3T1vCBINjhp71JVBvqn";
 protected-headers="v1"
From: Christian Grothoff <[email protected]>
To: Alessio Vanni <[email protected]>, [email protected]
Message-ID: <[email protected]>
Subject: Re: [bug-GNUnet] Can't specify different names for config file in
 project data
References: <[email protected]>
In-Reply-To: <[email protected]>

--wHhgrmpmsTJ18J3T1vCBINjhp71JVBvqn
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Ok, then I'm not sure how you expect this to work: if you do not give
the code access to the configuration data (i.e. by telling it to load it
from a different directory than where GNUnet was installed and also not
providing the right configuration information in that directory), then
obviously the logic will fail when it needs its configuration.

Note that you can use GNUNET_CONFIGURATION_load* with the "right"
path(s) to manually load either the GNUnet configuration data or your
own applications' configuration data (if they are in different
locations). However, without such manual action on your part,
libgnunetutil will by design only load the configuration data from the
one location that is configured via the ProjectData mechanism.

Does this help?

On 9/10/19 9:41 PM, Alessio Vanni wrote:
> Sorry for the late reply.  I didn't see there was a reply to the report=

> (I'm not subscribed to this list... I check the archives from time to
> time though.)
>=20
>> This shouldn't be the case, as GNUnet picks up the (default) service
>> contact information from a the share/gnunet/config.d/ directory.
>>
>> Also, when I change the value, everything still works for me. What is
>> the error message you are seeing (if any)?
>=20
> The problem is in 3rd-party applications.  GNUnet itself correctly read=
s
> its config files from the correct directories.  However, if the
> GNUNET_OS_ProjectData structure holds different values, the application=

> doesn't work.
>=20
> The main problem is that it can't connect to GNUnet services, so the
> error is that `GNUNET_CLIENT_connect' returns NULL when making a
> connection.
>=20
> For a concrete error message, using `GNUNET_IDENTITY_ego_lookup' (which=

> makes an implicit connection to the IDENTITY service) when .config_file=

> and .user_config_file are different from "gnunet.conf" and
> "~/.config/gnunet.conf" respectively, it fails with the following
> message:
>=20
> ERROR Assertion failed at identity_api_lookup.c:202.
>=20
> The line in question is a `GNUNET_break' called when
> `GNUNET_CLIENT_connect' returns NULL.
>=20
> The error does not happen if the configuration file (either one, as lon=
g
> as it exists) is the same as GNUnet itself.
>=20
> I attached a minimal program for testing this issue.  It simply calls
> `GNUNET_IDENTITY_ego_lookup'.  If it successfully connects, it will
> print wether or not the ego "test-ego" exists; otherwise, it will fail
> with the above message.
>=20
> Thanks,
> A.V.
>=20
>=20
> _______________________________________________
> Bug-GNUnet mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/bug-gnunet
>=20


--wHhgrmpmsTJ18J3T1vCBINjhp71JVBvqn--

--0CMZ16MS42SCkO1jrIv089PQV1ZQv30Dx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE2EI7yzJseQcDOSnHk55r4eKfw8wFAl14PiYACgkQk55r4eKf
w8xnJQ//Q90ohnWbNkOOB8kVVXivre7iRn7/2/YZzRyczOTJzVKKZCHEJjK98bYa
MVez//dRZOsGX3bzckopg+lUBoiGcYqxEEIE8ftBaZ98jbnSMoBJkt3zUYyw/GCt
aXJTHQzMxR9NTaaC8Zapj0eSWFdE/Qn2RrYso1sMcolke+hrrFvHGT0RE+wDzo5B
JVOJGPCZAXOwwzZ4nF9rLA/6NUgM13JD7PHUy9lLS6R35pcSgTkWs+Jtomi//7DU
Gl/5ME26L1BhvrM31xZMVmokPNj4JNzFLzvZ0L0gc+Jo6QgVAUqB3nus5YjrUOgU
aEpFoIwwFdd0Dj3pjiAo7Tc0qR26rH9qySJKIeP8UO6QOFW/X3nPrvM5HdGeU7Cm
8xqZ0STCsjPxJnBYossUhAvKjCh3pwRazRAEC0Q/1vMWMDEWxsII90V7yptgVrPd
doD9vh8yekksGceGapDgMDxCTC2WqL9DC2ySDYBS5R3pRJ/JyshT/azuX7g08K2g
7OiKAV2AwA2y1yC9gJekxK3xhRd95R4fSJTHQ2NPlwol/LNpor/3P95yYqsFkjqU
EYvzyrc76gMHO3KcC3w4PfgS8JeFi58LS8XtfCuYsl89fRnjFfl4Ioa2TnCdxuZb
krkmO0CWRCZQK4irYWYJnHyLz9u7RxO/SzsyoBLgRiATRwfSeUA=
=gL51
-----END PGP SIGNATURE-----

--0CMZ16MS42SCkO1jrIv089PQV1ZQv30Dx--


--===============4411924637973170865==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQnVnLUdOVW5l
dCBtYWlsaW5nIGxpc3QKQnVnLUdOVW5ldEBnbnUub3JnCmh0dHBzOi8vbGlzdHMuZ251Lm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2J1Zy1nbnVuZXQK

--===============4411924637973170865==--