Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bleadperl v5.27.5-396-gdd6661605f breaks VPIT/B-RecDeparse-0.10.tar.gz #16285

Closed
p5pRT opened this issue Dec 2, 2017 · 10 comments
Closed

Bleadperl v5.27.5-396-gdd6661605f breaks VPIT/B-RecDeparse-0.10.tar.gz #16285

p5pRT opened this issue Dec 2, 2017 · 10 comments
Labels
BBC Blead Breaks CPAN - changes in blead broke a cpan module(s)

Comments

@p5pRT
Copy link

p5pRT commented Dec 2, 2017

Migrated from rt.perl.org#132528 (status was 'open')

Searchable as RT132528$

@p5pRT
Copy link
Author

p5pRT commented Dec 2, 2017

From @andk

A not very surprising BBC​:

  : commit dd66616
  : Author​: Zefram <zefram@​fysh.org>
  : Date​: Thu Nov 16 11​:01​:34 2017 +0000
  :
  : deparse trailing-colon barewords carefully

Diagnostics​:

  http​://www.cpantesters.org/cpan/report/d711b67e-cbbe-11e7-adfc-8406b34ff3ca

perl -V​:

  : Summary of my perl5 (revision 5 version 27 subversion 6) configuration​:
  : Commit id​: dd66616
  : Platform​:
  : osname=linux
  : osvers=4.12.0-2-amd64
  : archname=x86_64-linux-thread-multi-ld
  : uname='linux k93msid 4.12.0-2-amd64 #1 smp debian 4.12.13-1 (2017-09-19) x86_64 gnulinux '
  : config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.5-396-gdd6661605f/496c -Dmyhostname=k93msid -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Dlibswanted=cl pthread socket inet nsl gdbm dbm malloc dl ld sun m crypt sec util c cposix posix ucb BSD gdbm_compat -Duseithreads -Duselongdouble -DEBUGGING=none'
  : hint=recommended
  : useposix=true
  : d_sigaction=define
  : useithreads=define
  : usemultiplicity=define
  : use64bitint=define
  : use64bitall=define
  : uselongdouble=define
  : usemymalloc=n
  : default_inc_excludes_dot=define
  : bincompat5005=undef
  : Compiler​:
  : cc='cc'
  : ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
  : optimize='-O2'
  : cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  : ccversion=''
  : gccversion='7.2.0'
  : gccosandvers=''
  : intsize=4
  : longsize=8
  : ptrsize=8
  : doublesize=8
  : byteorder=12345678
  : doublekind=3
  : d_longlong=define
  : longlongsize=8
  : d_longdbl=define
  : longdblsize=16
  : longdblkind=3
  : 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-strong -L/usr/local/lib'
  : libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
  : libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  : perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  : libc=libc-2.24.so
  : so=so
  : useshrplib=false
  : libperl=libperl.a
  : gnulibc_version='2.24'
  : Dynamic Linking​:
  : dlsrc=dl_dlopen.xs
  : dlext=so
  : d_dlsymun=undef
  : ccdlflags='-Wl,-E'
  : cccdlflags='-fPIC'
  : lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'
  :
  :
  : Characteristics of this binary (from libperl)​:
  : Compile-time options​:
  : HAS_TIMES
  : MULTIPLICITY
  : PERLIO_LAYERS
  : PERL_COPY_ON_WRITE
  : PERL_DONT_CREATE_GVSV
  : PERL_IMPLICIT_CONTEXT
  : PERL_MALLOC_WRAP
  : PERL_OP_PARENT
  : PERL_PRESERVE_IVUV
  : PERL_USE_DEVEL
  : USE_64_BIT_ALL
  : USE_64_BIT_INT
  : USE_ITHREADS
  : USE_LARGE_FILES
  : USE_LOCALE
  : USE_LOCALE_COLLATE
  : USE_LOCALE_CTYPE
  : USE_LOCALE_NUMERIC
  : USE_LOCALE_TIME
  : USE_LONG_DOUBLE
  : USE_PERLIO
  : USE_PERL_ATOF
  : USE_REENTRANT_API
  : Built under linux
  : Compiled at Nov 16 2017 11​:51​:20
  : @​INC​:
  : /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.5-396-gdd6661605f/496c/lib/site_perl/5.27.6/x86_64-linux-thread-multi-ld
  : /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.5-396-gdd6661605f/496c/lib/site_perl/5.27.6
  : /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.5-396-gdd6661605f/496c/lib/5.27.6/x86_64-linux-thread-multi-ld
  : /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.5-396-gdd6661605f/496c/lib/5.27.6

