Hi,

Bug 1082419 is blocked by a FTBFS on ppc64el. The issue seems to be
(judging from the error log) that auto_compact is used during testing,
but that isn't implemented on ppc64el. My attached proposed fix is to
*try* to do auto_compact, but don't fail if that fails (inspired by the
several lines higher). I've tested that amd64 still builds. My test
builds on ppc64el on debomatic-ppc64el.d.n seem to be blocked by issues
with the infrastructure, so I have not tested my fix yet.

If you think my fix is good, please upload. If not, I'll probably NMU
once I confirm it builds on debomatic.

Paul

Hi ruby-msgpack maintainers,

I just tested this on our porterbox and my patch isn't enough. With the
patch, the test seems to hang. I had to disable the following tests to
finish the tests. It *seems* that either the test runs quickly, within
seconds, or gets a process at 100% cpu for at least several minutes.
Killing the build doesn't kill the job that takes 100% cpu by the way,
it remains running in the background. Killing it with sigterm didn't
work, I used sigkill.

spec/cases_spec.rb
spec/cruby/buffer_io_spec.rb
spec/cruby/buffer_packer.rb
spec/cruby/buffer_spec.rb
spec/ext_value_spec.rb
spec/factory_spec.rb
spec/format_spec.rb
spec/msgpack_spec.rb

Weirdly enough, when I started disabling tests in a different order, I
also got a passing set with only disabling these:

spec/msgpack_spec.rb
spec/packer_spec.rb
spec/unpacker_spec.rb

So the different tests also influence each other and the order matters.
Even more weirdness, when I run each test stand alone, or only these
latest three, they pass.

ruby-msgpack is in the key package set. Can somebody with ruby expertise
please have a look.

Paul