From @andk

git bisect

commit a49b10d
Author​: Brian Fraser <fraserbn@​gmail.com>
Date​: Sun Sep 1 20​:41​:26 2013 -0300

  toke.c, scan_ident()​: use PEEKSPACE() to skip over whitespace.

diagnostics

http​://www.cpantesters.org/cpan/report/8121d6e4-206f-11e3-8321-e2dca0a565e3
http​://www.cpantesters.org/cpan/report/8a7d994e-2092-11e3-a5fc-4c00a1a565e3
http​://www.cpantesters.org/cpan/report/938f1694-2096-11e3-8a39-9e01a1a565e3

Also affected​: FREW/DBIx-Class-DeploymentHandler-0.002207.tar.gz

perl -V

Summary of my perl5 (revision 5 version 19 subversion 4) configuration​:
  Commit id​: a49b10d
  Platform​:
  osname=linux, osvers=3.10-2-amd64, archname=x86_64-linux-ld
  uname='linux k83 3.10-2-amd64 #1 smp debian 3.10.7-1 (2013-08-17) x86_64 gnulinux '
  config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.19.3-653-ga49b10d/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.8.1', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8
  alignbytes=16, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
  libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.17'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
  PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
  PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT
  USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LONG_DOUBLE
  USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Sep 18 2013 23​:28​:14
  @​INC​:
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.3-653-ga49b10d/127e/lib/site_perl/5.19.4/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.3-653-ga49b10d/127e/lib/site_perl/5.19.4
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.3-653-ga49b10d/127e/lib/5.19.4/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.3-653-ga49b10d/127e/lib/5.19.4
  .

--
andreas

From @cpansprout

On Wed Sep 18 23​:26​:50 2013, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

git bisect
----------
commit a49b10d
Author​: Brian Fraser <fraserbn@​gmail.com>
Date​: Sun Sep 1 20​:41​:26 2013 -0300

toke\.c\, scan\_ident\(\)​: use PEEKSPACE\(\) to skip over whitespace\.

diagnostics
-----------
http​://www.cpantesters.org/cpan/report/8121d6e4-206f-11e3-8321-
e2dca0a565e3
http​://www.cpantesters.org/cpan/report/8a7d994e-2092-11e3-a5fc-
4c00a1a565e3
http​://www.cpantesters.org/cpan/report/938f1694-2096-11e3-8a39-
9e01a1a565e3

Also affected​: FREW/DBIx-Class-DeploymentHandler-0.002207.tar.gz

Aha! So *nobody* can touch the lexer without breaking things. :-)

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From @Hugmeir

On Thu, Sep 19, 2013 at 3​:26 AM, Andreas J. Koenig via RT <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by (Andreas J. Koenig)
# Please include the string​: [perl #119889]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=119889 >

git bisect
----------
commit a49b10d
Author​: Brian Fraser <fraserbn@​gmail.com>
Date​: Sun Sep 1 20​:41​:26 2013 -0300

toke\.c\, scan\_ident\(\)​: use PEEKSPACE\(\) to skip over whitespace\.

diagnostics
-----------
http​://www.cpantesters.org/cpan/report/8121d6e4-206f-11e3-8321-e2dca0a565e3
http​://www.cpantesters.org/cpan/report/8a7d994e-2092-11e3-a5fc-4c00a1a565e3
http​://www.cpantesters.org/cpan/report/938f1694-2096-11e3-8a39-9e01a1a565e3

Also affected​: FREW/DBIx-Class-DeploymentHandler-0.002207.tar.gz

Uhm. I'm in the awkward position that I know how to fix this, but I don't
quite understand why it happens.
The problem is the first

  if (s < PL_bufend && isSPACE(*s)) {
  s = PEEKSPACE(s);
  }

For some reason, if there's enough characters before a %{\nfoo}, like in
those two modules, somehow we never go inside that if(), which causes this.
Perhaps things will clarify once there's a more self-contained test case.

