#946178 mercurial: FTBFS on hurd-i386: Testsuite failures

Package:
src:mercurial
Source:
mercurial
Submitter:
Paul Sonnenschein
Date:
2019-12-07 20:39:12 UTC
Severity:
important
#946178#5
Date:
2019-12-04 20:45:14 UTC
From:
To:
Hello,

mercurial fails to build from source on hurd-i386 due to five failing
tests.

Of these tests, four fail due to unexpected error numbers.
This should be fixed in mercurial, because error numbers are not
standardized.

The test-http-bad-server.t fails due to an unexpected behaviour of
local sockets in the Hurd. This seems to be a bug in the Hurd itself
(pflocal specifically), being in violation of the POSIX specification
Issue 6 and newer.
This could be fixed by
 * Fixing the Hurd itself
 * Making the test more permissive
 * Blacklisting the test

The attached patch replaces the error number in the offending tests
with a * glob.

Thanks!


Excerpts from build log [0]:

(Analogous failures exist for test-largefiles-misc.t, test-lfs-serve-
access.t and test-repair-strip.t)


[0]:
https://buildd.debian.org/status/fetch.php?pkg=mercurial&arch=hurd-i386&ver=5.2-1&stamp=1573130161&raw=0
#946178#10
Date:
2019-12-04 22:26:21 UTC
From:
To:
Hello,

Paul Sonnenschein, le mer. 04 déc. 2019 21:45:14 +0100, a ecrit:

Which violation is happening here?

Samuel
#946178#15
Date:
2019-12-05 06:43:10 UTC
From:
To:
Hello,

Am Mittwoch, den 04.12.2019, 23:26 +0100 schrieb Samuel Thibault:

According to POSIX, both read and recv shall set errno to ECONNRESET if
"[a] read was attempted on a socket and the connection was forcibly
closed by its peer." As far as I can tell, pflocal will never return
ECONNRESET.

After further study however, I do no longer believe that this is the
reason of the observed test failure, since connect already should fail.

I now have no idea why this test is failing.

Paul
#946178#20
Date:
2019-12-06 14:42:22 UTC
From:
To:
Thanks, forwarded upstream as https://phab.mercurial-scm.org/D7556

Cheers,
Julien
#946178#25
Date:
2019-12-06 18:54:08 UTC
From:
To:
Cheers,
Julien
#946178#30
Date:
2019-12-07 20:27:30 UTC
From:
To:
Hello,

Paul Sonnenschein, le jeu. 05 déc. 2019 07:43:10 +0100, a ecrit:

Yes. The question is what "forcibly" means. On TCP connections, when the
peer sends a RST, ECONNRESET makes complete sense: the stream is not
finished, it was really interrupted. What would be the equivalent for a
local socket?

I played a bit with Linux, and found the attached case to be returning
ECONNRESET, but it's not clear to me why that precise case should do
this. In such case OpenBSD returns 0.

Samuel