Bug#950297: libyaml-syck-perl FTCBFS: compiler check too strict

> On Jan 31, 2020, at 9:50 AM, gregor herrmann wrote: > > In my understanding, ExtUtils::HasCompiler is there for situations > where the presence of a compiler is not guaranteed. Right. If I don't do this then I get all sorts of testing failure reports about systems which don't have a

Bug#950297: libyaml-syck-perl FTCBFS: compiler check too strict

> On Feb 4, 2020, at 1:03 PM, Todd Rinaldo wrote: > > > >> On Jan 31, 2020, at 9:50 AM, gregor herrmann > <mailto:gre...@debian.org>> wrote: >> >> In my understanding, ExtUtils::HasCompiler is there for situations >> where the presence of a co

Bug#450663: Upstream response

I'm the upstream author and am having quite a bit of trouble determining if this bug is reported upstream. I would guess the issue you're reporting here is related to this which we're actively discussing. Thoughts? https://github.com/toddr/IPC-Run/issues/116 smime.p7s Description: S/MIME

Bug#703569: Upstream tracking

Tracked upstream via https://github.com/toddr/IPC-Run/issues/119 smime.p7s Description: S/MIME cryptographic signature

Bug#489100: libyaml-syck-perl generates double-references and fails to load them back

I've added test t/bug/rt-49404-double_free.t to github and it will be in 1.10_3 this week. I cannot re-produce it on my instances of perl which makes me think that this may be a gcc optimization bug and nothing to do with this module. Hopefully we'll find something in cpan testers this week.