Building applications without AGPL restriction

2022-10-20 Thread marty1885
Hi,

I've been interested in GNUnet for quite a while now. Recently I got time to
learn the API and be able to build a C++ wrapper for some of the subsystems.
It's fun!

Now I want to build applications using GNUnet. As I understand, GNUnet is
licensed under AGPL thus my application also has to be AGPL. But it may not be
suitable for my use case.

For example I want to show GNUnet stats on my personal website. Or some REST
that exposes GNUnet metadata, FS proxy for download, DHT get/put, etc.. Which
enable others to have easy-ish access to GNUnet. But I don't want to force them
to also use AGPL. (Or even some security/commercial application in the future.)

Is it possible to let applications be licensed under BSD/MIT/LGPL (or even via
special clauses in GNUnet) without complicating the code?

I know this is a long shot. But no harm to ask.

Best Regards,

Martin



Unexpectly short DHT entry lifetime

2023-05-08 Thread marty1885
Hi all,

I've been messing around with GNUnet and building fun applications with it. One 
thing I noticed recently. Looking at the source code of gnunet-dht-put. The 
default lifetime of a DHT entry should be an hour[1]. But when I run the 
following command. The key `hello` is not found via the get command just 5 
minutes or less later.

> gnunet-dht-put -k "hello" -d "world" # Set hello to world
> # Running immediately after set works
> gnunet-dht-get -k "hello"  -T 1000
Result 0, type 8:
world
> sleep 300
> gnunet-dht-get -k "hello"  -T 1000
# No key found

[1]: https://git.gnunet.org/gnunet.git/tree/src/dht/gnunet-dht-put.c#n235

Am I doing something wrong? My application needs the DHT to bootstrap group 
information. 

Best,
Martin



Re: Unexpectly short DHT entry lifetime

2023-05-14 Thread marty1885
Hi Martin,

I increased the cache and routing table size and that seems to do the trick. 
Didn't try restarting GNUnet on it's own. Not sure what fixed it.

Best

--- Original Message ---
On Tuesday, May 9th, 2023 at 11:38 PM, Schanzenbach, Martin 
 wrote:


> Hi Martin,
> 
> I just tested this and I don't get results at all. Not even when I am
> not connected to the network.
> This may be related to some recent changes to the DHT.
> 
> BR
> 
> Am 09.05.23 um 08:02 schrieb marty1885:
> 
> > Hi all,
> > 
> > I've been messing around with GNUnet and building fun applications with it. 
> > One thing I noticed recently. Looking at the source code of gnunet-dht-put. 
> > The default lifetime of a DHT entry should be an hour1. But when I run the 
> > following command. The key `hello` is not found via the get command just 5 
> > minutes or less later.
> > 
> > > gnunet-dht-put -k "hello" -d "world" # Set hello to world
> > > # Running immediately after set works
> > > gnunet-dht-get -k "hello" -T 1000
> > > Result 0, type 8:
> > > world
> > > sleep 300
> > > gnunet-dht-get -k "hello" -T 1000
> > > # No key found
> > 
> > Am I doing something wrong? My application needs the DHT to bootstrap group 
> > information.
> > 
> > Best,
> > Martin



New node won't connect to existing nodes without manually providing HELLO message

2023-07-23 Thread marty1885
Hi,

Sorry it's me again.

Today I was setting up 2 new nodes at a new location for my experiments. 
However, I fail over and over to connect them to the GNUnet network. I've tried 
adding my existing nodes via hello using the peerinfo tool. But the node 1. 
takes about 30min to establish a connection to the other node. If that happens 
at all. 2. Afterwards, it node is not making new peers. Thus is the node I 
added manually goes down, that node is also disconnected from GNUnet.

Also, I have tried bootstraping off my node's hostlist. I have also tried 
enabling the -e -b flag of the hostlist daemon. Still can't get the node to 
connect to others.

How can I solve this? Is there a drastic change recently leading to 
bootstrapping so difficult?

Hopefully these information helps

Currently, the new nodes are setup with connections to my other node

❯ gnunet-core
Sun Jul 23 14:06:48 2023: connection established CCXH (timeout in  299 
s)

However, I can find many more peers in peerinfo

Peer `V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG'
Peer `7WRDFAMRXJ14K752Z2SF9SSD3VR5XAVKPEBJ19ZKA2M6QHT3YBV0'


