(tests guix-download) fails when DNS is bogus

  • Done
  • quality assurance status badge
Details
4 participants
  • Leo Famulari
  • Ludovic Courtès
  • Maxim Cournoyer
  • ng0
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 23 May 2017 18:24
(address . bug-guix@gnu.org)
20170523162431.GB15379@jasmine
The guix-download test includes this snippet:

------
# Make sure it fails here.
if guix download http://does.not/exist
then false; else true; fi
------

Unfortunately, many ISPs (such as T-Mobile) return bogus results for
otherwise unclaimed domain names, causing this test to fail.

Does anyone know if there is some domain that is designed to fail as a
"standard", as http://example.com is intended to be used for examples
of good domains?
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlkkYj8ACgkQJkb6MLrK
fwixsRAAowCZvG4EZxxG9nGCKgmSANAgAbj/1Iq7veLFc6S/MCTTgSDW7hpnQPpy
iOIILkHuKEDdMXbgcadncmdvOXZ0DZMw8ywSPkfkr5vPWr05W8HKIWRatvyYX0kd
bqAyF4SsVa24+ZfOlvy51YADRmweu2d+h+wxp+x2b8UPauW5HgS0IOdEAC57C86j
Zy6rgOirYh7p+FJWnhpVEPqQR9LaZmhUejBV3VZacU5UrMd5QwWnnH6hu5m6RiN6
dU5E7UB0DIFEfYojirFFdMj9zKRIMNeD0mXzFld8j4+q3g+NZhLg15hnOORlYzgS
jUGDO25xDxQORVQaH1KjBqU3XJvg5C7kpDNMGoO7c7za54t4rVndxOlS3w5OCNf8
ck+XNNvqFNgdFiJfJTbar5zrsKBQsDswi2wtcfPg6RqSeFBXnBkrhzLwN+xSpvXZ
I44YkC2jxmOK+DjSNo3u1bFkzVOW8fd90XdO3UtfIYGVh2466ySHSzmh1AM01oom
P22BrPdIgF6ZdbW87DNSyD/uZIRy5y1yRnmGCUtub/pQekF4kxStNOaYaQKRZSnx
8ohlIoFizwKuJAup03j8GzqwXiPS5V5cDgtcrFaypzz99MqHkfF2upSLfJcdEPpu
ajy96H8gK/Y1j1j4N+3nNVRrs6bNLZgjKjMVj6j8PQK+2eFu1AM=
=H/x/
-----END PGP SIGNATURE-----


M
M
Maxim Cournoyer wrote on 23 May 2017 18:47
BC77E34E-40B0-402A-9C85-4223FAB5A8CB@gmail.com
On May 23, 2017 9:24:31 AM PDT, Leo Famulari <leo@famulari.name> wrote:
Toggle quote (15 lines)
>The guix-download test includes this snippet:
>
>------
># Make sure it fails here.
>if guix download http://does.not/exist
>then false; else true; fi
>------
>
>Unfortunately, many ISPs (such as T-Mobile) return bogus results for
>otherwise unclaimed domain names, causing this test to fail.
>
>Does anyone know if there is some domain that is designed to fail as a
>"standard", as <http://example.com> is intended to be used for examples
>of good domains?

Could we simply mock the expected response?

Maxim
N
(name . 27039)(address . 27039@debbugs.gnu.org)
E1dDDHH-0002gK-UV@rmmprod05.runbox
On Tue, 23 May 2017 12:24:31 -0400, Leo Famulari <leo@famulari.name> wrote:

Toggle quote (15 lines)
> The guix-download test includes this snippet:
>
> ------
> # Make sure it fails here.
> if guix download http://does.not/exist
> then false; else true; fi
> ------
>
> Unfortunately, many ISPs (such as T-Mobile) return bogus results for
> otherwise unclaimed domain names, causing this test to fail.
>
> Does anyone know if there is some domain that is designed to fail as a
> "standard", as <http://example.com> is intended to be used for examples
> of good domains?

http://fail.0

fails to resolve with "ping: bad address 'fail.0'. This was run on an OpenNIC connected computer.
L
L
Ludovic Courtès wrote on 23 May 2017 23:03
(name . Leo Famulari)(address . leo@famulari.name)(address . 27039@debbugs.gnu.org)
87shjv70by.fsf@gnu.org
Leo Famulari <leo@famulari.name> skribis:

Toggle quote (11 lines)
> The guix-download test includes this snippet:
>
> ------
> # Make sure it fails here.
> if guix download http://does.not/exist
> then false; else true; fi
> ------
>
> Unfortunately, many ISPs (such as T-Mobile) return bogus results for
> otherwise unclaimed domain names, causing this test to fail.

Yes, this has been reported several times in the past and marked as
“wontfix”. :-)

Toggle quote (4 lines)
> Does anyone know if there is some domain that is designed to fail as a
> "standard", as <http://example.com> is intended to be used for examples
> of good domains?

There’s an RFC defining example.org et al. These domain names are
guaranteed to exist, so we’d be testing something different; also, I
don’t know if the RFC defines pages guaranteed to be 404, for instance.

Ludo’.
L
L
Ludovic Courtès wrote on 4 Jun 2017 23:04
control message for bug #27039
(address . control@debbugs.gnu.org)
87vaobh3bt.fsf@gnu.org
tags 27039 wontfix
close 27039
?
Your comment

This issue is archived.

To comment on this conversation send an email to 27039@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 27039
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch