Bug#1093338: libbio-eutilities-perl: FTBFS: Failed 8/20 test programs. 0/174 subtests failed.

[Étienne Mollier]

David Miguel Susano Pinto, on 2025-01-23:
> Étienne Mollier <emollier at debian.org> writes:
>> Again, thanks for your thoughts on the issue, as discussed in
>> the issue tracker upstream, this turns out to be a Debian
>> specific problem.  After further investigations, it seems to
>> originate from debian/patches/inline-DTDs-on-testsuite.  If I
>> remove such patch, the build goes through upon build time test.
> 
> It happens that I wrote that patch :)

Thanks for the patches by the way, note that despite the
behavioral change not in favor of keeping it applied, I believe
that the resolution of the issue could still rely on having the
inlined schemas.

>> […] I'm not supposed to have
>> much more network access from my build environment than from my
>> autopkgtest environment, […]

I thought a second time about what I wrote yesterday and ended
up wondering: "is that really true?"  On yesterday's setup,
there was actually a tiny little more network in autopkgtest
context than in build context.  See below for the details.

> What's happening here is that the XML parsers download the DTD
> associated with the XML files (the DTD declares the structure of the XML
> file which is used to validade it).  To avoid requiring internet
> connection during the tests in Debian, those DTD are inlined.
> 
> Still don't know why it was working before and not anymore.

The more I dig into this, the more I run into subtle behavioral
changes from one type of package isolation environment to
another among options to isolate packaging environments in
Debian.  The thing is: I have rerun my autopkgtest integration
suite this evening, but have migrated my isolation engine in use
yesterday to one that aligns with the isolation in use with the
build environment.  Tonight's autopkgtest run passed with
success while yesterday's didn't.  For reference, the build was
run with sbuild using "unshare" isolation, while my autopkgtest
run still involved the former "schroot" isolation mode.

Between the two, the "unshare" mode relies on Linux namespaces
which hides away the system's network card, while "schroot" is
much closer to the classical chroot, wrapped with many helpers.
I lack resolver configuration in my schroot, which captures
certain attempts to access the network, but not all possible
sorts of attempts, and that difference may be sufficient to
trigger an attempt to fetch the missing schema in the "schroot"
case I guess.

This is just a conjecture I have not verified, but it may be
possible that the XML engine does not attempt at all validating
the schemas when there is no chance of having a working network
to fetch the DTD.  It might explain why the tests would pass.

> As a side note, the PurePerl XML parser is being used which is the
> fallback, slowest, not recommended (from the Debian package description)
> parser.  So maybe other parsers should be recommended.

Perhaps, do you have particular implementations in mind?  That
would be helpful to populate Recommends or Suggests fields.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <emollier at debian.org>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-    on air: Camel - The Great Marsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20250123/d0fd8e00/attachment.sig>