Hello,
(for some reason I didn't receive Christian's e-mail, so I'm replying
here for both.)
I'm not using the GNUnet configuration as my own, I always initialized
the application using GNUNET_OS_init with application-specific values.
The test.c file I attached to my first e-mail does do that t
Hello,
GNUnet 0.23 changed the way GNUNET_OS_ProjectData is used, moving it
from being global state to a function parameter in commit
9ab62c62c3d508033d31ea5289013255ec7a0c87.
The same commit also removes the GNUNET_CONFIGURATION_default function
to return a new configuration object with GNU
Before replying on your points, a correction: the line saying "The main
reason is that it's so long to be basically unreadable." wasn't related
only to the program's description, but to the whole output, sorry for
the confusion.
As for the rest:
> Man pages are not always installed by people, and
madmurphy writes:
> I have pushed the new gnunet-search with printf-like capabilities to
> the git repository. I have also updated the man page. Feel free to
> play with it and write your feedbacks :)
I think the help text when using `--help' is too long.
That's not really the place to write the
but
I wanted to push these changes fast as I'm being a bit busy these days
and doing it like this means people can still get gnunet-bcd even with a
buggy macro.
Adding the package checks to AM_CONDITIONAL is trivial, so if people can
test it out in the meantime, I can then finalize it for go
"Schanzenbach, Martin" writes:
> 1. The uncrustify detection is now verbose. configure outputs the
> output of "uncrustify". Can we prevent that? It looks like an error.
You are right, there was an error in the check. I'm not sure what
happened, but AC_CHECK_PROG became AC_CHECK_PROGS (with the
Christian Grothoff writes:
> I'm a bit confused by this, I don't recall making this change or
> discussing something like this with anyone. What I do recall is that we
> added the cipher type sometime in the past. However, prefixing by a
> readable representation of the string length!?!? Why woul
Hello,
these past few weeks I've been working on a few things summarized by the
subject of this mail.
Initially I simply wanted to replace a vector image, but I ended up
changing a lot more stuff, including doing some major work on the
configure.ac file.
It all started when I thought I'd try bri
Christian Grothoff writes:
> Why don't you just run a few VMs on your local machine? It's not like a
> GNUnet peer requires tons of resources, so a typical system should
> easily be able to run several VMs with a GNUnet peer in each. If you
> then disable external network connectivity, you're pre
Hello,
as per the subject, I'm looking for a way to set up a small independent
network of peers to test an application.
What I'm looking for is primarily for this network to exist
independently from the normal global GNUnet network that peers connect
to when using the default configuration.
I do
Christian Grothoff writes:
> With that change, the logic gnunet-config shared with taler-config and
> anastasis-config is now properly moved into libgnunetconfig, so we can
> avoid the PRELOAD hack in the future.
>
> For how to do GNUnet-only extensions of the existing gnunet-config tool,
> pleas
Christian Grothoff writes:
> GNUnet should run on embedded-ish systems, and binary size does
> matter. The idea behind the configure flag is that by default, DEBUG
> messages are never included, and only developers can (and likely will)
> explicitly enable them to aid their diagnosis.
I see, tha
Hello,
I was recently puzzled by a behaviour which apparently has been going on
for a while, but I noticed it only now.
It seems that `GNUNET_log' (and `GNUNET_log_from') is unable to print
messages when the error level is GNUNET_ERROR_TYPE_DEBUG under certain
circumstances.
Consider this small
Christian Grothoff writes:
> Good point, but that's a specific issue with that macro, which I agree
> should not use "_" but dgettext(). I've fixed this (and a few related)
> instance(s) in Git master just now.
Hello,
thanks for the fix.
Related to this issue: since those macros explicitly use
Hello,
there is a problem regarding the usage of gettext in header files,
specifically in `gnunet_common.h'.
In that file, a number of macros expand to a call to `GNUNET_log' with
its template string wrapped inside a call to `_', which is the common
gettext alias.
Within GNUnet itself this doesn
Hello,
apologies for the late reply...
Christian Grothoff writes:
> I suggest youy pass all of the information (also possibly via #define's)
> into the GNUNET_OS_ProjectData and grab it from there! That way, Taler
> can override it without having to change gnunet-config itself.
I'm not really
Hello,
Christian Grothoff writes:
> GNU Taler has taler-config, which recycles gnunet-config in a funky way
> using LD_PRELOAD:
>
> https://git.taler.net/exchange.git/tree/src/util/taler-config.in
>
> This works, because there is:
> https://git.taler.net/exchange.git/tree/src/util/os_installatio
Hello,
"Schanzenbach, Martin" writes:
> But what the OP in the report also and possibly primarily thinks is missing
> is a way to get the build information
> which is output on configure at the end which is useful for users to
> understand what kind of build configuration their gnunet installa
Hello,
I made an attempt at implementing what was discussed in bug #5708 [0],
that is, additional flags for `gnunet-config' to print various
informations similar to what other `*-config' tools do
(e.g. `nss-config'.)
After sending this mail I'm going to push a branch called
'dev/vanni/build-info'
Christian Grothoff writes:
> Hi Alessio,
>
> You should store a copy of the 'cls' together with your channel handle.
> Typically, the 'cls' would actually point to the struct in which you
> store your channel handle. So if you do this in any reasonable way, you
> should not need an API to lookup
Hello,
there might be a better way to do what I'm trying to do, but I couldn't
really think of it, so here it is:
I'm opening CADET channels on demand and then stashing them away until
they are needed again (or closed.) Because those channels require some
"state" when something is received throug
"Schanzenbach, Martin" writes:
> Can be merged from my point of view.
Hello,
I merged the branch with master and pushed it.
Hopefully nothing wrong happened.
Thanks,
A.V.
Alessio Vanni writes:
> Huh, that's strange. Admittedly, I didn't properly test successful
> insertions, but I didn't get any crash on errors.
> I'll check it out.
I pushed a fix for this.
It was indeed because I had forgotten to put terminating NULL values in
t
"Schanzenbach, Martin" writes:
> Adding them seems to work but the service then
> crashes in all cases (error, success) at gnunet-namestore-fcfsd.c:326.
Huh, that's strange. Admittedly, I didn't properly test successful
insertions, but I didn't get any crash on errors.
I'll check it out.
> Oh a
Hello,
I was looking at the list of bugs on Mantis and through [1] I discovered
the FCFS daemon (the namestore is not a component I've checked in
details.)
I think it's a useful tool, so I tried improving it.
I pushed a branch called "/dev/vanni/fcfsd" and the (currently only)
commit adding the
7f7ead2386ba10987f1bccabcb75c2419612bcba Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Thu, 22 Apr 2021 18:06:13 +0200
Subject: [PATCH 1/2] Swap gnunet-config's default behaviour for the rewrite
flag
With the previous default, a configuration file could keep values different
from t
Hello,
I was investigating something in the codebase and found two things I'd
like to ask clarifications for. They are small and there is no need to
send two different mails, hence the subject of this mail.
1. I was looking at common_logging.c and found this:
static enum GNUNET_ErrorType
get_typ
A.V.
[0] https://lists.gnu.org/archive/html/gnunet-developers/2020-12/msg8.html
>From d46844972f2baa061ef7aa333eb11a8755f22898 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Sun, 4 Apr 2021 16:51:09 +0200
Subject: [PATCH] Implement function to load plugins within a specific context
Wh
Christian Grothoff writes:
> Hi Alessio,
>
> The idea is good, but I dislike two details:
>
> 1) GNUNET_PLUGIN_load_all_default should be a function, not a macro;
It's a macro because the original `load_all' is declared with a void
return value, so instead of calling two functions (`load_all_def
Christian Grothoff writes:
> That's intentional. Same as with 'exec'. First argument is the file
> name/path to the binary, and argv[0] is separate. See 'exec'. In
> general, simply pass the binary name twice.
>
> -Christian
Thank you for the explanation.
Since the documentation simply says "st
Hello,
I noticed a curious situation, best explained by this example:
Let's say I have a program (let's call it 'gnunet-exec') that starts a
process using `GNUNET_OS_start_process', with the program file name
taken from the command line and using the two strings "hello" and
"world" as arguments t
[0] https://lists.gnu.org/archive/html/gnunet-developers/2020-07/msg00049.html
>From b1255303796c1fbe971b08251e05ab4c28349b28 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Sun, 13 Dec 2020 15:20:38 +0100
Subject: [PATCH] Add macro to load plugins within GNUnet's context
When `GNUNET_OS_i
Martin Schanzenbach writes:
> The gist of the flow is also here:
> https://docs.gnunet.org/handbook/gnunet.html#reclaimID-Identity-Provider
Thank you, completely forgot about the handbook!
> Basically:
> 1. A relying party requests a set of attributes from the user
> 2. The user decides if he w
Hello,
for a number of reasons I'm looking into ways to authenticate a user
with a custom service (i.e. not something already existing), so I
started checking out re:claimID as it seems to be the solution.
I have two questions about it:
1. is there some other documentation aside from what is on
Martin Schanzenbach writes:
> tl;dr:
> - Should we move towards a monolithic gnunet.git repo which includes
> gtk/secushare again?
> - Should we instead move optional components (conversation, reclaim,
> messenger) out of gnunet.git as extensions?
Hello,
I want to express my opinion on the matt
.V.
>From 098b884da641e141f1972649ff155cf6bc306e03 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Mon, 26 Oct 2020 01:26:27 +0100
Subject: [PATCH] - fix '-c' in applications without base config
---
src/util/configuration_loader.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
Christian Grothoff writes:
> I don't see how the anonymity level of FS can possibly be
> abstracted/used in other services. The anonymity level tries to capture
> the available cover traffic, and only traffic that is basically
> "indistinguishable" in terms of the origin should count. As (for
> e
Hello,
I have a simple question: can the whole "anonimity level" mechanism used
by FS be "abstracted" so that other unrelated applications can use it,
or is it deeply connected with FS's architecture?
I can think of a few applications that might want to use it instead of
using e.g. CADET as-is, s
en without installing an empty configuration file in
`GNUNET_OS_IPK_DATADIR'.
Thanks,
A.V.
>From 67adc95a802f0c88ba048af75b96a082cd90c129 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Sat, 10 Oct 2020 17:19:53 +0200
Subject: [PATCH] Allow applications to change ProjectData
new code. In the meantime, it will avoid a lot of noise
and disk activity.
Thanks,
A.V.
>From 86819deb0a6c2e680bdc33f273a865e62ec807be Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Thu, 24 Sep 2020 22:04:17 +0200
Subject: [PATCH] Disable some diagnostic until TNG is available
---
configu
gument.
Attached is a patch to fix it.
Sorry and thanks again,
A.V.
>From 535193f2c01c21e21e7d2459d815d07ce039acab Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Wed, 15 Jul 2020 20:58:51 +0200
Subject: [PATCH] - Use correct argument in GNUNET_OS_init call
---
src/gnsrecord/gnsrecord
ers/2020-07/msg9.html
>From 998126274cca69b87dd58d04d7b62514d121e496 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Wed, 15 Jul 2020 17:21:39 +0200
Subject: [PATCH] Load GNSRECORD plugins within GNUnet's context
When applications set a new project data structure using `GNUNET_OS_init&#
_OS_init' (or at any other point in time, really.)
Please review it so I can fix anything if needed.
Thanks,
A.V.
>From 2a30dca1819c4a7fd03a4d820d16968ca296efdf Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Fri, 3 Jul 2020 22:37:42 +0200
Subject: [PATCH] Add function to return GN
ts (if the patch is
accepted) to GNUnet...
>From a3bffbe0e38fd336ad2230185c79e9e0466e4a11 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Wed, 27 May 2020 15:01:30 +0200
Subject: [PATCH] Make REQUEST_AGPL messages configurable and add handler by
default
This makes two changes:
*
Christian Grothoff writes:
> If you are linking against GNUnet libraries, you fall under the AGPL.
> It does not matter whether you are in our repository.
That was the missing link. From what I gathered the license is like the
normal GPL so my application will have to be licensed as AGPL too.
Christian Grothoff writes:
> Actually, no. Type 6 implements our *Affero* GPL mechanism to provide
> anyone who accesses *any* GNUnet service with the means to download the
> source code. GNUnet is released under the AGPL, which specifically
> states that such a mechanism to obtain the source mus
Christian Grothoff writes:
> Hi Alessio,
>
> I'm pretty sure that we don't actually ever send the REQUEST_AGPL
> messages to services. So if you got one, that suggests that either your
> transmission was somehow wrong (i.e. wrong length, maybe
> big-endian/little-endian issue?) or you have some m
Hello,
I wrote a small service which is meant to be part of a bigger project.
While I was checking stdout to see if everything worked correctly, I was
notified that there was no handle for a message of type 6 and size 4
(and subsequently that the handle in the service didn't call
`GNUNET_SERVICE_c
Christian Grothoff writes:
> This looks indeed perfect to me, modulo possibly one issue that is
> totally unrelated to the design and more like a legacy bug you're copying:
> https://en.wikipedia.org/wiki/Endianness#Floating_point
> implies that we should actually also do network byte order conve
nything. That was what prompted me to
check the web archive. Anyway, I received my second mail (the one you
replied to) so everything seems to be fixed, whatever the problem was.
Thanks,
A.V.
>From 8ac66216adada0dd45c3a29caaf7a4e63bb2d626 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Thu, 14 Ma
(For some reason, I'm not receiving all the mails from this list. Some
are arriving, some not. Not sure what is going on, if there's an issue
in a configuration somewhere or simply a network problem; still, I had
to reply like this because I didn't receive anything and noticed the
reply only beca
y objective evaluation :)
Thanks,
A.V.
---
[1] https://lists.gnu.org/archive/html/gnunet-developers/2020-04/msg00015.html
>From 0cf140eae8a36699ef5cb917e1c60f1b3b020c0f Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Sat, 9 May 2020 14:20:48 +0200
Subject: [PATCH] New BIO API
---
src/include
Florian Dold writes:
> We already have something exactly like that:
>
> https://git.gnunet.org/gnunet.git/tree/src/include/gnunet_buffer_lib.h
Oh... didn't notice it. Sorry.
> Maybe it makes more sense to add new functionality to the buffer lib?
> I.e., teach the buffer lib to read from / write
Christian Grothoff writes:
> However, there are two issues. First, your patch introduces a new type
> 'struct GNUNET_BIO_MemoryHandle'. I think to avoid having to duplicate
> all of the individual BIO-read/write functions
Yes, I made a new struct to avoid touching already-existing code.
Mostly,
rts.
Thanks,
A.V.
>From c1951bac149e49ccf12d57ae59c891c2cee92424 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Sat, 18 Apr 2020 16:20:27 +0200
Subject: [PATCH] Add formatted I/O to buffers allocated in memory
---
src/include/gnunet_bio_lib.h | 219 ++
src/ut
Hello,
I'm trying to add a GNS URI through 'gnunet-qr', but even though the
record is successfully added, the program reports that it failed to add
it. The URI is generated by 'gnunet-bcd'.
Actually, as I can't scan QR codes through the webcam, I hacked
'gnunet-qr' to parse PNG files. I tested th
Christian Grothoff writes:
> Hi Martin,
>
> Why do you say that PKEY expiration values should have to be 'forever'?
> PKEY records have expiration times like any other record and they don't
> have to be eternal.
>
> Now, I can see that the main use case (import via URL) may have a
> difficulty of
the
problem.
Thank you,
A.V.
>From 6f9ff18588ac64bad4963e0036a987fe1d041f1e Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Fri, 20 Mar 2020 15:35:54 +0100
Subject: [PATCH] Make gnunet-namestore honour expiration dates when importing
an URI
---
src/namestore/gnunet-namestore.c | 17 ++
Christian Grothoff writes:
> Could it be that you added it twice? PKEY records are mutually
> exclusive, so if one exist, trying to create another one would cause
> this type of error.
I made sure to delete the record first and it still happen. However,
also see below.
> Actually, a bug in the
Christian Grothoff writes:
> Hi Alessio,
>
> I've now fixed and tested gnunet-qr, so it should work now.
>
> Thanks for reporting!
>
> -Christian
Yes, I pulled the fixes from the repository and tested it.
The GNS URI is correctly passed to gnunet-namestore which then adds the
PKEY record; howev
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 writes:
> OMG. That shouldn't even look like that. We have a special function
Hello,
Due to the fact that I don't have a device that can work with gnunet-qr,
I decided to hack it in an attempt to add support for PNG files. The
attempt was mostly successful, but I met some issues that made the
program generate errors.
The first error isn't particularily serious, but I thou
Alessio Vanni writes:
> I made sure to use a new envelope each time. In fact, the real
> implementation is a dedicated function that does some basic checking
> (e.g. make sure the pointer to the data is not NULL) before sending the
> message. I tried calling it both inside a nor
Christian Grothoff writes:
> Yes, in the worst-case they are buffered in the _client_ processes'
> memory. You can check the MQ API (length, send callback) for ways to
> find out if your messages are piling up (or at least have left your
> process), so you DO have a way to do proper flow control.
Christian Grothoff writes:
> Segmenting is the right answer. As for 'fast enough', there is usually
> no requirement on how fast you call those APIs. However, for a CADET
> channel, the receiver must call "GNUNET_CADET_receive_done" after each
> message. Until you call that function, you won't ge
Christian Grothoff writes:
> If you get the "GNUNET_CLIENT_test()" symbol undefined, then somehow
> you're not linking against the 'right' (latest) libgnunetutil. Maybe you
> have two installations on your system, and the linker finds the wrong
> one? Please make sure you only have one libgnunetu
xrs writes:
> Seems to work. Thank you!
It's the opposite for me, instead.
If I run "gnunet-arm -s" the program hangs even though the services are
running. On the other hand, "gnunet-arm -e" says the
`GNUNET_CLIENT_test' symbol is undefined. The hang happens for any flag
that is not "-e".
I
Christian Grothoff writes:
> Right now, my best idea is to modify GNUNET_PROGRAM_run() to detect "is
> ARM running" by asking it which services are running, and if we fail to
> detect the ARM listen socket, we give up hard. Furthermore, we could
> pass information to GNUNET_PROGRAM_run() which s
on Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Sun, 8 Sep 2019 16:29:11 +0200
Subject: [PATCH] Add initialization to service
---
src/ext/gnunet-service-ext.c | 32
1 file changed, 32 insertions(+)
diff --git a/src/ext/gnunet-service-ext.c b/src/ext/gnunet-serv
Christian Grothoff writes:
> but in this case there seems to be a better alternative: use
> a C constructor to call GNUNET_OS_init():
>
> /**
> * Initialize i18n
> */
> void __attribute__ ((constructor)) i18n_init () {
> GNUNET_OS_init (...);
> }
>
> Constructors run before main(), so that sh
In the meantime, the attached patch adds localization to services.
Until now, even if the locale is changed, any message printed by a
service would not be translated regardless of what the relevat PO file
contains.
Thanks,
A.V.
>From 85bd2ed1c06816cc851cb51263c44615f5e40347 Mon Sep 17 00:00
;m still not subscribed to the list... yet.
>From ab468fc8110316f3ec8c4651a95b058b82812e86 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Sat, 31 Aug 2019 00:23:19 +0200
Subject: [PATCH] Improve how gettext is used
---
src/include/gnunet_os_lib.h | 12
src/include/plat
le? I'm not sure if the ProjectData
struct should be initialized for gnunet-ext-service too, though.
A.V.
>From e0b0bd62037f4d40eb370e4dcfd96d70503508e7 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Thu, 8 Aug 2019 16:27:28 +0200
Subject: [PATCH] Print help on GNU software only wh
unet-developers/2019-08/msg5.html
[2] https://gitlab.com/gnunet/gnunet/merge_requests/1
>From 39c08b8b1c3d4a7402c0174cc6e3b077f5316a02 Mon Sep 17 00:00:00 2001
From: Alessio Vanni
Date: Tue, 6 Aug 2019 19:36:01 +0200
Subject: [PATCH] Add version string to GNUNET_OS_ProjectData
---
src
> You are not doing something wrong. There is no callback called, after
> you call GNUNET_CADET_close_port. Can you please point me to the
> outdated documentation.
The GNUnet handbook on gnunet.org has a section on libcadet, but it
explains it by using an API that is different than the current on
> I don't know which documentation sentence in what manual you are
> referencing here, but I think that documentation is simply wrong. CADET
> is port-scan resistant, in that the peer will simply not send anything
> back if the port is not open. In fact, CADET will accept your incoming
> request in
Christian Grothoff writes:
> That said, if you're truly not part of GNUnet, you might want your
> service to be launched using the usual OS-specific way for launching
> services (i.e. systemd, upstart, sys5init, whatever) instead of using
> GNUnet ARM (and then just tell your OS-specific launcher
Christian Grothoff writes:
> Have a look at the attached os_installation.c from GNU Taler. It shows
> you how to initialize libgnunetutil to customize the --help output (at
> least some of it). It also demonstrates how we could easily enable
> further customizations in the future, if necessary.
Hi Martin,
> 0. Is there a reason you include the new header into every single C file?
> There does not seem to be
> a need for that in most cases.
It was mostly future-proofing. While I was making changes I wasn't sure
if I were going to put some other things in there, so just in case I
added
Hi Martin,
> Are you building your app in a separate source tree (gnunet-ext) or inside
> gnunet?
> If it is the latter, then this is the expected behaviour.
> If it is the former, then this might also be an issue that could be addressed
> in gnunet-ext => bugreport.
At first I used gnunet-ext,
Hello everyone.
I've been following the project for a while and, besides keeping the
peer active when possible, I've also tried developing some simple
clients/services. In this mail I want to report a couple of things I
think are a problem and ask some questions to some things I couldn't
fully gr
81 matches
Mail list logo