--
andreas

@p5pRT
Copy link
Author

p5pRT commented Dec 2, 2017

From zefram@fysh.org

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:

Needs examination by Vincent. It's not surprising that a change
to B​::Deparse would break some oversensitive test, but this one
doesn't look exactly like that. B​::RecDeparse doesn't look like it
should be that sensitive, and the way the tests are failing is funny.
But B​::RecDeparse's relationship to B​::Deparse is quite convoluted,
and I can't readily see what's going on.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 2, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Apr 21, 2018

From @iabyn

On Sat, Dec 02, 2017 at 03​:15​:35PM +0000, Zefram wrote​:

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:

Needs examination by Vincent. It's not surprising that a change
to B​::Deparse would break some oversensitive test, but this one
doesn't look exactly like that. B​::RecDeparse doesn't look like it
should be that sensitive, and the way the tests are failing is funny.
But B​::RecDeparse's relationship to B​::Deparse is quite convoluted,
and I can't readily see what's going on.

I don't think this ticket should be a 5.28.0 blocker

--
This is a great day for France!
  -- Nixon at Charles De Gaulle's funeral

@p5pRT
Copy link
Author

p5pRT commented Apr 22, 2018

From @xsawyerx

On 04/21/2018 05​:18 PM, Dave Mitchell wrote​:

On Sat, Dec 02, 2017 at 03​:15​:35PM +0000, Zefram wrote​:

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:
Needs examination by Vincent. It's not surprising that a change
to B​::Deparse would break some oversensitive test, but this one
doesn't look exactly like that. B​::RecDeparse doesn't look like it
should be that sensitive, and the way the tests are failing is funny.
But B​::RecDeparse's relationship to B​::Deparse is quite convoluted,
and I can't readily see what's going on.
I don't think this ticket should be a 5.28.0 blocker

Because of the tight relationship between B​::RecDeparse and B​::Deparse?

@p5pRT
Copy link
Author

p5pRT commented Apr 23, 2018

From @iabyn

On Sun, Apr 22, 2018 at 09​:20​:54AM +0200, Sawyer X wrote​:

On 04/21/2018 05​:18 PM, Dave Mitchell wrote​:

On Sat, Dec 02, 2017 at 03​:15​:35PM +0000, Zefram wrote​:

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:
Needs examination by Vincent. It's not surprising that a change
to B​::Deparse would break some oversensitive test, but this one
doesn't look exactly like that. B​::RecDeparse doesn't look like it
should be that sensitive, and the way the tests are failing is funny.
But B​::RecDeparse's relationship to B​::Deparse is quite convoluted,
and I can't readily see what's going on.
I don't think this ticket should be a 5.28.0 blocker

Because of the tight relationship between B​::RecDeparse and B​::Deparse?

Yes.

--
Fire extinguisher (n) a device for holding open fire doors.

@p5pRT
Copy link
Author

p5pRT commented Apr 23, 2018

From @xsawyerx

On 04/23/2018 10​:33 AM, Dave Mitchell wrote​:

On Sun, Apr 22, 2018 at 09​:20​:54AM +0200, Sawyer X wrote​:

On 04/21/2018 05​:18 PM, Dave Mitchell wrote​:

On Sat, Dec 02, 2017 at 03​:15​:35PM +0000, Zefram wrote​:

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:
Needs examination by Vincent. It's not surprising that a change
to B​::Deparse would break some oversensitive test, but this one
doesn't look exactly like that. B​::RecDeparse doesn't look like it
should be that sensitive, and the way the tests are failing is funny.
But B​::RecDeparse's relationship to B​::Deparse is quite convoluted,
and I can't readily see what's going on.
I don't think this ticket should be a 5.28.0 blocker
Because of the tight relationship between B​::RecDeparse and B​::Deparse?
Yes.

This is reasonable. I just wanted to be sure.

I think any module in which you're depending on internal state, you are
in charged with updating your code. Equivalent to any other module that
has the purpose of exposing the current OPs. If they change, it needs
updating.

@p5pRT
Copy link
Author

p5pRT commented Apr 23, 2018

From @iabyn

On Mon, Apr 23, 2018 at 10​:35​:26AM +0200, Sawyer X wrote​:

On 04/23/2018 10​:33 AM, Dave Mitchell wrote​:

On Sun, Apr 22, 2018 at 09​:20​:54AM +0200, Sawyer X wrote​:

