Your message dated Tue, 26 Apr 2011 01:38:22 -0500
with message-id <20110426063822.GE26320@elie>
and subject line Re: cupt: unable to set download client socket timeout: 
Protocol not available
has caused the Debian Bug report #623167,
regarding [hurd] cupt: unable to set download client socket timeout: Protocol 
not available
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
623167: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623167
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.



--- End Message ---
--- Begin Message ---
Version: 2.0.1

Hi Eugene,

Eugene V. Lyubimkin wrote:

> Cupt 2.0.1 has landed to unstable, can you confirm that downloading,
> aside of some number of warnings, works on hurd now?

Yes, the bug is fixed to my taste.  Unfortunately it is replaced by a
different bug.

| # cupt update
| W: an attempt to set wrong list option 'Acquire::gpgv::Options'
| W: unable to set download client socket timeout: Protocol not available
| W: unable to set download client socket timeout: Protocol not available
| W: unable to set download client socket timeout: Protocol not available
| W: unable to set download client socket timeout: Protocol not available
| W: unable to set download client socket timeout: Protocol not available
| Get:1 http://mirrors.kernel.org/debian experimental Release
| Get:2 http://mirrors.kernel.org/debian sid Release
| W: unable to set download client socket timeout: Protocol not available7KiB 
82%]            | 13.1KiB/s | ETA: 1s
| E: internal error: download client: wrong parameter count for download result 
message]      | 14.7KiB/s | ETA: 0s
| E: internal error: download client: wrong parameter count for download result 
message
| E: internal error: download client: wrong parameter count for download result 
message
| E: internal error: download client: wrong parameter count for download result 
message
(hangs)

In another terminal:

| # ps-hurd ax | grep cupt
| root     20238 p5 Sw    0:00.12 cupt update
| root     20244 p5 Sf    0:00.01 cupt update
| root     20363 p7 S     0:00.00 grep cupt

I don't know what the "w" and "f" mean, and the manual does not
say.

This may be a cupt bug or a libc bug; as usual one has to start
somewhere.  If you have a dummy download method lying around for easy
debugging, I'd be happy to start there. :)

Will clone the bug with a separate message.  Thanks.

Regards,
Jonathan


--- End Message ---

Reply via email to