Hi, On 2011-04-17 19:29, Jonathan Nieder wrote: > 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?
Honestly I did not expect there will be a system where it fails, it turns I was wrong :) Yes, the functionality is not critical, it's an additional check against download methods (which could be also be written by third parties). I just committed a one-line fix to turn this into a warning. Depending on the view of porters/bug reporter, this bug, after this fix is released, may downgrade to either 'minor', 'wishlist' or 'closed'. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
