[apparmor] [patch] [utils] Fix make check failure due to raw_input in ui.py

Kshitij Gupta kgupta8592 at gmail.com
Thu Oct 16 10:51:08 UTC 2014


Hello,

On Sat, Oct 11, 2014 at 3:04 AM, Steve Beattie <steve at nxnw.org> wrote:
> Hi Kshitij,
>
> Sorry for the delay in responding.
>
> On Mon, Sep 15, 2014 at 12:51:28AM +0530, Kshitij Gupta wrote:
>> The make check for utils was failing due to the raw_input being
>> present as a function (which it is not in Python3, even though it was
>> under an if else python version check).
>
> Part of the reason for a lack of urgency in responding to this issue is
> that I'm not seeing this failure locally. I'm guessing that you're
> seeing a pyflakes failure when running make check? I wonder if this is
> due to running an out of date pyflakes?
>
> I *do* see a current failure with pyflakes 0.5.0 (as packaged in ubuntu
> 12.04 LTS) when running make check:
>
Indeed, the issue was due to me running an older version of pyflakes
which caused the make check to fail.

Updating pyflakes fixed it.

Hence, this patch is not required.

Thanks!

Regards,

Kshitij Gupta

>   Checking apparmor
>   apparmor/yasti.py:20: redefinition of unused 'ycp' from line 17
>
> It looks like this can be worked around like so:
>
> === modified file 'utils/apparmor/yasti.py'
> --- utils/apparmor/yasti.py     2014-02-15 06:52:31 +0000
> +++ utils/apparmor/yasti.py     2014-10-10 21:02:53 +0000
> @@ -15,6 +15,7 @@
>  import sys
>  try:
>      import ycp
> +    ycp; # workaround for pyflakes issue #13
>  except ImportError:
>      # ycp isn't found everywhere.
>      ycp = None
>
> based on the comment at
> https://github.com/kevinw/pyflakes/issues/13#issuecomment-2144121 .
>
> That said, poking around, I don't see a specific bug report (open or
> closed) for your issue against pyflakes.
>
> I'm not opposed to the way you've addressed it here, as it
> makes the check more explicit (look for the existence of
> the function, rather than depend on the python version);
> it's slightly different than the route suggested at
> http://python3porting.com/differences.html#input-and-raw-input but
> that's okay. I do wonder how upstream python expected people to cope
> with renaming a builtin like this.
>
>> The following patch:
>> - checks the __builtins__ module for existence of raw_input and sets
>> it up for Python3
>>
>> Tested in aa-logprof and also with make check.
>> === modified file 'utils/apparmor/ui.py'
>> --- utils/apparmor/ui.py    2014-09-14 18:17:00 +0000
>> +++ utils/apparmor/ui.py    2014-09-14 19:22:56 +0000
>> @@ -28,6 +28,9 @@
>>  # The operating mode: yast or text, text by default
>>  UI_mode = 'text'
>>
>> +# If Python3 wrap input in raw_input so make check passes
>> +if not 'raw_input' in dir(__builtins__): raw_input = input
>> +
>>  ARROWS = {'A': 'UP', 'B': 'DOWN', 'C': 'RIGHT', 'D': 'LEFT'}
>>
>>  def getkey():
>> @@ -173,10 +176,7 @@
>>      if UI_mode == 'text':
>>          readline.set_startup_hook(lambda: readline.insert_text(default))
>>          try:
>> -            if sys.version_info[0] >= 3:
>> -                string = input('\n' + text)
>> -            else:
>> -                string = raw_input('\n' + text)
>> +            string = raw_input('\n' + text)
>>          except EOFError:
>>              string = ''
>>          finally:
>
> --
> Steve Beattie
> <sbeattie at ubuntu.com>
> http://NxNW.org/~steve/
>
> --
> AppArmor mailing list
> AppArmor at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
>



More information about the AppArmor mailing list