On 25/03/2024 10:22, Jan Palus wrote:
On 25.03.2024 11:05, arekm wrote:
commit d073fb40c26996aedc0c52fdea5af8b596e4f395
Author: Arkadiusz Miśkiewicz
Date: Mon Mar 25 09:58:15 2024 +0100
python points to python3 now
python3.spec | 4
1 file changed, 4 insertions(+)
---
diff
On 25.03.2024 11:05, arekm wrote:
> commit d073fb40c26996aedc0c52fdea5af8b596e4f395
> Author: Arkadiusz Miśkiewicz
> Date: Mon Mar 25 09:58:15 2024 +0100
>
> python points to python3 now
>
> python3.spec | 4
> 1 file changed, 4 insertions(+)
> ---
&g
p todate with each release of git-filter-repo,
> additionally deal with sending to builders, and in proper order as well.
>
> why?
github package doesn't contain metadata for python package (or data to
generate them).
pypi package doesn't contain docs for git side.
Alternative so
proper order as well.
why?
On 08.10.2022 21:51, qboosh wrote:
commit 61919f8f6ee682327311dfb153d2fb5474d1e622
Author: Jakub Bogusz
Date: Sat Oct 8 20:51:52 2022 +0200
- new, separated from git-filter-repo.spec (now with python metadata,
required for e.g. b4)
python3-git-filter
ges
> > > > >
> > > > > $ python3 -c "import sys; from distutils import sysconfig;
> > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > > > /usr/lib64/python3.10/site-packages
> > >
lib(1,0,prefix='/usr'))"
> > > > /usr/lib64/python3.10/site-packages
> > >
> > > What package version do you have? Python3 shows /usr/share for me:
> > >
> > > $ python3 -c "import sys; from distutils import sysconfig;
> > >
;
> > > $ python3 -c "import sys; from distutils import sysconfig;
> > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > /usr/lib64/python3.10/site-packages
> >
> > What package version do you have? Python3 shows /usr/share for
/python3.10/site-packages
>
> What package version do you have? Python3 shows /usr/share for me:
>
> $ python3 -c "import sys; from distutils import sysconfig;
> sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm
> -q python3
> :1: Depre
out.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q
python3
:1: DeprecationWarning: The distutils package is deprecated and slated
for removal in Python 3.12. Use setuptools or check PEP 632 for potential
alternatives
:1: DeprecationWarning: The distutils.sysconf
After recent python3.10 changes meson started to use /usr/share for
purelib, but automake's pythondir is broken now:
pythondir (platform-indepdendent) is wrong:
$ python2 -c "import sys; from distutils import sysconfig;
sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
/usr/share/py
728569b130fd57bdc8acadd02
> > > > Author: Jan Rękorajski
> > > > Date: Thu Mar 11 23:32:30 2021 +0100
> > > >
> > > > - up to 1.7.1, python 2 no longer supported
> > > >
> > > > python-sympy-nodisplay.patch | 25
; > Date: Thu Mar 11 23:32:30 2021 +0100
> > >
> > > - up to 1.7.1, python 2 no longer supported
> > >
> > > python-sympy-nodisplay.patch | 25 -
> > > python-sympy.spec| 8 +++-----
> > > 2 file
On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusamäe wrote:
>
> On 12.03.2021 00:32, baggins wrote:
> > commit a7afb2642f193eb728569b130fd57bdc8acadd02
> > Author: Jan Rękorajski
> > Date: Thu Mar 11 23:32:30 2021 +0100
> >
> > - up to 1.7.1, python 2 no lon
On 12.03.2021 00:32, baggins wrote:
commit a7afb2642f193eb728569b130fd57bdc8acadd02
Author: Jan Rękorajski
Date: Thu Mar 11 23:32:30 2021 +0100
- up to 1.7.1, python 2 no longer supported
python-sympy-nodisplay.patch | 25 -
python-sympy.spec| 8
On 02.03.2021 11:38, Elan Ruusamäe wrote:
> On 01.03.2021 18:53, atler wrote:
>
> > commit 9c7664000af796dea8cd3794ae3ac37ff08274bb
> > Author: Jan Palus
> > Date: Mon Mar 1 17:52:20 2021 +0100
> >
> > explicit runtime deps on
> > python-{entry
On 01.03.2021 18:53, atler wrote:
commit 9c7664000af796dea8cd3794ae3ac37ff08274bb
Author: Jan Palus
Date: Mon Mar 1 17:52:20 2021 +0100
explicit runtime deps on python-{entrypoints,mccabe,pycodestyle,pyflakes};
rel 3
...because poldek cannot handle boolean dep
flake8
On 01.03.2021 21:48, Jan Rękorajski wrote:
Thanks that explains. Actually it made me realize that `rpm -qa` for
every build is the same global link. So far I was under impression that
`rpm -qa` would be done for each request before build or at least that
would make more sense to me. Can it be
> > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > > > > > python-traceback2.spec (HEAD): OK
> > > > > >
> > > > > > --- python-traceback2.spec:HEAD:
> > > > > > upgrading packages
> > > > > > B
On 01.03.2021 01:18, Jan Rękorajski wrote:
> On Mon, 01 Mar 2021, Jan Palus wrote:
>
> > On 01.03.2021 01:08, Jan Rękorajski wrote:
> > > On Mon, 01 Mar 2021, Jan Palus wrote:
> > >
> > > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
&
On Mon, 01 Mar 2021, Jan Palus wrote:
> On 01.03.2021 01:08, Jan Rękorajski wrote:
> > On Mon, 01 Mar 2021, Jan Palus wrote:
> >
> > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > > > python-traceback2.spec (HEAD): OK
> > > >
> >
On 01.03.2021 01:08, Jan Rękorajski wrote:
> On Mon, 01 Mar 2021, Jan Palus wrote:
>
> > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > > python-traceback2.spec (HEAD): OK
> > >
> > > --- python-traceback2.spec:HEAD:
> > > upgrading pack
On Mon, 01 Mar 2021, Jan Palus wrote:
> On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > python-traceback2.spec (HEAD): OK
> >
> > --- python-traceback2.spec:HEAD:
> > upgrading packages
> > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:
On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> python-traceback2.spec (HEAD): OK
>
> --- python-traceback2.spec:HEAD:
> upgrading packages
> Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751)
>
> Files queued for ftp:
> 22657 python3-trace
On Fri, 26 Feb 2021, Jan Rękorajski wrote:
> On Fri, 26 Feb 2021, Jakub Bogusz wrote:
>
> > What about python provides change (python3egg vs python3dist, probably
> > similarly for python2)?
> >
> > While python3 packaged will be rebuilt anyway due to python 3.9, t
On Fri, 26 Feb 2021, Jakub Bogusz wrote:
> What about python provides change (python3egg vs python3dist, probably
> similarly for python2)?
>
> While python3 packaged will be rebuilt anyway due to python 3.9, there
> is no need to rebuild python2 packages (other than provides
What about python provides change (python3egg vs python3dist, probably
similarly for python2)?
While python3 packaged will be rebuilt anyway due to python 3.9, there
is no need to rebuild python2 packages (other than provides scheme
change).
--
Jakub Boguszhttp://qboosh.pl
On 11/28/20 8:38 PM, Jakub Bogusz wrote:
On Sat, Nov 28, 2020 at 08:24:55PM +0200, Elan Ruusamäe wrote:
On 11/27/20 10:17 PM, qboosh wrote:
-Requires: python(abi) = %{py_ver}
+Requires: python(abi) = %{py3_ver}
shouldn't this be namespace to python3 name?
Req
On Sat, Nov 28, 2020 at 08:24:55PM +0200, Elan Ruusamäe wrote:
>
> On 11/27/20 10:17 PM, qboosh wrote:
> >-Requires: python(abi) = %{py_ver}
> >
> >+Requires: python(abi) = %{py3_ver}
>
>
> shouldn't this be namespace to python3 name?
>
>
>
On 11/27/20 10:17 PM, qboosh wrote:
-Requires: python(abi) = %{py_ver}
+Requires: python(abi) = %{py3_ver}
shouldn't this be namespace to python3 name?
Requires: python3(abi) = %{py3_ver}
___
pld-devel-en mailing list
pld-
The packages listed below will be dropped from Th soon (as in a week or two)
until someone takes care of them.
python-flask
python-flask-cache
python-flask-debugtoolbar-lineprofilerpanel
python-flask-debugtoolbar
python-flask-mail
python-flask-script
python-flask_sqlalchemy
python-ipykernel
On Wednesday 15 of November 2017 00:51:12 Elan Ruusamäe wrote:
> On 13.11.2017 23:46, matkor wrote:
> > Rel 2. Strict dependencies on python*-persistent, added *.[ch] files.
> >
> > python-BTrees.spec | 11 ++-
> > +# Keep strict dependencies as build
On 13.11.2017 23:46, matkor wrote:
Rel 2. Strict dependencies on python*-persistent, added *.[ch] files.
python-BTrees.spec | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
---
diff --git a/python-BTrees.spec b/python-BTrees.spec
index 03cdf0b..479c7e8 100644
--- a
On 13.11.2017 23:06, matkor wrote:
+%dir %{_includedir}/python3.6m/persistent/
+%{_includedir}/python3.6m/persistent/cPersistence.h
+%{_includedir}/python3.6m/persistent/ring.h
you have hardcoded paths here!
python.spec has:
%define py_incdir %{_includedir}/python%{py_ver}
that macro even
On 12.11.2017 23:41, matkor wrote:
commit 77fde0462b048a607f7d8f18c9aa7e91c9b98ada
Author: Mateusz Korniak
Date: Sun Nov 12 22:41:41 2017 +0100
Initial 2.1.2. Rel 1.
i don't think you should be making "rel 1" if the spec is not cleaned up
from template cruft.
--
glen
_
On 12.11.2016 01:21, arekm wrote:
+Requires: python3 >= 3.4
you imported python3 with epoch 1, fix the consequences
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
On 05.10.2016 11:04, Paweł A. Gajda wrote:
On Wed, Oct 5, 2016 at 10:02 AM, Paweł A. Gajda wrote:
On Tue, Oct 4, 2016 at 6:25 PM, Elan Ruusamäe wrote:
i tried this hack:
bash-4.3# echo /etc/rc.d/init.d >> /etc/rpm/sysinfo/Dirnames
Would not help as "path" dependencies are resolved based
On Wed, Oct 5, 2016 at 10:02 AM, Paweł A. Gajda wrote:
> On Tue, Oct 4, 2016 at 6:25 PM, Elan Ruusamäe wrote:
>
>>
>> i tried this hack:
>>
>> bash-4.3# echo /etc/rc.d/init.d >> /etc/rpm/sysinfo/Dirnames
>
>
> Would not help as "path" dependencies are resolved based on package
> contents, in fac
On Tue, Oct 4, 2016 at 6:25 PM, Elan Ruusamäe wrote:
>
> i tried this hack:
>
> bash-4.3# echo /etc/rc.d/init.d >> /etc/rpm/sysinfo/Dirnames
Would not help as "path" dependencies are resolved based on package
contents, in fact rpm/poldek does not care if file/dir really exists.
ta-init and tzdata require tzdata-init for some undefined
migration time?
On 06.05.2016 18:52, Elan Ruusamäe wrote:
so, i install some stuff with pip, and one package pulled in whole
distro:
what you think should we make tzdata be optional with rc-scripts
dependency somehow?
python-dateu
ulled in whole
distro:
what you think should we make tzdata be optional with rc-scripts
dependency somehow?
python-dateutil-2.5.0-1.noarch marks tzdata-2016c-1.noarch (cap
tzdata >= 2016a)
tzdata-2016c-1.noarch marks rc-scripts-0.4.15-4.x86_64 (cap
/etc/rc.d/init.d)
rc-scripts-0.4.15-
.
or add tzdata-init and tzdata require tzdata-init for some undefined
migration time?
On 06.05.2016 18:52, Elan Ruusamäe wrote:
so, i install some stuff with pip, and one package pulled in whole
distro:
what you think should we make tzdata be optional with rc-scripts
dependency somehow?
p
On 11.09.2016 14:02, Elan Ruusamäe wrote:
strace shows just C level error:
open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt",
O_RDWR) = -1 EOPNOTSUPP (Operation not supported)
some more examples:
➔ strace -eopen truncate --size=0
/home/glen/.gvfs/sftp:host=ewok.local/media/N
any ideas?
i.e how come truncate from bash works and not from python, and how to
make it work
➔ python3 -c
'open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", "rb+")'
Traceback (most recent call last):
File "", line 1, in
OSE
On 29.06.2016 21:44, Jakub Bogusz wrote:
On Tue, Jun 28, 2016 at 10:28:09PM +0200, Jakub Bogusz wrote:
On Mon, Jun 27, 2016 at 02:10:59PM +0300, Elan Ruusamäe wrote:
On 20.06.2016 15:58, Elan Ruusamäe wrote:
1. egg name
2. python module name [*]
3. upstream tarball name
4. pld own convention
On Tue, Jun 28, 2016 at 10:28:09PM +0200, Jakub Bogusz wrote:
> On Mon, Jun 27, 2016 at 02:10:59PM +0300, Elan Ruusamäe wrote:
> > On 20.06.2016 15:58, Elan Ruusamäe wrote:
> > >
> > >1. egg name
> > >2. python module name [*]
> > >3. ups
On Mon, Jun 27, 2016 at 02:10:59PM +0300, Elan Ruusamäe wrote:
> On 20.06.2016 15:58, Elan Ruusamäe wrote:
> >
> >1. egg name
> >2. python module name [*]
> >3. upstream tarball name
> >4. pld own convention
> >
> >[*] this is said to be the recommendat
On 20.06.2016 15:58, Elan Ruusamäe wrote:
1. egg name
2. python module name [*]
3. upstream tarball name
4. pld own convention
[*] this is said to be the recommendation in template-specs
oh, one more! the egg filename and egg name also may mismatch:
➔ rpm -q python-Levenshtein -l |grep egg
On 20.06.2016 22:06, Jakub Bogusz wrote:
On Mon, Jun 20, 2016 at 04:11:41PM +0200, Jacek Konieczny wrote:
On 2016-06-20 14:58, Elan Ruusamäe wrote:
so, what way we should do the package naming?
1. egg name
That probably makes most sense today.
2. python module name [*]
That was decided
On Mon, Jun 20, 2016 at 04:11:41PM +0200, Jacek Konieczny wrote:
> On 2016-06-20 14:58, Elan Ruusamäe wrote:
> >so, what way we should do the package naming?
> >
> >1. egg name
>
> That probably makes most sense today.
>
> >2. python module name [*]
>
cks on contexts where NVR are used in
scripting.
The *RE's are doing nothing more than limiting the character set being used
currently.
It would not be hard to apply additional *RE's against, say, python package
naming.
There is also RPM+SED (i.e. a PCRE sed-like embedding) intende
On 20.06.2016 17:11, Jacek Konieczny wrote:
I think the best naming scheme would be python-${egg_name} now. But
that is inconsistent with what we used to do. Renaming all the
affected packages might be quite problematic
what about name cases, should we lowercase them? (i'd like that, en
On 2016-06-20 14:58, Elan Ruusamäe wrote:
so, what way we should do the package naming?
1. egg name
That probably makes most sense today.
2. python module name [*]
That was decided before python eggs started being a thing. And that is
how most of our packages are named now.
3
so, what way we should do the package naming?
1. egg name
2. python module name [*]
3. upstream tarball name
4. pld own convention
[*] this is said to be the recommendation in template-specs
reality is that we have no consistency, the package naming is from any
of the four choices:
the
On 20.05.2016 16:05, Mateusz Korniak wrote:
On Friday 20 May 2016 14:37:23 glen wrote:
cleanups; pldize; replace also hashbang for py2 examples package
-Source0:
https://pypi.python.org/packages/b4/01/68fcc0d43daf4c6bdbc6b33cc3f
77bda531c86b174cac56ef0ffdb96faab/PyPDF2-%{version}.
e:
so, i install some stuff with pip, and one package pulled in whole
distro:
what you think should we make tzdata be optional with rc-scripts
dependency somehow?
python-dateutil-2.5.0-1.noarch marks tzdata-2016c-1.noarch (cap tzdata
>= 2016a)
tzdata-2016c-1.noarch marks rc-scripts-0.4.15-
On Wednesday 04 of May 2016, Elan Ruusamäe wrote:
> On 04.05.2016 13:07, Jacek Konieczny wrote:
> > That could be because of the recent changes to python3.spec by Jan,
> > which I knew they are breaking something, but I couldn't tell what.
>
> seems builds now after arekm changes (whatever they we
On 04.05.2016 13:07, Jacek Konieczny wrote:
That could be because of the recent changes to python3.spec by Jan,
which I knew they are breaking something, but I couldn't tell what.
seems builds now after arekm changes (whatever they were)
--
glen
__
On 2016-05-04 11:17, Elan Ruusamäe wrote:
On 03.05.2016 23:59, Arkadiusz Miśkiewicz wrote:
What's the rebuild procedure in case of openssl bump after this change?
python2 fixed, python3 looks like broken due other reasons, fails with
install even without tests.
That could be because of the r
On 03.05.2016 23:59, Arkadiusz Miśkiewicz wrote:
What's the rebuild procedure in case of openssl bump after this change?
python2 fixed, python3 looks like broken due other reasons, fails with
install even without tests.
--
glen
___
pld-devel-en m
not sure, maybe the strict dep can be dropped as last time it was due
broken openssl build breaking sslv2 symbols.
but i'd rather keep it strict dep, as it has been broken several times
in the past if openssl was upgraded because rpm doesn't support forward
library dependencies. i.e
What's the rebuild procedure in case of openssl bump after this change?
commit 9a0fad23f3d83106291fc38815d3fa40a2063ee7
Author: Elan Ruusamäe
Date: Fri Mar 4 10:10:31 2016 +0200
openssl 1.0.2g rebuild, strict openssl version dep
See recent openssh/python/python3 build
thod
[glen@blodnatt slack]$
On 05.03.2016 21:32, Elan Ruusamäe wrote:
can we add some suggests here to python*-requests package?
[glen@blodnatt slack]$ date|slacksend -C slacksend.conf
Traceback (most recent call last):
File "/usr/share/python3.5/site-packages/requests/adapters.py",
can we add some suggests here to python*-requests package?
[glen@blodnatt slack]$ date|slacksend -C slacksend.conf
Traceback (most recent call last):
File "/usr/share/python3.5/site-packages/requests/adapters.py", line
370, in send
timeout=timeout
File
"/usr/share
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 p
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
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 2015-12-01 23:19, Elan Ruusamäe wrote:
> On 01.12.2015 19:49, jajcus wrote:
>> The hack is to have architecture-specific pyconfig-*.h files and
>> a ghost
>> symlink updated with python-devel install. I hope this works.
>
> a cleaner way is to install wrap
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
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.b
On 2015-12-02 15:54, Jacek Konieczny wrote:
> On 2015-12-02 15:35, Jakub Bogusz wrote:
>> On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:
>
>>> At least for this:
>>> https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
>>>
On 2015-12-02 15:35, Jakub Bogusz wrote:
On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:
At least for this:
https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
get_config_h_filename() should return the ABI-specific file for multilib
installs to work
On 02.12.2015 15:56, Jacek Konieczny wrote:
ee, what patch?
At least for this:
https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
There might be other Python code parsing this header, as it is
considered a part of standard Python interface.
uh. what a mess!
python sucks
On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:
> On 2015-12-02 13:03, Elan Ruusamäe wrote:
> >>How would you convince python library to parse this file correctly?
> >>Another PLD-specific Python patch, which would cause many standard
> >>Python
On 2015-12-02 13:03, Elan Ruusamäe wrote:
How would you convince python library to parse this file correctly?
Another PLD-specific Python patch, which would cause many standard
Python packages to fail?
My solution is not pretty, but doesn't change a thing from the Python
perspective.
ee,
On 02.12.2015 14:03, Elan Ruusamäe wrote:
i'm speaking of installing "config.h" from static source111, and
python original rename as config-ARCH.h when packaging.
so you get the idea, it was in our linux-libc-headers too before
upstream started to do that themselves:
htt
On 02.12.2015 09:48, Jacek Konieczny wrote:
On 2015-12-01 23:19, Elan Ruusamäe wrote:
On 01.12.2015 19:49, jajcus wrote:
The hack is to have architecture-specific pyconfig-*.h files and
a ghost
symlink updated with python-devel install. I hope this works.
a cleaner way is to
On 2015-12-01 23:19, Elan Ruusamäe wrote:
On 01.12.2015 19:49, jajcus wrote:
The hack is to have architecture-specific pyconfig-*.h files and
a ghost
symlink updated with python-devel install. I hope this works.
a cleaner way is to install wrapper header file which based on
On 01.12.2015 19:49, jajcus wrote:
The hack is to have architecture-specific pyconfig-*.h files and a ghost
symlink updated with python-devel install. I hope this works.
a cleaner way is to install wrapper header file which based on
preprocessor variables includes proper arch
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/_v
anaged to fix that. Vanila upstream virtualenv seems to
> work correctly now, at least when not using --system-site-packages.
>
> I hope I have not introduced many new problems ;)
Well, icedove still doesn't build, this time with:
Creating Python environment
New python executable in
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 -
gt;> %if %{with doc}
>> BuildRequires: python-sphinxcontrib-issuetracker
>> -BuildRequires: sphinx-pdg
>> +BuildRequires: sphinx-pdg-2
>> %endif
>> %endif
>> %if %{with python3}
>> @@ -40,6 +40,10 @@ BuildRequires:python3-mock
>>
On Mon, Nov 30, 2015 at 07:17:21PM +0100, jajcus wrote:
> commit 8df16ed9ea864060d2f64e4da41c5b7261d4f1ad
> Author: Jacek Konieczny
> Date: Mon Nov 30 19:16:45 2015 +0100
>
> fix apidocs build
> %if %{with doc}
> BuildRequires: python-sphinxcontrib-issuetra
Y/site-packages – for noarch packages, but
there is probably no reason to split the Python package itself into
/usr/{lib64,share}/pythonX.Y. That should help virtualenv.
But I first check if there is no easier way.
Jacek
___
pld-devel-en mailing li
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 'noa
x.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 it broke virtualenv/pip:
>>
>> $ virtualenv xxx
>> New python executable in xxx/bin/python2
&
es, I have seen that.
Actually it broke virtualenv/pip:
$ virtualenv xxx
New python executable in xxx/bin/python2
Not overwriting existing python script xxx/bin/python (you must use
xxx/bin/python2)
[...]
OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'
That is str
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 ne
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
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
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
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
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
symlink? There was a hard-link for purpose. No need for extra
redirection. And there are no relative hard links.
symlink is easier to figure out what the file is, py2 or py3 version.
similarily other stuff is symlinked as well when it comes for generic
name vs versioned name. even python itself
On 2015-11-28 15:16, glen wrote:
> commit b6cbc91d94c8fad86e0ad1b271429f6772218700
> Author: Elan Ruusamäe
> Date: Sat Nov 28 16:16:47 2015 +0200
>
> adapter, use realtive symlink
[...]
> -ln -f $RPM_BUILD_ROOT/%{_bindir}/easy_install-%{py3_ver}
> $RPM_BUILD_ROOT/%{_bindir}/easy_install
>
1 - 100 of 300 matches
Mail list logo