On 04/21/2018 05​:18 PM, Dave Mitchell wrote​:

On Sat, Dec 02, 2017 at 03​:15​:35PM +0000, Zefram wrote​:

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:
Needs examination by Vincent. It's not surprising that a change
to B​::Deparse would break some oversensitive test, but this one
doesn't look exactly like that. B​::RecDeparse doesn't look like it
should be that sensitive, and the way the tests are failing is funny.
But B​::RecDeparse's relationship to B​::Deparse is quite convoluted,
and I can't readily see what's going on.
I don't think this ticket should be a 5.28.0 blocker
Because of the tight relationship between B​::RecDeparse and B​::Deparse?
Yes.

This is reasonable. I just wanted to be sure.

I think any module in which you're depending on internal state, you are
in charged with updating your code. Equivalent to any other module that
has the purpose of exposing the current OPs. If they change, it needs
updating.

I've now removed it from 5.28 blockers

--
The Enterprise successfully ferries an alien VIP from one place to another
without serious incident.
  -- Things That Never Happen in "Star Trek" #7

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2018

From @eserte

Dana Mon, 23 Apr 2018 05​:11​:17 -0700, davem reče​:

On Mon, Apr 23, 2018 at 10​:35​:26AM +0200, Sawyer X wrote​:

On 04/23/2018 10​:33 AM, Dave Mitchell wrote​:

On Sun, Apr 22, 2018 at 09​:20​:54AM +0200, Sawyer X wrote​:

On 04/21/2018 05​:18 PM, Dave Mitchell wrote​:

On Sat, Dec 02, 2017 at 03​:15​:35PM +0000, Zefram wrote​:

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:
Needs examination by Vincent. It's not surprising that a change
to B​::Deparse would break some oversensitive test, but this one
doesn't look exactly like that. B​::RecDeparse doesn't look like it
should be that sensitive, and the way the tests are failing is funny.
But B​::RecDeparse's relationship to B​::Deparse is quite convoluted,
and I can't readily see what's going on.
I don't think this ticket should be a 5.28.0 blocker
Because of the tight relationship between B​::RecDeparse and B​::Deparse?
Yes.

This is reasonable. I just wanted to be sure.

I think any module in which you're depending on internal state, you are
in charged with updating your code. Equivalent to any other module that
has the purpose of exposing the current OPs. If they change, it needs
updating.

I've now removed it from 5.28 blockers

What's the resolution here? Should a ticket in the CPAN module's queue be opened?

@p5pRT
Copy link
Author

p5pRT commented Jun 9, 2018

From @eserte

Dana Sat, 02 Jun 2018 01​:22​:34 -0700, slaven@​rezic.de reče​:

Dana Mon, 23 Apr 2018 05​:11​:17 -0700, davem reče​:

On Mon, Apr 23, 2018 at 10​:35​:26AM +0200, Sawyer X wrote​:

On 04/23/2018 10​:33 AM, Dave Mitchell wrote​:

On Sun, Apr 22, 2018 at 09​:20​:54AM +0200, Sawyer X wrote​:

On 04/21/2018 05​:18 PM, Dave Mitchell wrote​:

On Sat, Dec 02, 2017 at 03​:15​:35PM +0000, Zefram wrote​:

Andreas J. Koenig via RT wrote​:

A not very surprising BBC​:
Needs examination by Vincent. It's not surprising that a
change
to B​::Deparse would break some oversensitive test, but this
one
doesn't look exactly like that. B​::RecDeparse doesn't look
like it
should be that sensitive, and the way the tests are failing is
funny.
But B​::RecDeparse's relationship to B​::Deparse is quite
convoluted,
and I can't readily see what's going on.
I don't think this ticket should be a 5.28.0 blocker
Because of the tight relationship between B​::RecDeparse and
B​::Deparse?
Yes.

This is reasonable. I just wanted to be sure.

I think any module in which you're depending on internal state, you
are
in charged with updating your code. Equivalent to any other module
that
has the purpose of exposing the current OPs. If they change, it
needs
updating.

I've now removed it from 5.28 blockers

What's the resolution here? Should a ticket in the CPAN module's queue
be opened?

https://rt.cpan.org/Ticket/Display.html?id=125533

@p5pRT p5pRT added BBC Blead Breaks CPAN - changes in blead broke a cpan module(s) Severity Low labels Oct 19, 2019
@toddr toddr closed this as completed Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BBC Blead Breaks CPAN - changes in blead broke a cpan module(s)
Projects
None yet
Development

No branches or pull requests

2 participants