But gnunet-cadet -P shows I have no path to all of them (besides the ones I 
added manually).

008Q3SKSXDAQDBMKZSJ4VHPVV2ZNG9PF783RA4132SD96PRJZ1Z0 tunnel: N, paths: 0
CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG tunnel: N, paths: 1
5GYZVBTD5K0WCSVQGRHG18ZDBC3TT6905M34R9WKWQZHD906PDBG tunnel: N, paths: 0
DSTJBRRKZ8TBW3FGK6B0M5QXWT9WYNZ45H5MCV4HY7ST64Q8T9F0 tunnel: N, paths: 0
DRD47JG4E9X1B67TXHV9M6V03RYD415FGCSA63X11F23NRRXDQFG tunnel: N, paths: 0
1YGNJFY3VM6VQYY9M8K80ZZ9233TCBSZDQG93NSJM7J0T47D9VY0 tunnel: N, paths: 1
Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 tunnel: N, paths: 0
2WWVHMQX4DY90K3N9BFJXSZZ6F7E85VCJ66MYD1RG5BGMXBAY9FG tunnel: N, paths: 0
V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG tunnel: N, paths: 0
VQPDVF1QZ7QV6JQATFATYBSA3SAQQ0F6VM5VZK264S5EVXPB8ZX0 tunnel: N, paths: 0
KW7VNM3R256MCFBA5BJ644NXQC9NX58VRFBSQB15M76B4YTQR10G tunnel: N, paths: 0
7XF202E96N2THGAGXZ00M15GJGH7K4V1S29KHWV3031WM96PE16G tunnel: N, paths: 0

Best,
Martin



Re: Any peers running 0.20?

2023-12-17 Thread marty1885
Hi Kevin,

I am not sure about the NAT part. But I am running 0.20 on a public IP address. 
My node ID is CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG


Can you try adding `http://clehaxze.tw:9876/` to your hostlist provider? I've 
opened mine for others to use too.
Martin

> gnunet-core
Mon Dec 18 10:12:58 2023: connection established 5GYZ (timeout in  298 
s)
Mon Dec 18 10:12:58 2023: connection established 008Q (timeout in  299 
s)
Mon Dec 18 10:12:58 2023: connection established FGXY (timeout in  299 
s)
Mon Dec 18 10:12:58 2023: connection established 1YGN (timeout in  262 
s)
Mon Dec 18 10:12:58 2023: connection established 1T8F (timeout in  296 
s)
Mon Dec 18 10:12:58 2023: connection established DESN (timeout in  299 
s)
Mon Dec 18 10:12:58 2023: connection established 51V4 (timeout in  290 
s)
Mon Dec 18 10:12:58 2023: connection established DRD4 (timeout in  297 
s)
Mon Dec 18 10:12:58 2023: connection established SMS8 (timeout in  200 
s)

