Patchwork glib-2.0: fix broken python script header on machines using buildtools

login
register
mail settings
Submitter Paul Eggleton
Date Sept. 20, 2013, 2:43 p.m.
Message ID <1379688225-29241-1-git-send-email-paul.eggleton@linux.intel.com>
Download mbox | patch
Permalink /patch/58441/
State Accepted
Commit 1d16e8035dda062041394b1e51839a9a7d077cf5
Headers show

Comments

Paul Eggleton - Sept. 20, 2013, 2:43 p.m.
With buildtools (which contains Python) installed on a build machine,
glib-2.0's gtester-report script was ending up with the full path to
the installed python binary in the shebang, which when rpm packaging
was used led to this being added as a per-file dependency by rpmdeps for
the libglib-2.0-utils package in which it ends up. This of course broke
do_rootfs when the package was included in the rootfs and had been
restored from sstate from another machine, as happened on the Yocto
Project autobuilder.

We were already trying to sed this script apparently only for the
shebang (since it appears that there are no other paths in the script)
so let's just sed the shebang properly; it also seems sensible to do
this for native as well instead of explicitly trying to exclude that
case.

Fixes [YOCTO #5205].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-core/glib-2.0/glib.inc | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
Colin Walters - Sept. 20, 2013, 4:04 p.m.
On Fri, 2013-09-20 at 15:43 +0100, Paul Eggleton wrote:
>  it also seems sensible to do
> this for native as well instead of explicitly trying to exclude that
> case.

But someone presumably introduced the explicit special case for native
for a reason, I'd expect some blame analysis to be done here to
determine whether those reasons were bogus or not.
Paul Eggleton - Sept. 20, 2013, 4:14 p.m.
Hi Colin,

On Friday 20 September 2013 12:04:15 Colin Walters wrote:
> On Fri, 2013-09-20 at 15:43 +0100, Paul Eggleton wrote:
> >  it also seems sensible to do
> > this for native as well instead of explicitly trying to exclude that
> > case.
> 
> But someone presumably introduced the explicit special case for native
> for a reason, I'd expect some blame analysis to be done here to
> determine whether those reasons were bogus or not.

I already did that as a matter of course; there is no clue in the message
for the commit that added it:

http://cgit.openembedded.org/openembedded-core/commit/?id=08fd9740b9359425ec6ee9810fab1152e9737b0c

Cheers,
Paul
Colin Walters - Sept. 20, 2013, 4:19 p.m.
On Fri, 2013-09-20 at 17:14 +0100, Paul Eggleton wrote:
> Hi Colin,
> 
> On Friday 20 September 2013 12:04:15 Colin Walters wrote:
> > On Fri, 2013-09-20 at 15:43 +0100, Paul Eggleton wrote:
> > >  it also seems sensible to do
> > > this for native as well instead of explicitly trying to exclude that
> > > case.
> > 
> > But someone presumably introduced the explicit special case for native
> > for a reason, I'd expect some blame analysis to be done here to
> > determine whether those reasons were bogus or not.
> 
> I already did that as a matter of course; there is no clue in the message
> for the commit that added it:
> 
> http://cgit.openembedded.org/openembedded-core/commit/?id=08fd9740b9359425ec6ee9810fab1152e9737b0c

Ok, well then I'd expect something in your commit message similar to
"There was no original rationale for why native was special cased, and I
think it should be safe to remove."

It might be still cached in Richard's brain of course...let's see =)
Richard Purdie - Sept. 20, 2013, 4:27 p.m.
On Fri, 2013-09-20 at 12:19 -0400, Colin Walters wrote:
> On Fri, 2013-09-20 at 17:14 +0100, Paul Eggleton wrote:
> > Hi Colin,
> > 
> > On Friday 20 September 2013 12:04:15 Colin Walters wrote:
> > > On Fri, 2013-09-20 at 15:43 +0100, Paul Eggleton wrote:
> > > >  it also seems sensible to do
> > > > this for native as well instead of explicitly trying to exclude that
> > > > case.
> > > 
> > > But someone presumably introduced the explicit special case for native
> > > for a reason, I'd expect some blame analysis to be done here to
> > > determine whether those reasons were bogus or not.
> > 
> > I already did that as a matter of course; there is no clue in the message
> > for the commit that added it:
> > 
> > http://cgit.openembedded.org/openembedded-core/commit/?id=08fd9740b9359425ec6ee9810fab1152e9737b0c
> 
> Ok, well then I'd expect something in your commit message similar to
> "There was no original rationale for why native was special cased, and I
> think it should be safe to remove."
> 
> It might be still cached in Richard's brain of course...let's see =)

That particular expression would have at best been a null operation for
the -native case. Its around release time so I probably fixed the thing
that was broken, no more, no less.

I'm fine with replacing it with something better.

Cheers,

Richard

Patch

diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc
index aa1d400..e57d2ac 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -46,7 +46,5 @@  ARM_INSTRUCTION_SET = "arm"
 USE_NLS = "yes"
 
 do_install_append () {
-	if [ "${PN}" != "glib-2.0-native" ]; then
-		sed ${D}${bindir}/gtester-report -i -e 's,${STAGING_BINDIR_NATIVE},${bindir},g'
-	fi
+	sed ${D}${bindir}/gtester-report -i -e '1s|^#!.*|#!/usr/bin/env python|'
 }