On 12/12/19 10:29 AM, bo0od wrote:
Debian 10 build warnings:
i tried to build GNUnet on debian 10, and i got some warnings (i dont
know if they are bad or not but thought about sharing that with you):
### Compile and Install
$ make -j$(nproc || echo -n 1)
digestauth.c:483:9: warning: ‘strncpy’ specified bound depends on the
length of the source argument [-Wstringop-overflow=]
strncpy (dest,
^~~~~~~~~~~~~~
q1,
~~~
size);
~~~~~
digestauth.c:479:15: note: length computed here
len = strlen (q1) + 1;
Not really "bad", just memcpy would have been minimally more efficient.
I've updated the code which should eliminate the warning in the future.
Thanks for pointing it out.
^~~~~~~~~~~
$ make -j$(nproc || echo -n 1)
oidc_helper.c:286:1: warning: ‘url_decode’ defined but not used
[-Wunused-function]
url_decode (const char *str)
^~~~~~~~~~
Very harmless, not sure if the function should be removed or if Martin
has plans and this one is just 'future work'.
$ sudo make install
libtool: warning: relinking 'libgnunetscalarproduct.la'
(and more like it).
Expected, harmless
### In Addition: gnunet-gtk
user@host:~/gnunet_installation/gnunet-gtk$ make -j$(nproc || echo -n 1)
make: *** No targets specified and no makefile found. Stop.
You need to run the 'configure' step first (or bootstrap + configure
from Git). Not sure which instructions you are following.
----------------------------------------------------------
Wiki Enhancements:
- Section "Requirements" instead of adding / / / for each new packages
section , why not adding all of them into single shot like this:
sudo apt install git libtool autoconf autopoint build-essential
libgcrypt-dev libidn11-dev zlib1g-dev libunistring-dev libglpk-dev
miniupnpc libextractor-dev libjansson-dev libcurl4-gnutls-dev gnutls-bin
libsqlite3-dev openssl libnss3-tools libopus-dev libpulse-dev libogg-dev
Where exactly is this? I don't know of a Wiki under our control, but if
it is in *our* documentation, we should fix it. However, I couldn't find
this in our Git. That said, if you are talking about the "generic
instructions" (which has such a list), then the problem is simply that
"apt install" is a Debian-specific solution.
- Section "Compile and Install"
$ sudo apt install libgnutls28-dev <- Why not adding this package to
Section "Requirements" ?
It's technically optional.
- Section "In Addition: gnunet-gtk"
$ sudo apt install libgtk-3-dev libgladeui-dev libunique-dev
libqrencode-dev $ cd ~/gnunet_installation/gnunet-gtk
^^^ Typo mistake, it should be like this:
$ sudo apt install libgtk-3-dev libgladeui-dev libunique-dev
libqrencode-dev
$ cd ~/gnunet_installation/gnunet-gtk
Again, where exactly is this? I don't know of a Wiki under our control,
but if it is in *our* documentation, we should fix it. However, I
couldn't find this in our Git.
----------------------------------------------------------
Questions:
- What do you think about having Appimage for GNUnet to work on every
GNU/Linux system without the need to install anything?
https://appimage.org
I don't think Appimage can work for installing GNUnet. Just reading
their description saying "no root required" -- well, how do you do SUID
binaries then? How do you modify /etc/nsswitch.conf? How do you create a
user 'gnunet' for privilege separation without root? So just reading the
high-level statements about Appimage suggests to me that you could at
best get a half-functional GNUnet with it.
- What do you think about Rust programming language rather than using C?
https://www.rust-lang.org/
The language still seems to evolve a bit too quickly for production
code, forcing everybody on recent compilers and not providing good
long-term stability of APIs yet. Also, the resulting lack of a gcc
frontend is troubling. But that said, GNUnet components can be written
(or re-written) in any language, and certainly Rust (and Go) have some
advantages. Also, GNUnet benefits a lot from existing C code and
libraries, which would have to be ported to imported into Rust (or Go),
which is a non-trivial starting cost that must be paid. But overall I'm
in favor of type safety and we generally welcome people contributing
code in any language with a free compiler.
Having a re-implementation of libgnunetutil in Rust would be a good
start. The recent crypto changes might facilitate this, as they were
done to make the re-implementation of libgnunetutil's crypto in Go
easier, and hence should also facilitate the same for a Rust library.