Re: gnunet mysql errors
Nikita Ronja Gillmann transcribed 4.1K bytes: On 2/1/23 19:34, Nikita Ronja Gillmann wrote: Martin Schanzenbach transcribed 3.7K bytes: Please try with https://git.gnunet.org/gnunet.git/commit/?id=ac40efdae723f850bfff62c0cddad130a37f425e on whatever system this failed for you. similar issues for me with this patch: never mind, I forgot that I don't rebuild configure in what I run there. I'll get back to you Okay, as far as I can tell the patch works for my situation. gmake[4]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2' /bin/sh ./config.status --recheck gmake[4]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' CC mysql.lo mysql.c: In function 'iopen': mysql.c:224:3: error: unknown type name 'MYSQL_BOOL'; did you mean 'MYSQL_BIND'? 224 | MYSQL_BOOL reconnect; | ^~ | MYSQL_BIND gmake[3]: *** [Makefile:560: mysql.lo] Error 1 gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' gmake[2]: *** [Makefile:548: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src' gmake[1]: *** [Makefile:599: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' gmake: *** [Makefile:510: all] Error 2 *** Error code 2 Br Christian Grothoff writes: Well, I touched it because it didn't build on my system(s), and with my fix it did. But of course, I didn't test all the various mysql versions... Maybe we should introduce a configure-level check for 'my_bool' instead of relying on the MySQL version? Just reverting the code is sure to then simply cause a similar FTBFS on one of my systems. On 2/1/23 01:19, Martin Schanzenbach wrote: This is a regression introduced by Christian recently: https://git.gnunet.org/gnunet.git/commit/?id=b73a7c5da48e09bd39c1d7c1dabec269dbacd1c8 I think the check before this commit was correct (and the comment wrong). Br Martin Nikita Ronja Gillmann writes: mysql is correctly detected (version: mysql-client-8.0.31nb1). yet I run into this. any idea if this is on your side or mine? gmake[3]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' CC mysql.lo In file included from mysql.c:28: mysql.c: In function 'iopen': ../../src/include/gnunet_mysql_compat.h:48:20: error: 'my_bool' undeclared (first use in this function); did you mean 'bool'? 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this | ^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ ../../src/include/gnunet_mysql_compat.h:48:20: note: each undeclared identifier is reported only once for each function it appears in 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this | ^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ mysql.c:224:14: error: 'reconnect' undeclared (first use in this function); did you mean 'connect'? 224 | MYSQL_BOOL reconnect; | ^ | connect gmake[3]: *** [Makefile:560: mysql.lo] Error 1 gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' gmake[2]: *** [Makefile:548: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src' gmake[1]: *** [Makefile:599: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' gmake: *** [Makefile:510: all] Error 2 *** Error code 2 Stop. make[1]: stopped in /usr/pkgsrc/net/gnunet *** Error code 1
Re: gnunet mysql errors
On 2/1/23 19:34, Nikita Ronja Gillmann wrote: Martin Schanzenbach transcribed 3.7K bytes: Please try with https://git.gnunet.org/gnunet.git/commit/?id=ac40efdae723f850bfff62c0cddad130a37f425e on whatever system this failed for you. similar issues for me with this patch: never mind, I forgot that I don't rebuild configure in what I run there. I'll get back to you gmake[4]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2' /bin/sh ./config.status --recheck gmake[4]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' CC mysql.lo mysql.c: In function 'iopen': mysql.c:224:3: error: unknown type name 'MYSQL_BOOL'; did you mean 'MYSQL_BIND'? 224 | MYSQL_BOOL reconnect; | ^~ | MYSQL_BIND gmake[3]: *** [Makefile:560: mysql.lo] Error 1 gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' gmake[2]: *** [Makefile:548: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src' gmake[1]: *** [Makefile:599: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' gmake: *** [Makefile:510: all] Error 2 *** Error code 2 Br Christian Grothoff writes: Well, I touched it because it didn't build on my system(s), and with my fix it did. But of course, I didn't test all the various mysql versions... Maybe we should introduce a configure-level check for 'my_bool' instead of relying on the MySQL version? Just reverting the code is sure to then simply cause a similar FTBFS on one of my systems. On 2/1/23 01:19, Martin Schanzenbach wrote: This is a regression introduced by Christian recently: https://git.gnunet.org/gnunet.git/commit/?id=b73a7c5da48e09bd39c1d7c1dabec269dbacd1c8 I think the check before this commit was correct (and the comment wrong). Br Martin Nikita Ronja Gillmann writes: mysql is correctly detected (version: mysql-client-8.0.31nb1). yet I run into this. any idea if this is on your side or mine? gmake[3]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' CC mysql.lo In file included from mysql.c:28: mysql.c: In function 'iopen': ../../src/include/gnunet_mysql_compat.h:48:20: error: 'my_bool' undeclared (first use in this function); did you mean 'bool'? 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this | ^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ ../../src/include/gnunet_mysql_compat.h:48:20: note: each undeclared identifier is reported only once for each function it appears in 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this | ^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ mysql.c:224:14: error: 'reconnect' undeclared (first use in this function); did you mean 'connect'? 224 | MYSQL_BOOL reconnect; | ^ | connect gmake[3]: *** [Makefile:560: mysql.lo] Error 1 gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' gmake[2]: *** [Makefile:548: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src' gmake[1]: *** [Makefile:599: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' gmake: *** [Makefile:510: all] Error 2 *** Error code 2 Stop. make[1]: stopped in /usr/pkgsrc/net/gnunet *** Error code 1
Re: gnunet mysql errors
Martin Schanzenbach transcribed 3.7K bytes: Please try with https://git.gnunet.org/gnunet.git/commit/?id=ac40efdae723f850bfff62c0cddad130a37f425e on whatever system this failed for you. similar issues for me with this patch: gmake[4]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2' /bin/sh ./config.status --recheck gmake[4]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' CC mysql.lo mysql.c: In function 'iopen': mysql.c:224:3: error: unknown type name 'MYSQL_BOOL'; did you mean 'MYSQL_BIND'? 224 | MYSQL_BOOL reconnect; | ^~ | MYSQL_BIND gmake[3]: *** [Makefile:560: mysql.lo] Error 1 gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' gmake[2]: *** [Makefile:548: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src' gmake[1]: *** [Makefile:599: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' gmake: *** [Makefile:510: all] Error 2 *** Error code 2 Br Christian Grothoff writes: Well, I touched it because it didn't build on my system(s), and with my fix it did. But of course, I didn't test all the various mysql versions... Maybe we should introduce a configure-level check for 'my_bool' instead of relying on the MySQL version? Just reverting the code is sure to then simply cause a similar FTBFS on one of my systems. On 2/1/23 01:19, Martin Schanzenbach wrote: This is a regression introduced by Christian recently: https://git.gnunet.org/gnunet.git/commit/?id=b73a7c5da48e09bd39c1d7c1dabec269dbacd1c8 I think the check before this commit was correct (and the comment wrong). Br Martin Nikita Ronja Gillmann writes: mysql is correctly detected (version: mysql-client-8.0.31nb1). yet I run into this. any idea if this is on your side or mine? gmake[3]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' CC mysql.lo In file included from mysql.c:28: mysql.c: In function 'iopen': ../../src/include/gnunet_mysql_compat.h:48:20: error: 'my_bool' undeclared (first use in this function); did you mean 'bool'? 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this |^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ ../../src/include/gnunet_mysql_compat.h:48:20: note: each undeclared identifier is reported only once for each function it appears in 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this |^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ mysql.c:224:14: error: 'reconnect' undeclared (first use in this function); did you mean 'connect'? 224 | MYSQL_BOOL reconnect; | ^ | connect gmake[3]: *** [Makefile:560: mysql.lo] Error 1 gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' gmake[2]: *** [Makefile:548: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src' gmake[1]: *** [Makefile:599: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' gmake: *** [Makefile:510: all] Error 2 *** Error code 2 Stop. make[1]: stopped in /usr/pkgsrc/net/gnunet *** Error code 1
gnunet mysql errors
mysql is correctly detected (version: mysql-client-8.0.31nb1). yet I run into this. any idea if this is on your side or mine? gmake[3]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' CC mysql.lo In file included from mysql.c:28: mysql.c: In function 'iopen': ../../src/include/gnunet_mysql_compat.h:48:20: error: 'my_bool' undeclared (first use in this function); did you mean 'bool'? 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this |^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ ../../src/include/gnunet_mysql_compat.h:48:20: note: each undeclared identifier is reported only once for each function it appears in 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this |^~~ mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL' 224 | MYSQL_BOOL reconnect; | ^~ mysql.c:224:14: error: 'reconnect' undeclared (first use in this function); did you mean 'connect'? 224 | MYSQL_BOOL reconnect; | ^ | connect gmake[3]: *** [Makefile:560: mysql.lo] Error 1 gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql' gmake[2]: *** [Makefile:548: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src' gmake[1]: *** [Makefile:599: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2' gmake: *** [Makefile:510: all] Error 2 *** Error code 2 Stop. make[1]: stopped in /usr/pkgsrc/net/gnunet *** Error code 1
Re: portability patch (was: GNUnet 0.18.0 released)
Hi, I think you may not understand the main issue. This is not very pkgsrc specific, very likely for other portable package managers as well, the issue is that the file is distributed. There is no option to uncheck/not fail on a file which fails the tests, as this is run on every matching file in the build directory after unpacking. It's a simple fix, and would mean one less patch to carry around once I get to merge gnunet into pkgsrc proper. On 11/2/22 7:18 AM, Martin Schanzenbach wrote: Hi, this is a fedora-specific packaging file which does not need to be portable. It only needs to work for fedora. But I will keep that in mind. Br On 01.11.22 19:53, Nikita Ronja Gillmann wrote: Hi, here's a fix to make contrib/packages/fedora/10-dns2gns.sh portable. Taken from my pkgsrc package, NetBSD header not removed, feel free to do so or just take the patch as an info. I'd suggest to add checkbashisms as part of dev tests to check all .sh files. ERROR: [check-portability.awk] => Found test ... == ...: ERROR: [check-portability.awk] contrib/packages/fedora/10-dns2gns.sh:31: if [ $? == 0 ]; then Explanation: === The "test" command, as well as the "[" command, are not required to know the "==" operator. Only a few implementations like bash and some versions of ksh support it. When you run "test foo == foo" on a platform that does not support the "==" operator, the result will be "false" instead of "true". This can lead to unexpected behavior. There are two ways to fix this error message. If the file that contains the "test ==" is needed for building the package, you should create a patch for it, replacing the "==" operator with "=". If the file is not needed, add its name to the CHECK_PORTABILITY_SKIP variable in the package Makefile. === checkbashisms: checkbashisms /usr/work/wip/gnunet/work/gnunet-0.18.0/contrib/packages/fedora/10-dns2gns.sh possible bashism in /usr/work/wip/gnunet/work/gnunet-0.18.0/contrib/packages/fedora/10-dns2gns.sh line 31 (should be 'b = a'): if [ $? == 0 ]; then Martin Schanzenbach transcribed 6.2K bytes: We are pleased to announce the release of GNUnet 0.18.0. GNUnet is an alternative network stack for building secure, decentralized and privacy-preserving distributed applications. Our goal is to replace the old insecure Internet protocol stack. Starting from an application for secure publication of files, it has grown to include all kinds of basic protocol components and applications towards the creation of a GNU internet. This is a new major release. It breaks protocol compatibility with the 0.17.x versions. Please be aware that Git master is thus henceforth (and has been for a while) INCOMPATIBLE with the 0.17.x GNUnet network, and interactions between old and new peers will result in issues. 0.17.x peers will be able to communicate with Git master or 0.18.x peers, but some services - in particular the DHT - will not be compatible. In terms of usability, users should be aware that there are still a number of known open issues in particular with respect to ease of use, but also some critical privacy issues especially for mobile users. Also, the nascent network is tiny and thus unlikely to provide good anonymity or extensive amounts of interesting information. As a result, the 0.18.0 release is still only suitable for early adopters with some reasonable pain tolerance. Download links: - http://ftpmirror.gnu.org/gnunet/gnunet-0.18.0.tar.gz - http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.18.0.tar.gz Note that due to mirror synchronization, not all links might be functional early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/ Noteworthy changes in 0.18.0 (since 0.17.6): UTIL: Added enum GNUNET_ErrorCode for better error handling throughout the API. NAMESTORE: - Moved namecache updates out of namestore and into zonemaster. This fixes issues from version 0.17.6 with respect to premature namestore monitor update messages and zone propagation. [#7378] - Added a new API for bulk imports: GNUNET_NAMESTORE_records_store2. The API can be combined with the transactional API in order to significantly improve namestore performance for lage zones. For postgres databases, storing records is around 20x faster than the old API. [#7379] - New database setup utility gnunet-namestore-dbtool. Databases can be initialized and reset using this new CLI. Currently, database plugins still allow to initialize databases automatically as well by setting INIT_ON_CONNECT (Default: YES). [#7204] - There are new APIs for zone iterations
portability patch (was: GNUnet 0.18.0 released)
Hi, here's a fix to make contrib/packages/fedora/10-dns2gns.sh portable. Taken from my pkgsrc package, NetBSD header not removed, feel free to do so or just take the patch as an info. I'd suggest to add checkbashisms as part of dev tests to check all .sh files. ERROR: [check-portability.awk] => Found test ... == ...: ERROR: [check-portability.awk] contrib/packages/fedora/10-dns2gns.sh:31: if [ $? == 0 ]; then Explanation: === The "test" command, as well as the "[" command, are not required to know the "==" operator. Only a few implementations like bash and some versions of ksh support it. When you run "test foo == foo" on a platform that does not support the "==" operator, the result will be "false" instead of "true". This can lead to unexpected behavior. There are two ways to fix this error message. If the file that contains the "test ==" is needed for building the package, you should create a patch for it, replacing the "==" operator with "=". If the file is not needed, add its name to the CHECK_PORTABILITY_SKIP variable in the package Makefile. === checkbashisms: checkbashisms /usr/work/wip/gnunet/work/gnunet-0.18.0/contrib/packages/fedora/10-dns2gns.sh possible bashism in /usr/work/wip/gnunet/work/gnunet-0.18.0/contrib/packages/fedora/10-dns2gns.sh line 31 (should be 'b = a'): if [ $? == 0 ]; then Martin Schanzenbach transcribed 6.2K bytes: > We are pleased to announce the release of GNUnet 0.18.0. > GNUnet is an alternative network stack for building secure, decentralized and > privacy-preserving distributed applications. Our goal is to replace the old > insecure Internet protocol stack. Starting from an application for secure > publication of files, it has grown to include all kinds of basic protocol > components and applications towards the creation of a GNU internet. > > This is a new major release. It breaks protocol compatibility with the 0.17.x > versions. Please be aware that Git master is thus henceforth (and has been > for a > while) INCOMPATIBLE with the 0.17.x GNUnet network, and interactions between > old > and new peers will result in issues. 0.17.x peers will be able to communicate > with Git master or 0.18.x peers, but some services - in particular the DHT - > will not be compatible. > In terms of usability, users should be aware that there are still a number of > known open issues in particular with respect to ease of use, but also some > critical privacy issues especially for mobile users. Also, the nascent network > is tiny and thus unlikely to provide good anonymity or extensive amounts of > interesting information. As a result, the 0.18.0 release is still only > suitable > for early adopters with some reasonable pain tolerance. > > Download links: > > - http://ftpmirror.gnu.org/gnunet/gnunet-0.18.0.tar.gz > - http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.18.0.tar.gz > > Note that due to mirror synchronization, not all links might be functional > early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/ > > Noteworthy changes in 0.18.0 (since 0.17.6): > > UTIL: Added enum GNUNET_ErrorCode for better error handling throughout > the API. > NAMESTORE: > - Moved namecache updates out of namestore and into zonemaster. > This fixes issues from version 0.17.6 with respect to premature > namestore monitor update messages and zone propagation. [#7378] > - Added a new API for bulk imports: GNUNET_NAMESTORE_records_store2. > The API can be combined with the transactional API in order to > significantly improve namestore performance for lage zones. For > postgres databases, storing records is around 20x faster than the > old > API. [#7379] > - New database setup utility gnunet-namestore-dbtool. Databases can be > initialized and reset using this new CLI. Currently, database > plugins > still allow to initialize databases automatically as well by setting > INIT_ON_CONNECT (Default: YES). [#7204] > - There are new APIs for zone iterations and monitoring which support > filtering of records using GNUNET_GNSRECORD_Filter. By default, > maintenance records such as TOMBSTONEs are filtered. [#7193] > - New zonefile import utility gnunet-namestore-zonefile that for DNS > zone files. [#7396] > - Make use of new enum GNUNET_ErrorCode in C and REST API. [#7399] > - Included handling of orphaned GNS records. Records are orphaned of > Egos are (accidentally) deleted which makes operations on records > difficult but at the same time existing records are still published. > [#7401, #7402] > - Updated the C API documentation to reflect the above changes: > >
portability patch (was: GNUnet 0.18.0 released)
resent, please disregard/delete previous message if arrived. Hi, here's a fix to make contrib/packages/fedora/10-dns2gns.sh portable. Taken from my pkgsrc package, NetBSD header not removed, feel free to do so or just take the patch as an info. I'd suggest to add checkbashisms as part of dev tests to check all .sh files. ERROR: [check-portability.awk] =Found test ... == ...: ERROR: [check-portability.awk] contrib/packages/fedora/10-dns2gns.sh:31: if [ $? == 0 ]; then Explanation: === The "test" command, as well as the "[" command, are not required to know the "==" operator. Only a few implementations like bash and some versions of ksh support it. When you run "test foo == foo" on a platform that does not support the "==" operator, the result will be "false" instead of "true". This can lead to unexpected behavior. There are two ways to fix this error message. If the file that contains the "test ==" is needed for building the package, you should create a patch for it, replacing the "==" operator with "=". If the file is not needed, add its name to the CHECK_PORTABILITY_SKIP variable in the package Makefile. === checkbashisms: checkbashisms /usr/work/wip/gnunet/work/gnunet-0.18.0/contrib/packages/fedora/10-dns2gns.sh possible bashism in /usr/work/wip/gnunet/work/gnunet-0.18.0/contrib/packages/fedora/10-dns2gns.sh line 31 (should be 'b = a'): if [ $? == 0 ]; then Martin Schanzenbach transcribed 6.2K bytes: We are pleased to announce the release of GNUnet 0.18.0. GNUnet is an alternative network stack for building secure, decentralized and privacy-preserving distributed applications. Our goal is to replace the old insecure Internet protocol stack. Starting from an application for secure publication of files, it has grown to include all kinds of basic protocol components and applications towards the creation of a GNU internet. This is a new major release. It breaks protocol compatibility with the 0.17.x versions. Please be aware that Git master is thus henceforth (and has been for a while) INCOMPATIBLE with the 0.17.x GNUnet network, and interactions between old and new peers will result in issues. 0.17.x peers will be able to communicate with Git master or 0.18.x peers, but some services - in particular the DHT - will not be compatible. In terms of usability, users should be aware that there are still a number of known open issues in particular with respect to ease of use, but also some critical privacy issues especially for mobile users. Also, the nascent network is tiny and thus unlikely to provide good anonymity or extensive amounts of interesting information. As a result, the 0.18.0 release is still only suitable for early adopters with some reasonable pain tolerance. Download links: - http://ftpmirror.gnu.org/gnunet/gnunet-0.18.0.tar.gz - http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.18.0.tar.gz Note that due to mirror synchronization, not all links might be functional early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/ Noteworthy changes in 0.18.0 (since 0.17.6): UTIL: Added enum GNUNET_ErrorCode for better error handling throughout the API. NAMESTORE: - Moved namecache updates out of namestore and into zonemaster. This fixes issues from version 0.17.6 with respect to premature namestore monitor update messages and zone propagation. [#7378] - Added a new API for bulk imports: GNUNET_NAMESTORE_records_store2. The API can be combined with the transactional API in order to significantly improve namestore performance for lage zones. For postgres databases, storing records is around 20x faster than the old API. [#7379] - New database setup utility gnunet-namestore-dbtool. Databases can be initialized and reset using this new CLI. Currently, database plugins still allow to initialize databases automatically as well by setting INIT_ON_CONNECT (Default: YES). [#7204] - There are new APIs for zone iterations and monitoring which support filtering of records using GNUNET_GNSRECORD_Filter. By default, maintenance records such as TOMBSTONEs are filtered. [#7193] - New zonefile import utility gnunet-namestore-zonefile that for DNS zone files. [#7396] - Make use of new enum GNUNET_ErrorCode in C and REST API. [#7399] - Included handling of orphaned GNS records. Records are orphaned of Egos are (accidentally) deleted which makes operations on records difficult but at the same time existing records are still published. [#7401, #7402] - Updated the C API documentation to reflect the above changes: https://docs.gnunet.org/developers/subsystems/namestore/namestore.html - Updated
Re: gnunet-rest-server shutdown issues
Hi, so the issue still exists, but I didn't have the time to send more information, busy last months. I'll try to get back to you soon. As an aside: I haven't followed gnunet development that much recently, but as I have started to add invocations for a couple of BSDs to gnunet-dns-helper (a long time ago and ran out of time as well), I was wondering if those firewall parts would eventually become obsolete in the rewrites you are doing right now, long-term? Schanzenbach, Martin transcribed 5.0K bytes: > Did the output "Shutting down..." appear before or after the normal > shutdown trigger (ctrl-c or gnunet-arm -e)? > If it appeared with the normal shutdown, then I really don't know. > According to the pkill log there is another select happening before the > SIGKILL, > but I cannot see where this is coming from. The cleanup logic looks ok. > > If the log message appears after the SIGKILL then I need to investigate a bit > further, > but it may be a signal handler issue. > > BR > > > On 11. Apr 2022, at 13:46, Nikita Ronja Gillmann wrote: > > > > Hi, > > > > Schanzenbach, Martin transcribed 4.0K bytes: > >> You can try stopping the rest service > >> > >> $ gnunet-arm -k rest > > > > here it continued running, for whatever reason. > > No return from gnunet-arm -k rest. > > > >> > >> and then starting it manually through the server binary. > >> Then try to ctrl-c it. > >> > >> If that also does not work, maybe look at the output there. > > > > the output did not provide any useful insights. > > I did a couple of runs, but in both I had to pkill rest-server. > > > >> If there is not output, I am pretty lost. > >> Should ctrl-c work, then something odd is going on with the signals from > >> arm? > > > > CTRL-C didn't work. > > Would the two kdump logs I did for this help? > > > >> > >> BR > >> > >>> On 11. Apr 2022, at 09:06, Nikita Ronja Gillmann wrote: > >>> > >>> The hang produces no DEBUG infos, all I get for that (when stopping > >>> the user service) is, in addition to what I posted: > >>> > >>> 2022-04-11T09:04:32.426431+0200 arm-2811 WARNING Service `rest' > >>> terminated with status signal/9, will restart in 1 ms > >>> > >>> which is expected as I kill with -9. > >>> > >>> Nikita Ronja Gillmann transcribed 1.8K bytes: > >>>> Thanks. > >>>> > >>>> Possibly related, with explanation ahead: > >>>> > >>>> I'm still debugging the service layout I have. > >>>> /var/chroot/gnunet is the $HOME of the 'gnunet' system user (which > >>>> runs the system service). > >>>> system user logs go into /var/chroot/gnunet/cache, > >>>> hostlist, topology into /var/chroot/gnunet/.config, > >>>> and all the rest into /var/chroot/gnunet/data. > >>>> > >>>> The service I start for my user (and the user services) > >>>> has no read access to this directory. > >>>> What problems could cause that? > >>>> Should I solve this differently, or is a change like > >>>> a gnunet:gnunetdns as owner for /var/chroot/gnunet > >>>> and adding my user to gnunetdns enough (or no changes > >>>> and just adding to gnunet group) enough? > >>>> > >>>> $/HOME/.cache/gnunet/gnunet-2022-04-11.log > >>>> 2022-04-11T08:17:11.373925+0200 namestore-656 ERROR Assertion failed at > >>>> sq_result_helper.c:180. > >>>> 2022-04-11T08:17:11.374183+0200 namestore-656 ERROR Assertion failed at > >>>> plugin_namestore_sqlite.c:537. > >>>> 2022-04-11T08:17:11.374232+0200 namestore-656 ERROR Assertion failed at > >>>> gnunet-service-namestore.c:1949. > >>>> > >>>> looks like there is some issue related to accessing information? > >>>> > >>>> Schanzenbach, Martin transcribed 1.9K bytes: > >>>>> Hi, > >>>>> > >>>>> this is not a known bug and it would be very odd if the REST API is not > >>>>> even used. > >>>>> > >>>>> So yes, debug logs would be helpful. > >>>>> > >>>>> BR > >>>>> > >>>>>> On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann > >>>>>> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> in my system service I have a pill + kill for gnunet-rest-server, > >>>>>> as this process seems to not react to gnunet-arm -e. > >>>>>> > >>>>>> I am not sure how to debug this. look at loglevel DEBUG logs? > >>>>>> It seems like a bug to me when this prevents a normal shutdown > >>>>>> of gnunet. > >>>>>> > >>>>>> This is via the user process, not the system process run as the > >>>>>> system user "gnunet". > >>>>>> > >>>>>> Any clues before I sent in logs? Is this is a known bug? > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >> > > > > > > >
mantis sets no real domain to filter emails from
Mantis used to set nore...@gnunet.org, now it sets the example.com address for everything. This makes it rather hard to filter when you are still on some bug tickets. Can you please fix that to conform to point to gnunet.org? Thanks.
Packaging problems
More or less, from my work back then and observations still today: complexity is to blame (and complex scenarios). Only people involved in gnunet at some point or close to the project managed to create correct packages. With my pkgsrc hat on: almost nobody gets paid to do packaging work. Updates happen whenever someone cares for or has the time, we're all just human with limited time for this. I can understand the view on this, I've given up ar some point and it is solely a responsibly of packagers. Emails help in some cases.
Re: Attacking the documentation monster
Hi, qemu did this a while back it seems On 5/24/22 22:38, Willow Liquorice wrote: As an aside, *does anyone know of any tools to convert TeXinfo to reST*? This migration is going to be much smoother if there are. https://patchwork.kernel.org/project/qemu-devel/patch/20200226113034.6741-19-pbonz...@redhat.com/ - Willow On 24/05/2022 18:01, Christian Grothoff wrote: The doxygen configuration file in Git just had an ancient version number. I've fixed that now. The rest was up-to-date ;-). -Christian On 5/23/22 16:24, Willow Liquorice wrote: Just look at https://docs.gnunet.org/doxygen/html/index.html and you'll see what I mean. - Willow On 23/05/2022 15:23, Christian Grothoff wrote: I cannot even find a version number on https://docs.gnunet.org/, so that's likely not what you are refering to. So where exactly are you looking to find documentation for 0.11.x? Likely some code to update some location is not working (or was never written, and someone put something out manually...). -Christian On 5/23/22 16:16, Willow Liquorice wrote: Alright, doc/sphinx it is. The handbook is already intended for two wildly different audiences, what with being both a user's and developer's manual. Having the source code documentation in one place (and possibly better organised) might make it easier to work with, and help keep the Developer's Manual up-to-date. On another note, are the online source docs even up to date? The indicated version on them is 0.11.x, which is several years gone at this point. Best wishes, Willow On 23/05/2022 08:39, Christian Grothoff wrote: On 5/23/22 00:57, Willow Liquorice wrote: Hello again, Thanks for the info, good to hear that I've got most of it. Setting up a branch in my local GNUnet repository, to start experimenting with Sphinx, as I write this. Seeing as there's some experience with the software in the project already, where would be the most sensible place to put the root directory? My thinking is either the repository root or the doc folder. Definitively doc/, I think doc/sphinx/ would be good. Would it be sensible to migrate to Sphinx throughout the whole GNUnet repository? Breathe (https://www.breathe-doc.org/) could very well make the transition easy, as I think it would allow us to read the Doxygen comments that are already present in the source code. I'm not sure importing the Doxygen makes sense, that's very different from the main handbook/tutorial/man-pages both in terms of style and audience. my 2 cents Christian Best wishes, Willow Liquorice On 22/05/2022 22:27, Christian Grothoff wrote: Hi Willow, We've been using RST/Sphinx for the GNU Taler documentation, and it can generate reasonable TeXinfo. From that experience, I'm not against converting the existing documentation to RST. As far as finding the documentation, I think you found most of it, except maybe the RFC-style specs at https://lsd.gnunet.org/. The handbook is supposed to cover things in depth, with different chapters for installation (for the various platforms), users (by application, explaining what each application can do and how to use it) and developers (by subsystem, explaining how each subsystem is supposed to work). The man-pages are supposed to be for the day-to-day usage when someone wants to quickly look up command-line options. The doxygen is for function-level documentation for developers-only. The tutorial is for newbie-developers, and is a bit dated. Finally, the LSDs are in-depth protocol descriptions for those wanting to do interoperable (re)implementations. I hope that answers your questions and look forward to you improving the documentation! Happy hacking! Christian On 5/20/22 02:21, Willow Liquorice wrote: I've got some free time on my hands now, and I gave some thought to improving the readability of the HTML documentation on the website (which is what the average prospective GNUnet dev is going to look at). Read the Docs and friends set the standard in this regard. Having the contents in a sidebar for easy access (regardless of your location) would be far more convenient than what's currently available. I understand that TeXinfo's HTML generation is a bit simplistic in the name of compatibility, which, while not a bad thing, results in a subpar reading experience for the average dev who will, in all likelihood, be reading the docs on a very capable modern browser. While thinking about how to improve things with TeXinfo, it occurred to me that, instead of trying to emulate the experience of using Read the Docs, one could just use Read the Docs! It's Free Software, after all. I haven't looked into it too deeply, but if the .texi sources are converted to the reStructuredText that it accepts, a migration (or use of a similar platform) might be worth considering. What do the people here think? If I'm going to dedicate time to restructuring GNUnet's docs, I need to know where it
Re: gnunet-rest-server shutdown issues
Hi, Schanzenbach, Martin transcribed 4.0K bytes: > You can try stopping the rest service > > $ gnunet-arm -k rest here it continued running, for whatever reason. No return from gnunet-arm -k rest. > > and then starting it manually through the server binary. > Then try to ctrl-c it. > > If that also does not work, maybe look at the output there. the output did not provide any useful insights. I did a couple of runs, but in both I had to pkill rest-server. > If there is not output, I am pretty lost. > Should ctrl-c work, then something odd is going on with the signals from arm? CTRL-C didn't work. Would the two kdump logs I did for this help? > > BR > > > On 11. Apr 2022, at 09:06, Nikita Ronja Gillmann wrote: > > > > The hang produces no DEBUG infos, all I get for that (when stopping > > the user service) is, in addition to what I posted: > > > > 2022-04-11T09:04:32.426431+0200 arm-2811 WARNING Service `rest' terminated > > with status signal/9, will restart in 1 ms > > > > which is expected as I kill with -9. > > > > Nikita Ronja Gillmann transcribed 1.8K bytes: > >> Thanks. > >> > >> Possibly related, with explanation ahead: > >> > >> I'm still debugging the service layout I have. > >> /var/chroot/gnunet is the $HOME of the 'gnunet' system user (which > >> runs the system service). > >> system user logs go into /var/chroot/gnunet/cache, > >> hostlist, topology into /var/chroot/gnunet/.config, > >> and all the rest into /var/chroot/gnunet/data. > >> > >> The service I start for my user (and the user services) > >> has no read access to this directory. > >> What problems could cause that? > >> Should I solve this differently, or is a change like > >> a gnunet:gnunetdns as owner for /var/chroot/gnunet > >> and adding my user to gnunetdns enough (or no changes > >> and just adding to gnunet group) enough? > >> > >> $/HOME/.cache/gnunet/gnunet-2022-04-11.log > >> 2022-04-11T08:17:11.373925+0200 namestore-656 ERROR Assertion failed at > >> sq_result_helper.c:180. > >> 2022-04-11T08:17:11.374183+0200 namestore-656 ERROR Assertion failed at > >> plugin_namestore_sqlite.c:537. > >> 2022-04-11T08:17:11.374232+0200 namestore-656 ERROR Assertion failed at > >> gnunet-service-namestore.c:1949. > >> > >> looks like there is some issue related to accessing information? > >> > >> Schanzenbach, Martin transcribed 1.9K bytes: > >>> Hi, > >>> > >>> this is not a known bug and it would be very odd if the REST API is not > >>> even used. > >>> > >>> So yes, debug logs would be helpful. > >>> > >>> BR > >>> > >>>> On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann wrote: > >>>> > >>>> Hi, > >>>> > >>>> in my system service I have a pill + kill for gnunet-rest-server, > >>>> as this process seems to not react to gnunet-arm -e. > >>>> > >>>> I am not sure how to debug this. look at loglevel DEBUG logs? > >>>> It seems like a bug to me when this prevents a normal shutdown > >>>> of gnunet. > >>>> > >>>> This is via the user process, not the system process run as the > >>>> system user "gnunet". > >>>> > >>>> Any clues before I sent in logs? Is this is a known bug? > >>>> > >>> > >> > >> > >> > > >
Re: gnunet-rest-server shutdown issues
The hang produces no DEBUG infos, all I get for that (when stopping the user service) is, in addition to what I posted: 2022-04-11T09:04:32.426431+0200 arm-2811 WARNING Service `rest' terminated with status signal/9, will restart in 1 ms which is expected as I kill with -9. Nikita Ronja Gillmann transcribed 1.8K bytes: > Thanks. > > Possibly related, with explanation ahead: > > I'm still debugging the service layout I have. > /var/chroot/gnunet is the $HOME of the 'gnunet' system user (which > runs the system service). > system user logs go into /var/chroot/gnunet/cache, > hostlist, topology into /var/chroot/gnunet/.config, > and all the rest into /var/chroot/gnunet/data. > > The service I start for my user (and the user services) > has no read access to this directory. > What problems could cause that? > Should I solve this differently, or is a change like > a gnunet:gnunetdns as owner for /var/chroot/gnunet > and adding my user to gnunetdns enough (or no changes > and just adding to gnunet group) enough? > > $/HOME/.cache/gnunet/gnunet-2022-04-11.log > 2022-04-11T08:17:11.373925+0200 namestore-656 ERROR Assertion failed at > sq_result_helper.c:180. > 2022-04-11T08:17:11.374183+0200 namestore-656 ERROR Assertion failed at > plugin_namestore_sqlite.c:537. > 2022-04-11T08:17:11.374232+0200 namestore-656 ERROR Assertion failed at > gnunet-service-namestore.c:1949. > > looks like there is some issue related to accessing information? > > Schanzenbach, Martin transcribed 1.9K bytes: > > Hi, > > > > this is not a known bug and it would be very odd if the REST API is not > > even used. > > > > So yes, debug logs would be helpful. > > > > BR > > > > > On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann wrote: > > > > > > Hi, > > > > > > in my system service I have a pill + kill for gnunet-rest-server, > > > as this process seems to not react to gnunet-arm -e. > > > > > > I am not sure how to debug this. look at loglevel DEBUG logs? > > > It seems like a bug to me when this prevents a normal shutdown > > > of gnunet. > > > > > > This is via the user process, not the system process run as the > > > system user "gnunet". > > > > > > Any clues before I sent in logs? Is this is a known bug? > > > > > > > >
Re: gnunet-rest-server shutdown issues
Thanks. Possibly related, with explanation ahead: I'm still debugging the service layout I have. /var/chroot/gnunet is the $HOME of the 'gnunet' system user (which runs the system service). system user logs go into /var/chroot/gnunet/cache, hostlist, topology into /var/chroot/gnunet/.config, and all the rest into /var/chroot/gnunet/data. The service I start for my user (and the user services) has no read access to this directory. What problems could cause that? Should I solve this differently, or is a change like a gnunet:gnunetdns as owner for /var/chroot/gnunet and adding my user to gnunetdns enough (or no changes and just adding to gnunet group) enough? $/HOME/.cache/gnunet/gnunet-2022-04-11.log 2022-04-11T08:17:11.373925+0200 namestore-656 ERROR Assertion failed at sq_result_helper.c:180. 2022-04-11T08:17:11.374183+0200 namestore-656 ERROR Assertion failed at plugin_namestore_sqlite.c:537. 2022-04-11T08:17:11.374232+0200 namestore-656 ERROR Assertion failed at gnunet-service-namestore.c:1949. looks like there is some issue related to accessing information? Schanzenbach, Martin transcribed 1.9K bytes: > Hi, > > this is not a known bug and it would be very odd if the REST API is not even > used. > > So yes, debug logs would be helpful. > > BR > > > On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann wrote: > > > > Hi, > > > > in my system service I have a pill + kill for gnunet-rest-server, > > as this process seems to not react to gnunet-arm -e. > > > > I am not sure how to debug this. look at loglevel DEBUG logs? > > It seems like a bug to me when this prevents a normal shutdown > > of gnunet. > > > > This is via the user process, not the system process run as the > > system user "gnunet". > > > > Any clues before I sent in logs? Is this is a known bug? > > >
gnunet-rest-server shutdown issues
Hi, in my system service I have a pill + kill for gnunet-rest-server, as this process seems to not react to gnunet-arm -e. I am not sure how to debug this. look at loglevel DEBUG logs? It seems like a bug to me when this prevents a normal shutdown of gnunet. This is via the user process, not the system process run as the system user "gnunet". Any clues before I sent in logs? Is this is a known bug?
Re: mysql check always fails
Thanks! Schanzenbach, Martin transcribed 3.7K bytes: > Hi, > > I pushed this fix. > > BR > > > > On 9. Apr 2022, at 11:33, Nikita Ronja Gillmann wrote: > > > > Hi, > > > > for some reason I can't open an account at the bug tracker. > > The issue is a one character problem: > > https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/patches/patch-configure;h=ff56f7067812362ff4f0de0b8276e02119aa5479;hb=HEAD > > > > where #include > > should be, configure.ac has > > include > > > > So in a packaging environment where you pass > > --with-mysql=/mysql/prefix/ you get a detected > > mysql, but the version check fails. Which leads > > to <= 4.x being assumed, and therefore mysql isn't > > picked up by configure. > > > > https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/options.mk;h=821017177ceb47baaee6f41378b81e8da55ce278;hb=HEAD#l80 > > > > This happens with mysql-client 8.0.24. > > > > The patch I use fixes the version detection for me. > > > > Schanzenbach, Martin transcribed 2.6K bytes: > >> Can anyone of you open a bug report for this with a description. > >> From the mails I do not understand the problem beyond "the check does not > >> work". > >> I can look at it next week. > >> > >> BR > >> Martin > >> > >>> On 8. Apr 2022, at 10:04, Nikita Ronja Gillmann wrote: > >>> > >>> Daniel Golle transcribed 0.7K bytes: > >>>> Hi Nikita, > >>>> > >>>> On Fri, Apr 08, 2022 at 09:12:29AM +0200, Nikita Ronja Gillmann wrote: > >>>>> Hi, > >>>>> > >>>>> I have no time to work on a patch for this, but even with the right > >>>>> version of mysql(-client) (version => 8.0.24), > >>>>> configure.ac generates a configure file which leads to broken C code > >>>>> for what applies for my builds (--with-mysql=PRFX). > >>>>> I have attached the files. > >>>> > >>>> Just to confirm your findings: > >>>> I've also encountered this problem when building recent GNUnet releases > >>>> for OpenWrt and have decided to simply drop the version check (as in > >>>> this case I just know the version is recent enough): > >>> > >>> thanks. I still think that fixing 1 character would be better. > >>> last time moved/touched in 2021, and I've seen this error for > >>> some versions now as well in pkgsrc: > >>> 20ffa0aa54 (Alessio Vanni2021-11-11 00:56:30 +0100 1032) > >>> [[include ]], > >>> > >>>> https://github.com/openwrt/packages/blob/master/net/gnunet/patches/100-remove-mysql-version-check.patch > >>>> > >>>> > >>>> Cheers > >>>> > >>>> > >>>> Daniel > >> > > > > > > >
Re: mysql check always fails
Hi, for some reason I can't open an account at the bug tracker. The issue is a one character problem: https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/patches/patch-configure;h=ff56f7067812362ff4f0de0b8276e02119aa5479;hb=HEAD where #include should be, configure.ac has include So in a packaging environment where you pass --with-mysql=/mysql/prefix/ you get a detected mysql, but the version check fails. Which leads to <= 4.x being assumed, and therefore mysql isn't picked up by configure. https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/options.mk;h=821017177ceb47baaee6f41378b81e8da55ce278;hb=HEAD#l80 This happens with mysql-client 8.0.24. The patch I use fixes the version detection for me. Schanzenbach, Martin transcribed 2.6K bytes: > Can anyone of you open a bug report for this with a description. > From the mails I do not understand the problem beyond "the check does not > work". > I can look at it next week. > > BR > Martin > > > On 8. Apr 2022, at 10:04, Nikita Ronja Gillmann wrote: > > > > Daniel Golle transcribed 0.7K bytes: > >> Hi Nikita, > >> > >> On Fri, Apr 08, 2022 at 09:12:29AM +0200, Nikita Ronja Gillmann wrote: > >>> Hi, > >>> > >>> I have no time to work on a patch for this, but even with the right > >>> version of mysql(-client) (version => 8.0.24), > >>> configure.ac generates a configure file which leads to broken C code for > >>> what applies for my builds (--with-mysql=PRFX). > >>> I have attached the files. > >> > >> Just to confirm your findings: > >> I've also encountered this problem when building recent GNUnet releases > >> for OpenWrt and have decided to simply drop the version check (as in > >> this case I just know the version is recent enough): > > > > thanks. I still think that fixing 1 character would be better. > > last time moved/touched in 2021, and I've seen this error for > > some versions now as well in pkgsrc: > > 20ffa0aa54 (Alessio Vanni2021-11-11 00:56:30 +0100 1032) > > [[include ]], > > > >> https://github.com/openwrt/packages/blob/master/net/gnunet/patches/100-remove-mysql-version-check.patch > >> > >> > >> Cheers > >> > >> > >> Daniel >
Re: Debugging help needed: gnunet services in a multiuser setup
# Runtime data (i.e UNIX domain sockets, locks, always lost on system boot)
# This is the variable for system-wide services; use GNUNET_USER_RUNTIME_DIR
# for per-user services (where RUN_PER_USER=YES is set)
# Note that the 'gnunet'/system user must have $TMPDIR/$TMP set to
# exactly the same values as 'normal' users, otherwise this will fail.
# If $TMPDIR or $TMP are set to different directories for different
# users, this option should be changed to point to the same directory
# for all users (i.e. by simply using "/tmp/gnunet-system-runtime/").
GNUNET_RUNTIME_DIR = ${TMPDIR:-${TMP:-/tmp}}/gnunet-system-runtime/
I guess that explains my issue (both are not set to the same directory).
I hope I can report back that I've fixed it.
Nikita Ronja Gillmann transcribed 25K bytes:
> A look at the dump of ktrace of gnunet-core run as my user makes me suggest
> that
> the system user might be putting the socket files in the wrong place for some
> reason?
>
> 1670 1670 gnunet-core MISC mbsoname:
> [/tmp/gnunet-system-runtime//gnunet-service-core.sock]
> 1670 1670 gnunet-core NAMI
> "/tmp/gnunet-system-runtime//gnunet-service-core.sock"
> 1670 1670 gnunet-core RET connect -1 errno 2 No such file or directory
> 1670 1670 gnunet-core CALL close(6)
> 1670 1670 gnunet-core RET close 0
>
> So what I'm asking for here is also a detailed map on how this should look
> like,
> if working. Right now system user 'gnunet' has the $HOME in /var/chroot/gnunet
> and most of the sock files are in there (except for -arm).
>
> Nikita Ronja Gillmann transcribed 23K bytes:
> > Nikita Ronja Gillmann transcribed 23K bytes:
> > > So my gnunet is mostly working:
> > >
> > > Logs for the gnunet user are looking good (as far as I can tell).
> > > When I su into the gnunet user and execute gnunet-core with a path
> > > to the config file, I get results. Same happens for -peerinfo.
> > > gnunet-search works there as well.
> > > All of this is the gnunet service (system user).
> > >
> > > Now here are the issues, for the normal user:
> > > The gnunetuser service has an issue running stop, the rest-service hangs
> > > around (but on system shutdown it terminates).
> > > gnunet-core doesn't display anything.
> > > gnunet-peerinfo the same.
> > > gnunet-search doesn't find anything.
> > > gnunet-publish doesn't publish.
> > > This is after approximately 14 days or more with this setup.
> > >
> > > I'd like to keep the multiuser option for some added local security
> > > and layouts.
> > > Do you have any idea how I could fix this? Is there anything obviously
> > > wrong with the gnunetuser service?
> > > Does the multiuser setup work at all in your experience?
> > >
> > > Does the gnunet normal user require (read?) access to the path
> > > the system gnunet-arm is running in? At least that's what I read
> > > from the DEBUG level log of the gnunet-arm as user.
> >
> > drwx-- 5 gnunetgnunet1536 Apr 8 12:07 gnunet
> >
> > so far, for /var/chroot/gnunet (the gnunet system user).
> > the only other service (on my system) doing it like this
> > is tor. unbound gives at least r-x for the other groups.
> >
> > > Probably not related as I provide the config file in the service:
> > > Did the default config move into .config/gnunet/gnunet.conf?
> > >
> > > The newest code is at
> > > https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree;f=gnunet
> > >
> > > Thanks.
> >
> > > 2022-04-08T13:57:53.073600+0200 gnunet-arm-15439 WARNING GNUnet not
> > > running, cannot stop the peer
> > > Starting gnunetuser.
> > > 2022-04-08T13:57:53.095900+0200 gnunet-arm-586 DEBUG Loading
> > > configuration from entry point specified as option
> > > (/home/nikita/.config/gnunet.conf)
> > > 2022-04-08T13:57:53.096220+0200 util-586 DEBUG Asked to parse config file
> > > `/usr/pkg/share/gnunet/config.d/abd.conf'
> > > 2022-04-08T13:57:53.096301+0200 util-586 DEBUG Deserializing contents of
> > > file `/usr/pkg/share/gnunet/config.d/abd.conf'
> > > 2022-04-08T13:57:53.096328+0200 util-586 DEBUG Asked to parse config file
> > > `/usr/pkg/share/gnunet/config.d/arm.conf'
> > > 2022-04-08T13:57:53.096357+0200 util-586 DEBUG Deserializing contents of
> > > file `/usr/pkg/share/gnunet/config.d/arm.conf'
> > > 2022-04-08T13:57:53.096382+0200 util-586 DEBUG Asked to parse config file
> > > `/usr/pkg/share/gnunet/config.d/ats.conf'
> >
Re: Debugging help needed: gnunet services in a multiuser setup
A look at the dump of ktrace of gnunet-core run as my user makes me suggest that the system user might be putting the socket files in the wrong place for some reason? 1670 1670 gnunet-core MISC mbsoname: [/tmp/gnunet-system-runtime//gnunet-service-core.sock] 1670 1670 gnunet-core NAMI "/tmp/gnunet-system-runtime//gnunet-service-core.sock" 1670 1670 gnunet-core RET connect -1 errno 2 No such file or directory 1670 1670 gnunet-core CALL close(6) 1670 1670 gnunet-core RET close 0 So what I'm asking for here is also a detailed map on how this should look like, if working. Right now system user 'gnunet' has the $HOME in /var/chroot/gnunet and most of the sock files are in there (except for -arm). Nikita Ronja Gillmann transcribed 23K bytes: > Nikita Ronja Gillmann transcribed 23K bytes: > > So my gnunet is mostly working: > > > > Logs for the gnunet user are looking good (as far as I can tell). > > When I su into the gnunet user and execute gnunet-core with a path > > to the config file, I get results. Same happens for -peerinfo. > > gnunet-search works there as well. > > All of this is the gnunet service (system user). > > > > Now here are the issues, for the normal user: > > The gnunetuser service has an issue running stop, the rest-service hangs > > around (but on system shutdown it terminates). > > gnunet-core doesn't display anything. > > gnunet-peerinfo the same. > > gnunet-search doesn't find anything. > > gnunet-publish doesn't publish. > > This is after approximately 14 days or more with this setup. > > > > I'd like to keep the multiuser option for some added local security > > and layouts. > > Do you have any idea how I could fix this? Is there anything obviously > > wrong with the gnunetuser service? > > Does the multiuser setup work at all in your experience? > > > > Does the gnunet normal user require (read?) access to the path > > the system gnunet-arm is running in? At least that's what I read > > from the DEBUG level log of the gnunet-arm as user. > > drwx-- 5 gnunetgnunet1536 Apr 8 12:07 gnunet > > so far, for /var/chroot/gnunet (the gnunet system user). > the only other service (on my system) doing it like this > is tor. unbound gives at least r-x for the other groups. > > > Probably not related as I provide the config file in the service: > > Did the default config move into .config/gnunet/gnunet.conf? > > > > The newest code is at > > https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree;f=gnunet > > > > Thanks. > > > 2022-04-08T13:57:53.073600+0200 gnunet-arm-15439 WARNING GNUnet not > > running, cannot stop the peer > > Starting gnunetuser. > > 2022-04-08T13:57:53.095900+0200 gnunet-arm-586 DEBUG Loading configuration > > from entry point specified as option (/home/nikita/.config/gnunet.conf) > > 2022-04-08T13:57:53.096220+0200 util-586 DEBUG Asked to parse config file > > `/usr/pkg/share/gnunet/config.d/abd.conf' > > 2022-04-08T13:57:53.096301+0200 util-586 DEBUG Deserializing contents of > > file `/usr/pkg/share/gnunet/config.d/abd.conf' > > 2022-04-08T13:57:53.096328+0200 util-586 DEBUG Asked to parse config file > > `/usr/pkg/share/gnunet/config.d/arm.conf' > > 2022-04-08T13:57:53.096357+0200 util-586 DEBUG Deserializing contents of > > file `/usr/pkg/share/gnunet/config.d/arm.conf' > > 2022-04-08T13:57:53.096382+0200 util-586 DEBUG Asked to parse config file > > `/usr/pkg/share/gnunet/config.d/ats.conf' > > 2022-04-08T13:57:53.096407+0200 util-586 DEBUG Deserializing contents of > > file `/usr/pkg/share/gnunet/config.d/ats.conf' > > 2022-04-08T13:57:53.096438+0200 util-586 DEBUG Asked to parse config file > > `/usr/pkg/share/gnunet/config.d/auction.conf' > > 2022-04-08T13:57:53.096465+0200 util-586 DEBUG Deserializing contents of > > file `/usr/pkg/share/gnunet/config.d/auction.conf' > > 2022-04-08T13:57:53.096480+0200 util-586 DEBUG Asked to parse config file > > `/usr/pkg/share/gnunet/config.d/cadet.conf' > > 2022-04-08T13:57:53.096505+0200 util-586 DEBUG Deserializing contents of > > file `/usr/pkg/share/gnunet/config.d/cadet.conf' > > 2022-04-08T13:57:53.096533+0200 util-586 DEBUG Asked to parse config file > > `/usr/pkg/share/gnunet/config.d/communicator-unix.conf' > > 2022-04-08T13:57:53.096559+0200 util-586 DEBUG Deserializing contents of > > file `/usr/pkg/share/gnunet/config.d/communicator-unix.conf' > > 2022-04-08T13:57:53.096577+0200 util-586 DEBUG Asked to parse config file > > `/usr/pkg/share/gnunet/config.d/consensus.conf' > > 2022-04-08T13:57:53.096609+0200
Re: Debugging help needed: gnunet services in a multiuser setup
Nikita Ronja Gillmann transcribed 23K bytes: > So my gnunet is mostly working: > > Logs for the gnunet user are looking good (as far as I can tell). > When I su into the gnunet user and execute gnunet-core with a path > to the config file, I get results. Same happens for -peerinfo. > gnunet-search works there as well. > All of this is the gnunet service (system user). > > Now here are the issues, for the normal user: > The gnunetuser service has an issue running stop, the rest-service hangs > around (but on system shutdown it terminates). > gnunet-core doesn't display anything. > gnunet-peerinfo the same. > gnunet-search doesn't find anything. > gnunet-publish doesn't publish. > This is after approximately 14 days or more with this setup. > > I'd like to keep the multiuser option for some added local security > and layouts. > Do you have any idea how I could fix this? Is there anything obviously > wrong with the gnunetuser service? > Does the multiuser setup work at all in your experience? > > Does the gnunet normal user require (read?) access to the path > the system gnunet-arm is running in? At least that's what I read > from the DEBUG level log of the gnunet-arm as user. drwx-- 5 gnunetgnunet1536 Apr 8 12:07 gnunet so far, for /var/chroot/gnunet (the gnunet system user). the only other service (on my system) doing it like this is tor. unbound gives at least r-x for the other groups. > Probably not related as I provide the config file in the service: > Did the default config move into .config/gnunet/gnunet.conf? > > The newest code is at > https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree;f=gnunet > > Thanks. > 2022-04-08T13:57:53.073600+0200 gnunet-arm-15439 WARNING GNUnet not running, > cannot stop the peer > Starting gnunetuser. > 2022-04-08T13:57:53.095900+0200 gnunet-arm-586 DEBUG Loading configuration > from entry point specified as option (/home/nikita/.config/gnunet.conf) > 2022-04-08T13:57:53.096220+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/abd.conf' > 2022-04-08T13:57:53.096301+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/abd.conf' > 2022-04-08T13:57:53.096328+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/arm.conf' > 2022-04-08T13:57:53.096357+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/arm.conf' > 2022-04-08T13:57:53.096382+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/ats.conf' > 2022-04-08T13:57:53.096407+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/ats.conf' > 2022-04-08T13:57:53.096438+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/auction.conf' > 2022-04-08T13:57:53.096465+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/auction.conf' > 2022-04-08T13:57:53.096480+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/cadet.conf' > 2022-04-08T13:57:53.096505+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/cadet.conf' > 2022-04-08T13:57:53.096533+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/communicator-unix.conf' > 2022-04-08T13:57:53.096559+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/communicator-unix.conf' > 2022-04-08T13:57:53.096577+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/consensus.conf' > 2022-04-08T13:57:53.096609+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/consensus.conf' > 2022-04-08T13:57:53.096634+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/conversation.conf' > 2022-04-08T13:57:53.096694+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/conversation.conf' > 2022-04-08T13:57:53.096722+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/core.conf' > 2022-04-08T13:57:53.096760+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/core.conf' > 2022-04-08T13:57:53.096782+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/datacache.conf' > 2022-04-08T13:57:53.096812+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/config.d/datacache.conf' > 2022-04-08T13:57:53.096832+0200 util-586 DEBUG Asked to parse config file > `/usr/pkg/share/gnunet/config.d/datastore.conf' > 2022-04-08T13:57:53.096874+0200 util-586 DEBUG Deserializing contents of file > `/usr/pkg/share/gnunet/confi
Debugging help needed: gnunet services in a multiuser setup
So my gnunet is mostly working: Logs for the gnunet user are looking good (as far as I can tell). When I su into the gnunet user and execute gnunet-core with a path to the config file, I get results. Same happens for -peerinfo. gnunet-search works there as well. All of this is the gnunet service (system user). Now here are the issues, for the normal user: The gnunetuser service has an issue running stop, the rest-service hangs around (but on system shutdown it terminates). gnunet-core doesn't display anything. gnunet-peerinfo the same. gnunet-search doesn't find anything. gnunet-publish doesn't publish. This is after approximately 14 days or more with this setup. I'd like to keep the multiuser option for some added local security and layouts. Do you have any idea how I could fix this? Is there anything obviously wrong with the gnunetuser service? Does the multiuser setup work at all in your experience? Does the gnunet normal user require (read?) access to the path the system gnunet-arm is running in? At least that's what I read from the DEBUG level log of the gnunet-arm as user. Probably not related as I provide the config file in the service: Did the default config move into .config/gnunet/gnunet.conf? The newest code is at https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree;f=gnunet Thanks.2022-04-08T13:57:53.073600+0200 gnunet-arm-15439 WARNING GNUnet not running, cannot stop the peer Starting gnunetuser. 2022-04-08T13:57:53.095900+0200 gnunet-arm-586 DEBUG Loading configuration from entry point specified as option (/home/nikita/.config/gnunet.conf) 2022-04-08T13:57:53.096220+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/abd.conf' 2022-04-08T13:57:53.096301+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/abd.conf' 2022-04-08T13:57:53.096328+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/arm.conf' 2022-04-08T13:57:53.096357+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/arm.conf' 2022-04-08T13:57:53.096382+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/ats.conf' 2022-04-08T13:57:53.096407+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/ats.conf' 2022-04-08T13:57:53.096438+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/auction.conf' 2022-04-08T13:57:53.096465+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/auction.conf' 2022-04-08T13:57:53.096480+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/cadet.conf' 2022-04-08T13:57:53.096505+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/cadet.conf' 2022-04-08T13:57:53.096533+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/communicator-unix.conf' 2022-04-08T13:57:53.096559+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/communicator-unix.conf' 2022-04-08T13:57:53.096577+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/consensus.conf' 2022-04-08T13:57:53.096609+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/consensus.conf' 2022-04-08T13:57:53.096634+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/conversation.conf' 2022-04-08T13:57:53.096694+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/conversation.conf' 2022-04-08T13:57:53.096722+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/core.conf' 2022-04-08T13:57:53.096760+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/core.conf' 2022-04-08T13:57:53.096782+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/datacache.conf' 2022-04-08T13:57:53.096812+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/datacache.conf' 2022-04-08T13:57:53.096832+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/datastore.conf' 2022-04-08T13:57:53.096874+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/datastore.conf' 2022-04-08T13:57:53.096908+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/dht.conf' 2022-04-08T13:57:53.096947+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/dht.conf' 2022-04-08T13:57:53.096985+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/dhtu.conf' 2022-04-08T13:57:53.097028+0200 util-586 DEBUG Deserializing contents of file `/usr/pkg/share/gnunet/config.d/dhtu.conf' 2022-04-08T13:57:53.097051+0200 util-586 DEBUG Asked to parse config file `/usr/pkg/share/gnunet/config.d/dns.conf' 2022-04-08T13:57:53.097114+0200 util-586 DEBUG Deserializing contents of file
Re: GNUnet Name System not working (as expected)
On 4/8/22 12:29, Nikita Ronja Gillmann wrote: Hi, Tanguy LE CARROUR transcribed 6.2K bytes: Hello GNUnet, I'm not reporting this into the bug tracker (yet), because (good) chances are the problem exists between the chair and keyboard… ``` 2022-04-07T17:14:00.996911+0200 peerstore-sqlite-29500 ERROR Error executing SQL query: attempt to write a readonly database PRAGMA auto_vacuum=INCREMENTAL 2022-04-07T17:14:00.997101+0200 peerstore-sqlite-29500 ERROR `sqlite3_step' failed at plugin_peerstore_sqlite.c:211 with error: attempt to write a readonly database Where is the $HOME of the gnunet user? Is it writeable for you? 2022-04-07T17:14:00.997124+0200 sqlite-29500 ERROR Failed to reset sqlite statement with error: attempt to write a readonly database 2022-04-07T17:14:00.999847+0200 namestore-29495 ERROR Assertion failed at sq_result_helper.c:180. 2022-04-07T17:14:00.999877+0200 namestore-29495 ERROR Assertion failed at plugin_namestore_sqlite.c:537. 2022-04-07T17:14:00.999891+0200 namestore-29495 ERROR Assertion failed at gnunet-service-namestore.c:1949. 2022-04-07T17:14:01.000896+0200 transport-tcp-29503 WARNING Unexpected address length: 24 bytes 2022-04-07T17:14:01.000925+0200 transport-29503 ERROR Assertion failed at gnunet-service-transport_validation.c:902. 2022-04-07T17:14:01.000932+0200 transport-29503 ERROR Address with 24 bytes for plugin tcp and peer DSTJ is malformed 2022-04-07T17:14:01.000938+0200 transport-tcp-29503 WARNING Unexpected address length: 12 bytes 2022-04-07T17:14:01.000942+0200 transport-29503 ERROR Assertion failed at gnunet-service-transport_validation.c:902. 2022-04-07T17:14:01.000947+0200 transport-29503 ERROR Address with 12 bytes for plugin tcp and peer DSTJ is malformed 2022-04-07T17:14:01.001095+0200 transport-tcp-29503 WARNING Unexpected address length: 24 bytes 2022-04-07T17:14:01.001105+0200 transport-29503 ERROR Assertion failed at gnunet-service-transport_validation.c:902. 2022-04-07T17:14:01.001110+0200 transport-29503 ERROR Address with 24 bytes for plugin tcp and peer V8XX is malformed 2022-04-07T17:14:01.001114+0200 transport-tcp-29503 WARNING Unexpected address length: 12 bytes 2022-04-07T17:14:01.001118+0200 transport-29503 ERROR Assertion failed at gnunet-service-transport_validation.c:902. 2022-04-07T17:14:01.001125+0200 transport-29503 ERROR Address with 12 bytes for plugin tcp and peer V8XX is malformed 2022-04-07T17:14:01.005084+0200 nat-29505 ERROR UPnP enabled in configuration, but UPnP client `upnpc` command not found, disabling UPnP I assume that you have upnpc(-mini?) as dependency in the guix package. When you look at the C code in src/nat/ you'll see 2 files which you need to patch for them to work for Guix (same applies for the cases where iptables, ip6tables, and ip binaries are used). The other binaries are in other places, not src/nat/. The alternative is that a gnunet-service (or manually, symlinks creation in those places) makes the binary/binaries available in one of the paths which are tried before resulting in "not found". I'm not sure if taking an environment variable or for example a gnunet config file value for those binaries would be good. at least it would be more flexible, but that's just my 2cts on this topic from memory. 2022-04-07T17:14:01.099784+0200 hostlist-29482 WARNING Download of hostlist from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote key was not OK' 2022-04-07T17:14:02.015851+0200 hostlist-29482 WARNING Download of hostlist from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote key was not OK' ``` On computer_2, the logs contain the following: ``` 2022-04-07T19:18:24.601705+0200 hostlist-2604 WARNING Download of hostlist from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote key was not OK' 2022-04-07T19:18:24.603510+0200 nat-2625 ERROR UPnP enabled in configuration, but UPnP client `upnpc` command not found, disabling UPnP 2022-04-07T19:18:25.597153+0200 hostlist-2604 WARNING Download of hostlist from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote key was not OK' 2022-04-07T19:18:27.597664+0200 hostlist-2604 WARNING Download of hostlist from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote key was not OK' 2022-04-07T19:18:31.628126+0200 transport-tcp-2621 WARNING Unexpected address length: 24 bytes 2022-04-07T19:18:31.628416+0200 transport-2621 ERROR Assertion failed at gnunet-service-transport_validation.c:902. 2022-04-07T19:18:31.628470+0200 transport-2621 ERROR Address with 24 bytes for plugin tcp and peer DSTJ is malformed 2022-04-07T19:18:31.628520+0200 transport-tcp-2621 WARNING Unexpected address length: 12 bytes 2022-04-07T19:18:31.628559+0200 transport-2621 ERROR Assertion failed at gnunet-service-transport_validation.c:902. 2022-04-07T19:18:31.628597+0200 transport-2621 ERROR Address with 12 bytes for plugin tcp and
Re: GNUnet Name System not working (as expected)
Hi, Tanguy LE CARROUR transcribed 6.2K bytes: > Hello GNUnet, > > I'm not reporting this into the bug tracker (yet), because (good) chances > are the problem exists between the chair and keyboard… > > ``` > 2022-04-07T17:14:00.996911+0200 peerstore-sqlite-29500 ERROR Error executing > SQL query: attempt to write a readonly database > PRAGMA auto_vacuum=INCREMENTAL > 2022-04-07T17:14:00.997101+0200 peerstore-sqlite-29500 ERROR `sqlite3_step' > failed at plugin_peerstore_sqlite.c:211 with error: attempt to write a > readonly database Where is the $HOME of the gnunet user? Is it writeable for you? > 2022-04-07T17:14:00.997124+0200 sqlite-29500 ERROR Failed to reset sqlite > statement with error: attempt to write a readonly database > 2022-04-07T17:14:00.999847+0200 namestore-29495 ERROR Assertion failed at > sq_result_helper.c:180. > 2022-04-07T17:14:00.999877+0200 namestore-29495 ERROR Assertion failed at > plugin_namestore_sqlite.c:537. > 2022-04-07T17:14:00.999891+0200 namestore-29495 ERROR Assertion failed at > gnunet-service-namestore.c:1949. > 2022-04-07T17:14:01.000896+0200 transport-tcp-29503 WARNING Unexpected > address length: 24 bytes > 2022-04-07T17:14:01.000925+0200 transport-29503 ERROR Assertion failed at > gnunet-service-transport_validation.c:902. > 2022-04-07T17:14:01.000932+0200 transport-29503 ERROR Address with 24 bytes > for plugin tcp and peer DSTJ is malformed > 2022-04-07T17:14:01.000938+0200 transport-tcp-29503 WARNING Unexpected > address length: 12 bytes > 2022-04-07T17:14:01.000942+0200 transport-29503 ERROR Assertion failed at > gnunet-service-transport_validation.c:902. > 2022-04-07T17:14:01.000947+0200 transport-29503 ERROR Address with 12 bytes > for plugin tcp and peer DSTJ is malformed > 2022-04-07T17:14:01.001095+0200 transport-tcp-29503 WARNING Unexpected > address length: 24 bytes > 2022-04-07T17:14:01.001105+0200 transport-29503 ERROR Assertion failed at > gnunet-service-transport_validation.c:902. > 2022-04-07T17:14:01.001110+0200 transport-29503 ERROR Address with 24 bytes > for plugin tcp and peer V8XX is malformed > 2022-04-07T17:14:01.001114+0200 transport-tcp-29503 WARNING Unexpected > address length: 12 bytes > 2022-04-07T17:14:01.001118+0200 transport-29503 ERROR Assertion failed at > gnunet-service-transport_validation.c:902. > 2022-04-07T17:14:01.001125+0200 transport-29503 ERROR Address with 12 bytes > for plugin tcp and peer V8XX is malformed > 2022-04-07T17:14:01.005084+0200 nat-29505 ERROR UPnP enabled in > configuration, but UPnP client `upnpc` command not found, disabling UPnP I assume that you have upnpc(-mini?) as dependency in the guix package. When you look at the C code in src/nat/ you'll see 2 files which you need to patch for them to work for Guix (same applies for the cases where iptables, ip6tables, and ip binaries are used). > 2022-04-07T17:14:01.099784+0200 hostlist-29482 WARNING Download of hostlist > from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote > key was not OK' > 2022-04-07T17:14:02.015851+0200 hostlist-29482 WARNING Download of hostlist > from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote > key was not OK' > ``` > > On computer_2, the logs contain the following: > > ``` > 2022-04-07T19:18:24.601705+0200 hostlist-2604 WARNING Download of hostlist > from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote > key was not OK' > 2022-04-07T19:18:24.603510+0200 nat-2625 ERROR UPnP enabled in configuration, > but UPnP client `upnpc` command not found, disabling UPnP > 2022-04-07T19:18:25.597153+0200 hostlist-2604 WARNING Download of hostlist > from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote > key was not OK' > 2022-04-07T19:18:27.597664+0200 hostlist-2604 WARNING Download of hostlist > from `https://gnunet.io/hostlist' failed: `SSL peer certificate or SSH remote > key was not OK' > 2022-04-07T19:18:31.628126+0200 transport-tcp-2621 WARNING Unexpected address > length: 24 bytes > 2022-04-07T19:18:31.628416+0200 transport-2621 ERROR Assertion failed at > gnunet-service-transport_validation.c:902. > 2022-04-07T19:18:31.628470+0200 transport-2621 ERROR Address with 24 bytes > for plugin tcp and peer DSTJ is malformed > 2022-04-07T19:18:31.628520+0200 transport-tcp-2621 WARNING Unexpected address > length: 12 bytes > 2022-04-07T19:18:31.628559+0200 transport-2621 ERROR Assertion failed at > gnunet-service-transport_validation.c:902. > 2022-04-07T19:18:31.628597+0200 transport-2621 ERROR Address with 12 bytes > for plugin tcp and peer DSTJ is malformed > 2022-04-07T19:18:31.630577+0200 transport-tcp-2621 WARNING Unexpected address > length: 24 bytes > 2022-04-07T19:18:31.630668+0200 transport-2621 ERROR Assertion failed at > gnunet-service-transport_validation.c:902. > 2022-04-07T19:18:31.630721+0200 transport-2621 ERROR Address with 24 bytes > for plugin tcp and peer V8XX is malformed >
Re: mysql check always fails
Daniel Golle transcribed 0.7K bytes: > Hi Nikita, > > On Fri, Apr 08, 2022 at 09:12:29AM +0200, Nikita Ronja Gillmann wrote: > > Hi, > > > > I have no time to work on a patch for this, but even with the right version > > of mysql(-client) (version => 8.0.24), > > configure.ac generates a configure file which leads to broken C code for > > what applies for my builds (--with-mysql=PRFX). > > I have attached the files. > > Just to confirm your findings: > I've also encountered this problem when building recent GNUnet releases > for OpenWrt and have decided to simply drop the version check (as in > this case I just know the version is recent enough): thanks. I still think that fixing 1 character would be better. last time moved/touched in 2021, and I've seen this error for some versions now as well in pkgsrc: 20ffa0aa54 (Alessio Vanni2021-11-11 00:56:30 +0100 1032) [[include ]], > https://github.com/openwrt/packages/blob/master/net/gnunet/patches/100-remove-mysql-version-check.patch > > > Cheers > > > Daniel >
Re: gnurl CVE applicability
On 4/4/22 17:23, Schanzenbach, Martin wrote: On 4. Apr 2022, at 17:14, Christian Grothoff wrote: On 4/4/22 17:09, Nikita Ronja Gillmann wrote: Regardless, you should be able to build GNUnet against vanilla libcurl these days, so that might be a better way to avoid worrying about this. In the context of pkgsrc, the problem is that I can not enforce a change of setting in curl (for example built against gnutls) for the defaults. Or maybe you can explain how a gnunet built against curl and gnurl would differ these days in terms of functionality and features. Ah, I see. Well, yes, non-gnutls curl is likely still going to cause grief for some parts of GNUnet... Well afair it only does for the gns proxy. So you may simply not install/package that and link against vanilla curl. Thanks. At least that's an additional option argument I can create for gnurl/curl choice. BR
Re: gnurl CVE applicability
On 4/4/22 16:58, Christian Grothoff wrote: I don't see how either is terribly relevant for the (limited) GNUnet use-cases of HTTPS. Users would have to work pretty hard on a very customized curl/GNUnet setup to make themselves theoretically vulnerable --- and even then the impact would seem negligible. Worst I can imagine is a network-level adversary doing a MiTM for every hostlist request to force a peer to bootstrap only against malicious nodes the adversary controls. But such a network-level adversary can likely achieve this almost as well by simply dropping traffic. Thanks! I'll see if I can apply the upstream patches then, even if it's not very likely to be an issue. Regardless, you should be able to build GNUnet against vanilla libcurl these days, so that might be a better way to avoid worrying about this. In the context of pkgsrc, the problem is that I can not enforce a change of setting in curl (for example built against gnutls) for the defaults. Or maybe you can explain how a gnunet built against curl and gnurl would differ these days in terms of functionality and features. On 4/4/22 16:47, Nikita Ronja Gillmann wrote: Hi, finishing the gnunet package for pkgsrc might require merging back the inactive gnurl into the pkgsrc tree from pkgsrc-wip. I've looked at the current CVEs for curl, and I have open questions for 2 of them. Could someone take a look at them and tell me if they apply in the context of how gnunet makes use of gnurl? I guess the 2 CVEs aren't applicable in our context, but I'd like to be sure before I decide if I merge it back or not, or if I let the security team add an CVE to our security db. https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f=gnurl/gnurl-CVEs;h=190a57f1d3e672ae53a1ee8f799ab0068d94b1a0;hb=HEAD https://curl.se/docs/CVE-2021-22924.html https://curl.se/docs/CVE-2021-22890.html Thanks!
gnurl CVE applicability
Hi, finishing the gnunet package for pkgsrc might require merging back the inactive gnurl into the pkgsrc tree from pkgsrc-wip. I've looked at the current CVEs for curl, and I have open questions for 2 of them. Could someone take a look at them and tell me if they apply in the context of how gnunet makes use of gnurl? I guess the 2 CVEs aren't applicable in our context, but I'd like to be sure before I decide if I merge it back or not, or if I let the security team add an CVE to our security db. https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f=gnurl/gnurl-CVEs;h=190a57f1d3e672ae53a1ee8f799ab0068d94b1a0;hb=HEAD https://curl.se/docs/CVE-2021-22924.html https://curl.se/docs/CVE-2021-22890.html Thanks!
Re: compiling gnunet 0.16.3 on openbsd
On 4/1/22 11:50, Mikhail wrote: On Fri, Apr 01, 2022 at 11:22:22AM +0200, Nikita Ronja Gillmann wrote: Mikhail transcribed 77K bytes: On Fri, Apr 01, 2022 at 07:37:49AM +, Schanzenbach, Martin wrote: Yes. The IP DHT underlay implementation is simply not portable. I just commited a fix to not built it for openbsd. Thank you for fixing the issues! Build is successful, full log is inlined - I got some warnings, maybe they will be interesting to the developers. The iptables/ip6tables/ip binary tests are just that, warnings. There's an unresolved bug which means that one helper binary won't work on the *BSDs. I've recently picked this back up and as a solution I am translating the invocations, which takes some time. As I'm a NetBSD dev it might not work fully on OpenBSD, but I try to keep this portable (ipf/ipfw/route in mind). I wasn't clear - I meant compilation warnings, and this strange one: That one can be ignored I think - something about texinfo version supporting this or not and how, if I remember correctly. Even with the warning the manual should display fine. Updating ./version.texi MAKEINFO ./gnunet.info ./gnunet.texi:5: warning: unrecognized encoding name `UTF-8'.
Re: compiling gnunet 0.16.3 on openbsd
Mikhail transcribed 77K bytes: > On Fri, Apr 01, 2022 at 07:37:49AM +, Schanzenbach, Martin wrote: > > Yes. The IP DHT underlay implementation is simply not portable. > > I just commited a fix to not built it for openbsd. > > Thank you for fixing the issues! Build is successful, full log is > inlined - I got some warnings, maybe they will be interesting to the > developers. The iptables/ip6tables/ip binary tests are just that, warnings. There's an unresolved bug which means that one helper binary won't work on the *BSDs. I've recently picked this back up and as a solution I am translating the invocations, which takes some time. As I'm a NetBSD dev it might not work fully on OpenBSD, but I try to keep this portable (ipf/ipfw/route in mind). > $ uname -a > OpenBSD rapi.lab.local 7.1 GENERIC.MP#1605 arm64 > > $ cc -v > OpenBSD clang version 13.0.0 > Target: aarch64-unknown-openbsd7.1 > Thread model: posix > InstalledDir: /usr/bin > > $ AUTOCONF_VERSION=2.71 AUTOMAKE_VERSION=1.16 ./bootstrap > Removing folder 'libltdl'... > Synchronizing submodule url for 'contrib/gana' > recfix --check registry.rec > ../format.sh h.template < registry.rec > gnu_name_system_record_types.h.tmp > cat h.header gnu_name_system_record_types.h.tmp h.footer > > gnu_name_system_record_types.h > rm -f gnu_name_system_record_types.h *.tmp > recfix --check registry.rec > ../format.sh tlds.template < registry.rec > tlds.conf.tmp > cat tlds.header tlds.conf.tmp > tlds.conf > rm -f tlds.conf *.tmp > recfix --check registry.rec > ../format.sh h.template < registry.rec > gnunet_signatures.h.tmp > cat h.header gnunet_signatures.h.tmp h.footer > gnunet_signatures.h > rm -f gnunet_signatures.h *.tmp > Uncrustify not detected, hook not installed. > Please install uncrustify if you plan on doing development > yapf not detected, please install yapf if you plan on contributing python code > checking for libtoolize / libtool... > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'. > libtoolize: copying file `build-aux/ltmain.sh' > libtoolize: putting macros in `m4'. > libtoolize: copying file `m4/libtool.m4' > libtoolize: copying file `m4/ltoptions.m4' > libtoolize: copying file `m4/ltsugar.m4' > libtoolize: copying file `m4/ltversion.m4' > libtoolize: copying file `m4/lt~obsolete.m4' > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and > libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. > misha:/home/misha/work/gnunet:351$ > I-search: > misha:/home/misha/work/gnunet:351$ mutt > misha:/home/misha/work/gnunet:351$ ./configure --with-microhttpd=/usr/local/ > checking build system type... aarch64-unknown-openbsd7.1 > checking host system type... aarch64-unknown-openbsd7.1 > checking target system type... aarch64-unknown-openbsd7.1 > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a race-free mkdir -p... ./build-aux/install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking whether UID '1000' is supported by ustar format... yes > checking whether GID '1000' is supported by ustar format... yes > checking how to create a ustar tar archive... plaintar > checking whether make supports nested variables... (cached) yes > checking for gawk... (cached) awk > checking for gcc... no > checking for cc... cc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether the compiler supports GNU C... yes > checking whether cc accepts -g... yes > checking for cc option to enable C11 features... none needed > checking whether cc understands -c and -o together... yes > checking whether make supports the include directive... yes (GNU style) > checking dependency style of cc... gcc3 > checking whether cc understands -c and -o together... yes > checking whether ln -s works... yes > checking whether make sets $(MAKE)... (cached) yes > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.29.2... yes > checking how to print strings... print -r > checking for a sed that does not truncate output... /usr/bin/sed > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for fgrep... /usr/bin/grep -F > checking for ld used by cc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking the maximum length of command line arguments... 393216 > checking whether the shell understands some XSI constructs...
Re: compiling gnunet 0.16.3 on openbsd
Mikhail transcribed 77K bytes:
> checking for python3 version... 3.9
> checking for python3 platform... openbsd7
> checking for python3 script directory... ${prefix}/lib/python3.9/site-packages
> checking for python3 extension module directory...
> ${exec_prefix}/lib/python3.9/site-packages
I'm fairly positive that 3.9 should work, but I have yet to run the
full test-suite with my pkgsrc build.
> configure: WARNING: NSS plugin will not be build
> checking for extractor.h... no
> GNU libextractor not found, some features disabled
> configure: WARNING: libextractor not found, but various file-sharing
> operations require it
You might have to explicitly point to the directory prefix you
installed LE in, if it's installed.
> configure:
> Detected system
> ===
>
> GNUnet version: 0.16.3-7-ge6a0ea8cf
>
> Host Setup: aarch64-unknown-openbsd7.1
> Install Prefix: /usr/local
> Compiler: cc
> CFLAGS: -fPIC -g -O2 -fno-strict-aliasing
> -Wno-address-of-packed-member -Wno-tautological-constant-out-of-range-compare
> -I/usr/local/include
> CPPFLAGS: -I/usr/local/include
> LDFLAGS: -lc
> LIBS: -lm
> Build Target: openbsd
>
> Default Interface: lo0
>
> sqlite3:yes
> MySQL: no
> PostgreSQL: no
>
> HTTP Client:curl-openssl
> Bluetooth: no
> iptables: no (DNS query interception might not work)
> ifconfig: yes
> UPnPc: no (NAT traversal might not work)
> GnuTLS: yes (with DANE support)
>
> LaTeX: yes
>
> libextractor: no
> libzbar:no
> libpng: no
> libidn: libidn2
> libopus:no (required to build conversation)
> libpulse: no (required to build conversation)
> gstreamer: no (required to build conversation)
>
> Java: no
>
> texi2mdoc: no
> mandoc: yes
>
> GNUnet configuration
>
>
> Transports: tcp udp unix http
> Conversation: no
> Database Backends sqlite
> Experimental Code: no
>
> Texinfo Manual: yes
> Transpiled mdocml Manual: no
>
> configure: WARNING: Please make sure NOW to create a user and group 'gnunet'
> and additionall a group 'gnunetdns'. Make sure that '/var/lib/gnunet' is
> owned (and writable) by user 'gnunet'.
> configure: To do this on this system, run:
> # addgroup gnunetdns
> # adduser --system --disabled-login --home /var/lib/gnunet gnunet
>
> configure: WARNING: Each user of GNUnet should be added to the 'gnunet' group
> configure: To do this on this system, run:
> # adduser USERNAME gnunet
> for each of your users, replacing 'USERNAME' with the respective login name.
> Users may have to login again for the changes to take effect.
> configure: For detailed setup instructions, type 'info gnunet' after the
> installation or visit https://docs.gnunet.org/
If you want to add/revive a port or what you call it for OpenBSD, take
a look at wip/gnunet in pkgsrc (or rather gnunet in pkgsrc-wip). It's
not done yet, minor feature testing and file lists for FreeBSD and
Linux missing, and the rc scripts need some tweaking I can't figure
out on my own so far.
Re: compiling gnunet 0.16.3 on openbsd
Hi,
PK_PKTINFO with a quick search seems to be implemented in NetBSD (turns
up on my system, never ran into this issue) and FreeBSD.
OpenBSD had discussions in 2001, and fast-forward to 2016 it is not
implemented according to the Changelog of their usr/sbin/unbound:
https://github.com/openbsd/src/blob/master/usr.sbin/unbound/doc/Changelog#L4522
Maybe this also holds a solution on how to solve this for gnunet.
On 4/1/22 09:05, Mikhail wrote:
On Thu, Mar 31, 2022 at 06:58:55PM +, Schanzenbach, Martin wrote:
Hi Mikhail,
I just pushed some portability fixes to git master.
I tried in a VM (with gcc, however) and it builds for me now on openbsd.
Can you try again?
It seems to me as if you are missing something in your toolchain.
Maybe libtool? Can you check that you have installed all dependencies?
Yes, latest git started to build fine (clang 13), no 'srcdir' configure
hack is needed, but it failed to compile because of IP_PKTINFO being not
implemented.
I'm not sure what 'dhtu' module is doing, googling gives no answer - is
it possible to disable it?
Making all in dhtu
CC testing_dhtu_cmd_send.lo
CCLD libgnunettestingdhtu.la
CC plugin_dhtu_gnunet.lo
CCLD libgnunet_plugin_dhtu_gnunet.la
CC plugin_dhtu_ip.lo
plugin_dhtu_ip.c:857:37: error: use of undeclared identifier 'IP_PKTINFO'
(cmsg->cmsg_type == IP_PKTINFO),
^
plugin_dhtu_ip.c:860:30: error: use of undeclared identifier 'IP_PKTINFO'
(cmsg->cmsg_type == IP_PKTINFO) )
^
plugin_dhtu_ip.c:862:21: error: invalid application of 'sizeof' to an
incomplete type 'struct in_pktinfo'
if (CMSG_LEN (sizeof (struct in_pktinfo)) ==
^ ~~~
/usr/include/sys/socket.h:546:58: note: expanded from macro 'CMSG_LEN'
#define CMSG_LEN(len) (_ALIGN(sizeof(struct cmsghdr)) + (len))
^~~
plugin_dhtu_ip.c:862:36: note: forward declaration of 'struct in_pktinfo'
if (CMSG_LEN (sizeof (struct in_pktinfo)) ==
^
plugin_dhtu_ip.c:865:27: error: variable has incomplete type 'struct in_pktinfo'
struct in_pktinfo pi;
^
plugin_dhtu_ip.c:862:36: note: forward declaration of 'struct in_pktinfo'
if (CMSG_LEN (sizeof (struct in_pktinfo)) ==
^
plugin_dhtu_ip.c:1033:23: error: use of undeclared identifier 'IP_PKTINFO'
IP_PKTINFO,
^
5 errors generated.
*** Error 1 in src/dhtu (Makefile:896 'plugin_dhtu_ip.lo': @echo " CC "
plugin_dhtu_ip.lo;/bin/sh ../../libtool --silent --tag=CC-...)
*** Error 1 in src (Makefile:569 'all-recursive': @fail=; if (target_option=k; case
${target_option-} in ?) ;; *) echo "am__make_running_...)
*** Error 1 in . (Makefile:651 'all-recursive': @fail=; if (target_option=k; case
${target_option-} in ?) ;; *) echo "am__make_running_wi...)
*** Error 2 in /home/misha/work/gnunet (Makefile:516 'all')
Re: packaging question on gnunet-gtk
Issue locally solved by remembering that I did not add the code to re-bootstrap in the pkgsrc package after the applied patch to configure.ac. Nikita Ronja Gillmann transcribed 2.4K bytes: > The issue is odd: with just --with-extractor pointing to the prefix > of libextractor, I no longer get the gnunet-conversation-gtk file > built. > Same happens with the patch applied. > Both tests done in a clean build environment. > > Nikita Ronja Gillmann transcribed 2.0K bytes: > > Hi Christian, > > > > thanks for looking into this issue! > > > > By the way, I'm very close to merging most of the gnunet packages into > > pkgsrc, > > tested for NetBSD so far, I just need to look into some issue with the user > > servicefile. > > > > On 3/25/22 14:27, Christian Grothoff wrote: > > > Hi Nikita, > > > > > > I've figured it out: gnunet-conversation-gtk was only being built when > > > GNU libextractor was found by configure --- because it was linked > > > against that library. However, that linkage was no longer needed, so I > > > was able to remove the dependency and now it works even without LE. > > > > > > So workaround: --with-extractor=$LE_PREFIX > > > or: update to latest Git ;-) > > > > > > Happy hacking! > > > > > > Christian > > > > > > On 3/21/22 19:34, Nikita Ronja Gillmann wrote: > > > > Hi, > > > > > > > > I've picked the gnunet packages back up for pkgsrc. > > > > One odd thing I observed about gnunet-gtk is that > > > > it does not build the gnunet-conversation-gtk binary, > > > > even if the conditions for it are (as per config logs) > > > > met. > > > > > > > > I don't see anything in my first look at this which makes me > > > > think that src/conversation is set to not build. > > > > > > > > Build transcripts for builds from 0.16.0 tarball attached, > > > > "building" is with a gnunet with conversations submodule, > > > > "building-without" is with a gnunet without conversations submodule. > > > > > > > > > > > > Note: in log file 'building', the text below essentially says that the > > > > expected file (at the end of the build process, during creation of the > > > > package file) is not found: > > > > > > > > pkg_create: can't stat > > > > `/usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk' > > > > => Checking file-check results for gnunet-gtk-0.16.0 > > > > ERROR: > > > > ERROR: The following files are in the PLIST but not in > > > > /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg: > > > > ERROR: > > > > /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk > > > > *** Error code 1 > > > > > > > > PS: please only on-list replies, thanks. I subscribed for the time > > > > being. > > >
Re: packaging question on gnunet-gtk
The issue is odd: with just --with-extractor pointing to the prefix of libextractor, I no longer get the gnunet-conversation-gtk file built. Same happens with the patch applied. Both tests done in a clean build environment. Nikita Ronja Gillmann transcribed 2.0K bytes: > Hi Christian, > > thanks for looking into this issue! > > By the way, I'm very close to merging most of the gnunet packages into > pkgsrc, > tested for NetBSD so far, I just need to look into some issue with the user > servicefile. > > On 3/25/22 14:27, Christian Grothoff wrote: > > Hi Nikita, > > > > I've figured it out: gnunet-conversation-gtk was only being built when > > GNU libextractor was found by configure --- because it was linked > > against that library. However, that linkage was no longer needed, so I > > was able to remove the dependency and now it works even without LE. > > > > So workaround: --with-extractor=$LE_PREFIX > > or: update to latest Git ;-) > > > > Happy hacking! > > > > Christian > > > > On 3/21/22 19:34, Nikita Ronja Gillmann wrote: > > > Hi, > > > > > > I've picked the gnunet packages back up for pkgsrc. > > > One odd thing I observed about gnunet-gtk is that > > > it does not build the gnunet-conversation-gtk binary, > > > even if the conditions for it are (as per config logs) > > > met. > > > > > > I don't see anything in my first look at this which makes me > > > think that src/conversation is set to not build. > > > > > > Build transcripts for builds from 0.16.0 tarball attached, > > > "building" is with a gnunet with conversations submodule, > > > "building-without" is with a gnunet without conversations submodule. > > > > > > > > > Note: in log file 'building', the text below essentially says that the > > > expected file (at the end of the build process, during creation of the > > > package file) is not found: > > > > > > pkg_create: can't stat > > > `/usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk' > > > => Checking file-check results for gnunet-gtk-0.16.0 > > > ERROR: > > > ERROR: The following files are in the PLIST but not in > > > /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg: > > > ERROR: > > > /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk > > > *** Error code 1 > > > > > > PS: please only on-list replies, thanks. I subscribed for the time being. >
Re: packaging question on gnunet-gtk
Hi Christian, thanks for looking into this issue! By the way, I'm very close to merging most of the gnunet packages into pkgsrc, tested for NetBSD so far, I just need to look into some issue with the user servicefile. On 3/25/22 14:27, Christian Grothoff wrote: Hi Nikita, I've figured it out: gnunet-conversation-gtk was only being built when GNU libextractor was found by configure --- because it was linked against that library. However, that linkage was no longer needed, so I was able to remove the dependency and now it works even without LE. So workaround: --with-extractor=$LE_PREFIX or: update to latest Git ;-) Happy hacking! Christian On 3/21/22 19:34, Nikita Ronja Gillmann wrote: Hi, I've picked the gnunet packages back up for pkgsrc. One odd thing I observed about gnunet-gtk is that it does not build the gnunet-conversation-gtk binary, even if the conditions for it are (as per config logs) met. I don't see anything in my first look at this which makes me think that src/conversation is set to not build. Build transcripts for builds from 0.16.0 tarball attached, "building" is with a gnunet with conversations submodule, "building-without" is with a gnunet without conversations submodule. Note: in log file 'building', the text below essentially says that the expected file (at the end of the build process, during creation of the package file) is not found: pkg_create: can't stat `/usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk' => Checking file-check results for gnunet-gtk-0.16.0 ERROR: ERROR: The following files are in the PLIST but not in /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg: ERROR: /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk *** Error code 1 PS: please only on-list replies, thanks. I subscribed for the time being.
