View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007182 | GNUnet | integration tests | public | 2022-03-02 14:17 | 2022-10-05 13:51 |
Reporter | tanguy | Assigned To | schanzen | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | x86_64 | OS | Guix System | OS Version | e725b24 |
Product Version | 0.16.0 | ||||
Target Version | 0.16.2 | Fixed in Version | 0.16.2 | ||
Summary | 0007182: All tests passing on Guix System | ||||
Description | Dear GNUnet, Sorry, it took me longer than I expected, but, eventually, I found some time to udpate GNUnet package definition in Guix. Chance or coincidence, GNUnet version 0.16.0 was released the week after I started working on 0.15.3. So, I decided to drop all the patches we had (mostly to skip failing tests), and start from (almost) scratch [1]. The good: - all the tests are passing! (I guess issue 0006114 can be closed) - once installed, I can `gnunet-arm -s` and `gnunet-core` shows some peer connected! - I try the section "Name resolution using GNS on the command line" describe on the "use" page [2] and everything went well! I don't (yet) have a second host to test name resolution, but that's a good starting point. The bad: - even though all tests pass (see attachment), the make commands returns 2 [3] which is seen as a failure by the Guix build system. - `gnunet-arm -e` does not kill the service!? It hangs forever. I haven't investigated yet, but kill the components one by one. Hope my small contribution is useful! And thanks for you work! -- Tanguy [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54036 [2]: https://www.gnunet.org/en/use.html [3]: make fails with the following log ``` […] error: in phase 'check': uncaught exception: %exception #<&invoke-error program: "make" arguments: ("check") exit-status: 2 term-signal: #f stop-signal: #f> phase `check' failed after 4791.0 seconds command "make" "check" failed with status 2 ``` So I cannot (yet) have GNUnet 0.16.0 integrated into master | ||||
Steps To Reproduce | Get latest Guix sources: https://guix.gnu.org/cookbook/en/guix-cookbook.html#Direct-checkout-hacking Apply GNUnet 0.16.0 patch: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54036 Build: $ ./pre-inst-env guix build --keep-failed gnunet | ||||
Additional Information | I'm attaching all the "test-suite.log" and the "BUILD.log". | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
|
I just released 0.16.1 and did not catch this issue here :( Yes, the tarball is missing the test_proxy.sh script and that is why make check fails. Maybe you can patch it back in for the package? Otherwise, wait for 0.16.2. Regarding the gnunet-arm -e issue: That needs some more investigation. Atm I cannot reproduce this. |
|
Hi. In order to close this bug can you try https://buildbot.gnunet.org/artifacts/gnunet-0.16.1-3-g1f240bd13.tar.gz for the make bug and then check which services hang on "gnunet-arm -e" by investigating (e.g. ps aux | grep gnunet) |
|
Hi schanzen, Thanks for taking the time to look into it! I used the provided archive, but the check phase still fails with: ``` error: in phase 'check': uncaught exception: %exception #<&invoke-error program: "make" arguments: ("check") exit-status: 2 term-signal: #f stop-signal: #f> phase `check' failed after 4353.1 seconds command "make" "check" failed with status 2 ``` The build folder contains the `test_proxy.sh` file as expected and all the `test-suite.log` contain `# FAIL: 0`. I'm attaching the new build log. I'm not sure what to look for because everything seem to be either skipped or successful. Regarding my `gnunet-arm -e`… seems like it's not relevant anymore! All the services stop when I `gnunet-arm -s` them. And I can see some peers, so I'm looking forward for 0.16.x to be merged into Guix master! :-) ``` $ gnunet-core Mon Mar 07 16:35:36 2022: connection established Y924 (timeout in 299 s) ``` |
|
Well the DHT tests seem to fail: ============================================================================ Testsuite summary for gnunet 0.16.1-3-g1f240bd13 ============================================================================ # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See src/dht/test-suite.log Please report to bug-gnunet@gnu.org ============================================================================ make[4]: *** [Makefile:1429: test-suite.log] Error 1 make[4]: Leaving directory '/tmp/guix-build-gnunet-0.16.1.drv-0/gnunet-0.16.1-3-g1f240bd13/src/dht' make[3]: *** [Makefile:1537: check-TESTS] Error 2 make[3]: Leaving directory '/tmp/guix-build-gnunet-0.16.1.drv-0/gnunet-0.16.1-3-g1f240bd13/src/dht' make[2]: *** [Makefile:1653: check-am] Error 2 make[2]: Leaving directory '/tmp/guix-build-gnunet-0.16.1.drv-0/gnunet-0.16.1-3-g1f240bd13/src/dht' make[1]: *** [Makefile:545: check-recursive] Error 1 make[1]: Leaving directory '/tmp/guix-build-gnunet-0.16.1.drv-0/gnunet-0.16.1-3-g1f240bd13/src' make: *** [Makefile:626: check-recursive] Error 1 So I would need to look into the "src/dht/test-suite.log" file to see what makes this script fail. It is a bit odd as it did not fail before (?) |
|
My bad!! "all the `test-suite.log` contain `# FAIL: 0`" … but one! Sorry! … I'll investigate because it seems that it's on my side! |
|
Hi schanzen, The problem comes from `src/dht/test_dht_tools.py`. In Guix, we substitute binary paths in scripts. I was replacing `/usr/bin/python` with the actual Python path (somewhere under `/gnu/store`) to make the script work. The archive you provided me with contains a `src/dht/test_dht_tools.py` with a different path (`/home/buildbot/bb-worker/sandbox/bin/python`) so the substitution fails and so does the test. I've fixed the problem and I'm running the test suite… |
|
Ah this is certainly a bug! The substitutions should not happen on autoconf! I will look into this issue. |
|
Good news is that the `test_dht_tools.py` problem has been fixed! Bad news is that, now, I have a different test failing!? ```console $ fd test-suite /tmp/guix-build-gnunet-0.16.1.drv-0 | xargs ag -v "# FAIL: 0" -l /tmp/guix-build-gnunet-0.16.1.drv-0/gnunet-0.16.1-3-g1f240bd13/src/namestore/test-suite.log $ cat /tmp/guix-build-gnunet-0.16.1.drv-0/gnunet-0.16.1-3-g1f240bd13/src/namestore/test-suite.log ============================================================== gnunet 0.16.1-3-g1f240bd13: src/namestore/test-suite.log ============================================================== # TOTAL: 40 # PASS: 12 # SKIP: 27 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test_namestore_api_lookup_public_sqlite ============================================= 2022-03-08T10:07:35.437491+0000 test-namestore-api-4688 ERROR Assertion failed at test_namestore_api_lookup_public.c:111. Aborting. FAIL test_namestore_api_lookup_public_sqlite (exit status: 134) # The rest of the file contains SKIP tests ``` Could it be a random failure? Or a hardware dependent one? Because I'm on a different computer than yesterday. |
|
Well, is it a random failure on your side? I tried a few times here and it did not fail once :( For example, it could be a random failure related to the expiration of the record which is set in the test. But it could be a lot of things if it fails always. |
|
> Well, is it a random failure on your side? :-) … good question! I could not reproduce yesterday, because the tests take too long on my computer at home! > I tried a few times here and it did not fail once :( And I tried twice today at work, and… it's alive!! \o/ I mean, it's a success! Both times, all the tests passed! I'll try again running the test suite at home. Could it be a problem with running the tests on a computer with not enough horsepower?! So, now, I can either create a package for 0.16.1 and manually add the missing `test_proxy.sh`, or wait for the 0.16.2. What do you think? Is it scheduled to be released anytime soon? Anyway, thanks again for your help! |
|
0.16.2 is coming soon. It would be great if you could investigate the error on your system and then reopen another bug report. In general, next time maybe split your report if you have two different issues. For example, is the "service not stopping" issue still present from the OP? |
|
>0.16.2 is coming soon. Looking forward to it! >It would be great if you could investigate the error on your system and then reopen another bug report. I'll try with version 0.16.2 and open a new ticket if the problem is still happening. > In general, next time maybe split your report if you have two different issues. Sorry, my bad, I will! :-) |
|
Released |
Date Modified | Username | Field | Change |
---|---|---|---|
2022-03-02 14:17 | tanguy | New Issue | |
2022-03-02 14:17 | tanguy | File Added: test-suite.tbz2 | |
2022-03-02 14:17 | tanguy | File Added: BUILD.log | |
2022-03-04 23:40 | schanzen | Changeset attached | => gnunet master 343177a0 |
2022-03-04 23:40 | schanzen | Target Version | => 0.16.2 |
2022-03-04 23:42 | schanzen | Assigned To | => schanzen |
2022-03-04 23:42 | schanzen | Status | new => confirmed |
2022-03-04 23:42 | schanzen | Note Added: 0018763 | |
2022-03-04 23:43 | schanzen | Note Edited: 0018763 | |
2022-03-06 19:57 | schanzen | Note Added: 0018769 | |
2022-03-07 16:44 | tanguy | Note Added: 0018771 | |
2022-03-07 16:44 | tanguy | File Added: 4nvrn46d7r87jviwbwzci9c6mfcdcm-gnunet-0.16.1.drv.gz | |
2022-03-07 17:40 | schanzen | Note Added: 0018774 | |
2022-03-07 17:52 | tanguy | Note Added: 0018775 | |
2022-03-08 09:47 | tanguy | Note Added: 0018776 | |
2022-03-08 09:52 | schanzen | Note Added: 0018777 | |
2022-03-08 11:17 | tanguy | Note Added: 0018778 | |
2022-03-08 22:32 | schanzen | Note Added: 0018781 | |
2022-03-09 13:45 | tanguy | Note Added: 0018782 | |
2022-03-09 13:52 | schanzen | Note Added: 0018783 | |
2022-03-10 08:02 | tanguy | Note Added: 0018790 | |
2022-03-10 23:53 | schanzen | Fixed in Version | => 0.16.2 |
2022-03-10 23:53 | schanzen | Status | confirmed => resolved |
2022-03-10 23:53 | schanzen | Resolution | open => fixed |
2022-03-19 18:11 | schanzen | Note Added: 0018816 | |
2022-03-19 18:11 | schanzen | Status | resolved => closed |
2022-10-05 13:51 | schanzen | Changeset attached | => gnunet master 343177a0 |