In any case, I already had half of the solution in my hands, since I was
trying to fix 119823​:
http​://perl5.git.perl.org/perl.git/shortlog/refs/heads/hugmeir/lex_no_swallow_comments
With LEX_NO_SWALLOW_COMMENTS in place, we no longer have to play games to
decide if we have to call PEEKSPACE or not; we can just unconditionally
call skipspace_flags() and let that handle the details, which solves the
issue, and is what the rest of toke.c generally does.
Unless there's any objections, I'll push that branch to blead later today,
after I dilute a self-contained test case.

From @cpansprout

On Thu Sep 19 08​:06​:04 2013, Hugmeir wrote​:

On Thu, Sep 19, 2013 at 3​:26 AM, Andreas J. Koenig via RT <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by (Andreas J. Koenig)
# Please include the string​: [perl #119889]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=119889 >

git bisect
----------
commit a49b10d
Author​: Brian Fraser <fraserbn@​gmail.com>
Date​: Sun Sep 1 20​:41​:26 2013 -0300

toke\.c\, scan\_ident\(\)​: use PEEKSPACE\(\) to skip over whitespace\.

diagnostics
-----------
http​://www.cpantesters.org/cpan/report/8121d6e4-206f-11e3-8321-
e2dca0a565e3
http​://www.cpantesters.org/cpan/report/8a7d994e-2092-11e3-a5fc-
4c00a1a565e3
http​://www.cpantesters.org/cpan/report/938f1694-2096-11e3-8a39-
9e01a1a565e3

Also affected​: FREW/DBIx-Class-DeploymentHandler-0.002207.tar.gz

Uhm. I'm in the awkward position that I know how to fix this, but I
don't
quite understand why it happens.
The problem is the first

    if \(s \< PL\_bufend && isSPACE\(\*s\)\) \{
        s = PEEKSPACE\(s\);
    \}

For some reason, if there's enough characters before a %{\nfoo}, like
in
those two modules, somehow we never go inside that if(), which causes
this.
Perhaps things will clarify once there's a more self-contained test
case.

In any case, I already had half of the solution in my hands, since I
was
trying to fix 119823​:

http​://perl5.git.perl.org/perl.git/shortlog/refs/heads/hugmeir/lex_no_swallow_comments

With LEX_NO_SWALLOW_COMMENTS in place, we no longer have to play games
to
decide if we have to call PEEKSPACE or not; we can just
unconditionally
call skipspace_flags() and let that handle the details, which solves
the
issue, and is what the rest of toke.c generally does.
Unless there's any objections, I'll push that branch to blead later
today,
after I dilute a self-contained test case.

If you could figure out why it’s failing (and why your changes fix it)
and put that in the commit message, that would be nice.

--

Father Chrysostomos

From @cpansprout

On Thu Sep 19 08​:06​:04 2013, Hugmeir wrote​:

Uhm. I'm in the awkward position that I know how to fix this, but I
don't
quite understand why it happens.
The problem is the first

    if \(s \< PL\_bufend && isSPACE\(\*s\)\) \{
        s = PEEKSPACE\(s\);
    \}

For some reason, if there's enough characters before a %{\nfoo}, like
in
those two modules, somehow we never go inside that if(), which causes
this.
Perhaps things will clarify once there's a more self-contained test
case.

The failure mention in
<CADED=K4hfV=tgwjYh+ahjjH=1uHp5j_frwy3HNX+vc_i6knFnw@​mail.gmail.com>
may be related. I can reduce it to something not requiring PERLIO=stdio​:

$ ./miniperl -e '*{' -e ' XS​::APItest​::gv_fetchmeth_type()' -e '}'
Unrecognized character \x80; marked by <-- HERE after

From @cpansprout

On Thu Sep 19 23​:43​:24 2013, sprout wrote​:

On Thu Sep 19 08​:06​:04 2013, Hugmeir wrote​:

Uhm. I'm in the awkward position that I know how to fix this, but I
don't
quite understand why it happens.
The problem is the first

    if \(s \< PL\_bufend && isSPACE\(\*s\)\) \{
        s = PEEKSPACE\(s\);
    \}

