View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005555 | GNUnet | ARM service | public | 2019-02-10 21:09 | 2021-02-28 12:57 |
| Reporter | nikita | Assigned To | Due Date | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | feedback | Resolution | open | ||
| Platform | amd64 | OS | NetBSD | OS Version | CURRENT |
| Product Version | Git master | ||||
| Summary | 0005555: arm: test_gnunet_service_arm fails on netbsd | ||||
| Description | ================================================ gnunet 0.11.0pre66: src/arm/test-suite.log ================================================ # TOTAL: 4 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test_gnunet_service_arm ============================= Feb 10 21:03:38-131511 resolver-29960 WARNING `accept' failed at service.c:843 with error: Resource temporarily unavailable Feb 10 21:03:38-135891 test-gnunet-service-arm-28419 ERROR Failed to resolve our own hostname! Feb 10 21:03:38-136020 test-gnunet-service-arm-28419 ERROR Assertion failed at test_gnunet_service_arm.c:118. Feb 10 21:03:38-136457 resolver-29960 ERROR Assertion failed at gnunet-service-resolver.c:1249. Aborting. Test failed with error code 3 FAIL test_gnunet_service_arm (exit status: 3) | ||||
| Steps To Reproduce | gmake clean; LDFLAGS=-L/usr/pkg/lib ./configure --prefix=/home/ng0/opt gmake su - cd to source directory, gmake install exit PATH=$PATH:/home/ng0/opt/bin GNUNET_PREFIX=/home/ng0/opt gmake check | ||||
| Tags | No tags attached. | ||||
| Did you run 'make install' first? Should this be RC for 0.11.0? | |
| As I wrote above, make install was run before the tests (gmake is gnu make). I don't think this has to be 0.11.0, it can be 0.11.1 or later. Effectively if nothing major changes I can keep testing gnunet 0.11.0 in pkgsrc-wip. Once the testsuite passes I would ask a developer with commit access to move it to pkgsrc. | |
| Let's target 0.12.0 to be on the optimistic side and have enough wiggle and testing room. | |
| Did we not fix this issue? Or at least traced it to a network issue (in IRC)? | |
| if we did, it was many months ago. I don't remember the results of what we looked into. We might have to do it again. | |
| Ok. The problem was that if you execute gethostbyname() or gethostbyname2() and then try to resolve that hostname through DNS the results do not match. This can be an issue with your local DNS router or the local setup of the hostname. Considering that there is also the error "Feb 10 21:03:38-131511 resolver-29960 WARNING `accept' failed at service.c:843 with error: Resource temporarily unavailable" this might also be a different issue. OTOH, this error is an EAGAIN and should not be fatal (hence it is just a warning) as the service probably retries. | |
| Is this still an issue? | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-02-10 21:09 | nikita | New Issue | |
| 2019-02-12 08:23 | Christian Grothoff | Note Added: 0013676 | |
| 2019-02-12 10:46 | nikita | Note Added: 0013678 | |
| 2019-02-12 11:51 | nikita | Target Version | => 0.12.0 |
| 2019-02-12 11:52 | nikita | Note Added: 0013681 | |
| 2019-08-08 17:22 | schanzen | Note Added: 0014775 | |
| 2019-08-08 17:22 | schanzen | Assigned To | => schanzen |
| 2019-08-08 17:22 | schanzen | Status | new => feedback |
| 2019-08-17 09:32 | nikita | Note Added: 0014786 | |
| 2019-08-17 09:32 | nikita | Status | feedback => assigned |
| 2019-08-17 10:04 | schanzen | Note Added: 0014787 | |
| 2019-11-16 17:40 | Christian Grothoff | Target Version | 0.12.0 => |
| 2019-12-20 12:08 | schanzen | Status | assigned => feedback |
| 2019-12-20 12:08 | schanzen | Note Added: 0015196 | |
| 2019-12-20 12:08 | schanzen | Assigned To | schanzen => nikita |
| 2021-02-28 12:34 | schanzen | Assigned To | nikita => schanzen |
| 2021-02-28 12:57 | schanzen | Assigned To | schanzen => |