Hi Santiago,
Santiago Vila wrote:
> t/lsof-force.t ............................. ok
> # File [t/RzW1OPQy83/1/.foobar/fnord] does not exist
>
> # Failed test 't/RzW1OPQy83/1/.foobar/fnord exists'
> # at t/lsof.t line 20.
> # File [t/RzW1OPQy83/2/WjZOoAFGuoIq-foobar/fnord] exists
>
> # Failed test 't/RzW1OPQy83/2/WjZOoAFGuoIq-foobar/fnord does not exist'
> # at t/lsof.t line 21.
> # Looks like you failed 2 tests of 8.
> t/lsof.t ...................................
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/8 subtests
[...]
> t/lsof.t (Wstat: 512 Tests: 8 Failed: 2)
> Failed tests: 7-8
> Non-zero exit status: 2
> Files=29, Tests=543, 8 wallclock secs ( 0.17 usr 0.04 sys + 6.76 cusr
> 0.88 csys = 7.85 CPU)
[...]
> This always fail for me on different autobuilders, using sbuild with
> union-type=overlay, but it does not fail on reproducible builds, and
> it does not fail without union-type=overlay.
Thanks for the report.
On a first glance this looks to me as if lsof does not work properly
or at least not as expected with overlayfs.
Is there a way to detect if overlayfs is used so that I can skip that
test like I do in t/lsof-force.t with builds on NFS:
| SKIP: {
| skip "Can't test lsof forcing on NFS", 8 if
| (-x which('df') and grep { /\bnfs\b/ } `df -T .`);
Then again, this probably also means that unburden-home-dir won't work
properly for some cases on overlayfs. I have no idea if the use case
of overlayfs intersects with the use cases of unburden-home-dir, so
I'm not sure if I should just ignore the fact, if lsof needs to be
fixed or if this is a real potential issue.
> Would you consider making the next upload in source-only form, just to
> be sure that this is buildable in the official buildds?
Should be possible.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
