[OE-core] [oe-core] oprofile: avoid processing files under .pc

[McClintock Matthew-B29882]

On Fri, Feb 1, 2013 at 4:40 PM, Chris Larson <clarson at kergoth.com> wrote:
>
> On Fri, Feb 1, 2013 at 1:16 PM, McClintock Matthew-B29882
> <B29882 at freescale.com> wrote:
>>
>> On Fri, Feb 1, 2013 at 4:12 AM,  <b28495 at freescale.com> wrote:
>> > From: Ting Liu <b28495 at freescale.com>
>> >
>> > Fix the below issue:
>> > | DEBUG: Executing shell function do_configure
>> > | sed: can't read ./.pc/opstart.patch/doc/opstop.1.in: Permission denied
>> > | sed: can't read ./.pc/opstart.patch/doc/opstart.1.in: Permission
>> > denied
>> > | sed: can't read ./.pc/opstart.patch/utils/opstart.c: Permission denied
>> > | ERROR: Function failed: do_configure
>>
>> Permissions are messed up on these files, obviously:
>>
>> $ ls -alh .pc/opstart.patch/doc/
>> total 12K
>> drwxr-sr-x 2 jenkins jenkins 4.0K Jan 31 20:49 .
>> drwxr-sr-x 4 jenkins jenkins 4.0K Jan 31 20:49 ..
>> -rw-r--r-- 1 jenkins jenkins 2.5K Jan 31 20:49 Makefile.am
>> ---------- 1 jenkins jenkins    0 Jan 31 20:49 opstart.1.in
>> ---------- 1 jenkins jenkins    0 Jan 31 20:49 opstop.1.in
>>
>> But this was only occurring on one machine (our CentOS box). So, I've
>> actually isolated this down to the version of patch we were using
>> which is creating these new files with odd permissions.
>>
>> So, I'm not sure how to handle this - do we actually require a newer
>> version of patch? patch-native is assume provided and we can't just
>> remove that since we will get circular deps.
>>
>> Should we require the user upgrade patch on this old CentOS 5.x box? I
>> need to leave now so I'm leaving the problem here for now to see if
>> anyone else has a comment.
>
>
> This seems like a silly reason to require a newer patch version, when it's
> trivial to fix the recipe to not enter .pc, IMO. Nothing should be modifying
> files in there directly anyway.

Sounds good to me.

-M