gnunet-cadet -P 
008Q3SKSXDAQDBMKZSJ4VHPVV2ZNG9PF783RA4132SD96PRJZ1Z0 tunnel: N, paths: 1
RJCSG4Z1AMS9PFTCQBX95CWRTR3BRD0FCRXQ90CCA1Y31KEQH47G tunnel: N, paths: 1
SMS8ADJPF83165FG78EEZ0EJCNCDDBQPQR5S5KN56NKG2W3BCDCG tunnel: N, paths: 1
1T8FY3QRXC4XJWWG8X7T2NYNVAM00CNVDTE4AQQEVB6PQ3ED8MC0 tunnel: N, paths: 1
1YGNJFY3VM6VQYY9M8K80ZZ9233TCBSZDQG93NSJM7J0T47D9VY0 tunnel: Y, paths: 2
JJ1N7W3C36XQT272JTXTD331H8196V09C37BM7Y433WXZ8ZA82DG tunnel: Y, paths: 0
AKN0F88HH4BQY1TB5Z2V6PRF3KWKFCCRZBJYVH0BD7P4S1D0NJF0 tunnel: N, paths: 2
V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG tunnel: N, paths: 0
KHHRWZ0MYZVPWR5NQGFV5T15GE0M01TP4WJ8ZKRENYA8TZE038A0 tunnel: Y, paths: 0
KW7VNM3R256MCFBA5BJ644NXQC9NX58VRFBSQB15M76B4YTQR10G tunnel: Y, paths: 0
CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG tunnel: N, paths: 0
WH8J95E3GVC9C54G0AV7EYY744TZ7NV4TXDGFWN5XCM770CN0HT0 tunnel: N, paths: 2
MHBHB5BH2V877T1W8CE9BNXTV3P4Q43H12J3Q7DQKP2S9QFJ301G tunnel: Y, paths: 0
CR0V1C1P529RDWKMSP64MGWPT5E8VZARYZH2J5B6W2YED66WWKK0 tunnel: N, paths: 0
51V4ZGBXA7E5WQF9WHW5KWNYYP7TRA10FWF1SPEVZRTC5G2K75N0 tunnel: N, paths: 1
DESNPFW7GF0NT3XZ9GJ5JPK18JF6DFZ9PD01QS31X8T93AN8X12G tunnel: N, paths: 1
5GYZVBTD5K0WCSVQGRHG18ZDBC3TT6905M34R9WKWQZHD906PDBG tunnel: N, paths: 4
NNQMC4284WYAKYKSK8WE4T4NJBC4SARXC1MR67DPRVAVNJJRYP6G tunnel: Y, paths: 0
DRD47JG4E9X1B67TXHV9M6V03RYD415FGCSA63X11F23NRRXDQFG tunnel: N, paths: 1
DSTJBRRKZ8TBW3FGK6B0M5QXWT9WYNZ45H5MCV4HY7ST64Q8T9F0 tunnel: N, paths: 0
Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 tunnel: N, paths: 0
7EQ9XKYTQSDZZ735A2XQ5YG7RBN4VNDBJ1EGX7QXVQDF2SGGENXG tunnel: N, paths: 1
FGXY5RP0YJBS4XSMG0ERWBE4YQPWQ712VSJ6PJ6FSVDQDDXE5NC0 tunnel: N, paths: 1
QRKT0506TTR7TG940NNYFPX5GCT83YZQAAYA81TE48XYG5WD34AG tunnel: Y, paths: 0

On Monday, December 18th, 2023 at 7:20 AM, Kevin Steen  
wrote:


> Greetings
> 
> Firstly, congratulations on getting the RFC published!
> 
> I've managed to get GNUnet v0.20 running by installing from the Debian
> Testing repository, but it doesn't seem to be connecting to any peers.
> Are there any compatible peers running, or is everyone running an
> incompatible version straight from source?
> 
> The hostlist URL used by this version ("http://v15.gnunet.org/hostlist";)
> refuses connections, but I found "https://gnunet.io/hostlist"; which
> seems to return some data after I added it to the config.
> 
> `gnunet-cadet -P` gives me:
> Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 tunnel: N, paths: 0
> V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG tunnel: N, paths: 0
> DSTJBRRKZ8TBW3FGK6B0M5QXWT9WYNZ45H5MCV4HY7ST64Q8T9F0 tunnel: N, paths: 0
> QTJ1MHPKXY1HTRJGBP1WDETBGFZ8QK27RDTNBMZ5JBV6TPY2YYWG tunnel: N, paths: 0
> 
> and `gnunet-core` returns nothing.
> 
> If someone could post the output of `gnunet-peerinfo -g` I would
> appreciate it.
> 
> I'm behind a CG-NAT setup, so outgoing connections only - will GNUnet be
> able to operate at all?
> 
> Thanks in advance
> -Kevin
> 
> --
> Following the easy path, strewn with treats, is how animals end up in cages.



Failing to resolve gnunet.org via GNS

2024-01-13 Thread marty1885
Hi,

I found that I can't resolve gnunet.org via GNS.The following command simply do 
not finish. I'm resolving gnunet.org in my unit test to make sure my GNS 
resolving works. Is the node hosting that domain down? Or something happened? 
Or it got upgraded to an incomparable version with the official 0.20?

```
❯ gnunet-gns -u gnunet.org

```

I am peer CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG. And I do see 
I'm connected to other nodes. I don't think network connection is the issue.

Martin



Re: Failing to resolve gnunet.org via GNS

2024-01-14 Thread marty1885
Hi,

I see the FCFS page has a new zone key now. I still got the gnunet.org and pin 
zone in my config. I believe this is from an old(?) configuration and the old 
pin zone is discontinued? Can you confirm?

