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

[Chris Larson]

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.
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130201/7016be6d/attachment-0002.html>