Description of problem: For a short while, we've been seeing a number of perl modules FTBFS. These include perl-Log-Dispatch-Config, perl-MooseX-LogDispatch and perl-MooseX-LazyLogDispatch. The one thing they all have in common is that they share a common parent, perl-Log-Dispatch. As an experiment, I tried to rebuild perl-MooseX-LogDispatch while updating perl-LogDispatch and it started FTBFS-ing when I updated perl-LogDispatch from 2.46 to 2.47. Neither 2.48 nor 2.49 fixed things. Version-Release number of selected component (if applicable): 2.48-1 (but this started with 2.47) How reproducible: always Additional info: I'll file a bug report on rt.cpan.org later today.
I can reproduce this issue and believe to have identified the commit to blame. Reverting the commit below lets perl-Log-Dispatch-Config's testsuite succeed, again: https://github.com/houseabsolute/Log-Dispatch/commit/b92533ceaf813a2b237ab8ec52380b2d6ff72325#diff-9526e99d501c3c7adce70bc84c30ac1d I haven't tried to furtherly investigate, but I am inclined to believe this change in Log::Display may expose utf8 issues with the packages listed above.
That's because the commit logs into STDERR's file descriptor. It logged into perl's STDERR handle before. For example Log-Dispatch-Config test ties a scalar variable to the STDERR object in order to redirect the logging I/O into the variable. As a result of the commit, the log messages are printed to /dev/stderr instead of into the $err scalar tied to the STDERR object, and the test fail. While I can fix Log-Dispatch-Config's tests (even Log-Dispatch's tests were changed in the commit) because the Log::Dispatch::Config is just a simple wrapper around Log::Dispatch constructor, the Log-Dispatch's behavior will remain changed and other code using the module possibly affected. There is Log-Dispatch's CPAN RT#106605 supposedly fixed in 2.49, but this still does not fix this bug.
Because the change is documented as: +- Add a utf8 flag for Log::Dispatch::Screen. If this is true, then it sets the + ":encoding(UTF-8)" flag on the handle it uses for output (without affecting + STDOUT or STDERR elsewhere). Suggested by Ivan Baidakou. I believe logging to an independent file handle was an intentional change. Therefore I think upstream will not go back.
Ticket #106823 has been filed on rt.cpan.org .
(In reply to Emmanuel Seyman from comment #4) > Ticket #106823 has been filed on rt.cpan.org . If what Petr wrote in comments #2 and #3 applies (which I tend to agree to), then I'm inclined to believe the failing modules are subject to an unintentional incompatibility and thus would need to be updated.
(In reply to Ralf Corsepius from comment #5) > > If what Petr wrote in comments #2 and #3 applies (which I tend to agree to), JFTR, I agree that Petr is right and that all the other modules are wrong but I'ld like to hear back from the Log-Dispatch maintainers first.
Log-Dispatch 2.50 has been released reverting the behaviour: https://metacpan.org/source/DROLSKY/Log-Dispatch-2.50/Changes#L5 Ralf, the ball's in your court.
(In reply to Emmanuel Seyman from comment #7) > Log-Dispatch 2.50 has been released reverting the behaviour: > https://metacpan.org/source/DROLSKY/Log-Dispatch-2.50/Changes#L5 Wow, this surprizes me. I had expected a decision into the opposite direction. The reversion will requires careful testing of all depending packages ;) > Ralf, the ball's in your court. OK, I'll try to push updates, ASAP. Formally take this bug.
The fc23 build failed. Seems as if somebody has screwed up perl-ExtUtils-MakeMaker in fc23: ... DEBUG util.py:377: Error: Package: perl-ExtUtils-MakeMaker-7.04-346.fc23.noarch (build) DEBUG util.py:377: Requires: perl(ExtUtils::Command) >= 1.16 ...
I retired perl-ExtUtils-Command in F24, but faulty fedpkg tool blocked it in F23 too. Unblocking <https://fedorahosted.org/rel-eng/ticket/6242> was requested.
(In reply to Petr Pisar from comment #10) > I retired perl-ExtUtils-Command in F24, but faulty fedpkg tool blocked it in > F23 too. Unblocking <https://fedorahosted.org/rel-eng/ticket/6242> was > requested. Thanks for the info. To my surprize, a subsequent build ca. 20-30 later succeeded. No idea if this was thanks to your action or if bodhi/koji/repos are such kind of broken, building has become a lottery - I guess it's the latter ;)
perl-Log-Dispatch-2.50-1.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update perl-Log-Dispatch'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14961
perl-Log-Dispatch-2.50-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update perl-Log-Dispatch'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14960
perl-Log-Dispatch-2.50-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update perl-Log-Dispatch'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14962
perl-Log-Dispatch-2.50-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
perl-Log-Dispatch-2.50-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
perl-Log-Dispatch-2.50-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.