For some reason, if there's enough characters before a %{\nfoo}, like
in
those two modules, somehow we never go inside that if(), which causes
this.
Perhaps things will clarify once there's a more self-contained test
case.

The failure mention in
<CADED=K4hfV=tgwjYh+ahjjH=1uHp5j_frwy3HNX+vc_i6knFnw@​mail.gmail.com>
may be related. I can reduce it to something not requiring PERLIO=stdio​:

$ ./miniperl -e '*{' -e ' XS​::APItest​::gv_fetchmeth_type()' -e '}'
Unrecognized character \x80; marked by <-- HERE after

That got cut off. Someone doesn’t like the nulls in the output.

Piped to less, it is​:

Unrecognized character \x80; marked by <-- HERE after
^@​^@​^@​^@​^@​^@​^@​^@​^@​2<-- HERE near column 24 at -e line 2.

And the rest of my message was something like this​:

It looks as though, after the identifier scan fails, some buffer
pointers are not being updated.

I haven’t tested it with your new branch yet.

--

Father Chrysostomos

From @cpansprout

On Thu Sep 19 23​:45​:24 2013, sprout wrote​:

On Thu Sep 19 23​:43​:24 2013, sprout wrote​:

On Thu Sep 19 08​:06​:04 2013, Hugmeir wrote​:

Uhm. I'm in the awkward position that I know how to fix this, but I
don't
quite understand why it happens.
The problem is the first

    if \(s \< PL\_bufend && isSPACE\(\*s\)\) \{
        s = PEEKSPACE\(s\);
    \}

For some reason, if there's enough characters before a %{\nfoo}, like
in
those two modules, somehow we never go inside that if(), which causes
this.
Perhaps things will clarify once there's a more self-contained test
case.

The failure mention in
<CADED=K4hfV=tgwjYh+ahjjH=1uHp5j_frwy3HNX+vc_i6knFnw@​mail.gmail.com>
may be related. I can reduce it to something not requiring
PERLIO=stdio​:

$ ./miniperl -e '*{' -e ' XS​::APItest​::gv_fetchmeth_type()'
-e '}'
Unrecognized character \x80; marked by <-- HERE after

That got cut off. Someone doesn’t like the nulls in the output.

Piped to less, it is​:

Unrecognized character \x80; marked by <-- HERE after
^@​^@​^@​^@​^@​^@​^@​^@​^@​2<-- HERE near column 24 at -e line 2.

And the rest of my message was something like this​:

It looks as though, after the identifier scan fails, some buffer
pointers are not being updated.

I haven’t tested it with your new branch yet.

With your new branch that one-line still fails.

--

Father Chrysostomos

From @cpansprout

On Thu Sep 19 23​:45​:24 2013, sprout wrote​:

On Thu Sep 19 23​:43​:24 2013, sprout wrote​:

On Thu Sep 19 08​:06​:04 2013, Hugmeir wrote​:

Uhm. I'm in the awkward position that I know how to fix this, but I
don't
quite understand why it happens.
The problem is the first

    if \(s \< PL\_bufend && isSPACE\(\*s\)\) \{
        s = PEEKSPACE\(s\);
    \}

For some reason, if there's enough characters before a %{\nfoo}, like
in
those two modules, somehow we never go inside that if(), which causes
this.
Perhaps things will clarify once there's a more self-contained test
case.

The failure mention in
<CADED=K4hfV=tgwjYh+ahjjH=1uHp5j_frwy3HNX+vc_i6knFnw@​mail.gmail.com>
may be related. I can reduce it to something not requiring
PERLIO=stdio​:

$ ./miniperl -e '*{' -e ' XS​::APItest​::gv_fetchmeth_type()'
-e '}'
Unrecognized character \x80; marked by <-- HERE after

That got cut off. Someone doesn’t like the nulls in the output.

Piped to less, it is​:

