[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[David Owens]

When the output directory is nested under a long path name, calling the
gdbus-codegen, glib-genmarshal, or glib-mkenums scripts throws the
error:

> '/usr/bin/env: /...: No such file or directory'

This is because libglib2 uses the absolute path to the python
interpreter for its shebang statements, and shebangs have a max length
of 127 chars[1]. A long absolute path will be cut off and appear as a
missing file.

Since the host Python is present in the $PATH passed to all packages, we
can copy the workaround from Yocto and just use the python interpreter
in $PATH[2]. However, 'python' is used instead of 'python3' as the
scripts are compatible with both.

[1] https://linux.die.net/man/2/execve
[2] http://cgit.openembedded.org/openembedded-core/commit/?id=eef7883587acc933d6f34b559ec03ff84d18573b

Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: David Owens <david.owens@rockwellcollins.com>
---
 ...t-hardcode-python-path-into-various-tools.patch | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 package/libglib2/0004-Do-not-hardcode-python-path-into-various-tools.patch

diff --git a/package/libglib2/0004-Do-not-hardcode-python-path-into-various-tools.patch b/package/libglib2/0004-Do-not-hardcode-python-path-into-various-tools.patch
new file mode 100644
index 0000000..aadd050
--- /dev/null
+++ b/package/libglib2/0004-Do-not-hardcode-python-path-into-various-tools.patch
@@ -0,0 +1,48 @@
+From b9160d951b9af647b97766c57295ca4f45cf9521 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin <alex.kanavin@gmail.com>
+Date: Tue, 3 Oct 2017 10:45:55 +0300
+Subject: [PATCH 10/10] Do not hardcode python path into various tools
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+Fetch from:
+http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/glib-2.0/glib-2.0/0010-Do-not-hardcode-python-path-into-various-tools.patch?id=eef7883587acc933d6f34b559ec03ff84d18573b
+---
+ gio/gdbus-2.0/codegen/gdbus-codegen.in | 2 +-
+ gobject/glib-genmarshal.in             | 2 +-
+ gobject/glib-mkenums.in                | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/gio/gdbus-2.0/codegen/gdbus-codegen.in b/gio/gdbus-2.0/codegen/gdbus-codegen.in
+index 8050981..e693ef3 100644
+--- a/gio/gdbus-2.0/codegen/gdbus-codegen.in
++++ b/gio/gdbus-2.0/codegen/gdbus-codegen.in
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env @PYTHON@
++#!/usr/bin/env python
+ 
+ # GDBus - GLib D-Bus Library
+ #
+diff --git a/gobject/glib-genmarshal.in b/gobject/glib-genmarshal.in
+index 09e8408..b2f9d99 100755
+--- a/gobject/glib-genmarshal.in
++++ b/gobject/glib-genmarshal.in
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env @PYTHON@
++#!/usr/bin/env python
+ 
+ # pylint: disable=too-many-lines, missing-docstring, invalid-name
+ 
+diff --git a/gobject/glib-mkenums.in b/gobject/glib-mkenums.in
+index d4bfd11..051fce4 100755
+--- a/gobject/glib-mkenums.in
++++ b/gobject/glib-mkenums.in
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env @PYTHON@
++#!/usr/bin/env python
+ 
+ # If the code below looks horrible and unpythonic, do not panic.
+ #
+-- 
+2.14.1
+
-- 
1.9.1

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Thomas Petazzoni]

Hello,

On Thu, 12 Jul 2018 11:37:34 -0500, David Owens wrote:
> When the output directory is nested under a long path name, calling the
> gdbus-codegen, glib-genmarshal, or glib-mkenums scripts throws the
> error:
> 
> > '/usr/bin/env: /...: No such file or directory'  
> 
> This is because libglib2 uses the absolute path to the python
> interpreter for its shebang statements, and shebangs have a max length
> of 127 chars[1]. A long absolute path will be cut off and appear as a
> missing file.
> 
> Since the host Python is present in the $PATH passed to all packages, we
> can copy the workaround from Yocto and just use the python interpreter
> in $PATH[2]. However, 'python' is used instead of 'python3' as the
> scripts are compatible with both.
> 
> [1] https://linux.die.net/man/2/execve
> [2] http://cgit.openembedded.org/openembedded-core/commit/?id=eef7883587acc933d6f34b559ec03ff84d18573b
> 
> Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
> Signed-off-by: David Owens <david.owens@rockwellcollins.com>
> ---
>  ...t-hardcode-python-path-into-various-tools.patch | 48 ++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>  create mode 100644 package/libglib2/0004-Do-not-hardcode-python-path-into-various-tools.patch

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Anisse Astier]

