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 breaks ILYAZ/modules/Audio-FindChunks-2.00.tar.gz #13823

Closed
p5pRT opened this issue May 12, 2014 · 15 comments
Closed

Bleadperl breaks ILYAZ/modules/Audio-FindChunks-2.00.tar.gz #13823

p5pRT opened this issue May 12, 2014 · 15 comments

Comments

@p5pRT
Copy link

p5pRT commented May 12, 2014

Migrated from rt.perl.org#121853 (status was 'resolved')

Searchable as RT121853$

@p5pRT
Copy link
Author

p5pRT commented May 12, 2014

From @andk

All facts I know (which is not much) are in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=115910 but that has been
closed as "no longer useful". What would be considered useful instead?

--
andreas

@p5pRT
Copy link
Author

p5pRT commented May 12, 2014

From @rjbs

* "Andreas J. Koenig via RT" <perlbug-followup@​perl.org> [2014-05-12T17​:27​:08]

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

All facts I know (which is not much) are in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=115910 but that has been
closed as "no longer useful". What would be considered useful instead?

I closed that ticket because it covered 18 months of various modules being
broken and fixed, and didn't really seem to be a ticket that could be
addressed. Also, because has been untouched in nearly a year, and was mostly
just sitting there getting mentioned as a "blocker," which it wasn't.

If you think it would be useful to re-open and use as an omnibus ticket for
"stuff still broken and bisecting to COW-enabling," I suppose that's fine with
me. It seemed to me like I was the only user, and I was getting no use.
That's all.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented May 12, 2014

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

@p5pRT
Copy link
Author

p5pRT commented May 13, 2014

From @andk

"Ricardo Signes via RT" <perlbug-followup@​perl.org> writes​:

* "Andreas J. Koenig via RT" <perlbug-followup@​perl.org> [2014-05-12T17​:27​:08]

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

All facts I know (which is not much) are in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=115910 but that has been
closed as "no longer useful". What would be considered useful instead?

I closed that ticket because it covered 18 months of various modules being
broken and fixed, and didn't really seem to be a ticket that could be
addressed. Also, because has been untouched in nearly a year, and was mostly
just sitting there getting mentioned as a "blocker," which it wasn't.

But what constitutes a blocker is a decision of the pumpkin, you are the
pumpkin, if you close a ticket it's per definition not a blocker
anymore.

If you think it would be useful to re-open and use as an omnibus ticket for
"stuff still broken and bisecting to COW-enabling," I suppose that's fine with
me. It seemed to me like I was the only user, and I was getting no use.
That's all.

There is stuff still broken. If you have hints what needs bisecting,
I'll be glad to start my bisect engine again, but I'd be surprised if
anything in 115910 would not be v5.19.0-246-g13b0f67.

It's not possible to say we care about backwards compatibility and at
the same time close blocker tickets because nobody works on them. If we
do not have enough manpower to manage the breakage, should we release at
all? And why?

--
andreas

@p5pRT
Copy link
Author

p5pRT commented May 13, 2014

From @tonycoz

On Mon May 12 14​:27​:08 2014, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

All facts I know (which is not much) are in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=115910 but that has been
closed as "no longer useful". What would be considered useful instead?

I'm not Ricardo, but I'd prefer individual tickets.

This makes the issues found easier to track whether they're still a problem with that module.

eg. sprout's last summary listed​:

ILYAZ/modules/Audio-FindChunks-2.00.tar.gz
ATHOMASON/Log-Syslog-Fast-0.61.tar.gz
NI-S/Math-Rand48-1.00.tar.gz
MSCHILLI/Process-MaxSize-0.03.tar.gz
GRIAN/Storable-AMF-1.00.tar.gz
SHURIKO/String-Simrank-0.079.tar.gz
LEONT/SysV-SharedMem-0.008.tar.gz
SISYPHUS/Math-GMPz-0.37.tar.gz
SISYPHUS/Math-GMPf-0.35.tar.gz
SISYPHUS/Math-GMPq-0.35.tar.gz
KULP/PHP-Serialization-XS-0.06.tar.gz

Are they all still broken?

I'll take a look at Audio-FindChunks.

Tony

@p5pRT
Copy link
Author

p5pRT commented May 13, 2014

From @andk

"Tony Cook via RT" <perlbug-followup@​perl.org> writes​:

On Mon May 12 14​:27​:08 2014, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

All facts I know (which is not much) are in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=115910 but that has been
closed as "no longer useful". What would be considered useful instead?

I'm not Ricardo, but I'd prefer individual tickets.

Thanks! I'll try to open more individual tickets.

This makes the issues found easier to track whether they're still a problem with that module.

eg. sprout's last summary listed​:

