View Issue Details

IDProjectCategoryView StatusLast Update
0007182GNUnetintegration testspublic2022-10-05 13:51
Reportertanguy Assigned Toschanzen  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Platformx86_64OSGuix SystemOS Versione725b24
Product Version0.16.0 
Target Version0.16.2Fixed in Version0.16.2 
Summary0007182: All tests passing on Guix System
DescriptionDear 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 ReproduceGet 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 InformationI'm attaching all the "test-suite.log" and the "BUILD.log".
TagsNo tags attached.
Attached Files
test-suite.tbz2 (56,476 bytes)
BUILD.log (1,047,828 bytes)

Activities

schanzen

2022-03-04 23:42

administrator   ~0018763

Last edited: 2022-03-04 23:43

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.

schanzen

2022-03-06 19:57

administrator   ~0018769

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)

tanguy

2022-03-07 16:44

reporter   ~0018771

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)
```

schanzen

2022-03-07 17:40

administrator   ~0018774

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 (?)

tanguy

2022-03-07 17:52

reporter   ~0018775

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!

tanguy

2022-03-08 09:47

reporter   ~0018776

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…

schanzen

2022-03-08 09:52

administrator   ~0018777

Ah this is certainly a bug! The substitutions should not happen on autoconf!
I will look into this issue.

tanguy

2022-03-08 11:17

reporter   ~0018778

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.

schanzen

2022-03-08 22:32

administrator   ~0018781

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.

tanguy

2022-03-09 13:45

reporter   ~0018782

> 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!

schanzen

2022-03-09 13:52

administrator   ~0018783

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?

tanguy

2022-03-10 08:02

reporter   ~0018790

>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! :-)

schanzen

2022-03-19 18:11

administrator   ~0018816

Released

Related Changesets

gnunet: master 343177a0

2022-03-05 00:40

schanzen


Details Diff
GNS: Fix including proxy test in make dist. Addresses issue 0007182 Affected Issues
0007182
mod - src/gns/Makefile.am Diff File

Issue History

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