Hi, On Tue, Dec 30, 2014 at 07:14:41PM +1100, Russell Sim wrote: > >> 1) Failure: > >> repo::iterator::fs_preserves_error > >> [/tmp/libgit2-0.21.1/tests/repo/iterator.c:952] > >> Expected function call to fail: git_iterator_advance(&e, i) > > > > This problem is only occurs when running is root (the test chmods a file to > > 000 and checks if accessing it fails). It would probably be a good idea to > > add > > another test to check if the test is running as root, and fail in that case > > (because the tests assume they aren't). > > Interesting I didn't know that the user running the tests was the > problem. Is that a problem with the buildd deployments? Or is it not a > requirement that they all run as the same user? I guess what I'm really > asking is if I add a test who will fix it when it fails?
The buildd's never run builds as root. This issue was only reported by people running the build manually (as root, apparently). I suggested added a check for this, to avoid people losing time debugging this. Another option would be to simply disable this test, or to disable it when running as root. > > The failure that happens on the i386 buildd is this one: > > > > 1) Failure: > > clone::nonetwork::local_absolute_path > > [/«PKGBUILDDIR»/tests/clone/nonetwork.c:91] > > Function call failed: (git_clone(&g_repo, local_src, "./foo", &g_options)) > > error -1 - git_path_direach callback returned -1 > > > > > > I can reproduce this in my test environment on i386 and amd64. It only > > happens > > when the builddir and /tmp are on different filesystems. It seems the local > > clone tries to create a hard link, which fails across filesystems (the fact > > that this happens without fallback is an error in itself, so the test > > actually > > discovered a problem here). When setting the TMPDIR to a directory on the > > same > > filesystem, the test doesn't hit this issue, and the build works fine. > > > > It's unclear to me why this only happens on i386, but I suspect that the > > setup > > of the buildd chroots isn't the same everywhere. > > Yeah it struck me as odd. This same problem effects kfreebsd too so the > change of the tmp dir will fix those builds as well. I'll have go at the > running the clone nonetwork test with TMPDIR set to a mounted file > system and report a bug upstream. > > > In any case, adding this patch fixes it in my environment. I can do an NMU > > if > > necessary. > > Thanks heaps for the patch, I only yesterday did exactly the same > thing. It's included in the yet to be uploaded 0.21.3-1 that will also > address the recent CVE. > > 0. > http://anonscm.debian.org/cgit/users/arrsim-guest/libgit2.git/commit/?id=bd3a1fc82c5af703fe061fb22022eb48fb89be50 Does the tmp-test dir get cleaned up in the clean target? Also, please note that most of the changes in the latest uploads probably don't comply with the freeze policy. If you think they do, you need to file an unblock request explaining why (including a debdiff). https://release.debian.org/jessie/freeze_policy.html I guess #761170 and #761539 should be unmerged, as they are really different issues. Bug #761170 should be downgraded back to important. Adding support for new architectures isn't something that is allowed during the freeze. The only real issue for the version in testing is #761539, which is about clone::nonetwork::local_absolute_path, which can be fixed by setting the tmp dir. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