ILYAZ/modules/Audio-FindChunks-2.00.tar.gz
ATHOMASON/Log-Syslog-Fast-0.61.tar.gz
NI-S/Math-Rand48-1.00.tar.gz
MSCHILLI/Process-MaxSize-0.03.tar.gz
GRIAN/Storable-AMF-1.00.tar.gz
SHURIKO/String-Simrank-0.079.tar.gz
LEONT/SysV-SharedMem-0.008.tar.gz
SISYPHUS/Math-GMPz-0.37.tar.gz
SISYPHUS/Math-GMPf-0.35.tar.gz
SISYPHUS/Math-GMPq-0.35.tar.gz
KULP/PHP-Serialization-XS-0.06.tar.gz

Are they all still broken?

I'm glad to report these 6 seem to be fixed​:

ATHOMASON/Log-Syslog-Fast-0.61.tar.gz
SHURIKO/String-Simrank-0.079.tar.gz
SISYPHUS/Math-GMPz-0.38.tar.gz
SISYPHUS/Math-GMPf-0.39.tar.gz
SISYPHUS/Math-GMPq-0.37.tar.gz
KULP/PHP-Serialization-XS-0.06.tar.gz

I'll take a look at Audio-FindChunks.

Thanks! I'll file individual reports for the others (unless somebody
beats me to it).

--
andreas

@p5pRT
Copy link
Author

p5pRT commented May 14, 2014

From @tonycoz

On Mon May 12 23​:25​:11 2014, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

"Tony Cook via RT" <perlbug-followup@​perl.org> writes​:

I'll take a look at Audio-FindChunks.

Thanks! I'll file individual reports for the others (unless somebody
beats me to it).

I've posted a patch to the CPAN ticket as

https://rt.cpan.org/Ticket/Display.html?id=95272#txn-1362843

I'll close this in a couple of days unless someone objects.

Tony

@p5pRT
Copy link
Author

p5pRT commented May 14, 2014

From @rjbs

* Andreas Koenig <andreas.koenig.7os6VVqR@​franz.ak.mind.de> [2014-05-12T23​:01​:53]

It's not possible to say we care about backwards compatibility and at
the same time close blocker tickets because nobody works on them. If we
do not have enough manpower to manage the breakage, should we release at
all? And why?

It's just that my understanding at this point — and it may very well be flawed
— is that the things broken by that commit are either (a) now fixed by the
changes Yves made that will avoid OOM problems or (b) bugs in the CPAN
libraries, caused by assuming too much about the implementation of PVs.

That is​: I do not intend to say that "nobody is going to fix this, so I am
closing it," but rather that "this ticket no longer represents a clear problem
that can be worked on, because it has become a muddle after 18 months of
various things."

What would be useful would be to see reports of failure post-e8c6a47 that still
bisect to the default-on of COW. Those would constitute a still very
interesting set of failures.

I assumed — perhaps too much — that these would still show up in the near
future, if they exist. I don't really know how the BBC machinery works,
though, so perhaps I've blundered.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented May 14, 2014

From @andk

Ricardo Signes <perl.p5p@​rjbs.manxome.org> writes​:

* Andreas Koenig <andreas.koenig.7os6VVqR@​franz.ak.mind.de> [2014-05-12T23​:01​:53]

It's not possible to say we care about backwards compatibility and at
the same time close blocker tickets because nobody works on them. If we
do not have enough manpower to manage the breakage, should we release at
all? And why?

It's just that my understanding at this point — and it may very well be flawed
— is that the things broken by that commit are either (a) now fixed by the
changes Yves made that will avoid OOM problems or (b) bugs in the CPAN
libraries, caused by assuming too much about the implementation of
PVs.

Quite possibly correct.

That is​: I do not intend to say that "nobody is going to fix this, so I am
closing it," but rather that "this ticket no longer represents a clear problem
that can be worked on, because it has become a muddle after 18 months of
various things."

It was a muddle but it ended with a list of not yet cleared CPAN
distros, so the muddle was summarized nicely.

What would be useful would be to see reports of failure post-e8c6a47 that still
bisect to the default-on of COW. Those would constitute a still very
interesting set of failures.

Audio-FindChunks-2.00 is still failing with v5.19.11-107-gcfe3322, six
candidates are cleared. For the others I have yet to check where exactly
they stand now.

I assumed — perhaps too much — that these would still show up in the near
future, if they exist. I don't really know how the BBC machinery works,
though, so perhaps I've blundered.

One option would be to keep that ticket open until we have found a
dictum for each candidate on that list. Opening new individual tickets
for the remaining candidates is another one. We can also continue here.
I don't mind either way, I just don't want to lose the interesting
candidates. Otherwise they'll haunt us​:)

--
andreas

@p5pRT
Copy link
Author

p5pRT commented May 15, 2014

From @andk

"Tony Cook via RT" <perlbug-followup@​perl.org> writes​:

On Mon May 12 14​:27​:08 2014, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

