Bug 1563208 - perl-IO-Async-0.72 is available
Summary: perl-IO-Async-0.72 is available
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-IO-Async
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Emmanuel Seyman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-03 12:17 UTC by Upstream Release Monitoring
Modified: 2018-04-11 08:10 UTC (History)
4 users (show)

Fixed In Version: perl-IO-Async-0.72-2.fc29
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-11 07:47:06 UTC
Type: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
CPAN 114376 None None None 2018-04-11 08:10:23 UTC

Description Upstream Release Monitoring 2018-04-03 12:17:13 UTC
Latest upstream release: 0.72
Current version/release in rawhide: 0.71-5.fc28
URL: http://search.cpan.org/dist/IO-Async

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.

Based on the information from anitya:  https://release-monitoring.org/project/7999/

Comment 1 Emmanuel Seyman 2018-04-08 20:18:01 UTC
This fails to build against rawhide. I'm seeing errors like the following:
http://www.cpantesters.org/cpan/report/9f4359d6-38b1-11e8-9a96-3b1e7347484a

Comment 2 Petr Pisar 2018-04-09 12:04:12 UTC
I cannot reproduce it locally. Does it happen in Koji only?

Comment 3 Emmanuel Seyman 2018-04-09 13:06:11 UTC
Interesting. This builds in koji but not in mock.

Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=26265832
Mock: http://people.parinux.org/~seyman/fedora/result/

Comment 4 Petr Pisar 2018-04-09 13:56:11 UTC
The test tries to resolve TCP/localhost:www. Maybe the mock Koji is older and the newer local mock has broken /etc/hosts. Or it tries to resolve using /etc/resolv.conf that is properly blocked in Koji, but the new Mock discards the packets instead of rejecting them.

Comment 5 Petr Pisar 2018-04-09 15:38:30 UTC
Running in local mock:

# perl -Ilib t/50resolver.t 
ok 1 - '$loop->resolver' isa 'IO::Async::Resolver'
ok 2 - '$future' isa 'Future'
ok 3 - getpwuid from future
ok 4 - getpwuid
ok 5 - getpwuid via $loop->resolve
ok 6 - getpwnam
ok 7 - getprotobyname
ok 8 - getprotobynumber
ok 9 - getaddrinfo_array - resolved
ok 10 - getaddrinfo_array - resolved addresses
ok 11 - getaddrinfo_hash - resolved
ok 12 - getaddrinfo_hash - resolved addresses
ok 13 - $resolver->getaddrinfo - resolved
ok 14 - $resolver->getaddrinfo - resolved addresses
ok 15 - '$future for $resolver->getaddrinfo' isa 'Future'
ok 16 - $resolver->getaddrinfo - resolved addresses
ok 17 - $resolver->getaddrinfo on numeric host/service is synchronous
ok 18 - $resolver->getaddrinfo resolved addresses synchronously
ok 19 - $resolver->getaddrinfo on numeric host/no service is synchronous
ok 20 - $resolver->getaddrinfo resolved addresses synchronously with no service
ok 21 - $resolver->getaddrinfo passive - resolved synchronously
ok 22 - $resolver->getaddrinfo passive - resolved addresses
ok 23 - '$future for $resolver->getaddrinfo numerical' isa 'Future'
ok 24 - $resolver->getaddrinfo resolved addresses synchronously

Here is hangs. And then it spits out:

Nothing was ready after 10 second wait; called at lib/IO/Async/Test.pm line 214
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 24.

This hang is at t/50resolver.t:327 on:

    skip "Resolver has an answer for $missinghost", 1 if gethostbyname( $missinghost );

then the error about 10-second wait is from subsequent command:

    my $future = wait_for_future $resolver->getaddrinfo(
       host     => $missinghost,
       service  => "80",
       socktype => SOCK_STREAM,
    );

So the test tries to resolve nonexistent domain name and after a 40-second timeout in glibc resolver, the wait_for_future dies after 10 seconds with the error message.

If I comment out the "skip" test, it still dies after 10 seconds. It looks like the $resolver has 10-second timeout and the test expect a negative answer from a glibc resolved comes sooner. Sooner that glibc-in-mock's 40 seconds.

Comment 6 Petr Pisar 2018-04-09 16:14:48 UTC
This makes the test to pass:

diff --git a/t/50resolver.t b/t/50resolver.t
index 7047b9d..587eb21 100644
--- a/t/50resolver.t
+++ b/t/50resolver.t
@@ -326,11 +326,13 @@ my $missinghost = "TbK4jM2M0OS.lm57DWIyu4i";
 SKIP: {
     skip "Resolver has an answer for $missinghost", 1 if gethostbyname( $missinghost );
 
-    my $future = wait_for_future $resolver->getaddrinfo(
+    my $future = $resolver->getaddrinfo(
        host     => $missinghost,
        service  => "80",
        socktype => SOCK_STREAM,
+       timeout => 60,
     );
+    wait_for { $future->is_ready } timeout => 60;
 
     ok( $future->failure, '$future failed for missing host' );
     is( ( $future->failure )[1], "resolve", '->failure [1] gives resolve' );

Maybe one could measure the "skip" command delay and use that period instead of the hard-coded 60 seconds. But if a resolver cached missed, and the cache expired, the measure would be unreliable.

Nevertheless I will need this patch to apply because the current code will fail in my weekly rebuilds.

Comment 7 Emmanuel Seyman 2018-04-11 07:47:06 UTC
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1068750


Note You need to log in before you can comment on or make changes to this bug.