Summary: | dev-python/pyxattr-0.5.0 fails tests on system without xattr support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Myckel Habets (work) <m.e.j.habets> |
Component: | [OLD] Library | Assignee: | Robin Johnson <robbat2> |
Status: | IN_PROGRESS --- | ||
Severity: | minor | CC: | nikoli, pacho, phajdan.jr, python |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 714478 | ||
Attachments: | skip tests if we cannot set extended attributes |
Description
Myckel Habets (work)
2010-04-14 14:39:15 UTC
Hmm, I'm tempted to just disable src_test entirely in this case, as I'm not sure of any reliable test to find our present mountpoint, and then test for it having xattr support. Python team: any opinions? (In reply to comment #1) Maybe create a test file in "${T}" and check if setfattr on this file succeeds. *** Bug 321229 has been marked as a duplicate of this bug. *** Fixed in Progress Overlay. (In reply to comment #1) > Hmm, I'm tempted to just disable src_test entirely in this case, as I'm not > sure of any reliable test to find our present mountpoint, and then test for > it having xattr support. > > Python team: > any opinions? This seems to be working as intended. The python xattr support would not be able to function without xattr so the test are failing correctly. I would suggest closing this as RESOLVED INVALID except it is useful to leave it open so people can search for it. Created attachment 310175 [details] skip tests if we cannot set extended attributes I agree with comment #2: if setting an extended attribute fails with EOPNOTSUPP we should assume the filesystem lacks support and skip the tests. I can't think of a nice way of being that specific without using pyxattr, which would be a bit circular. So I'd suggest something like this, which just sets an attribute using the "attr" utility (which we must depend on for libattr anyway) and assumes failure is caused by missing filesystem support. I've tested this by building on tmpfs (which misses xattr support on my kernel) and ext4 (which has it). It seems to work. Python 3 fails the tests, but that's an unrelated problem I think should be upstreamed. Are you ok with me committing this? (In reply to comment #6) > Created attachment 310175 [details] > skip tests if we cannot set extended attributes > > I agree with comment #2: if setting an extended attribute fails with > EOPNOTSUPP we should assume the filesystem lacks support and skip the tests. > I can't think of a nice way of being that specific without using pyxattr, > which would be a bit circular. So I'd suggest something like this, which > just sets an attribute using the "attr" utility (which we must depend on for > libattr anyway) and assumes failure is caused by missing filesystem support. > > I've tested this by building on tmpfs (which misses xattr support on my > kernel) and ext4 (which has it). It seems to work. Python 3 fails the tests, > but that's an unrelated problem I think should be upstreamed. > > Are you ok with me committing this? Hmm, using 'attr' means the ebuild needs to dep on sys-apps/attr, I think. I'm wondering if it wouldn't be enough to add a minimal Python snippet which would try to use the lib and check for appropriate errno. Or, even better, fix the test suite to 'skip' tests in that case. I have partially addressed the issue in -r1 through adding an 'einfo' before the test phase and setting TESTDIR=/var/tmp. This will make the tests meaningful on systems where /tmp is tmpfs but /var/tmp is a regular filesystem with xattr support. It's not a perfect solution, though. This is happening en masse on tmpfs in 0.7.1 again, while 0.6.0-r1 all passed (or perhaps skipped) on tmpfs |