Patchwork oprofile: avoid processing files under .pc

login
mail settings
Submitter Ting Liu
Date Feb. 1, 2013, 10:12 a.m.
Message ID <1359713558-22689-1-git-send-email-b28495@freescale.com>
Download mbox | patch
Permalink /patch/43807/
State Accepted
Commit d1003ea86543ce5d09c163db95e9e723aa1adc10
Headers show

Comments

Ting Liu - Feb. 1, 2013, 10:12 a.m.
From: Ting Liu <b28495@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

Signed-off-by: Ting Liu <b28495@freescale.com>
---
 meta/recipes-kernel/oprofile/oprofile.inc |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
McClintock Matthew-B29882 - Feb. 1, 2013, 8:16 p.m.
On Fri, Feb 1, 2013 at 4:12 AM,  <b28495@freescale.com> wrote:
> From: Ting Liu <b28495@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.

-M

>
> Signed-off-by: Ting Liu <b28495@freescale.com>
> ---
>  meta/recipes-kernel/oprofile/oprofile.inc |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-kernel/oprofile/oprofile.inc b/meta/recipes-kernel/oprofile/oprofile.inc
> index d6d20ae..b09aaf8 100644
> --- a/meta/recipes-kernel/oprofile/oprofile.inc
> +++ b/meta/recipes-kernel/oprofile/oprofile.inc
> @@ -19,7 +19,7 @@ FILES_${PN} = "${bindir} ${libdir}/${BPN}/lib*${SOLIBS} ${datadir}/${BPN}"
>  FILES_${PN}-dev += "${libdir}/${BPN}/lib*${SOLIBSDEV} ${libdir}/${BPN}/lib*.la"
>  FILES_${PN}-staticdev += "${libdir}/${BPN}/lib*.a"
>
> -INC_PR = "r1"
> +INC_PR = "r2"
>
>  SRC_URI = "file://opstart.patch \
>             file://oprofile-no-query-modules.patch \
> @@ -30,7 +30,7 @@ inherit autotools
>
>  EXTRA_OECONF = "--with-kernel=${STAGING_KERNEL_DIR}  --without-x"
>  do_configure () {
> -       find . -type f | xargs sed -i 's#ROOTHOME#${ROOT_HOME}#'
> +       find . -wholename './.pc' -prune -o -type f -print | xargs sed -i 's#ROOTHOME#${ROOT_HOME}#'
>         cp ${WORKDIR}/acinclude.m4 ${S}/
>         autotools_do_configure
>  }
> --
> 1.7.5.4
>
Chris Larson - Feb. 1, 2013, 10:40 p.m.
On Fri, Feb 1, 2013 at 1:16 PM, McClintock Matthew-B29882 <
B29882@freescale.com> wrote:

> On Fri, Feb 1, 2013 at 4:12 AM,  <b28495@freescale.com> wrote:
> > From: Ting Liu <b28495@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.
McClintock Matthew-B29882 - Feb. 4, 2013, 4:09 p.m.
On Fri, Feb 1, 2013 at 4:40 PM, Chris Larson <clarson@kergoth.com> wrote:
>
> On Fri, Feb 1, 2013 at 1:16 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>>
>> On Fri, Feb 1, 2013 at 4:12 AM,  <b28495@freescale.com> wrote:
>> > From: Ting Liu <b28495@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

Patch

diff --git a/meta/recipes-kernel/oprofile/oprofile.inc b/meta/recipes-kernel/oprofile/oprofile.inc
index d6d20ae..b09aaf8 100644
--- a/meta/recipes-kernel/oprofile/oprofile.inc
+++ b/meta/recipes-kernel/oprofile/oprofile.inc
@@ -19,7 +19,7 @@  FILES_${PN} = "${bindir} ${libdir}/${BPN}/lib*${SOLIBS} ${datadir}/${BPN}"
 FILES_${PN}-dev += "${libdir}/${BPN}/lib*${SOLIBSDEV} ${libdir}/${BPN}/lib*.la"
 FILES_${PN}-staticdev += "${libdir}/${BPN}/lib*.a"
 
-INC_PR = "r1"
+INC_PR = "r2"
 
 SRC_URI = "file://opstart.patch \
            file://oprofile-no-query-modules.patch \
@@ -30,7 +30,7 @@  inherit autotools
 
 EXTRA_OECONF = "--with-kernel=${STAGING_KERNEL_DIR}  --without-x"
 do_configure () {
-	find . -type f | xargs sed -i 's#ROOTHOME#${ROOT_HOME}#'
+	find . -wholename './.pc' -prune -o -type f -print | xargs sed -i 's#ROOTHOME#${ROOT_HOME}#'
 	cp ${WORKDIR}/acinclude.m4 ${S}/
 	autotools_do_configure
 }