Summary: | dev-python/pylibacl-0.5.3: testEquivMode fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rolf Eike Beer <eike> |
Component: | Current packages | Assignee: | Robin Johnson <robbat2> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ago, mgorny, python |
Priority: | Normal | Keywords: | TESTFAILURE |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
pylibacl-0.5.3-endianness.patch x86.log |
Description
Rolf Eike Beer
![]() To be honest, I think this issue may actually be arch-specific. Could you reproduce it on some other arch in your arsenal? ;-) Ago, would you be able to run it through all arches under your disposal and let me know if some of them fail? happens the same on hppa (which also has more errors) > Traceback (most recent call last): > File "test/test_acls.py", line 189, in testEquivMode > self.assertEqual(acl.equiv_mode(), mode) > AssertionError: 0 != 420 It's an unstream endianness bug in acl.c where mode_t was assumed to be unsigned short. Fixed upstream in https://github.com/iustin/pylibacl/commit/2c3c52bcf087c25a5ce58a68968b53f985b77d73. Created attachment 632554 [details, diff]
pylibacl-0.5.3-endianness.patch
I'm confused. Why is your patch different than upstream's? Is it because of surrounding code, or does upstream still do it wrong? If just the former, I think it'd make more sense to do a snapshot. Created attachment 632628 [details]
x86.log
this is on x86
Upstream fixed it in a few iterations. Initially it used format string "H" (unsigned short) and mode_t* (unsigned int*) mismatch. Then moved away from "H" format string into using runtime inspection of the object type (API change). Probably to workaround obscure bugs caused in other system. Upstream's final state looks reasonable. But I did not succeed building upstream master with python2.7. I'm not sure I tried properly though. One-liner to match actual type passed for "H" format string looks least invasive without changing program's semantics. I've added 0.5.4 (which is the last release supporting Python 2) and the current snapshot. I'd appreciate if you could test both and compare the results. The snapshot passes tests, 0.5.4 fails with: FAIL: testNegativeQualifier (__main__.ModificationTests) Tests negative qualifier handling ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_acls.py", line 616, in testNegativeQualifier e.qualifier = qualifier AssertionError: OverflowError not raised |