Hi,

We just hit this issue with the buildroot-2018.02 branch. Is this is the
scope of LTS-backportable patches ?

Otherwise it's very easy to take the patch in an external, but I'm
guessing it might break other builds somewhere.

Regards,

Anisse


On Wed, Jul 18, 2018 at 05:18:43PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 12 Jul 2018 11:37:34 -0500, David Owens wrote:
> > When the output directory is nested under a long path name, calling the
> > gdbus-codegen, glib-genmarshal, or glib-mkenums scripts throws the
> > error:
> > 
> > > '/usr/bin/env: /...: No such file or directory'  
> > 
> > This is because libglib2 uses the absolute path to the python
> > interpreter for its shebang statements, and shebangs have a max length
> > of 127 chars[1]. A long absolute path will be cut off and appear as a
> > missing file.
> > 
> > Since the host Python is present in the $PATH passed to all packages, we
> > can copy the workaround from Yocto and just use the python interpreter
> > in $PATH[2]. However, 'python' is used instead of 'python3' as the
> > scripts are compatible with both.
> > 
> > [1] https://linux.die.net/man/2/execve
> > [2] http://cgit.openembedded.org/openembedded-core/commit/?id=eef7883587acc933d6f34b559ec03ff84d18573b
> > 
> > Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
> > Signed-off-by: David Owens <david.owens@rockwellcollins.com>
> > ---
> >  ...t-hardcode-python-path-into-various-tools.patch | 48 ++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 package/libglib2/0004-Do-not-hardcode-python-path-into-various-tools.patch
> 
> Applied to master, thanks.
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Thomas Petazzoni]

Hello,

+Peter in Cc.

On Thu, 19 Jul 2018 09:58:42 +0200, Anisse Astier wrote:

> We just hit this issue with the buildroot-2018.02 branch. Is this is the
> scope of LTS-backportable patches ?
> 
> Otherwise it's very easy to take the patch in an external, but I'm
> guessing it might break other builds somewhere.

I think it definitely makes sense to have it in 2018.02.x, so I guess
Peter will backport it there.

However, it would be nice if someone could try to push this
upstream. The OE patch says it's not appropriate for upstream, but I
disagree, the fact that the shebang can be too long is a real problem,
and if both OE and Buildroot have to fix it, upstream should
(hopefully) be interested in finding a solution.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Peter Korsgaard]

>>>>> "Anisse" == Anisse Astier <anisse@astier.eu> writes:

 > Hi,
 > We just hit this issue with the buildroot-2018.02 branch. Is this is the
 > scope of LTS-backportable patches ?

 > Otherwise it's very easy to take the patch in an external, but I'm
 > guessing it might break other builds somewhere.

Yes, I'll backport to 2018.02.x and 2018.05.x. I'm running a bit behind
though (synched around July 1st), so it will take a few days.

Does the patch apply as is to 2018.02.x? Have you verified that it fixes
the issue for you on 2018.02.x?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[anisse at astier.eu]

On Thu, Jul 19, 2018 at 10:04:56AM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> +Peter in Cc.
> 
> On Thu, 19 Jul 2018 09:58:42 +0200, Anisse Astier wrote:
> 
> > We just hit this issue with the buildroot-2018.02 branch. Is this is the
> > scope of LTS-backportable patches ?
> > 
> > Otherwise it's very easy to take the patch in an external, but I'm
> > guessing it might break other builds somewhere.
> 
> I think it definitely makes sense to have it in 2018.02.x, so I guess
> Peter will backport it there.
> 
> However, it would be nice if someone could try to push this
> upstream. The OE patch says it's not appropriate for upstream, but I
> disagree, the fact that the shebang can be too long is a real problem,
> and if both OE and Buildroot have to fix it, upstream should
> (hopefully) be interested in finding a solution.
> 

I opened an issue upstream:
https://gitlab.gnome.org/GNOME/glib/issues/1455

