David Miguel Susano Pinto, on 2025-01-23: > Étienne Mollier <emoll...@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 <emoll...@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
signature.asc
Description: PGP signature
