Dear maintainer:

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

[ Note: The bug is marked as fixed with the version in trixie/forky/sid, but
  packages in bookworm must still build in bookworm ].

[ Note: The package seems to build ok when using the unshare backend of sbuild,
  but this was not the default in bookworm yet ]

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/bookworm/

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.

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

Thanks.
--------------------------------------------------------------------------------
[...]
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
	/usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Bio::DB::RefSeq
Writing MYMETA.yml and MYMETA.json
   dh_auto_build
	make -j2
make[1]: Entering directory '/<<PKGBUILDDIR>>'
cp lib/Bio/DB/RefSeq.pm blib/lib/Bio/DB/RefSeq.pm
Manifying 1 pod document
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
   dh_auto_test
	make -j2 test TEST_VERBOSE=1
make[1]: Entering directory '/<<PKGBUILDDIR>>'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t
t/00-compile.t ...........
1..1
ok 1 - Bio/DB/RefSeq.pm loaded ok
ok
t/author-mojibake.t ...... skipped: these tests are for testing by the author
t/author-pod-coverage.t .. skipped: these tests are for testing by the author
t/author-pod-syntax.t .... skipped: these tests are for testing by the author

STACK toplevel t/RefSeq.t:21
-------------------------------------

# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.
t/RefSeq.t ...............
ok 1
Dubious, test returned 255 (wstat 65280, 0xff00)
All 1 subtests passed

Test Summary Report
-------------------
t/RefSeq.t             (Wstat: 65280 (exited 255) Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
Files=5, Tests=2,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.19 cusr  0.05 csys =  0.26 CPU)
Result: FAIL
Failed 1/5 test programs. 0/2 subtests failed.
make[1]: *** [Makefile:854: test_dynamic] Error 255
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
dh_auto_test: error: make -j2 test TEST_VERBOSE=1 returned exit code 2
make: *** [debian/rules:4: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
--------------------------------------------------------------------------------

Hi Santiago,

I'm sorry I have only rediscovered that bug during today's LHF
Perl session.  Since the ultimate Debian 12 point release, this
bug is not actionable anymore.  I consider closing it in order
to remove the entry off the Debian Med bugs panel.  At least I
mark it as "wontfix" to move the issue out of the main track of
serious bugs.  I hope that okay to you?

In any case, thanks for the report!

Have a nice day,  :)

tags 1137046 - wontfix
close 1137046 1.7.4-2
thanks

Yes, I agree.

I actually prefer closed to wontfix, assuming it also helps to clean
the bugs panel.

To me, "wontfix" conveys the idea that the cure is worse than the
disease, and it's something inherent to the bug itself.

In this case it's not that we don't want to fix the bug, it's that we
can't (a slightly different thing), because the Stable Release
Managers will not accept new uploads, but I guess the LTS team would
still be able to fix it if they wanted.

Also, if we had to use wontfix for all the bugs in bookworm that we
were unable to fix, we would have to use the tag a lot more, which
would not be nice. I have no problem with closing the bug, as the bug
was indeed fixed in a later upload.

Thanks.

Santiago Vila, on 2026-07-21:

Thanks for your thoughts on the matter and sorting the bug!
I agree it is much better this way.  :)

Have a nice day,  :)