libglib2: Avoid absolute path to python in shebang
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
When the output directory is nested under a long path name, calling the gdbus-codegen, glib-genmarshal, or glib-mkenums scripts throws the error:
Quoted 1 line
'
/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
--- ...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
package/libglib2/0004-Do-not-hardcode-python-path-into-various-tools.patch new file +48 -0
@@ -0,0 +1,48 @@ +From b9160d951b9af647b97766c57295ca4f45cf9521 Mon Sep 17 00:00:00 2001 +From: Alexander Kanavin <[email protected]> +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 <[email protected]> +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 +
Signature · 1 line
1.9.1
Thomas Petazzoni
AppliedPATCH 1/1 libglib2: Avoid absolute path to python in shebang
Hello,
Quoted 19 lines · 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:
Quoted 1 line
'
/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
Quoted 6 lines
Signed-off-by Brandon Maier <[email protected]>Signed-off-by David Owens <[email protected]>--- ...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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
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
Quoted 40 lines · Thomas Petazzoni
Hello,
Quoted 19 lines · 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:
Quoted 1 line
'
/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=eef7883587acc933d6f34b559ec03ff84d18573bQuoted 6 lines
Signed-off-by Brandon Maier <[email protected]>Signed-off-by David Owens <[email protected]>--- ...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.patchApplied to master, thanks.
Thomas
Signature · 7 lines
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
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
Hello,
+Peter in Cc.
Quoted 5 lines · Anisse Astier
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
Quoted 12 lines · Thomas Petazzoni
Hello,
+Peter in Cc.
Quoted 5 lines · Anisse Astier
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.
Quoted 9 lines
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
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
Hello,
Quoted 2 lines · anisse at astier.eu
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
Quoted 7 lines · Thomas Petazzoni
Hello,
Quoted 2 lines · anisse at astier.eu
I opened an issue upstream:
https://gitlab.gnome.org/GNOME/glib/issues/1455
Quoted 8 lines
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
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
Hello,
Quoted 6 lines · anisse at astier.eu
Quoted 2 lines
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.
Quoted 2 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
In reply to Anisse AstierQuoted 8 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Anisse" == Anisse Astier <[email protected]> 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?
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
Quoted 6 lines · Peter Korsgaard
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Anisse" == Anisse Astier <[email protected]> writes:
Hi,
We just hit this issue with the buildroot-2018.02 branch. Is this is the scope of LTS-backportable patches ?
Quoted 8 lines
Quoted 2 lines
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
PATCH 1/1 libglib2: Avoid absolute path to python in shebang
In reply to David OwensQuoted 18 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"David" == David Owens <[email protected]> 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:
Quoted 1 line
'
/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.
Quoted 5 lines
[1] https://linux.die.net/man/2/execve
[2] http://cgit.openembedded.org/openembedded-core/commit/?id=eef7883587acc933d6f34b559ec03ff84d18573bSigned-off-by Brandon Maier <[email protected]>Signed-off-by David Owens <[email protected]>
Committed to 2018.02.x and 2018.05.x, thanks.
Signature · 1 line
Bye, Peter Korsgaard