| Message ID | 1377008739-12484-1-git-send-email-markos.chandras@imgtec.com |
|---|---|
| State | Superseded |
| Headers | show |
On 20/08/13 16:25, Markos Chandras wrote: > Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> > --- > ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch > > diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch > new file mode 100644 > index 0000000..ebc8830 > --- /dev/null > +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch > @@ -0,0 +1,26 @@ > +Prevent build system from detecting an existing installation. > +Fixes the following problem when python-setuptools is installed > +on the host: > + > +Setuptools installation detected at /usr/lib64/python2.7/site-packages > +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to > +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 > +OSError: [Errno 13] Permission denied This happens because setuptools is called with: PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" Yegor, Gustavo, any idea why this is called with a python path pointing to the host? Maybe this isn't needed anymore? A quick grep in the source doesn't indicate an obvious place where PYTHONPATH would be relevant during install itself. I've just tried removing the PYTHONPATH override and it built OK, but I haven't tested if a package installed with setuptools actually works. Well, actually, host-setuptools _doesn't_ have that strange PYTHONPATH override and that is of course the only one used within buildroot itself... Regards, Arnout > + > +Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> > + > +Index: python-setuptools-0.6.36/setup.py > +=================================================================== > +--- python-setuptools-0.6.36.orig/setup.py > ++++ python-setuptools-0.6.36/setup.py > +@@ -129,10 +129,6 @@ def _being_installed(): > + return False > + return 'install' in sys.argv[1:] or _easy_install_marker() > + > +-if _being_installed(): > +- from distribute_setup import _before_install > +- _before_install() > +- > + # return contents of reStructureText file with linked issue references > + def _linkified(rst_path): > + bitroot = 'http://bitbucket.org/tarek/distribute' >
On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 20/08/13 16:25, Markos Chandras wrote: >> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> >> --- >> ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++ >> 1 file changed, 26 insertions(+) >> create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >> >> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >> new file mode 100644 >> index 0000000..ebc8830 >> --- /dev/null >> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >> @@ -0,0 +1,26 @@ >> +Prevent build system from detecting an existing installation. >> +Fixes the following problem when python-setuptools is installed >> +on the host: >> + >> +Setuptools installation detected at /usr/lib64/python2.7/site-packages >> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to >> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 >> +OSError: [Errno 13] Permission denied > > This happens because setuptools is called with: > > PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" > > Yegor, Gustavo, any idea why this is called with a python path pointing > to the host? Maybe this isn't needed anymore? A quick grep in the source > doesn't indicate an obvious place where PYTHONPATH would be relevant > during install itself. > > I've just tried removing the PYTHONPATH override and it built OK, but I > haven't tested if a package installed with setuptools actually works. > Well, actually, host-setuptools _doesn't_ have that strange > PYTHONPATH override and that is of course the only one used within > buildroot itself... I'll look into it. But I need some time. Yegor
On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov <yegorslists@googlemail.com> wrote: > On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >> On 20/08/13 16:25, Markos Chandras wrote: >>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> >>> --- >>> ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++ >>> 1 file changed, 26 insertions(+) >>> create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>> >>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>> new file mode 100644 >>> index 0000000..ebc8830 >>> --- /dev/null >>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>> @@ -0,0 +1,26 @@ >>> +Prevent build system from detecting an existing installation. >>> +Fixes the following problem when python-setuptools is installed >>> +on the host: >>> + >>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages >>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to >>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 >>> +OSError: [Errno 13] Permission denied >> >> This happens because setuptools is called with: >> >> PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" >> >> Yegor, Gustavo, any idea why this is called with a python path pointing >> to the host? Maybe this isn't needed anymore? A quick grep in the source >> doesn't indicate an obvious place where PYTHONPATH would be relevant >> during install itself. >> >> I've just tried removing the PYTHONPATH override and it built OK, but I >> haven't tested if a package installed with setuptools actually works. >> Well, actually, host-setuptools _doesn't_ have that strange >> PYTHONPATH override and that is of course the only one used within >> buildroot itself... > > I'll look into it. But I need some time. The only package, that relies on setuptools is netifaces. I've applied the patch, rebuilt BR and everything seems to be OK. I can use netifaces, when I start the new image. Yegor
On 22 August 2013 10:07, Yegor Yefremov <yegorslists@googlemail.com> wrote: > On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov > <yegorslists@googlemail.com> wrote: >> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >>> On 20/08/13 16:25, Markos Chandras wrote: >>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> >>>> --- >>>> ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++ >>>> 1 file changed, 26 insertions(+) >>>> create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>> >>>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>> new file mode 100644 >>>> index 0000000..ebc8830 >>>> --- /dev/null >>>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>> @@ -0,0 +1,26 @@ >>>> +Prevent build system from detecting an existing installation. >>>> +Fixes the following problem when python-setuptools is installed >>>> +on the host: >>>> + >>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages >>>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to >>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 >>>> +OSError: [Errno 13] Permission denied >>> >>> This happens because setuptools is called with: >>> >>> PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" >>> >>> Yegor, Gustavo, any idea why this is called with a python path pointing >>> to the host? Maybe this isn't needed anymore? A quick grep in the source >>> doesn't indicate an obvious place where PYTHONPATH would be relevant >>> during install itself. >>> >>> I've just tried removing the PYTHONPATH override and it built OK, but I >>> haven't tested if a package installed with setuptools actually works. >>> Well, actually, host-setuptools _doesn't_ have that strange >>> PYTHONPATH override and that is of course the only one used within >>> buildroot itself... >> >> I'll look into it. But I need some time. > > The only package, that relies on setuptools is netifaces. I've applied > the patch, rebuilt BR and everything seems to be OK. I can use > netifaces, when I start the new image. > > Yegor > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot Thanks for testing. Shall I submit a new patch removing the PYTHONPATH variable from the makefile?
On 22/08/13 11:07, Yegor Yefremov wrote: > On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov > <yegorslists@googlemail.com> wrote: >> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >>> On 20/08/13 16:25, Markos Chandras wrote: >>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> >>>> --- >>>> ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++ >>>> 1 file changed, 26 insertions(+) >>>> create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>> >>>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>> new file mode 100644 >>>> index 0000000..ebc8830 >>>> --- /dev/null >>>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>> @@ -0,0 +1,26 @@ >>>> +Prevent build system from detecting an existing installation. >>>> +Fixes the following problem when python-setuptools is installed >>>> +on the host: >>>> + >>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages >>>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to >>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 >>>> +OSError: [Errno 13] Permission denied >>> >>> This happens because setuptools is called with: >>> >>> PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" >>> >>> Yegor, Gustavo, any idea why this is called with a python path pointing >>> to the host? Maybe this isn't needed anymore? A quick grep in the source >>> doesn't indicate an obvious place where PYTHONPATH would be relevant >>> during install itself. >>> >>> I've just tried removing the PYTHONPATH override and it built OK, but I >>> haven't tested if a package installed with setuptools actually works. >>> Well, actually, host-setuptools _doesn't_ have that strange >>> PYTHONPATH override and that is of course the only one used within >>> buildroot itself... >> >> I'll look into it. But I need some time. > > The only package, that relies on setuptools is netifaces. I've applied > the patch, rebuilt BR and everything seems to be OK. I can use > netifaces, when I start the new image. With "the patch", do you the original patch that removes something from setuptools.py, or do you mean that you removed the PYTHONPATH overrides from python-setuptools.mk? In the former case, yes it will work because that part is indeed redundant in our context. In the latter case: actually I think python-netifaces incorrectly selects BR2_PACKAGE_PYTHON_SETUPTOOLS, because AFAICS it doesn't use it at runtime. The way to test setuptools on the target is probably to run easy_install for some packages. Regards, Arnout
On 22/08/13 11:17, Markos Chandras wrote: > On 22 August 2013 10:07, Yegor Yefremov <yegorslists@googlemail.com> wrote: >> On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov >> <yegorslists@googlemail.com> wrote: >>> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >>>> On 20/08/13 16:25, Markos Chandras wrote: >>>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> >>>>> --- >>>>> ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++ >>>>> 1 file changed, 26 insertions(+) >>>>> create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>>> >>>>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>>> new file mode 100644 >>>>> index 0000000..ebc8830 >>>>> --- /dev/null >>>>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>>> @@ -0,0 +1,26 @@ >>>>> +Prevent build system from detecting an existing installation. >>>>> +Fixes the following problem when python-setuptools is installed >>>>> +on the host: >>>>> + >>>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages >>>>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to >>>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 >>>>> +OSError: [Errno 13] Permission denied >>>> >>>> This happens because setuptools is called with: >>>> >>>> PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" >>>> >>>> Yegor, Gustavo, any idea why this is called with a python path pointing >>>> to the host? Maybe this isn't needed anymore? A quick grep in the source >>>> doesn't indicate an obvious place where PYTHONPATH would be relevant >>>> during install itself. >>>> >>>> I've just tried removing the PYTHONPATH override and it built OK, but I >>>> haven't tested if a package installed with setuptools actually works. >>>> Well, actually, host-setuptools _doesn't_ have that strange >>>> PYTHONPATH override and that is of course the only one used within >>>> buildroot itself... >>> >>> I'll look into it. But I need some time. >> >> The only package, that relies on setuptools is netifaces. I've applied >> the patch, rebuilt BR and everything seems to be OK. I can use >> netifaces, when I start the new image. >> >> Yegor >> _______________________________________________ >> buildroot mailing list >> buildroot@busybox.net >> http://lists.busybox.net/mailman/listinfo/buildroot > > Thanks for testing. Shall I submit a new patch removing the PYTHONPATH > variable from the makefile? It should probably be changed to $(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages I guess it was just a typo in the original patch, forgetting to add $(TARGET_DIR) Regards, Arnout
On Thu, Aug 22, 2013 at 11:18 AM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 22/08/13 11:07, Yegor Yefremov wrote: >> >> On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov >> <yegorslists@googlemail.com> wrote: >>> >>> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> >>> wrote: >>>> >>>> On 20/08/13 16:25, Markos Chandras wrote: >>>>> >>>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> >>>>> --- >>>>> ...etuptools-do-not-detect-installed-version.patch | 26 >>>>> ++++++++++++++++++++++ >>>>> 1 file changed, 26 insertions(+) >>>>> create mode 100644 >>>>> package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>>> >>>>> diff --git >>>>> a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>>> b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>>> new file mode 100644 >>>>> index 0000000..ebc8830 >>>>> --- /dev/null >>>>> +++ >>>>> b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch >>>>> @@ -0,0 +1,26 @@ >>>>> +Prevent build system from detecting an existing installation. >>>>> +Fixes the following problem when python-setuptools is installed >>>>> +on the host: >>>>> + >>>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages >>>>> +Renaming >>>>> /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to >>>>> >>>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 >>>>> +OSError: [Errno 13] Permission denied >>>> >>>> >>>> This happens because setuptools is called with: >>>> >>>> >>>> PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" >>>> >>>> Yegor, Gustavo, any idea why this is called with a python path >>>> pointing >>>> to the host? Maybe this isn't needed anymore? A quick grep in the source >>>> doesn't indicate an obvious place where PYTHONPATH would be relevant >>>> during install itself. >>>> >>>> I've just tried removing the PYTHONPATH override and it built OK, but >>>> I >>>> haven't tested if a package installed with setuptools actually works. >>>> Well, actually, host-setuptools _doesn't_ have that strange >>>> PYTHONPATH override and that is of course the only one used within >>>> buildroot itself... >>> >>> >>> I'll look into it. But I need some time. >> >> >> The only package, that relies on setuptools is netifaces. I've applied >> the patch, rebuilt BR and everything seems to be OK. I can use >> netifaces, when I start the new image. > > > With "the patch", do you the original patch that removes something from > setuptools.py, or do you mean that you removed the PYTHONPATH overrides from > python-setuptools.mk? > > In the former case, yes it will work because that part is indeed redundant > in our context. > > In the latter case: actually I think python-netifaces incorrectly selects > BR2_PACKAGE_PYTHON_SETUPTOOLS, because AFAICS it doesn't use it at runtime. But netifaces needs setuptools for build time, that's why it is there. Perhaps one could make only HOST dependency. > The way to test setuptools on the target is probably to run easy_install > for some packages. I've tried both the patch for setup.py and removing PYTHONPATH from python-setuptools.mk. But I haven't tried to install real pyhon package on my target system. Just started Python, imported netifaces and got the list of available interfaces. Yegor
On 08/22/2013 07:36 AM, Yegor Yefremov wrote: I'll answer on the last mail to make it simpler, otherwise it would be a lot of different mails :) Basically there's two issues going on here. First, Markos's patch is still necessary. On a gentoo build host which is also a desktop and where setuptools installed is "a common thing" thing fails no matter what is done without it. Second, what Arnout said is valid too, but it's correctness rather than a fix. python-netifaces doesn't need python-setuptools so that can be dropped from DEPENDENCIES and Config.in, and PYTHONPATH in HOST_PYTHON_SETUPTOOLS_INSTALL_CMDS is in fact redundant. However if someone wants to concoct a patch for python-setuptools there's an additional nag for the target variant - it should depend/select BR2_PACKAGE_PYTHON_SSL since pypi forces https these days otherwise it'll be a terrible experience. Regards.
On 22/08/13 13:12, Gustavo Zacarias wrote: > On 08/22/2013 07:36 AM, Yegor Yefremov wrote: > > I'll answer on the last mail to make it simpler, otherwise it would be a > lot of different mails :) > Basically there's two issues going on here. > > First, Markos's patch is still necessary. > On a gentoo build host which is also a desktop and where setuptools > installed is "a common thing" thing fails no matter what is done without it. Markos's patch, or a yet-to-be-created patch that adds $(TARGET_DIR) to the PYTHONPATH instead of passing the system's pythonpath? > Second, what Arnout said is valid too, but it's correctness rather than > a fix. python-netifaces doesn't need python-setuptools so that can be > dropped from DEPENDENCIES and Config.in, and PYTHONPATH in > HOST_PYTHON_SETUPTOOLS_INSTALL_CMDS is in fact redundant. Actually I didn't realize the PYTHONPATH setting for the host variant was redundant :-) I was only talking about the target. > However if someone wants to concoct a patch for python-setuptools > there's an additional nag for the target variant - it should > depend/select BR2_PACKAGE_PYTHON_SSL since pypi forces https these days > otherwise it'll be a terrible experience. But I guess that is a separate patch. Anyway I'm not sure if the target variant is that relevant, because it will not be able to install anything that requires compilation... Regards, Arnout
On 08/22/2013 08:17 AM, Arnout Vandecappelle wrote: > Markos's patch, or a yet-to-be-created patch that adds $(TARGET_DIR) to > the PYTHONPATH instead of passing the system's pythonpath? That's possible too, testing required :) > Actually I didn't realize the PYTHONPATH setting for the host variant > was redundant :-) I was only talking about the target. PYTHONPATH for the target is required because it's sometimes hardcoded in installed packages unfortunately - i don't recall the exact combination that triggered it at the moment, or it may have been some additional python package that i used for testing and never sent (useless, not interesting) when fixing the shebang and other details. > But I guess that is a separate patch. > > Anyway I'm not sure if the target variant is that relevant, because it > will not be able to install anything that requires compilation... Yes, something for someone to up their buildroot cred :) I'm unsure if we want to encourage the target setuptools, there are packages that'll install fine, and as you say the compiler ones will fail miserably. I'd keep it to avoid unnecessary noise and complaints with a big fat warning that it's not the buildroot way and it's just for convenience (and to forget about the target toolchain!). Regards.
diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch new file mode 100644 index 0000000..ebc8830 --- /dev/null +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch @@ -0,0 +1,26 @@ +Prevent build system from detecting an existing installation. +Fixes the following problem when python-setuptools is installed +on the host: + +Setuptools installation detected at /usr/lib64/python2.7/site-packages +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88 +OSError: [Errno 13] Permission denied + +Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> + +Index: python-setuptools-0.6.36/setup.py +=================================================================== +--- python-setuptools-0.6.36.orig/setup.py ++++ python-setuptools-0.6.36/setup.py +@@ -129,10 +129,6 @@ def _being_installed(): + return False + return 'install' in sys.argv[1:] or _easy_install_marker() + +-if _being_installed(): +- from distribute_setup import _before_install +- _before_install() +- + # return contents of reStructureText file with linked issue references + def _linkified(rst_path): + bitroot = 'http://bitbucket.org/tarek/distribute'
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> --- ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch