Bug 1258940 - perl-Log-Dispatch >= 2.47 causes other modules to fail
Summary: perl-Log-Dispatch >= 2.47 causes other modules to fail
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-Log-Dispatch
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ralf Corsepius
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-01 14:37 UTC by Emmanuel Seyman
Modified: 2015-09-18 18:47 UTC (History)
4 users (show)

Fixed In Version: 2.50-1.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-11 17:22:19 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CPAN 106823 0 None None None Never
Red Hat Bugzilla 1258920 0 unspecified CLOSED perl-Log-Dispatch-Config-1.04-10.fc24 FTBFS: tests fail 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1259392 0 unspecified CLOSED perl-MooseX-LogDispatch-1.2002-12.fc24 FTBFS: test fail with recent perl-Log-Dispatch 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1259396 0 unspecified CLOSED perl-MooseX-LazyLogDispatch-0.02-18.fc24 FTBFS: tests fail with recent perl-Log-Dispatch 2021-02-22 00:41:40 UTC

Internal Links: 1258920 1259392 1259396

Description Emmanuel Seyman 2015-09-01 14:37:25 UTC
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 17:42:25 UTC
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 08:50:28 UTC
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 09:12:22 UTC
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 12:30:36 UTC
Ticket #106823 has been filed on rt.cpan.org .

Comment 5 Ralf Corsepius 2015-09-02 12:40:09 UTC
(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 13:03:52 UTC
(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 07:41:13 UTC
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 10:38:58 UTC
(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 11:02:48 UTC
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 12:23:44 UTC
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 13:01:12 UTC
(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 06:53:11 UTC
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 07:29:49 UTC
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 07:33:56 UTC
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 17:22:18 UTC
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 18:48:27 UTC
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 18:47:46 UTC
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.