> Bone Baboon via Bug reports for GNU Guix writes: >> I have reported this to the inetutils bug mailing list and asked if the >> inetutils test suite could be modified so that syslogd.sh does not fail >> if IPv6 is disabled. > > I received this response on the inetutils mailing list: > >> Hi. Thanks for the report. Could you investigate if the >> tests/runtime-ipv6.c program return appropriately? It is supposed to >> check wether the runtime system supports IPv6 or not, and should detect >> this properly on your system (or there is a bug in the self-test code >> elsewhere). >> >> Looking at the code, I don't think a getaddrinfo-lookup is sufficient, >> the code probably need to attempt to listen to a socket too, in order to >> fully test wether IPv6 is disabled globally or not. > > I looked for tests/runtime-ipv6.c in the inetutils's build tree. I > could not find it. I looked up the current version of inetutils which > is 2.0. Guix has 1.9.4 of inetutils packaged. > > Based on the response I received on the inetutils mailing list it sounds > like updating the inetutils package to 2.0 may resolve this failing > test.
On the inetutils mailing list it was suggested that I try inetutils 2.0 on the core-updates branch. I can successfully build inetutils 2.0 from the core-updates branch even with IPv6 disabled. What is the purpose of the core-updates branch? If inetutils follows semantic version numbering then that would suggest a breaking change to the inetutils API moving from 1.9.4 to 2.0. Can the Guix master branch provide inetutils 2.0 instead of 1.9.4? How can I use a package definition from core-updates with guix build or in a system configuration if it is not available on Guix's master branch? What are the reasons I might not want to use a package from the core-updates branch?