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.
0x939E6BE1E29FC3CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