All facts I know (which is not much) are in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=115910 but that has been
closed as "no longer useful". What would be considered useful instead?

I'm not Ricardo, but I'd prefer individual tickets.

This makes the issues found easier to track whether they're still a problem with that module.

eg. sprout's last summary listed​:

ILYAZ/modules/Audio-FindChunks-2.00.tar.gz
ATHOMASON/Log-Syslog-Fast-0.61.tar.gz
NI-S/Math-Rand48-1.00.tar.gz
MSCHILLI/Process-MaxSize-0.03.tar.gz
GRIAN/Storable-AMF-1.00.tar.gz
SHURIKO/String-Simrank-0.079.tar.gz
LEONT/SysV-SharedMem-0.008.tar.gz
SISYPHUS/Math-GMPz-0.37.tar.gz
SISYPHUS/Math-GMPf-0.35.tar.gz
SISYPHUS/Math-GMPq-0.35.tar.gz
KULP/PHP-Serialization-XS-0.06.tar.gz

Are they all still broken?

| ILYAZ/modules/Audio-FindChunks-2.00.tar.gz | rt.cpan 95272 |
| ATHOMASON/Log-Syslog-Fast-0.61.tar.gz | fixed |
| NI-S/Math-Rand48-1.00.tar.gz | rt.perl 121874 |
| MSCHILLI/Process-MaxSize-0.03.tar.gz | rt.perl 121875 |
| GRIAN/Storable-AMF-1.00.tar.gz | rt.cpan 95660 |
| SHURIKO/String-Simrank-0.079.tar.gz | fixed |
| LEONT/SysV-SharedMem-0.008.tar.gz | rt.cpan 95659 |
| SISYPHUS/Math-GMPz-0.37.tar.gz | fixed |
| SISYPHUS/Math-GMPf-0.35.tar.gz | fixed |
| SISYPHUS/Math-GMPq-0.35.tar.gz | fixed |
| KULP/PHP-Serialization-XS-0.06.tar.gz | fixed |

Thanks,
--
andreas

@p5pRT
Copy link
Author

p5pRT commented May 19, 2014

From @tonycoz

On Wed May 14 19​:22​:50 2014, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

| ILYAZ/modules/Audio-FindChunks-2.00.tar.gz | rt.cpan 95272 |
| ATHOMASON/Log-Syslog-Fast-0.61.tar.gz | fixed |
| NI-S/Math-Rand48-1.00.tar.gz | rt.perl 121874 |
| MSCHILLI/Process-MaxSize-0.03.tar.gz | rt.perl 121875 |
| GRIAN/Storable-AMF-1.00.tar.gz | rt.cpan 95660 |
| SHURIKO/String-Simrank-0.079.tar.gz | fixed |
| LEONT/SysV-SharedMem-0.008.tar.gz | rt.cpan 95659 |
| SISYPHUS/Math-GMPz-0.37.tar.gz | fixed |
| SISYPHUS/Math-GMPf-0.35.tar.gz | fixed |
| SISYPHUS/Math-GMPq-0.35.tar.gz | fixed |
| KULP/PHP-Serialization-XS-0.06.tar.gz | fixed |

Except for Storable-AMF (which doesn't have an rt.perl.org ticket), they're all either fixed or have a fix waiting in their CPAN ticket.

Tony

@p5pRT
Copy link
Author

p5pRT commented May 20, 2014

From @tonycoz

On Sun May 18 17​:22​:39 2014, tonyc wrote​:

Except for Storable-AMF (which doesn't have an rt.perl.org ticket),
they're all either fixed or have a fix waiting in their CPAN ticket.

I think the Storable-AMF failure is caused by a reasonable change in perl.

It's doing​:

  $a = 1.0;
  $b = "$a";

and then the following test expects $a to be SvPOK(), but this is no longer true in all cases.

Tony

@p5pRT
Copy link
Author

p5pRT commented May 20, 2014

From @khwilliamson

On 05/19/2014 06​:52 PM, Tony Cook via RT wrote​:

On Sun May 18 17​:22​:39 2014, tonyc wrote​:

Except for Storable-AMF (which doesn't have an rt.perl.org ticket),
they're all either fixed or have a fix waiting in their CPAN ticket.

I think the Storable-AMF failure is caused by a reasonable change in perl.

It's doing​:

$a = 1.0;
$b = "$a";

and then the following test expects $a to be SvPOK(), but this is no longer true in all cases.

Tony

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121853

This turns out to be the same as
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121013

which we previously agreed that it was the module that should change,
and not Perl. My claim still stands that this is really a flaw in JSON
which returns a string when the underlying value is really a number.
Coincidentally, I found out today about a pull request to JSON​::PP that
I think would fix these
makamaka/JSON-PP#10

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2015

From @rjbs

All breakages appear fixed, apart from one in which we believe that the downstream code is at fault. Resolving.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant