1.7.1: self test failures on NetBSD

[0-wiz-0]

Reproduction steps

Build libgit2-1.7.1 on NetBSD 10.99.10/amd64, run the self tests.

Expected behavior

All tests pass.

Actual behavior

Test project /scratch/devel/libgit2/work/libgit2-1.7.1/cmake-pkgsrc-build
      Start  1: offline
 1/12 Test  #1: offline ..........................***Failed   87.86 sec
      Start  2: invasive
 2/12 Test  #2: invasive .........................***Failed    0.05 sec
...
83% tests passed, 2 tests failed out of 12

From the logfile:

worktree::worktree....................................

  1) Failure:
repo::init::extended_1 [/scratch/devel/libgit2/work/libgit2-1.7.1/tests/libgit2/repo/init.c:436]
  Function call failed: (git_repository_init_ext(&g_repo, "root/b/c.git", &opts))
  error -1 - failed to set permissions on 'root/b/c.git': Operation not permitted

  2) Failure:
repo::template::extended_with_template_and_shared_mode [/scratch/devel/libgit2/work/libgit2-1.7.1/tests/libgit2/repo/template.c:112]
  Function call failed: (git_repository_init_ext(&_repo, name, opts))
  error -1 - failed to set permissions on 'init_shared_from_tpl/.git': Operation not permitted

<end of output>

and

online::cloneS

  1) Failure:
repo::init::extended_1 [/scratch/devel/libgit2/work/libgit2-1.7.1/tests/libgit2/repo/init.c:436]
  Function call failed: (git_repository_init_ext(&g_repo, "root/b/c.git", &opts))
  error -1 - failed to set permissions on 'root/b/c.git': Operation not permitted

<end of output>

Version of libgit2 (release number or SHA1)

1.7.1

Operating system(s) tested

NetBSD/amd64

[ethomson]

I installed NetBSD 10.0 RC 1 and I cannot reproduce this. Are you running this in a somewhat odd environment where you cannot execute chmod for some reason?

[0-wiz-0]

I use an unprivileged user in a chroot for building and testing.
I've extended the error message a bit:

  1) Failure:
repo::init::extended_1 [/scratch/devel/libgit2/work/libgit2-1.7.1/tests/libgit2/repo/init.c:436]
  Function call failed: (git_repository_init_ext(&g_repo, "root/b/c.git", &opts))
  error -1 - failed to set permissions on 'root/b/c.git' from 40755 to 2775: Operation not permitted

  2) Failure:
repo::template::extended_with_template_and_shared_mode [/scratch/devel/libgit2/work/libgit2-1.7.1/tests/libgit2/repo/templ
ate.c:112]
  Function call failed: (git_repository_init_ext(&_repo, name, opts))
  error -1 - failed to set permissions on 'init_shared_from_tpl/.git' from 0 to 2775: Operation not permitted
...
  1) Failure:
repo::init::extended_1 [/scratch/devel/libgit2/work/libgit2-1.7.1/tests/libgit2/repo/init.c:436]
  Function call failed: (git_repository_init_ext(&g_repo, "root/b/c.git", &opts))
  error -1 - failed to set permissions on 'root/b/c.git' from 40755 to 2775: Operation not permitted

Why does it try to set setgid?

Is there way to take a look at the final state of the test directory (e.g. owner/group)? Perhaps my unprivileged user is not in the right group to use setgid.

[ethomson]

These particular tests try to emulate git init —shared, which:

Make the repository group-writable, (and g+sx, since the git group may be not the primary group of all users)

I agree that your constrained environment probably lacks the ability to do this.

We could add an environment variable in the tests that will skip these sorts of tests, that you could set. 🤔

[0-wiz-0]

I'm still a bit confused about the details, since all the files belong to the same user and its main group, and ctest is started by that user.
But the tests succeed when I try it outside of this environment.
Probably not worth the effort with the environment variable, thanks for explaining the details.

[ethomson]

OK. It's not too much trouble, really, so let me know if you change your mind.

One thing that's difficult, I suspect, for people who build packages for distributions (and perhaps that's what you're doing) is that tests fail because we have a lot that exercise a lot of cases. If I were doing this, I would want 100% tests passing to feel confident about my package but I would also be building in an environment that may artificially limit the ability of tests to run.

I want the people building packages to have high confidence in their builds.

[0-wiz-0]

Well, if you're offering and it's easy, then yes, please.
I didn't want to impose, but of course it's easier for me to set an environment variable for a package instead of having to remember that it's ok that two tests fail.

Thank you!