On Wed, Jan 06, 2016 at 04:58:39PM +0100, Jan Palus wrote:
> Are there any guidelines on how to adjust packages using automake for
> python installation? In particular those using AM_PATH_PYTHON which
> currently determines pythondir = ${prefix}/lib64/python3.5/site-packages
> while previously it w
Are there any guidelines on how to adjust packages using automake for
python installation? In particular those using AM_PATH_PYTHON which
currently determines pythondir = ${prefix}/lib64/python3.5/site-packages
while previously it was evaluated to %{prefix}/share/python3.5/site-packages.
In my case
On 18.12.2015 14:30, Jacek Konieczny wrote:
On 2015-12-18 13:03, Elan Ruusamäe wrote:
perhaps add macro which is to be defined in .spec:
%define py_install_options --no-compile-schemas --no-update-icon-cache
%py_install
For a single spec?
do you rather see it's better if he does not use t
On 2015-12-18 13:03, Elan Ruusamäe wrote:
perhaps add macro which is to be defined in .spec:
%define py_install_options --no-compile-schemas --no-update-icon-cache
%py_install
For a single spec?
Jacek
___
pld-devel-en mailing list
pld-devel-en@lis
On 18.12.2015 11:07, Jacek Konieczny wrote:
On 2015-12-17 21:34, Jan Palus wrote:
Regarding migration to new %py_* macros -- is there a way to define
setup.py options instead of "action" options? For example how to
correctly migrate following invocation:
%{__python} setup.py \
--no-comp
On 2015-12-17 21:34, Jan Palus wrote:
Regarding migration to new %py_* macros -- is there a way to define
setup.py options instead of "action" options? For example how to
correctly migrate following invocation:
%{__python} setup.py \
--no-compile-schemas \
--no-update-icon-cache
Regarding migration to new %py_* macros -- is there a way to define
setup.py options instead of "action" options? For example how to
correctly migrate following invocation:
%{__python} setup.py \
--no-compile-schemas \
--no-update-icon-cache \
install \
--optimize=2 \
On Wed, 02 Dec 2015, Jacek Konieczny wrote:
> On 2015-12-01 19:57, Jan Rękorajski wrote:
> > Well, icedove still doesn't build, this time with:
> [...]
> > checking Python environment is Mozilla virtualenv... Traceback (most recent
> > call last):
> > File "", line 1, in
> > ImportError: No mo
On 2015-12-01 19:57, Jan Rękorajski wrote:
> Well, icedove still doesn't build, this time with:
[...]
> checking Python environment is Mozilla virtualenv... Traceback (most recent
> call last):
> File "", line 1, in
> ImportError: No module named mozbuild.base
> configure: error: Python environ
On 2015-12-01 19:57, Jan Rękorajski wrote:
> On Tue, 01 Dec 2015, Jacek Konieczny wrote:
> Well, icedove still doesn't build, this time with:
>
> Creating Python environment
> New python executable in
> /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python2.7
>
On Tue, 01 Dec 2015, Jacek Konieczny wrote:
> On 2015-11-30 09:19, Jan Rękorajski wrote:
> > On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote:
> >> On 2015-11-29 23:30, Jan Rękorajski wrote:
>
> >>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'
>
> >> I will investig
On Tue, 01 Dec 2015, Jacek Konieczny wrote:
> On 2015-11-30 09:19, Jan Rękorajski wrote:
> > On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote:
> >> On 2015-11-29 23:30, Jan Rękorajski wrote:
>
> >>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'
>
> >> I will investig
On 2015-11-30 09:19, Jan Rękorajski wrote:
> On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote:
>> On 2015-11-29 23:30, Jan Rękorajski wrote:
>>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'
>> I will investigate this further in the evening.
>
> A food for thought -
On 2015-11-30 09:19, Jan Rękorajski wrote:
> A food for thought - what about dropping PLD specific hack with with
> lib<->share split?
> It constantly gives us grief with virtualenv.
Ok, now I can see what can be done. We need to keep the split between
/usr/{lib64,share}/pythonX.Y/site-packages –
On 2015-11-30 09:19, Jan Rękorajski wrote:
A food for thought - what about dropping PLD specific hack with with
lib<->share split?
What do you choose?
– binaries (*.so) in /usr/share and conflicts between x86_64 and i686
packages
– all python modules in %{_libdir} and no more 'noarch' Python p
On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote:
> On 2015-11-29 23:30, Jan Rękorajski wrote:
>>>
>>> The change broke icedove/iceweasel build, looks like some virtualenv
>>> paths confusion:
>>>
>>>
>>> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=icedove&id=3c8b
On 2015-11-29 23:30, Jan Rękorajski wrote:
The change broke icedove/iceweasel build, looks like some virtualenv
paths confusion:
http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=icedove&id=3c8b77d4-5fec-47a0-ae3d-dd2a575890c2&action=tail
Yes, I have seen that.
Actually
On Sun, 29 Nov 2015, Jan Rękorajski wrote:
> On Wed, 25 Nov 2015, Jacek Konieczny wrote:
>
> > On 2015-11-22 18:52, Jan Rękorajski wrote:
> > > On Sun, 22 Nov 2015, Jacek Konieczny wrote:
> > >>
> > >> I suggest patching python, python3 and, if neccessary, other packages,
> > >> so distutils/setu
On Wed, 25 Nov 2015, Jacek Konieczny wrote:
> On 2015-11-22 18:52, Jan Rękorajski wrote:
> > On Sun, 22 Nov 2015, Jacek Konieczny wrote:
> >>
> >> I suggest patching python, python3 and, if neccessary, other packages,
> >> so distutils/setuptools/pip would install Python modules to /usr/local
> >>
On 2015-11-29 10:51, Elan Ruusamäe wrote:
> looks like python egg dependency generator is broken, none provided:
>
> ➔ rpm -q --provides python-defusedxml
> python-defusedxml = 0.4.1-7
Already fixed in rpm.
> https://srcbuilder.pld-linux.org/~pldth/qa.php?q=main-ready-test
> currently 30 matches
On 2015-11-29 10:59, Elan Ruusamäe wrote:
> On 29.11.2015 11:51, Elan Ruusamäe wrote:
>> On 27.11.2015 13:06, Jacek Konieczny wrote:
>>> On 2015-11-27 10:28, Elan Ruusamäe wrote:
On 25.11.2015 22:19, Jacek Konieczny wrote:
> If there are no objections, I may try a mass-update of python-* s
On 29.11.2015 11:51, Elan Ruusamäe wrote:
On 27.11.2015 13:06, Jacek Konieczny wrote:
On 2015-11-27 10:28, Elan Ruusamäe wrote:
On 25.11.2015 22:19, Jacek Konieczny wrote:
If there are no objections, I may try a mass-update of python-* specs
tomorrow.
btw, why was mass rebuild necessary?
bin
On 27.11.2015 13:06, Jacek Konieczny wrote:
On 2015-11-27 10:28, Elan Ruusamäe wrote:
On 25.11.2015 22:19, Jacek Konieczny wrote:
If there are no objections, I may try a mass-update of python-* specs
tomorrow.
more like in the weekend ;)
looks like python egg dependency generator is broken
On 2015-11-27 10:28, Elan Ruusamäe wrote:
On 25.11.2015 22:19, Jacek Konieczny wrote:
If there are no objections, I may try a mass-update of python-* specs
tomorrow.
more like in the weekend ;)
afaik not all packages supported --build-base thing. i don't know why.
Most current Python packa
On 25.11.2015 22:19, Jacek Konieczny wrote:
If there are no objections, I may try a mass-update of python-* specs
tomorrow.
afaik not all packages supported --build-base thing. i don't know why.
so i'm not objecting, just warning.
you can find such packages with something like this:
➔ grep -r
On 2015-11-22 18:52, Jan Rękorajski wrote:
> On Sun, 22 Nov 2015, Jacek Konieczny wrote:
>>
>> I suggest patching python, python3 and, if neccessary, other packages,
>> so distutils/setuptools/pip would install Python modules to /usr/local
>> by default – like autoconf configure scripts do. Python
On 22.11.2015 14:25, Jacek Konieczny wrote:
I suggest patching python, python3 and, if neccessary, other packages,
so distutils/setuptools/pip would install Python modules to /usr/local
by default – like autoconf configure scripts do. Python would look for
modues in /usr/local first and then in /
On 2015-11-22 16:57, Tomasz Pala wrote:
> On Sun, Nov 22, 2015 at 13:25:16 +0100, Jacek Konieczny wrote:
>
>> I suggest patching python, python3 and, if neccessary, other packages,
>> so distutils/setuptools/pip would install Python modules to /usr/local
>> by default ??? like autoconf configure s
On Sun, 22 Nov 2015, Jacek Konieczny wrote:
> Hi,
>
> Most Python HOWTOs and similar resources suggest using 'pip',
> 'easy_install' or other tools to install python modules or python-based
> programs. The problem is, that in PLD those tools would install modules
> in /usr/{lib{64},share}/pythonX
On Sun, Nov 22, 2015 at 13:25:16 +0100, Jacek Konieczny wrote:
> I suggest patching python, python3 and, if neccessary, other packages,
> so distutils/setuptools/pip would install Python modules to /usr/local
> by default ??? like autoconf configure scripts do. Python would look for
> modues in /u
Hi,
Most Python HOWTOs and similar resources suggest using 'pip',
'easy_install' or other tools to install python modules or python-based
programs. The problem is, that in PLD those tools would install modules
in /usr/{lib{64},share}/pythonX.Y/site-packages – the same place, where
python modules f
31 matches
Mail list logo