```
❯ gnunet-config -s gns
.gnunet.org = 000G0047M3HN599H57MPXZK4VB59SWK4M9NRD68E1JQFY3RWAHDMKAPN30
.pin = 000G001MF6DVMZZ4Y8XRZQDXM1PB3D3VGEK29ZHXBA57EPSNW1QBPKT8J0
INTERCEPT_DNS = NO
MAX_PARALLEL_BACKGROUND_QUERIES = 1000
UNIX_MATCH_GID = YES
UNIX_MATCH_UID = NO
UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-gns.sock
BINARY = gnunet-service-gns
HOSTNAME = localhost
IMMEDIATE_START = YES
START_ON_DEMAND = YES
```

Best,
Martin

On Sunday, January 14th, 2024 at 3:54 PM, Schanzenbach, Martin 
 wrote:


> Hi,
> 
> "gnunet.org" is not configured by default through any start zone
> https://www.rfc-editor.org/rfc/rfc9498.html#name-start-zones
> 
> You can look at all suffix-to-zone mappings on your system using
> 
> $ gnunet-config -s gns
> 
> What is configured is our current registrar, as "gnunet.gns.alt".
> Basically, zones registered at https://fcfs.gnunet.org are reachable
> with that suffix.
> You can try registering your own zone and try it.
> You can also try resolving names of other user's zones (if you know any).
> 
> We currently do not publish the gnunet.org IP addresses in GNS I think.
> The unit tests locally configures gnunet.org.
> 
> I hope that helps.
> 
> BR
> Martin
> 
> 
> On 14.01.24 08:35, marty1885 wrote:
> 
> > Hi,
> > 
> > I found that I can't resolve gnunet.org via GNS.The following command 
> > simply do not finish. I'm resolving gnunet.org in my unit test to make sure 
> > my GNS resolving works. Is the node hosting that domain down? Or something 
> > happened? Or it got upgraded to an incomparable version with the official 
> > 0.20?
> > 
> > `❯ gnunet-gns -u gnunet.org `
> > 
> > I am peer CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG. And I do 
> > see I'm connected to other nodes. I don't think network connection is the 
> > issue.
> > 
> > Martin



Cannot bootstrap GNUnet 0.21.0

2024-03-09 Thread marty1885
Hi all,

I've just built and installed the new GNUnet 0.21. But my node isn't connected 
to any peer after hours of waiting. Running gnunet-core shows no node is 
connected to me.

```
❯ gnunet-core
(no output)
```

I have also checked `iotop` and can confirm gnunet-service-transport isn't 
doing much IO. While I was expecting at least hundreds of Kbps from experience 
in the past.

How can I connect to the network? Please let me know what information I can 
provide to diagnose the issue.

Best,
Martin





Re: Cannot bootstrap GNUnet 0.21.0

2024-03-09 Thread marty1885
Thanks for the reply.

I tried a few commands and still feels like my node is really not connected. 
DHT can't put, NSE returns a very small network size and GNS cannot resolve.

Is this expected?

