On Fri, Feb 1, 2013 at 4:40 PM, Chris Larson <clar...@kergoth.com> wrote: > > 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.
Sounds good to me. -M _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