Unrecognized character \x80; marked by <-- HERE after
^@​^@​^@​^@​^@​^@​^@​^@​^@​2<-- HERE near column 24 at -e line 2.

And the rest of my message was something like this​:

It looks as though, after the identifier scan fails, some buffer
pointers are not being updated.

I have fixed that one-liner in commit 4aaee9b. I assumed it was the
same bug, but it turns out not to be, because
FREW/DBIx-Class-DeploymentHandler-0.002207.tar.gz still fails for me.
(ILMARI/DBIx-Class-Schema-Loader-0.07036.tar.gz doesn’t fail for me at
all, with any commit.)

--

Father Chrysostomos

From @Hugmeir

On Fri, Sep 20, 2013 at 5​:21 AM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Thu Sep 19 23​:45​:24 2013, sprout wrote​:

On Thu Sep 19 23​:43​:24 2013, sprout wrote​:

On Thu Sep 19 08​:06​:04 2013, Hugmeir wrote​:

Uhm. I'm in the awkward position that I know how to fix this, but I
don't
quite understand why it happens.
The problem is the first

    if \(s \< PL\_bufend && isSPACE\(\*s\)\) \{
        s = PEEKSPACE\(s\);
    \}

For some reason, if there's enough characters before a %{\nfoo}, like
in
those two modules, somehow we never go inside that if(), which causes
this.
Perhaps things will clarify once there's a more self-contained test
case.

The failure mention in
<CADED=K4hfV=tgwjYh+ahjjH=1uHp5j_frwy3HNX+vc_i6knFnw@​mail.gmail.com>
may be related. I can reduce it to something not requiring
PERLIO=stdio​:

$ ./miniperl -e '*{' -e ' XS​::APItest​::gv_fetchmeth_type()'
-e '}'
Unrecognized character \x80; marked by <-- HERE after

That got cut off. Someone doesn’t like the nulls in the output.

Piped to less, it is​:

Unrecognized character \x80; marked by <-- HERE after
^@​^@​^@​^@​^@​^@​^@​^@​^@​2<-- HERE near column 24 at -e line 2.

And the rest of my message was something like this​:

It looks as though, after the identifier scan fails, some buffer
pointers are not being updated.

I have fixed that one-liner in commit 4aaee9b.

Thanks for looking into this. I meant to reply earlier, but I didn't have
anything concrete to write back, so you've beat me to the punch while I was
still trying to make heads or tails of the situation.

I assumed it was the
same bug, but it turns out not to be, because
FREW/DBIx-Class-DeploymentHandler-0.002207.tar.gz still fails for me.
(ILMARI/DBIx-Class-Schema-Loader-0.07036.tar.gz doesn’t fail for me at
all, with any commit.)

Schema-Loader used to break for me, but now works, so that appears to be
fixed. And like you say, the former is still broken. I'll keep looking.

From @Hugmeir

On Fri, Sep 20, 2013 at 5​:21 AM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Thu Sep 19 23​:45​:24 2013, sprout wrote​:

On Thu Sep 19 23​:43​:24 2013, sprout wrote​:

On Thu Sep 19 08​:06​:04 2013, Hugmeir wrote​:

Uhm. I'm in the awkward position that I know how to fix this, but I
don't
quite understand why it happens.
The problem is the first

    if \(s \< PL\_bufend && isSPACE\(\*s\)\) \{
        s = PEEKSPACE\(s\);
    \}

For some reason, if there's enough characters before a %{\nfoo}, like
in
those two modules, somehow we never go inside that if(), which causes
this.
Perhaps things will clarify once there's a more self-contained test
case.

The failure mention in
<CADED=K4hfV=tgwjYh+ahjjH=1uHp5j_frwy3HNX+vc_i6knFnw@​mail.gmail.com>
may be related. I can reduce it to something not requiring
PERLIO=stdio​:

$ ./miniperl -e '*{' -e ' XS​::APItest​::gv_fetchmeth_type()'
-e '}'
Unrecognized character \x80; marked by <-- HERE after

That got cut off. Someone doesn’t like the nulls in the output.

