Hello,
Am Donnerstag, 13. August 2015 schrieb Steve Beattie:
> I'm currently in a situation where I don't have easy accesss to my
> regular environment, but I'm getting failures when running the tests
> with python2, like so:
>
> ======================================================================
> ERROR: test_44306 (__main__.TestParseParserTests) test '{'exresult':
> u'PASS', 'tools_wrong': False, 'relfile': 'rlimits/ok_rlimit_01.sd',
> 'disabled': False, 'file':
> '/home/steve/bzr/apparmor/parser/tst/simple_tests/rlimits/ok_rlimit_0
> 1.sd', 'todo': False}'
...
> File "/home/steve/bzr/apparmor/utils/apparmor/rule/rlimit.py", line
> 66, in __init__ raise AppArmorBug('Passed unknown object to
> RlimitRule: %s' % str(rlimit)) AppArmorBug: Passed unknown object to
> RlimitRule: cpu
>
> ----------------------------------------------------------------------
>
> I don't *think* it's due to a quirk in my setup. With python3, it
> passes all tests.
That looks like something Kshitij reported on IRC on June 18th, but we
somehow failed to make a proper bugreport or patch out of it.
The problem is: You'll get a type() of "unicode" with py2, while it's
"str" in py3. To make things even more interesting, py3 doesn't know
anything about "unicode" and will throw a NameError if it hits that part
of the condition. So basically you'll need to change all conditions like
elif type(domain) == str:
to
elif type(domain) == str or (py_2 and type(domain) == unicode):
# py2 is pseudocode - in reality, you need to check sys.version
You'll find those checks in all rule classes, and usually more than one
of them.
Needless to say that the check looks a bit ugly and we need it in all
rule classes - so if we want to fix it, we should wrap it as a
is_string_in_this_py_version() function.
> (Granted, I would like to deprecate python2 in 2.11, making python3
> preferred, and then drop python2 support in 2.11+1.)
With the issue described above, 2.10 accidently is py3 only. So I tend
to wait for bugreports [1] - and if we don't receive any, just silently
require py3 instead of making the code a bit more ugly ;-)
BTW: are there any distributions that use the tools with py2?
(openSUSE and Debian both use py3.)
Regards,
Christian Boltz
[1] starting aa-logprof with py2 should be enough to trigger the problem
--
I've chosen Suse for over 10 years, despite knowing that my computer
would be safest, enclosed in several feet of cement -- but it's really
hard to use that way... ;-) [Linda Walsh in opensuse-factory]
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