Upstream is already working on a solution, but it might only be fixed in
the meson build:
https://gitlab.gnome.org/GNOME/glib/merge_requests/187

Which will require moving the package from autotools to meson.

Regards,

Anisse

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[anisse at astier.eu]

On Thu, Jul 19, 2018 at 01:04:10PM +0200, Peter Korsgaard wrote:
> >>>>> "Anisse" == Anisse Astier <anisse@astier.eu> writes:
> 
>  > Hi,
>  > We just hit this issue with the buildroot-2018.02 branch. Is this is the
>  > scope of LTS-backportable patches ?
> 
>  > Otherwise it's very easy to take the patch in an external, but I'm
>  > guessing it might break other builds somewhere.
> 
> Yes, I'll backport to 2018.02.x and 2018.05.x. I'm running a bit behind
> though (synched around July 1st), so it will take a few days.
> 
> Does the patch apply as is to 2018.02.x? Have you verified that it fixes
> the issue for you on 2018.02.x?

Yes, I have verified that the patch applies cleanly to libglib2 2.54.2
(the version in the 2018.02.x branch), and that it fixes the build of
json-glib, a package that was affected by the issue.

Regards,

Anisse

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Thomas Petazzoni]

Hello,

On Thu, 19 Jul 2018 13:50:33 +0200, anisse at astier.eu wrote:

> I opened an issue upstream:
> https://gitlab.gnome.org/GNOME/glib/issues/1455

In this, they say that using "python" is not correct, because python3
is needed to run libglib python code. Is this correct ? If that is
correct, then our patch in package/libglib2/ is not good, as it uses
just python, which might be python2.

And also, it's not correct because our libglib package does not depend
on having python3 available on the host.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[anisse at astier.eu]

On Thu, Jul 19, 2018 at 02:15:57PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 19 Jul 2018 13:50:33 +0200, anisse at astier.eu wrote:
> 
> > I opened an issue upstream:
> > https://gitlab.gnome.org/GNOME/glib/issues/1455
> 
> In this, they say that using "python" is not correct, because python3
> is needed to run libglib python code. Is this correct ? If that is
> correct, then our patch in package/libglib2/ is not good, as it uses
> just python, which might be python2.
> 
> And also, it's not correct because our libglib package does not depend
> on having python3 available on the host.
> 

My understanding is that the scripts work with python2 too but that
upstream is moving to python3 by default, because meson already requires
host python3, which narrows the number of build-time dependencies.

So I don't think there's anything to change here, since host python2 is
already a mandatory buidroot dependency.

Regards,

Anisse

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Thomas Petazzoni]

Hello,

On Thu, 19 Jul 2018 14:58:28 +0200, anisse at astier.eu wrote:

> > And also, it's not correct because our libglib package does not depend
> > on having python3 available on the host.
> 
> My understanding is that the scripts work with python2 too but that
> upstream is moving to python3 by default, because meson already requires
> host python3, which narrows the number of build-time dependencies.

OK, understood.

> So I don't think there's anything to change here, since host python2 is
> already a mandatory buidroot dependency.

Yes, that is correct. What I wasn't sure is if libglib2 needed any
version of python, or specifically python3.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] libglib2: Avoid absolute path to python in shebang

[Peter Korsgaard]

>>>>> "David" == David Owens <david.owens@rockwellcollins.com> writes:

 > When the output directory is nested under a long path name, calling the
 > gdbus-codegen, glib-genmarshal, or glib-mkenums scripts throws the
 > error:

 >> '/usr/bin/env: /...: No such file or directory'

 > This is because libglib2 uses the absolute path to the python
 > interpreter for its shebang statements, and shebangs have a max length
 > of 127 chars[1]. A long absolute path will be cut off and appear as a
 > missing file.

 > Since the host Python is present in the $PATH passed to all packages, we
 > can copy the workaround from Yocto and just use the python interpreter
 > in $PATH[2]. However, 'python' is used instead of 'python3' as the
 > scripts are compatible with both.

 > [1] https://linux.die.net/man/2/execve
 > [2] http://cgit.openembedded.org/openembedded-core/commit/?id=eef7883587acc933d6f34b559ec03ff84d18573b

 > Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
 > Signed-off-by: David Owens <david.owens@rockwellcollins.com>

Committed to 2018.02.x and 2018.05.x, thanks.

-- 
Bye, Peter Korsgaard