Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 87033
Status: resolved
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: paul [...] city-fan.org
Cc: ribasushi [...] leporine.io
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.4006
Fixed in: (no value)



Subject: t/manifypods_with_utf8.t fails with podlators 2.0.x
The t/manifypods_with_utf8.t test uses the utf8 option of Pod::Man, which was introduced in podlators 2.1.0 (Pod::Man 2.17). Prior to that, non-ASCII characters got escaped, so the test suite fails: $ ./Build test t/00-compile.t ................. ok t/PL_files.t ................... ok t/actions/installdeps.t ........ ok t/actions/manifest_skip.t ...... ok t/add_property.t ............... ok t/add_property_array.t ......... ok t/add_property_hash.t .......... ok t/basic.t ...................... ok t/bundle_inc.t ................. skipped: inc_bundling_support feature is not enabled t/compat.t ..................... ok t/compat/exit.t ................ ok t/debug.t ...................... ok t/destinations.t ............... ok t/ext.t ........................ ok t/extend.t ..................... ok t/files.t ...................... ok t/help.t ....................... ok t/install.t .................... ok t/install_extra_target.t ....... ok t/manifypods.t ................. ok # Failed test 'POD should contain special characters' # at t/manifypods_with_utf8.t line 62. # '.\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.28) # .\" # .\" Standard preamble: # .\" ======================================================================== # .de Sh \" Subsection heading # .br # .if t .Sp # .ne 5 # .PP # \fB\\$1\fR # .PP # .. # .de Sp \" Vertical space (when we can't use .PP) # .if t .sp .5v # .if n .sp # .. # .de Vb \" Begin verbatim text # .ft CW # .nf # .ne \\$1 # .. # .de Ve \" End verbatim text # .ft R # .fi # .. # .\" Set up some character translations and predefined strings. \*(-- will # .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left # .\" double quote, and \*(R" will give a right double quote. \*(C+ will # .\" give a nicer C++. Capital omega is used to do unbreakable dashes and # .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, # .\" nothing in troff, for use with C<>. # .tr \(*W- # .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' # .ie n \{\ # . ds -- \(*W- # . ds PI pi # . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch # . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch # . ds L" "" # . ds R" "" # . ds C` "" # . ds C' "" # 'br\} # .el\{\ # . ds -- \|\(em\| # . ds PI \(*p # . ds L" `` # . ds R" '' # 'br\} # .\" # .\" Escape single quotes in literal strings from groff's Unicode transform. # .ie \n(.g .ds Aq \(aq # .el .ds Aq ' # .\" # .\" If the F register is turned on, we'll generate index entries on stderr for # .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index # .\" entries marked with X<> in POD. Of course, you'll have to process the # .\" output yourself in some meaningful fashion. # .ie \nF \{\ # . de IX # . tm Index:\\$1\t\\n%\t"\\$2" # .. # . nr % 0 # . rr F # .\} # .el \{\ # . de IX # .. # .\} # .\" # .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). # .\" Fear. Run. Save yourself. No user-serviceable parts. # . \" fudge factors for nroff and troff # .if n \{\ # . ds #H 0 # . ds #V .8m # . ds #F .3m # . ds #[ \f1 # . ds #] \fP # .\} # .if t \{\ # . ds #H ((1u-(\\\\n(.fu%2u))*.13m) # . ds #V .6m # . ds #F 0 # . ds #[ \& # . ds #] \& # .\} # . \" simple accents for nroff and troff # .if n \{\ # . ds ' \& # . ds ` \& # . ds ^ \& # . ds , \& # . ds ~ ~ # . ds / # .\} # .if t \{\ # . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" # . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' # . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' # . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' # . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' # . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' # .\} # . \" troff and (daisy-wheel) nroff accents # .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' # .ds 8 \h'\*(#H'\(*b\h'-\*(#H' # .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] # .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' # .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' # .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] # .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] # .ds ae a\h'-(\w'a'u*4/10)'e # .ds Ae A\h'-(\w'A'u*4/10)'E # . \" corrections for vroff # .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' # .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' # . \" for low resolution devices (crt and lpr) # .if \n(.H>23 .if \n(.V>19 \ # \{\ # . ds : e # . ds 8 ss # . ds o a # . ds d- d\h'-1'\(ga # . ds D- D\h'-1'\(hy # . ds th \o'bp' # . ds Th \o'LP' # . ds ae ae # . ds Ae AE # .\} # .rm #[ #] #H #V #F C # .\" ======================================================================== # .\" # .IX Title "Simple::PodWithUtf8 3" # .TH Simple::PodWithUtf8 3 "2013-07-18" "perl v5.10.0" "User Contributed Perl Documentation" # .\" For nroff, turn off justification. Always turn off hyphenation; it makes # .\" way too many mistakes in technical documents. # .if n .ad l # .nh # .SH "NAME" # Simple::PodWithUtf8 \- POD with some (c\*, a\*' a\*` o\*^) special chars # ' # doesn't match '(?-xism: \(� � � �\) )' t/manifypods_with_utf8.t ....... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests # Looks like you failed 1 test of 1. t/metadata.t ................... ok t/metadata2.t .................. ok t/mymeta.t ..................... ok t/new_from_context.t ........... ok t/notes.t ...................... ok t/par.t ........................ ok t/parents.t .................... ok t/perl_mb_opt.t ................ ok t/pod_parser.t ................. ok t/ppm.t ........................ ok t/properties/dist_suffix.t ..... ok t/properties/license.t ......... ok t/properties/module_name.t ..... ok t/properties/needs_compiler.t .. ok t/properties/release_status.t .. ok t/properties/requires.t ........ ok t/properties/share_dir.t ....... ok t/resume.t ..................... ok t/runthrough.t ................. ok t/sample.t ..................... ok t/script_dist.t ................ ok t/signature.t .................. ok t/test_file_exts.t ............. ok t/test_type.t .................. ok t/test_types.t ................. ok t/tilde.t ...................... ok t/unit_run_test_harness.t ...... ok t/use_tap_harness.t ............ ok t/versions.t ................... ok t/write_default_maniskip.t ..... ok t/xs.t ......................... ok Test Summary Report ------------------- t/manifypods_with_utf8.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=52, Tests=1131, 47 wallclock secs ( 0.32 usr 0.07 sys + 39.18 cusr 5.51 csys = 45.08 CPU) Result: FAIL Failed 1/52 test programs. 1/1131 subtests failed. The test suite also manages to pass with podlators < 2.00 (Pod::Man 1.x), where no translation happened so the UTF8 characters in the test got passed straight through. Perhaps this test could be skipped if we have 2 <= Pod::Man <= 2.16 ?
Subject: Re: [rt.cpan.org #87033] t/manifypods_with_utf8.t fails with podlators 2.0.x
Date: Fri, 19 Jul 2013 00:06:10 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Leon Timmermans <fawaka [...] gmail.com>
On Thu, Jul 18, 2013 at 11:27 PM, paul@city-fan.org via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> The t/manifypods_with_utf8.t test uses the utf8 option of Pod::Man, which was introduced in podlators 2.1.0 (Pod::Man 2.17). > > Prior to that, non-ASCII characters got escaped, so the test suite fails: > > > The test suite also manages to pass with podlators < 2.00 (Pod::Man 1.x), where no translation happened so the UTF8 characters in the test got passed straight through. > > Perhaps this test could be skipped if we have 2 <= Pod::Man <= 2.16 ?
Or we just depend on Pod::Man 2.16. It was included in perl 5.10.0, so it's not like it'd be an extra dependency for most people. Leon
From: paul [...] city-fan.org
On Thu Jul 18 18:06:45 2013, fawaka@gmail.com wrote: Show quoted text
> On Thu, Jul 18, 2013 at 11:27 PM, paul@city-fan.org via RT > <bug-Module-Build@rt.cpan.org> wrote:
> > The t/manifypods_with_utf8.t test uses the utf8 option of Pod::Man,
> which was introduced in podlators 2.1.0 (Pod::Man 2.17).
> > > > Prior to that, non-ASCII characters got escaped, so the test suite
> fails:
> > > > > > The test suite also manages to pass with podlators < 2.00 (Pod::Man
> 1.x), where no translation happened so the UTF8 characters in the test > got passed straight through.
> > > > Perhaps this test could be skipped if we have 2 <= Pod::Man <= 2.16
> ? > > Or we just depend on Pod::Man 2.16. It was included in perl 5.10.0, so > it's not like it'd be an extra dependency for most people.
It would have to be 2.17 (2.16 is the last version that fails). Whether you want to do that depends on how much back-compatibility you want for Module::Build, which is still by lots of modules that might want to support older perls than 5.10.1. I can currently make a Module::Build package for an OS all the way back to Red Hat Enterprise :Linux 4 (Perl 5.8.5) without replacing any modules that are included in its shipped perl package, and it would be a shame I think if that was no longer the case.
Subject: Re: [rt.cpan.org #87033] t/manifypods_with_utf8.t fails with podlators 2.0.x
Date: Fri, 19 Jul 2013 12:41:24 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Leon Timmermans <leont [...] cpan.org>
On Fri, Jul 19, 2013 at 9:06 AM, paul@city-fan.org via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> It would have to be 2.17 (2.16 is the last version that fails). Whether you want to do that depends on how much back-compatibility you want for Module::Build, which is still by lots of modules that might want to support older perls than 5.10.1.
Requiring 2.17 doesn't break Module::Build on older releases, it just means they have an extra dependency when upgrading. Show quoted text
> I can currently make a Module::Build package for an OS all the way back to Red Hat Enterprise :Linux 4 (Perl 5.8.5) without replacing any modules that are included in its shipped perl package, and it would be a shame I think if that was no longer the case.
Module::Build already has dependencies that aren't shipped with RHEL 4 (or 5 for that matter), and even if it did that's not our concern. I'm willing to support outdated versions of operating systems, but I'm not optimizing for their comfort. Leon
From: paul [...] city-fan.org
On Fri Jul 19 06:42:01 2013, LEONT wrote: Show quoted text
> On Fri, Jul 19, 2013 at 9:06 AM, paul@city-fan.org via RT > <bug-Module-Build@rt.cpan.org> wrote:
> > It would have to be 2.17 (2.16 is the last version that fails).
> Whether you want to do that depends on how much back-compatibility > you want for Module::Build, which is still by lots of modules that > might want to support older perls than 5.10.1. > > Requiring 2.17 doesn't break Module::Build on older releases, it just > means they have an extra dependency when upgrading. >
> > I can currently make a Module::Build package for an OS all the way
> back to Red Hat Enterprise :Linux 4 (Perl 5.8.5) without replacing > any modules that are included in its shipped perl package, and it > would be a shame I think if that was no longer the case. > > Module::Build already has dependencies that aren't shipped with RHEL 4 > (or 5 for that matter), and even if it did that's not our concern. I'm > willing to support outdated versions of operating systems, but I'm not > optimizing for their comfort.
Indeed; the difference with podlators is that it's bundled with the main perl package on all current RHEL releases (probably not for the forthcoming EL-7 though), so updating that cleanly (i.e. with an rpm package and without fiddling with @INC) means replacing the vendor's main perl package, which might be a step too far for RHEL users. In the meantime I've added a very small patch to my local Module::Build package to skip the affected test (no need to touch the module itself) if the Pod::Man version is between 2 and 2.16 inclusive. I wouldn't have thought that was a big deal to include upstream but obviously that's your decision and not mine, and I can hold on to the patch and keep applying it in future if you decide to go the way of bumping the dependency.
Subject: Re: [rt.cpan.org #87033] t/manifypods_with_utf8.t fails with podlators 2.0.x
Date: Fri, 19 Jul 2013 13:58:32 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Leon Timmermans <leont [...] cpan.org>
On Fri, Jul 19, 2013 at 1:11 PM, paul@city-fan.org via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> Indeed; the difference with podlators is that it's bundled with the main perl package on all current RHEL releases (probably not for the forthcoming EL-7 though), so updating that cleanly (i.e. with an rpm package and without fiddling with @INC) means replacing the vendor's main perl package, which might be a step too far for RHEL users.
If you create a Pod::Man package that installs to site_perl, everything should still work fine. This is exactly why perl has 3 different install locations ;-) Leon
From: paul [...] city-fan.org
On Fri Jul 19 07:59:12 2013, LEONT wrote: Show quoted text
> On Fri, Jul 19, 2013 at 1:11 PM, paul@city-fan.org via RT > <bug-Module-Build@rt.cpan.org> wrote:
> > Indeed; the difference with podlators is that it's bundled with the
> main perl package on all current RHEL releases (probably not for > the forthcoming EL-7 though), so updating that cleanly (i.e. with > an rpm package and without fiddling with @INC) means replacing the > vendor's main perl package, which might be a step too far for RHEL > users. > > If you create a Pod::Man package that installs to site_perl, > everything should still work fine. This is exactly why perl has 3 > different install locations ;-)
In theory that works fine (and indeed does in RHEL 5 onwards) but RHEL 4 suffers from an @INC ordering problem (https://bugzilla.redhat.com/show_bug.cgi?id=124443) in that the core perl directory is ahead of the site perl directory in @INC, making overriding core perl modules nigh-on impossible in RHEL 4. Paul.
On 2013-07-19 05:31:39, paul@city-fan.org wrote: Show quoted text
> In theory that works fine (and indeed does in RHEL 5 onwards) but RHEL > 4 suffers from an @INC ordering problem > (https://bugzilla.redhat.com/show_bug.cgi?id=124443) in that the core > perl directory is ahead of the site perl directory in @INC, making > overriding core perl modules nigh-on impossible in RHEL 4.
"making overriding core perl modules nigh-on impossible in RHEL 4" --> so don't do that! :)
On Fri Jul 19 08:31:39 2013, paul@city-fan.org wrote: Show quoted text
> On Fri Jul 19 07:59:12 2013, LEONT wrote:
> > On Fri, Jul 19, 2013 at 1:11 PM, paul@city-fan.org via RT > > <bug-Module-Build@rt.cpan.org> wrote:
> > > Indeed; the difference with podlators is that it's bundled with the
> > main perl package on all current RHEL releases (probably not for > > the forthcoming EL-7 though), so updating that cleanly (i.e. with > > an rpm package and without fiddling with @INC) means replacing the > > vendor's main perl package, which might be a step too far for RHEL > > users. > > > > If you create a Pod::Man package that installs to site_perl, > > everything should still work fine. This is exactly why perl has 3 > > different install locations ;-)
> > In theory that works fine (and indeed does in RHEL 5 onwards) but RHEL > 4 suffers from an @INC ordering problem > (https://bugzilla.redhat.com/show_bug.cgi?id=124443) in that the core > perl directory is ahead of the site perl directory in @INC, making > overriding core perl modules nigh-on impossible in RHEL 4. > > Paul.
I'm marking this ticket as resolved as it passes its tests fine with the dependency. I'd advise you to just skip this test on RHEL4. Things should still work the way they always did for modules that don't use UTF-8, and if they do there's nothing I can do for you for modules that do anyway. Leon
On Wed Jun 04 13:34:39 2014, ETHER wrote: Show quoted text
> On 2013-07-19 05:31:39, paul@city-fan.org wrote: > > "making overriding core perl modules nigh-on impossible in RHEL 4" --> > so don't do that! :)
Paul's point is that if we increase the required version of a core module higher than what's available in core on RHEL 4, then we've essentially made M::B non-installable on RHEL 4. Just making sure the implications are understood - it's one thing to force someone to upgrade a module, it's another thing to shut out a whole platform that's still pretty common in the wild. The workaround for a user would be to create another library location and set their PERL5LIB accordingly; I think RHEL is at least sane enough that PERL5LIB comes before both the core & site lib dirs.