Piped to less, it is​:

Unrecognized character \x80; marked by <-- HERE after
^@​^@​^@​^@​^@​^@​^@​^@​^@​2<-- HERE near column 24 at -e line 2.

And the rest of my message was something like this​:

It looks as though, after the identifier scan fails, some buffer
pointers are not being updated.

I have fixed that one-liner in commit 4aaee9b. I assumed it was the
same bug, but it turns out not to be, because
FREW/DBIx-Class-DeploymentHandler-0.002207.tar.gz still fails for me.
(ILMARI/DBIx-Class-Schema-Loader-0.07036.tar.gz doesn’t fail for me at
all, with any commit.)

For FREW/DBIx-Class-DeploymentHandler, the problem comes down to

my %foo = (stuff => '%hash');
sub foo (&){["sub(&)"]}
warn @​{foo { "stuff" }};

Which changes behavior depending on whenever there's a newline after the
@​{, but consistently stays as @​{foo{"stuff"}} in blead. Both suck, but I
think consistency trumps.
Ideally, we should be detecting if a bareword followed by {...} is a & sub,
but that's likely not doable at that point of the parsing, and wouldn't
play well with plugged in keywords and/or parsers.

From @cpansprout

On Fri Sep 20 02​:24​:04 2013, Hugmeir wrote​:

For FREW/DBIx-Class-DeploymentHandler, the problem comes down to

my %foo = (stuff => '%hash');
sub foo (&){["sub(&)"]}
warn @​{foo { "stuff" }};

Which changes behavior depending on whenever there's a newline after
the
@​{, but consistently stays as @​{foo{"stuff"}} in blead. Both suck, but
I
think consistency trumps.
Ideally, we should be detecting if a bareword followed by {...} is a &
sub,
but that's likely not doable at that point of the parsing, and
wouldn't
play well with plugged in keywords and/or parsers.

I think the module should change.

--

Father Chrysostomos

From @Hugmeir

On Fri, Sep 20, 2013 at 12​:40 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Fri Sep 20 02​:24​:04 2013, Hugmeir wrote​:

For FREW/DBIx-Class-DeploymentHandler, the problem comes down to

my %foo = (stuff => '%hash');
sub foo (&){["sub(&)"]}
warn @​{foo { "stuff" }};

Which changes behavior depending on whenever there's a newline after
the
@​{, but consistently stays as @​{foo{"stuff"}} in blead. Both suck, but
I
think consistency trumps.
Ideally, we should be detecting if a bareword followed by {...} is a &
sub,
but that's likely not doable at that point of the parsing, and
wouldn't
play well with plugged in keywords and/or parsers.

I think the module should change.

I've submitted a patch for the module on github[*] and pushed tests for
this in 7bb20a1.
Uh, I've never really followed this process through, so I have to ask, what
now? Does the ticket remain open until the affected module is patched?

[*] frioux/DBIx-Class-DeploymentHandler#19

From @cpansprout

On Sun Sep 22 20​:54​:24 2013, Hugmeir wrote​:

On Fri, Sep 20, 2013 at 12​:40 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Fri Sep 20 02​:24​:04 2013, Hugmeir wrote​:

For FREW/DBIx-Class-DeploymentHandler, the problem comes down to

my %foo = (stuff => '%hash');
sub foo (&){["sub(&)"]}
warn @​{foo { "stuff" }};

Which changes behavior depending on whenever there's a newline after
the
@​{, but consistently stays as @​{foo{"stuff"}} in blead. Both suck, but
I
think consistency trumps.
Ideally, we should be detecting if a bareword followed by {...} is a &
sub,
but that's likely not doable at that point of the parsing, and
wouldn't
play well with plugged in keywords and/or parsers.

I think the module should change.

I've submitted a patch for the module on github[*] and pushed tests for
this in 7bb20a1.
Uh, I've never really followed this process through, so I have to ask,
what
now? Does the ticket remain open until the affected module is patched?

What I’ve been doing is adding it to Porting/perl5200delta.pod’s Known
Issues section and then closing the ticket. If it has fewer than 5
dependents, though, I just close the ticket.

The idea is that high-profile modules will be noted in 5.20.0’s delta.
Or if the pumpking decides they are too high-profile, the release may be
delayed. But at least they all get listed in one place for the
pumpking’s convenience.

--

Father Chrysostomos

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2013-09-26T09​:12​:42]

Or if the pumpking decides they are too high-profile, the release may be
delayed. But at least they all get listed in one place for the
pumpking’s convenience.

We appreciate one's efforts in this matter!

--
rjbs

From @Hugmeir

On Thu, Sep 26, 2013 at 10​:12 AM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sun Sep 22 20​:54​:24 2013, Hugmeir wrote​:

On Fri, Sep 20, 2013 at 12​:40 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Fri Sep 20 02​:24​:04 2013, Hugmeir wrote​:

For FREW/DBIx-Class-DeploymentHandler, the problem comes down to

my %foo = (stuff => '%hash');
sub foo (&){["sub(&)"]}
warn @​{foo { "stuff" }};

Which changes behavior depending on whenever there's a newline after
the
@​{, but consistently stays as @​{foo{"stuff"}} in blead. Both suck,
but
I
think consistency trumps.
Ideally, we should be detecting if a bareword followed by {...} is a
&
sub,
but that's likely not doable at that point of the parsing, and
wouldn't
play well with plugged in keywords and/or parsers.

I think the module should change.

I've submitted a patch for the module on github[*] and pushed tests for
this in 7bb20a1.
Uh, I've never really followed this process through, so I have to ask,
what
now? Does the ticket remain open until the affected module is patched?

What I’ve been doing is adding it to Porting/perl5200delta.pod’s Known
Issues section and then closing the ticket. If it has fewer than 5
dependents, though, I just close the ticket.

The idea is that high-profile modules will be noted in 5.20.0’s delta.
Or if the pumpking decides they are too high-profile, the release may be
delayed. But at least they all get listed in one place for the
pumpking’s convenience.

Swell, thanks. DBIx​::Class​::DeploymentHandler has been patched to work on

5.19.4, so this ticket can be closed, but I'll keep this in mind for the
next one.

@Hugmeir - Status changed from 'open' to 'resolved'

From @andk

Brian Fraser <fraserbn@​gmail.com> writes​:

Swell, thanks. DBIx​::Class​::DeploymentHandler has been patched to work on >
5.19.4, so this ticket can be closed, but I'll keep this in mind for the next
one.

Slaven discovered another package affected​:
TSIBLEY/Jifty-DBI-0.76.tar.gz

Nowadays failing due to a syntax error as in sample fail report

http​://www.cpantesters.org/cpan/report/b3c6505c-58e6-11e3-974f-bb3f9e5baa37

Bisect nailed the failure to the same commit.

--
andreas

From @Hugmeir

On Sun, Dec 1, 2013 at 12​:00 AM, Andreas Koenig <
andreas.koenig.7os6VVqR@​franz.ak.mind.de> wrote​:

Brian Fraser <fraserbn@​gmail.com> writes​:

Swell, thanks. DBIx​::Class​::DeploymentHandler has been patched to work
on >
5.19.4, so this ticket can be closed, but I'll keep this in mind for the
next
one.

Slaven discovered another package affected​:
TSIBLEY/Jifty-DBI-0.76.tar.gz

Nowadays failing due to a syntax error as in sample fail report

http​://www.cpantesters.org/cpan/report/b3c6505c-58e6-11e3-974f-bb3f9e5baa37

Bisect nailed the failure to the same commit.

(pardons, ended up replying directly to Andreas and didn't include the list)

Thanks! Same issue as before. Jifty​::DBI​::Collection is using @​{\neval {}},
and expecting it to be parsed @​{(eval {})}, rather than @​eval{}. I filed a
bug report last night ( https://rt.cpan.org/Public/Bug/Display.html?id=91088 )
and it has already been resolved. Hooray :D