Libstore file transfer unit tests fail when IPv6 is disabled in the kernel #564
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#564
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the bug
When IPv6 is disabled on a system building Lix, several tests in
lix/tests/unit/libstore/filetransfer.cc
fail to run:Steps To Reproduce
boot.kernelParams = [ "ipv6.disable=1" ];
.Expected behavior
Tests do not fail.
nix --version
outputnix (Lix, like Nix) 2.91.0
Additional context
filetransfer.cc
uses an IPv6 listener; can this be an IPv4 listener instead?This is a really hard one, most of us are using IPv6 all the time and if we could disable IPv4, we would do it. I am inclined to mark as wontfix, if you have a need of a kernel without a working IPv6 stack, consider not running the Lix tests as well and just build it.
Mm, alright. Was using Lix on a box that has a bunch of custom routing stuff and just turned off IPv6 entirely since I wasn't using it, suppose I can turn it back on and just configure it to drop all packets.
Aside--if you are okay with me swapping this to use 127.0.0.1 instead of [::1] for just this test, I've got a changeset prepared
Ideally, we would like to use only IPv6 in our tests except for IPv4 specifics behaviors, thank you for that change set, but we would prefer to keep it that way.
Thank you for your understanding!
Yep, no problem! Thanks for all your hard work!