On Fri, Feb 1, 2013 at 1:16 PM, McClintock Matthew-B29882 < b29...@freescale.com> wrote:
> On Fri, Feb 1, 2013 at 4:12 AM, <b28...@freescale.com> wrote: > > From: Ting Liu <b28...@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
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
