(resetting autoremoval timer) On Fri, May 11, 2018 at 12:44:01PM -0500, Benjamin Kaduk wrote: > ping? > > I cannot reproduce locally either on bare metal or in schroot. > > -Ben > > On Fri, May 04, 2018 at 09:15:51AM -0500, Benjamin Kaduk wrote: > > Hi Lucas, > > > > On Wed, May 02, 2018 at 10:52:53PM +0200, Lucas Nussbaum wrote: > > > > > > During a rebuild of all packages in sid, your package failed to build on > > > amd64. > > > > > > Relevant part (hopefully): > > > > rx/perf.................ok > > > > volser/vos-man..........ok > > > > volser/vos..............FAILED 5 > > > > bucoord/backup-man......ok > > > > kauth/kas-man...........ok > > > > > > > > Failed Set Fail/Total (%) Skip Stat Failing Tests > > > > -------------------------- -------------- ---- ---- > > > > ------------------------ > > > > volser/vos 1/6 17% 0 0 5 > > > > Unfortunately the upstream build system does not capture verbose > > test output for display in case of failure, but from the test number > > we can deduce that what is failing is that an outputted list of > > addresses does not match the expected string: > > char expecting[] = "10.0.0.0\n10.0.0.1\n10.0.0.2\n10.0.0.3\n10.0.0.4\n" > > "10.0.0.5\n10.0.0.6\n10.0.0.7\n10.0.0.8\n10.0.0.9\n" > > "10.0.0.10\n10.0.0.11\n10.0.0.12\n10.0.0.13\n" > > "10.0.0.14\n10.0.0.15\n"; > > > > I note that this test is disabled when the system's hostname > > resolves to a loopback address because those addresses are forbidden > > from being entered into the database as fileserver addresses, but > > even when I change my local configuration to avoid that, I still > > cannot reproduce the test failure locally. > > > > I surmise that the AWS machine may be getting assigned a 10/8 > > address as its primary address, and perhaps that would interfere > > with some of what the test is doing. Do you happen to know more > > about the network configuration on the AWS systems used for these > > autopkgtests? > > > > Thanks, > > > > Ben
