Hello Antonio et al.

This failure happens randomly, but I get a failure rate around 38% on machines
with 1 CPU and around 66% on machines with 2 CPUs (tried 20 times at least
in each case), which is bad enough for a stable release.

Follows my standard template for FTBFS bugs:
--------------------------------------------------------------------------

Dear maintainer:

During a rebuild of all packages in unstable, this package failed to build.

Below you will find the last part of the build log (probably the most
relevant part, but not necessarily). If required, the full build log
is available here:

https://people.debian.org/~sanvila/build-logs/202606/

About the archive rebuild: The build was made on virtual machines from AWS,
using sbuild and a reduced chroot with only build-essential packages.

If you cannot reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

Caveat: The above should be understood as "where the reported randomness happens".

If this is really a bug in one of the build-depends, please use
reassign and add an affects on src:ruby-bunny, so that this is still
visible in the BTS web page for this package.

Thanks.

--------------------------------------------------------------------------------
[...]
Failures:

  1) Bunny::Channel#basic_reject with requeue = default rejects a message
     Failure/Error: q  = ch.queue("bunny.basic.reject.with-requeue-false", exclusive: true)

     Bunny::ResourceLocked:
       RESOURCE_LOCKED - cannot obtain exclusive access to locked queue 'bunny.basic.reject.with-requeue-false' in vhost 'bunny_testbed'. It could be originally declared on another connection or the exclusive property value does not match that of the original...
     # /<<PKGBUILDDIR>>/debian/ruby-bunny/usr/share/rubygems-integration/all/gems/bunny-3.1.0/lib/bunny/channel.rb:2730:in `raise_if_continuation_resulted_in_a_channel_error!'
     # /<<PKGBUILDDIR>>/debian/ruby-bunny/usr/share/rubygems-integration/all/gems/bunny-3.1.0/lib/bunny/channel.rb:1412:in `queue_declare_without_recording_topology'
     # /<<PKGBUILDDIR>>/debian/ruby-bunny/usr/share/rubygems-integration/all/gems/bunny-3.1.0/lib/bunny/channel.rb:1368:in `queue_declare'
     # /<<PKGBUILDDIR>>/debian/ruby-bunny/usr/share/rubygems-integration/all/gems/bunny-3.1.0/lib/bunny/queue.rb:391:in `declare!'
     # /<<PKGBUILDDIR>>/debian/ruby-bunny/usr/share/rubygems-integration/all/gems/bunny-3.1.0/lib/bunny/queue.rb:90:in `initialize'
     # /<<PKGBUILDDIR>>/debian/ruby-bunny/usr/share/rubygems-integration/all/gems/bunny-3.1.0/lib/bunny/channel.rb:526:in `new'
     # /<<PKGBUILDDIR>>/debian/ruby-bunny/usr/share/rubygems-integration/all/gems/bunny-3.1.0/lib/bunny/channel.rb:526:in `queue'
     # ./spec/higher_level_api/integration/basic_reject_spec.rb:134:in `block (3 levels) in <top (required)>'

Finished in 3 minutes 33.1 seconds (files took 0.17811 seconds to load)
489 examples, 1 failure

Failed examples:

rspec ./spec/higher_level_api/integration/basic_reject_spec.rb:132 # Bunny::Channel#basic_reject with requeue = default rejects a message

/usr/bin/ruby3.3 -I/usr/share/rubygems-integration/all/gems/ [too-long-redacted] b --format documentation failed
Stopping and halting node bunny@sbuild ...
Gracefully halting Erlang VM
/usr/lib/ruby/vendor_ruby/gem2deb.rb:52:in `run': /usr/bin/ruby3.3 /usr/bin/gem2deb-test-runner (Gem2Deb::CommandFailed)
	from /usr/lib/ruby/vendor_ruby/gem2deb.rb:64:in `block in run_ruby'
	from /usr/lib/ruby/vendor_ruby/gem2deb.rb:87:in `maybe_crossbuild'
	from /usr/lib/ruby/vendor_ruby/gem2deb.rb:63:in `run_ruby'
	from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:189:in `run_tests_for_version'
	from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:176:in `block in run_tests'
	from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:175:in `each'
	from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:175:in `run_tests'
	from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:71:in `run_tests'
	from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:57:in `install'
	from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:163:in `install'
	from /usr/bin/dh_ruby:89:in `<main>'
dh_auto_install: error: dh_ruby --install /<<PKGBUILDDIR>>/debian/ruby-bunny returned exit code 1
make[1]: *** [debian/rules:12: override_dh_auto_install] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:8: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess failed with exit status 2
--------------------------------------------------------------------------------

Hi Santiago,

For what it's worth, I've tried building ruby-bunny 3.1.0-1 a hundred
times on sid using pbuilder on amd64 architecture (pbuilder builds
packages in a chroot with minimum necessary packages installed), and
did not get one failure. All builds went fine. (My workstation has a
12-core, 24-thread CPU and plenty of RAM).

Cheers!

This is why I offered a VM to reproduce in my bug report.

Thanks.

tags 1139980 patch
thanks

Hi.

It looks like three different "it" blocks are sharing the
same "exclusive: true" queue name, and the cleanup of one test
collides with the next test.

I guess this would require some kind of refactoring to fix it right,
and Sergei tells me this bug indirectly affects the erlang transition
(because rabbitmq-server is used in autopkgtests).

So I suggest disabling the test for the time being.

