Package: cupt Version: 2.0.0~rc2 Severity: normal Justification: "cupt update" broken on hurd
Hi cupt hackers and hurd porters, On hurd: | # cupt update | W: an attempt to set wrong list option 'Acquire::gpgv::Options' | E: unable to set download client socket timeout: Protocol not available | E: unable to set download client socket timeout: Protocol not available | E: unable to set download client socket timeout: Protocol not available | E: unable to set download client socket timeout: Protocol not available | E: unable to set download client socket timeout: Protocol not available | Fetched 0B in 0s. | E: there were errors while downloading release and index data The cause: cupt calls setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) for an AF_UNIX socket and expects it to succeed rather than returning ENOPROTOOPT. hurd (even upstream "master" as of today) has a stub implementation for S_socket_setopt in pflocal/socket.c which always returns either EOPNOTSUPP or ENOPROTOOPT[*]. This is an option at the socket level, but POSIX does not seem to require support for it (XSH 2.10.16 says: It is implementation-defined whether the SO_RCVTIMEO option can be set. ). I haven't looked carefully into what cupt is doing here. Maybe it would be okay to degrade gracefully to reduced functionality? Alternatively it might be possible to implement the same thing using the ALARM signal. Anyway, thought you might like to know. Regards, Jonathan [*] This looks like a bug. For example, if I understand correctly, getsockopt on SO_RCVTIMEO is supposed to succeed whether setting it is allowed or not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org