Bug 1258940 - perl-Log-Dispatch >= 2.47 causes other modules to fail
perl-Log-Dispatch >= 2.47 causes other modules to fail
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: perl-Log-Dispatch (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-01 10:37 EDT by Emmanuel Seyman
Modified: 2015-09-18 14:47 EDT (History)
4 users (show)

See Also:
Fixed In Version: 2.50-1.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-11 13:22:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
CPAN 106823 None None None Never

  None (edit)
Description Emmanuel Seyman 2015-09-01 10:37:25 EDT
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.
Comment 1 Ralf Corsepius 2015-09-01 13:42:25 EDT
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.
Comment 2 Petr Pisar 2015-09-02 04:50:28 EDT
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.
Comment 3 Petr Pisar 2015-09-02 05:12:22 EDT
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.
Comment 4 Emmanuel Seyman 2015-09-02 08:30:36 EDT
Ticket #106823 has been filed on rt.cpan.org .
Comment 5 Ralf Corsepius 2015-09-02 08:40:09 EDT
(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.
Comment 6 Emmanuel Seyman 2015-09-02 09:03:52 EDT
(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.
Comment 7 Emmanuel Seyman 2015-09-03 03:41:13 EDT
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.
Comment 8 Ralf Corsepius 2015-09-03 06:38:58 EDT
(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.
Comment 9 Ralf Corsepius 2015-09-03 07:02:48 EDT
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
...
Comment 10 Petr Pisar 2015-09-03 08:23:44 EDT
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.
Comment 11 Ralf Corsepius 2015-09-03 09:01:12 EDT
(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 ;)
Comment 12 Fedora Update System 2015-09-04 02:53:11 EDT
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
Comment 13 Fedora Update System 2015-09-04 03:29:49 EDT
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
Comment 14 Fedora Update System 2015-09-04 03:33:56 EDT
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
Comment 15 Fedora Update System 2015-09-11 13:22:18 EDT
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.
Comment 16 Fedora Update System 2015-09-11 14:48:27 EDT
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.
Comment 17 Fedora Update System 2015-09-18 14:47:46 EDT
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.

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