```
❯ gnunet-core -si
Current local peer identity: 
CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG
(no further output)

❯ gnunet-dht-put -k "hello" -d "world" -e 40m
(hangs, this used to return almost immidately)

❯ gnunet-nse
1710047156276913 1.688203 0.755488 1.474102

❯ gnunet-gns -u gnunet.gns.alt -t PKEY
>>> Looking for `PKEY' records under `gnunet.gns.alt'
(no output)
```

On Saturday, March 9th, 2024 at 11:39 PM, Schanzenbach, Martin 
 wrote:

> Hi,
> 
> the behaviour of gnunet-core changed. You can check the new switches
> with --help.
> Long-term core connections are know to be problematic behind NATs, still.
> But with a freshly started peer, "gnunet-core -i" should give you your
> peer id, "gnunet-core -s" the connections (you can also combine the
> switches).
> The command should probably output the help when called without arguments.
> 
> BR
> Martin
> 
> On 09.03.24 14:55, marty1885 wrote:
> 
> > Hi all,
> > 
> > I've just built and installed the new GNUnet 0.21. But my node isn't 
> > connected to any peer after hours of waiting. Running gnunet-core shows no 
> > node is connected to me.
> > 
> > `❯ gnunet-core (no output)`
> > 
> > I have also checked `iotop` and can confirm gnunet-service-transport isn't 
> > doing much IO. While I was expecting at least hundreds of Kbps from 
> > experience in the past.
> > 
> > How can I connect to the network? Please let me know what information I can 
> > provide to diagnose the issue.
> > 
> > Best,
> > Martin



Re: Cannot bootstrap GNUnet 0.21.0

2024-03-10 Thread marty1885
I deleted the databases for namestore and peerstore to get all processes 
running (peerstore and namestore was failing). But still no peer connections.

```
❯ gnunet-arm -I
Services (excluding stopped services):
(started: 23 / stopped: 22)
cadet (binary='gnunet-service-cadet', status=started)
core (binary='gnunet-service-core', status=started)
datastore (binary='gnunet-service-datastore', status=started)
dht (binary='gnunet-service-dht', status=started)
fs (binary='gnunet-service-fs', status=started)
gns (binary='gnunet-service-gns', status=started)
hostlist (binary='gnunet-daemon-hostlist', status=started)
identity (binary='gnunet-service-identity', status=started)
namecache (binary='gnunet-service-namecache', status=started)
namestore (binary='gnunet-service-namestore', status=started)
nat (binary='gnunet-service-nat', status=started)
nse (binary='gnunet-service-nse', status=started)
peerstore (binary='gnunet-service-peerstore', status=started)
reclaim (binary='gnunet-service-reclaim', status=started)
rest (binary='gnunet-rest-server', status=started)
revocation (binary='gnunet-service-revocation', status=started)
rps (binary='gnunet-service-rps', status=started)
setu (binary='gnunet-service-setu', status=started)
statistics (binary='gnunet-service-statistics', status=started)
topology (binary='gnunet-daemon-topology', status=started)
transport (binary='gnunet-service-transport', status=started)
communicator-tcp (binary='gnunet-communicator-tcp', status=started)
zonemaster (binary='gnunet-service-zonemaster', status=started)
```

On Sunday, March 10th, 2024 at 3:00 PM, Schanzenbach, Martin 
 wrote:

> Hi,
> 
> what does gnunet-arm -I output? Are all of the services running?
> For example, the peerstore database layout changed, so you probably have
> to delete your old database ($HOME/.local/share/gnunet/peerstore/sqlite.db).
> 
> The road to a stable TNG will also be bumpy, so we rely on reports such
> as this to iron out the remaining bugs with it.
> 
> BR
> Martin
> 
> On 10.03.24 06:08, marty1885 wrote:
> 
> > Thanks for the reply.
> > 
> > I tried a few commands and still feels like my node is really not 
> > connected. DHT can't put, NSE returns a very small network size and GNS 
> > cannot resolve.
> > 
> > Is this expected?
> > 
> > ```
> > ❯ gnunet-core -si
> > Current local peer identity: 
> > CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG
> > (no further output)
> > 
> > ❯ gnunet-dht-put -k "hello" -d "world" -e 40m
> > (hangs, this used to return almost immidately)
> > 
> > ❯ gnunet-nse
> > 1710047156276913 1.688203 0.755488 1.474102
> > 
> > ❯ gnunet-gns -u gnunet.gns.alt -t PKEY
> > 
> > > > > Looking for `PKEY' records under` gnunet.gns.alt'
> > > > > (no output)
> > > > > ```
> > 
> > On Saturday, March 9th, 2024 at 11:39 PM, Schanzenbach, Martin 
> > schan...@gnunet.org wrote:
> > 
> > > Hi,
> > > 
> > > the behaviour of gnunet-core changed. You can check the new switches
> > > with --help.
> > > Long-term core connections are know to be problematic behind NATs, still.
> > > But with a freshly started peer, "gnunet-core -i" should give you your
> > > peer id, "gnunet-core -s" the connections (you can also combine the
> > > switches).
> > > The command should probably output the help when called without arguments.
> > > 
> > > BR
> > > Martin
> > > 
> > > On 09.03.24 14:55, marty1885 wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > I've just built and installed the new GNUnet 0.21. But my node isn't 
> > > > connected to any peer after hours of waiting. Running gnunet-core shows 
> > > > no node is connected to me.
> > > > 
> > > > `❯ gnunet-core (no output)`
> > > > 
> > > > I have also checked `iotop` and can confirm gnunet-service-transport 
> > > > isn't doing much IO. While I was expecting at least hundreds of Kbps 
> > > > from experience in the past.
> > > > 
> > > > How can I connect to the network? Please let me know what information I 
> > > > can provide to diagnose the issue.
> > > > 
> > > > Best,
> > > > Martin



Re: Cannot bootstrap GNUnet 0.21.0

2024-03-13 Thread marty1885
Hi,

Yes. I've restarted GNUnet several times. For safety I've restarted it once 
again after reeving your reply. Still can't bootstrap.

Martin

On Tuesday, March 12th, 2024 at 10:15 PM, Schanzenbach, Martin 
 wrote:

> Hi,
> 
> did you try again the last few days?
> We are currently observing better connectivity after fixing a
> configuration mistake on the bootstrap peer.
> 
> Best
> Martin
> 
> On 10.03.24 15:41, marty1885 wrote:
> 
> > I deleted the databases for namestore and peerstore to get all processes 
> > running (peerstore and namestore was failing). But still no peer 
> > connections.
> > 
> > `❯ gnunet-arm -I Services (excluding stopped services): (started: 23 / 
> > stopped: 22) cadet (binary='gnunet-service-cadet', status=started) core 
> > (binary='gnunet-service-core', status=started) datastore 
> > (binary='gnunet-service-datastore', status=started) dht 
> > (binary='gnunet-service-dht', status=started) fs 
> > (binary='gnunet-service-fs', status=started) gns 
> > (binary='gnunet-service-gns', status=started) hostlist 
> > (binary='gnunet-daemon-hostlist', status=started) identity 
> > (binary='gnunet-service-identity', status=started) namecache 
> > (binary='gnunet-service-namecache', status=started) namestore 
> > (binary='gnunet-service-namestore', status=started) nat 
> > (binary='gnunet-service-nat', status=started) nse 
> > (binary='gnunet-service-nse', status=started) peerstore 
> > (binary='gnunet-service-peerstore', status=started) reclaim 
> > (binary='gnunet-service-reclaim', status=started) rest 
> > (binary='gnunet-rest-server', status=started) revocation 
> > (binary='gnunet-service-revocation', status=started) rps 
> > (binary='gnunet-service-rps', status=started) setu 
> > (binary='gnunet-service-setu', status=started) statistics 
> > (binary='gnunet-service-statistics', status=started) topology 
> > (binary='gnunet-daemon-topology', status=started) transport 
> > (binary='gnunet-service-transport', status=started) communicator-tcp 
> > (binary='gnunet-communicator-tcp', status=started) zonemaster 
> > (binary='gnunet-service-zonemaster', status=started)`
> > 
> > On Sunday, March 10th, 2024 at 3:00 PM, Schanzenbach, Martin 
> > schan...@gnunet.org wrote:
> > 
> > > Hi,
> > > 
> > > what does gnunet-arm -I output? Are all of the services running?
> > > For example, the peerstore database layout changed, so you probably have
> > > to delete your old database 
> > > ($HOME/.local/share/gnunet/peerstore/sqlite.db).
> > > 
> > > The road to a stable TNG will also be bumpy, so we rely on reports such
> > > as this to iron out the remaining bugs with it.
> > > 
> > > BR
> > > Martin
> > > 
> > > On 10.03.24 06:08, marty1885 wrote:
> > > 
> > > > Thanks for the reply.
> > > > 
> > > > I tried a few commands and still feels like my node is really not 
> > > > connected. DHT can't put, NSE returns a very small network size and GNS 
> > > > cannot resolve.
> > > > 
> > > > Is this expected?
> > > > 
> > > > ```
> > > > ❯ gnunet-core -si
> > > > Current local peer identity: 
> > > > CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG
> > > > (no further output)
> > > > 
> > > > ❯ gnunet-dht-put -k "hello" -d "world" -e 40m
> > > > (hangs, this used to return almost immidately)
> > > > 
> > > > ❯ gnunet-nse
> > > > 1710047156276913 1.688203 0.755488 1.474102
> > > > 
> > > > ❯ gnunet-gns -u gnunet.gns.alt -t PKEY
> > > > 
> > > > > > > Looking for `PKEY' records under` gnunet.gns.alt'
> > > > > > > (no output)
> > > > > > > ```
> > > > 
> > > > On Saturday, March 9th, 2024 at 11:39 PM, Schanzenbach, Martin 
> > > > schan...@gnunet.org wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > the behaviour of gnunet-core changed. You can check the new switches
> > > > > with --help.
> > > > > Long-term core connections are know to be problematic behind NATs, 
> > > > > still.
> > > > > But with a freshly started peer, "gnunet-core -i" should give you your
> > > > > peer id, "gnunet-core -s" the connections (you can also combine the
> > > > > switches).
> > > > > The command should probably output the help when called without 
> > > > > arguments.
> > > > > 
> > > > > BR
> > > > > Martin
> > > > > 
> > > > > On 09.03.24 14:55, marty1885 wrote:
> > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > I've just built and installed the new GNUnet 0.21. But my node 
> > > > > > isn't connected to any peer after hours of waiting. Running 
> > > > > > gnunet-core shows no node is connected to me.
> > > > > > 
> > > > > > `❯ gnunet-core (no output)`
> > > > > > 
> > > > > > I have also checked `iotop` and can confirm 
> > > > > > gnunet-service-transport isn't doing much IO. While I was expecting 
> > > > > > at least hundreds of Kbps from experience in the past.
> > > > > > 
> > > > > > How can I connect to the network? Please let me know what 
> > > > > > information I can provide to diagnose the issue.
> > > > > > 
> > > > > > Best,
> > > > > > Martin



Failing to build GNUnet 0.22.0 on Arch Linux with incorrect detection of libgcrypt version

2024-09-02 Thread marty1885
Hi,

Congrats for releasing 0.22.0. I tried to build the code on my Arch Linux 
server and ran into the following error during configuration. GNUnet is unhappy 
that my libgcrypt is too old and wants at least version 1.6.0.

checking for struct tm.tm_gmtoff... yes
checking for getaddrinfo_a in -lanl... yes
checking for libgcrypt-config... no
checking for LIBGCRYPT - version >= 1.6.0... no
checking for gcc options needed to detect all undeclared functions... none 
needed
checking whether gcry_mpi_set_opaque_copy is declared... yes
configure: error: You need libgcrypt to build this program.
At least version 1.6.0 (API 1) is required.

However, pacman says I have version 1.11.0-2.

pacman -Qi libgcrypt | head -n 2
Name: libgcrypt
Version : 1.11.0-2

Is there anything I can do to solve this problem? Hope my system info helps 
resolving this issue.

OS: Arch Linux ARM
Compile: GCC 14.1
GNUnet: 0.22.0
libgcrypt: 1.11.0
autotools: 2.72


BR,
Martin



Re: Failing to build GNUnet 0.22.0 on Arch Linux with incorrect detection of libgcrypt version

2024-09-02 Thread marty1885
Hi,

Sorry nevermind. I checked out the wrong tag. My apologies for the 
inconvenience.

BR,
Martin




Sent with Proton Mail secure email.

On Monday, September 2nd, 2024 at 10:34 PM, Christian Grothoff 
 wrote:

> Please provide (a gzipped/compressed) attachment with your config.log,
> that has key diagnostics for us. Thanks! -Christian
> 
> On 9/2/24 4:31 PM, marty1885 wrote:
> 
> > Hi,
> > 
> > Congrats for releasing 0.22.0. I tried to build the code on my Arch Linux 
> > server and ran into the following error during configuration. GNUnet is 
> > unhappy that my libgcrypt is too old and wants at least version 1.6.0.
> > 
> > checking for struct tm.tm_gmtoff... yes
> > checking for getaddrinfo_a in -lanl... yes
> > checking for libgcrypt-config... no
> > checking for LIBGCRYPT - version >= 1.6.0... no
> > checking for gcc options needed to detect all undeclared functions... none 
> > needed
> > checking whether gcry_mpi_set_opaque_copy is declared... yes
> > configure: error: You need libgcrypt to build this program.
> > At least version 1.6.0 (API 1) is required.
> > 
> > However, pacman says I have version 1.11.0-2.
> > 
> > pacman -Qi libgcrypt | head -n 2
> > Name : libgcrypt
> > Version : 1.11.0-2
> > 
> > Is there anything I can do to solve this problem? Hope my system info helps 
> > resolving this issue.
> > 
> > OS: Arch Linux ARM
> > Compile: GCC 14.1
> > GNUnet: 0.22.0
> > libgcrypt: 1.11.0
> > autotools: 2.72
> > 
> > BR,
> > Martin