The attached patch should do that.

(I've not tested the patch, please double-check. Also, you might
want to sort the list alphabetically).

Thanks.

forwarded 1139980 https://github.com/ruby-amqp/bunny/issues/739
thanks

I've forwarded this issue upstream.

Thanks.

Hi. Upstream has fixed this bug with this commit:

https://github.com/ruby-amqp/bunny/commit/bdc03154c4e5990813e233c2e4874d8b562ad9ff

They changed the queue names to be different for each test, and that way
they do not collide.

Thanks.

I'm attaching the patch here after verifying that it applies cleanly.

Thanks. I'm assuming you also tested on your setup to verify that it
does fix the issue? I cannot reproduce locally on an (arm64) VM with 1
vCPU. I get a different failure, which I'm also handling in the next
upload.

Hello,

Bug #1139980 in ruby-bunny reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-bunny/-/commit/e7bb807e9177ef6196575e9538450cd479dd60cb
------------------------------------------------------------------------
Add upstream patch to avoid flaky tests

Closes: #1139980
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1139980

We believe that the bug you reported is fixed in the latest version of
ruby-bunny, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1139980@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Antonio Terceiro <terceiro@debian.org> (supplier of updated ruby-bunny package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 20 Jun 2026 14:19:48 -0300
Source: ruby-bunny
Architecture: source
Version: 3.1.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Team <pkg-ruby-extras-maintainers@lists.alioth.debian.org>
Changed-By: Antonio Terceiro <terceiro@debian.org>
Closes: 1139980
Changes:
 ruby-bunny (3.1.0-2) unstable; urgency=medium
 .
   * Add upstream patch to avoid flaky tests (Closes: #1139980)
   * debian/ruby-tests.rake: skip test that fails consistently
Checksums-Sha1:
 3239243985d72949fc37ec2bd62eeca7fcef5c06 2166 ruby-bunny_3.1.0-2.dsc
 0c48a2dc2091894ab271ac46b2e9710a3bf0caeb 8368 ruby-bunny_3.1.0-2.debian.tar.xz
 d6c849bb565083610bf90f5ed25dfd45e9ecd923 8392 ruby-bunny_3.1.0-2_arm64.buildinfo
Checksums-Sha256:
 7a0f3ede877f68c8ef7db2496b46a15ba4b0faddb699d8683082eb601b3d0b58 2166 ruby-bunny_3.1.0-2.dsc
 aebd1f89db4e4889e40f05fc808418c3ce833e0e5e6ccc5a88445379b390ef20 8368 ruby-bunny_3.1.0-2.debian.tar.xz
 a3c4133ebfde96b55753962aaf604c1338ceed13b74e094c78b86c4d8d37c630 8392 ruby-bunny_3.1.0-2_arm64.buildinfo
Files:
 5162f154650cd75f42b7fae766fe1ce5 2166 ruby optional ruby-bunny_3.1.0-2.dsc
 59c19c579f86e8cb73e77fbe27c33d10 8368 ruby optional ruby-bunny_3.1.0-2.debian.tar.xz
 085cf09bc7f0e16a98ae0d4b7ac5ecfd 8392 ruby optional ruby-bunny_3.1.0-2_arm64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAmo2z5oACgkQ/A2xu81G
C97wYQ//dr8V67Gwe5EJCh50HKx6b5Ep4p8EsZ3IXh90+N4NWIaoCHnQffMcAw97
TPzMKcHXgTG7dF6SBQw9uDngtB2VlT2bMOlX4rajO/lswo1AsBmZdCKr3uI1VHSB
tQNSecVxJaUKY2Ngg7ThD+SocKIkofeDsBZGb2MgDABalepXKIHV1al1/JpMnjTE
xGYd76q+VRfw5WJMqRoLHFBHm9RFfKscddJA7qUoFfBJX31HfKx3dtv0d1Oa8S8C
9td2qQlpW454WZ4U7UMc0ZENbD8JrJax/cBMBj0WGdpg6f4BYgWxxiZOU86X40iy
dgElI9jzo3AsDl3GwP/EdUe9++YsgTl7zmNr1zZxldd7xAxIMtxn55QInIH9PN9f
Z6z7VOpl5JrkPMpQ9jKcQ/wZipZwUgBw8j+e6GC6KoNkOste7X2ZGZ3OOsifjHP/
/qsdQP3vdSnT1oVgSVzDfrWP0J0wvyisIQyfoPE5W/dKKGuXmIMxulFjs3U3jDc2
2oI8kR0LAJaBxA1XFdvEL/1ml2HHnbscIT4vH8qjN8YuL2MSXPhkEO6udO1q/6tN
C2oKN6fcJ57fLFexoy49gPt+jTypkLHXy0iocaK8KTgLyt/iiSQSIhdAvK0K0zhg
xyOPQmogfwuDVJuUockv9fa1+XuVXtyuqkYsul5c3408zkQ//Ig=
=gdhG
-----END PGP SIGNATURE-----

Hmm, no, sorry, I only did what I said I did...

... but since you tell me that you could not reproduce it, I have
recreated 3.1.0-2 from salsa and built it 20 times on machines
with 1 CPU and 20 times on machines with 2 CPUs, and it never failed,
so yes, the patch fixes the issue.

I also get such failure now (now 3.1.0-1 ftbfs all the time).
Maybe some build-dependency is to blame for that.

Thanks.