Hi Simon,
In this case I guess we could make tests optional so that the whole build will
not fail even if there's some test failures. In this way at lease we could
have some usable libraries in the archive.
The patch would be pretty simple by adding the following lines in
debian/rules:
override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-dh_auto_test
endif
I'm currently working on eliminating dependency on package "multiarch-support"
for all other packages currently in Debian archive [1]. By applying the patch
above, I guess we could fix that problem (at least for now).
Thanks,
Boyuan Yang
[1] https://lists.debian.org/debian-glibc/2019/07/msg00040.html
在 2019-07-24三的 19:44 +0200，Simon Richter写道：
> Hi,
>
> On Wed, Jul 24, 2019 at 01:30:26PM -0400, Boyuan Yang wrote:
>
> > I tried to rebuild this package in my local sbuild chroot and the result
> > appears to be successful. I plan to make a (no-change) NMU upload onto Sid
> > to
> > see if a sourceful rebuild would solve this issue.
>
> This is an error caused by network environment. The "find" test runs both
> an Avahi lookup and an USB scan (but largely ignores the results, as none
> of the devices found during that scan matches the "DUMMY" filter),
> depending on the autobuilder configuration that triggers a security policy,
> which makes the test fail.
>
> I have no really good idea how to keep the test meaningful and stop it from
> failing in more restricted environments. Note that the FTBFS happened
> during a QA rebuild, the packages in the archive are fine, so an unchanged
> source NMU would not fix the problem.
>
> Simon
>
