Bug#623167: cupt: unable to set download client socket timeout: Protocol not available

[Jonathan Nieder <jrnieder@gmail.com>]

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.