Description of problem: svn cannot access any remote server because it passes an invalid argument to the socket() syscall: [...] connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("65.19.174.2")}, 28) = 0 sendto(4, "Z\334\1\0\0\1\0\0\0\0\0\0\3svn\5gnome\3org\0\0\1\0\1"..., 31, MSG_NOSIGNAL, NULL, 0) = 31 recvfrom(4, "Z\334\201\200\0\1\0\1\0\0\0\0\3svn\5gnome\3org\0\0\1\0\1\300\f\0\1\0\1\0\1P\234\0\4[\275]\3"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("65.19.174.2")}, [16]) = 47 socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument) svn: OPTIONS of 'http://svn.gnome.org/svn/hippo-canvas/trunk': could not connect to server (http://svn.gnome.org) The Fedora 10 version of svn is working fine on a different VM on the same physical host and git is working fine on the same VM. Version-Release number of selected component (if applicable): subversion-1.5.6-3.x86_64 How reproducible: Always Steps to Reproduce: 1. svn co http://svn.gnome.org/svn/hippo-canvas/trunk 2. 3. Actual results: svn: OPTIONS of 'http://svn.gnome.org/svn/hippo-canvas/trunk': could not connect to server (http://svn.gnome.org) Expected results: Check out hippo-canvas. Additional info:
So I take it here that you're running the F11 userspace on a non-F11 kernel?
Actually an even older kernel since it's a Xen VM: Linux version 2.6.21.7-3.fc8xen (mockbuild.redhat.com) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Thu Mar 20 14:58:12 EDT 2008
Yeah, that'll fail. Not sure how much of this kind of thing we intend to support, since it requires lots of workarounds.
Thanks for the information! Though I'm puzzled about why a regular user space application like SVN needs a recent kernel, we will intensify our tries to get moved to a machine with a more recent Xen (so we can use later kernels).
(In reply to comment #3) > Yeah, that'll fail. Not sure how much of this kind of thing we intend to > support, since it requires lots of workarounds. What's the minimum kernel version that would fix this bug? We can also easily install a 2.6.25 xen image.
Created attachment 346503 [details] runtime detection of SOCK_CLOEXEC Recently happened on my DebXO install (Linux 2.6.25) as well, installing a newer version of libneon with this patch fixed it, so it might fix this one as well (the symptoms are the same, but I've not tried it out).
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm running into this as well, in a chroot that I've just upgraded to F-11. I have very little control over the kernel that runs on the actual root. Any chance the provided patch could be installed and an update issued to fix this problem?
neon-0.28.5-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/neon-0.28.5-1.fc11
Please test out this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=113661 and leave feedback via the Fedora Update System link above.
And thanks for the patch, by the way, Sascha - I used a different fix upstream in the end.
With the new version it works like a charm, thanks! I'm not the author of the patch, though, just took it from the Debian package. From the header of the patch: ## 01_runtime_detect_sock_cloexec.dpatch by <root.org.hu> Might have been written by the Debian maintainer ("Laszlo Boszormenyi (GCS) <gcs>").
Ah, yes, Laszlo had submitted something similar upstream.
neon-0.28.5-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update neon'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7680
neon-0.28.5-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.