| Message ID | 1531413454-11546-1-git-send-email-david.owens@rockwellcollins.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] libglib2: Avoid absolute path to python in shebang | expand |
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
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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
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
>>>>> "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?
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
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
Hello, On Thu, 19 Jul 2018 13:50:33 +0200, anisse@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
On Thu, Jul 19, 2018 at 02:15:57PM +0200, Thomas Petazzoni wrote: > Hello, > > On Thu, 19 Jul 2018 13:50:33 +0200, anisse@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
Hello, On Thu, 19 Jul 2018 14:58:28 +0200, anisse@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
>>>>> "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.
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 +