Re: Trying to run a Mumble Server
Hello, Samuel Thibault, le Sat 21 Sep 2013 16:20:33 +0200, a écrit : Yes. SOCK_CLOEXEC is not currently supported Well, it is supposed to; see what I wrote in http://news.gmane.org/find-root.php?message_id=%3C87r4d6khvr.fsf%40kepler.schwinge.homeip.net%3E. Just to follow-up in this thread as well: I've just commited that to debian's glibc. Samuel Thibault, le Sat 21 Sep 2013 15:59:28 +0200, a écrit : Since I've added the SOCK_CLOEXEC patch to the debian glibc, it'll get fixed, glibc has been uploaded, version 2.17-93. It also contains an implementation of pthread_atfork(), which is needed by libpkcs11-helper1, used by openvpn. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130923130710.gs5...@type.bordeaux.inria.fr
Re: Trying to run a Mumble Server
Thomas Schwinge, le Thu 19 Sep 2013 15:16:30 +0200, a écrit : Hi! On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org wrote: Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit : I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) Yes. SOCK_CLOEXEC is not currently supported Well, it is supposed to; see what I wrote in http://news.gmane.org/find-root.php?message_id=%3C87r4d6khvr.fsf%40kepler.schwinge.homeip.net%3E. Just to follow-up in this thread as well: I've just commited that to debian's glibc. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130921142033.gn30...@type.youpi.perso.aquilenet.fr
Re: Trying to run a Mumble Server
On Thu, 2013-09-19 at 23:12 +0200, Jens Mühlenhoff wrote: Am 19.09.2013 05:52, schrieb Svante Signell: In the Qt case you can make it a one-liner: Change if (fd != -1 || errno != EINVAL) to if (fd != -1 || !(errno == ENOSYS || errno == EINVAL)) as already used for accept4 on line 122 You meant EPROTOTYPE instead of ENOSYS? Yes, of course. I just tried that and the Mumble Server is now working fine with IPv4. I'll report this upstream. Good! -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1379657940.29261.29.ca...@g3620.my.own.domain
Re: Trying to run a Mumble Server
Hi! On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org wrote: Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit : I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) Yes. SOCK_CLOEXEC is not currently supported Well, it is supposed to; see what I wrote in http://news.gmane.org/find-root.php?message_id=%3C87r4d6khvr.fsf%40kepler.schwinge.homeip.net%3E. Svante, did you have a look what is wrong, what happened to these patches so that they no longer work? Grüße, Thomas pgpUNd3OcI40i.pgp Description: PGP signature
Re: Trying to run a Mumble Server
On Thu, 2013-09-19 at 15:16 +0200, Thomas Schwinge wrote: Hi! On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org wrote: Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit : I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) Yes. SOCK_CLOEXEC is not currently supported Well, it is supposed to; see what I wrote in http://news.gmane.org/find-root.php?message_id=%3C87r4d6khvr.fsf%40kepler.schwinge.homeip.net%3E. Svante, did you have a look what is wrong, what happened to these patches so that they no longer work? Well, dbus upstream is now taking care of the EPROTOYPE is returned (and glib2.0). Where the patches from Thomas five years ago are I have no idea where to find. Debian glibc or upstream libc? See my reply to the above mail. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1379597641.5825.112.ca...@s1499.it.kth.se
Re: Trying to run a Mumble Server
Thomas Schwinge, le Thu 19 Sep 2013 15:16:30 +0200, a écrit : On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org wrote: Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit : I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) Yes. SOCK_CLOEXEC is not currently supported Well, it is supposed to; see what I wrote in http://news.gmane.org/find-root.php?message_id=%3C87r4d6khvr.fsf%40kepler.schwinge.homeip.net%3E. That's not in the Debian glibc. I can commit that. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130919134028.gc5...@type.youpi.perso.aquilenet.fr
Re: Trying to run a Mumble Server
Am 19.09.2013 05:52, schrieb Svante Signell: In the Qt case you can make it a one-liner: Change if (fd != -1 || errno != EINVAL) to if (fd != -1 || !(errno == ENOSYS || errno == EINVAL)) as already used for accept4 on line 122 You meant EPROTOTYPE instead of ENOSYS? I just tried that and the Mumble Server is now working fine with IPv4. I'll report this upstream. -- Mit freundlichen Grüßen Jens Mühlenhoff -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523b68d3.20...@gmx.de
Re: Trying to run a Mumble Server
Am 19.09.2013 23:12, schrieb Jens Mühlenhoff: I'll report this upstream. https://bugreports.qt-project.org/browse/QTBUG-33572 -- Mit freundlichen Grüßen Jens Mühlenhoff -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523b70e7.5050...@gmx.de
Re: Trying to run a Mumble Server
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit : is returning errno = 1073741865 which is ESPIPE?! Err, no, it's 0x4029, i.e. _HURD_ERRNO(41), i.e. EPROTOTYPE. I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks the caller is inventing a new proto type numbered 4194305. You would get the same behavior on Linux when building the application against a recent libc, but running it against an old kernel without SOCK_CLOEXEC support. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130919000627.gv5...@type.youpi.perso.aquilenet.fr
Re: Trying to run a Mumble Server
Am 19.09.2013 02:06, schrieb Samuel Thibault: Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit : is returning errno = 1073741865 which is ESPIPE?! Err, no, it's 0x4029, i.e. _HURD_ERRNO(41), i.e. EPROTOTYPE. Yes of course, I mixed up hexadecimal and decimal, it's getting late here ;). I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks the caller is inventing a new proto type numbered 4194305. You would get the same behavior on Linux when building the application against a recent libc, but running it against an old kernel without SOCK_CLOEXEC support. Ok, so libc is reporting a feature the Hurd doesn't support. I was wondering why the Qt code is using (fd != -1 || errno != EINVAL) to determine success? Since errno is EPROTOTYPE it doesn't even try to call socket without SOCK_CLOEXEC which would be done on (errno == EINVAL). -- Mit freundlichen Grüßen Jens Mühlenhoff -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523a42d4.7050...@gmx.de
Re: Trying to run a Mumble Server
Jens Mühlenhoff, le Thu 19 Sep 2013 02:18:28 +0200, a écrit : Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks the caller is inventing a new proto type numbered 4194305. You would get the same behavior on Linux when building the application against a recent libc, but running it against an old kernel without SOCK_CLOEXEC support. Ok, so libc is reporting a feature the Hurd doesn't support. Yes, just like in the Linux case. I was wondering why the Qt code is using (fd != -1 || errno != EINVAL) to determine success? Because Linux probably returns EINVAL instead of EPROTOTYPE in such an error case. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130919003334.gy5...@type.youpi.perso.aquilenet.fr
Re: Trying to run a Mumble Server
On Thu, 2013-09-19 at 02:33 +0200, Samuel Thibault wrote: Jens Mühlenhoff, le Thu 19 Sep 2013 02:18:28 +0200, a écrit : Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks the caller is inventing a new proto type numbered 4194305. You would get the same behavior on Linux when building the application against a recent libc, but running it against an old kernel without SOCK_CLOEXEC support. Ok, so libc is reporting a feature the Hurd doesn't support. Yes, just like in the Linux case. I was wondering why the Qt code is using (fd != -1 || errno != EINVAL) to determine success? Because Linux probably returns EINVAL instead of EPROTOTYPE in such an error case. You can solve this problem with a code construct like (from a pending upstream glib2.0 patch. Recent dbus upstream patches use the same technique): #ifdef SOCK_CLOEXEC fd = socket (domain, type | SOCK_CLOEXEC, protocol); if (fd != -1) return fd; /* It's possible that libc has SOCK_CLOEXEC but the kernel does not */ if (fd 0 (errno == EINVAL || errno == EPROTOTYPE)) #endif fd = socket (domain, type, protocol); if (fd 0) ... Maybe file a bug report to Qt upstream? -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1379561898.12906.70.ca...@g3620.my.own.domain
Re: Trying to run a Mumble Server
On Thu, 2013-09-19 at 05:38 +0200, Svante Signell wrote: I was wondering why the Qt code is using (fd != -1 || errno != EINVAL) to determine success? Because Linux probably returns EINVAL instead of EPROTOTYPE in such an error case. You can solve this problem with a code construct like (from a pending upstream glib2.0 patch. Recent dbus upstream patches use the same technique): In the Qt case you can make it a one-liner: Change if (fd != -1 || errno != EINVAL) to if (fd != -1 || !(errno == ENOSYS || errno == EINVAL)) as already used for accept4 on line 122 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1379562730.12906.78.ca...@g3620.my.own.domain
