Re: [python] Add python2_version_nodots macro
by Nick Coghlan
On 11/14/2014 12:05 AM, Matej Stuchlik wrote:
> commit 6875a63831616c6c8e722632e24faaa1a09cc831
> Author: Matej Stuchlik <mstuchli(a)redhat.com>
> Date: Thu Nov 13 15:04:28 2014 +0100
>
> Add python2_version_nodots macro
>
> macros.python2 | 1 +
> python.spec | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
> ---
> diff --git a/macros.python2 b/macros.python2
> index 982b51f..d090296 100644
> --- a/macros.python2
> +++ b/macros.python2
> @@ -2,3 +2,4 @@
> %python2_sitelib %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")
> %python2_sitearch %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")
> %python2_version %(%{__python2} -c "import sys; sys.stdout.write(sys.version[:3])")
> +%python2_version_nodots %(%{__python2} -c "import sys; sys.stdout.write(sys.version[:3].replace('.',''))")
I just saw this commit go by on python-owners.
These macros are going to fail when Python 2.7.10 is released next year.
Anything currently depending on the new "no dots" version in particular
may also fail when it moves from 3 digits to 4 (since 2710 sorts
lexically lower than 279).
The version with dots can be fixed by using
"'.'.join(sys.version_info[:3])" instead of ignoring the explicit "Do
not extract version information out of it" guidance for sys.version.
The version without dots can be addressed by including the leading zero:
"{0.major}{0.minor}{0.micro:02d}".format(sys.version_info)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
9 years
distutils does not find g++ on Fedora 20
by Brad Bell
Sorry I am not able to directly reply to messages. I had my mail set in
digest mode without mine formatting.
You can find more information about my experiments on this problem at
https://lists.fedoraproject.org/pipermail/devel/2014-October/203774.html
Note that if I put the location of cc1plus in my path, the setup.py
script worked.
I was not able to fix the Fedora-20 system in questions, so I backed up
my files and did did a fresh install. Thus I do not have copy for
further testing.
On 11/18/2014 4:00 AM, python-devel-request(a)lists.fedoraproject.org wrote:
... snip ...
> Today's Topics:
>
> 1. distutils does not find g++ on Fedora 20 (Brad Bell)
> 2. Re: distutils does not find g++ on Fedora 20 (Thomas Spura)
> 3. Re: [python] Add python2_version_nodots macro (Matej Stuchlik)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Nov 2014 04:45:15 -0800
> From: Brad Bell <bradbell(a)seanet.com>
> To: python-devel(a)lists.fedoraproject.org
> Subject: distutils does not find g++ on Fedora 20
> Message-ID: <5469EDDB.1060200(a)seanet.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> This problem was due to corruption of the Fedora-20 system that showed
> up when one did a
> yum check
> see
> https://lists.fedoraproject.org/pipermail/devel/2014-November/204126.html
>
> On 10/19/2014 5:00 AM, python-devel-request(a)lists.fedoraproject.org wrote:
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 18 Oct 2014 06:32:20 -0700
>> From: Brad Bell <bradbell(a)seanet.com>
>> To: python-devel(a)lists.fedoraproject.org
>> Subject: distutils does not find g++ on Fedora 20
>> Message-ID: <54426BE4.1010000(a)seanet.com>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> If this is not the correct mailing list for my question below, please
>> redirect me to the proper list.
>>
>> I have a python setup.py script that works on Fedora-19 and does not
>> work on Fedora-20.
>> The error on Fedora-20 is:
>> -------
>> [bradbell@localhost pycppad-20140710]$ ./setup.py build_ext --inplace
>> --debug --undef NDEBUG
>> running build_ext
>> building 'pycppad/cppad_' extension
>> C compiler: gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
>> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
>> -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
>> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
>> -D_GNU_SOURCE -fPIC -fwrapv -fPIC
>>
>> compile options: '-g -UNDEBUG
>> -I/usr/lib64/python2.7/site-packages/numpy/core/include
>> -I/home/bradbell/prefix/cppad/include -I/usr/include
>> -I/usr/include/python2.7 -c'
>> gcc: pycppad/vector.cpp
>> gcc: error trying to exec 'cc1plus': execvp: No such file or directory
>> ...
>> ------
>> Here is what I get when I check for g++:
>> [bradbell@localhost pycppad]$ g++ --version
>> g++ (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7)
>>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 17 Nov 2014 13:10:35 +0000
> From: Thomas Spura <tomspur(a)fedoraproject.org>
> To: Fedora Python SIG <python-devel(a)lists.fedoraproject.org>
> Subject: Re: distutils does not find g++ on Fedora 20
> Message-ID:
> <CAE4GLsukdg39wvg028BpWRL46AzzC1s5O=wMovjK5e6A5K+D-w(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Do you have the file "/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus"
> on your system as that's called from gcc later on.
>
> It seems your installation broke, so maybe that file is gone now.
> What is the output of "yum reinstall gcc-c++"? You only wrote "you got
> errors"...
>
>
... snip ...
9 years
distutils does not find g++ on Fedora 20
by Brad Bell
This problem was due to corruption of the Fedora-20 system that showed
up when one did a
yum check
see
https://lists.fedoraproject.org/pipermail/devel/2014-November/204126.html
On 10/19/2014 5:00 AM, python-devel-request(a)lists.fedoraproject.org wrote:
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 18 Oct 2014 06:32:20 -0700
> From: Brad Bell <bradbell(a)seanet.com>
> To: python-devel(a)lists.fedoraproject.org
> Subject: distutils does not find g++ on Fedora 20
> Message-ID: <54426BE4.1010000(a)seanet.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> If this is not the correct mailing list for my question below, please
> redirect me to the proper list.
>
> I have a python setup.py script that works on Fedora-19 and does not
> work on Fedora-20.
> The error on Fedora-20 is:
> -------
> [bradbell@localhost pycppad-20140710]$ ./setup.py build_ext --inplace
> --debug --undef NDEBUG
> running build_ext
> building 'pycppad/cppad_' extension
> C compiler: gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
> -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
> -D_GNU_SOURCE -fPIC -fwrapv -fPIC
>
> compile options: '-g -UNDEBUG
> -I/usr/lib64/python2.7/site-packages/numpy/core/include
> -I/home/bradbell/prefix/cppad/include -I/usr/include
> -I/usr/include/python2.7 -c'
> gcc: pycppad/vector.cpp
> gcc: error trying to exec 'cc1plus': execvp: No such file or directory
> ...
> ------
> Here is what I get when I check for g++:
> [bradbell@localhost pycppad]$ g++ --version
> g++ (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7)
>
9 years
Template for modules that use pbr?
by Tim Landscheidt
Hi,
I'm trying to update git-review to 1.24. With that version,
git-review uses pbr. I have no deeper knowledge of Python
packaging in Fedora and only tweaked the spec file so that
it works for me
(cf. https://github.com/scfc/fedora-git-review/commit/b35c26010d67affd5da0305a...),
so I wanted to solicit some advice on how to do it
right(TM).
1. Previously, Fedora used GitHub "releases" that appear to
be verbatim snapshots of the source repository. But with
https://github.com/openstack-infra/git-review/archive/1.24.tar.gz,
this no longer works as "python setup.py build" gives:
"error in setup command: Error parsing
/tmp/tmp.ITVvwuYttj/git-review-1.24/setup.cfg: Exception:
Versioning for this project requires either an sdist tar-
ball, or access to an upstream git repository." However,
using
http://pypi.python.org/packages/source/g/git-review/git-review-1.24.tar.gz
works fine.
Comparing the two shows a number of additional files in
the latter (AUTHORS, ChangeLog, git_review.egg-info,
PKG-INFO). Am I correct to assume that this is a problem
upstream, i. e. that the tarballs should not have been
published in this state, and/or is there a way to work
around that in the spec file?
2. By default, pbr seems to pull any dependencies from the
network.
http://docs.openstack.org/developer/pbr/packagers.html
suggests that this can and should be avoided by setting
SKIP_PIP_INSTALL=1. Is there a template for how to do
that properly, i. e. in a macro or just prepending to
%{__python}, etc.?
3. Testing with Koji
(cf. http://koji.fedoraproject.org/koji/taskinfo?taskID=7977881),
the build log
(cf. https://kojipkgs.fedoraproject.org//work/tasks/7881/7977881/build.log)
starts with:
| Mock Version: 1.1.41
| Mock Version: 1.1.41
| ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target noarch --nodeps builddir/build/SPECS/git-review.spec'], False, '/var/lib/mock/f19-build-2538894-429281/root/', None, 86400, True, False, 1000, 425, None, False, {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n "<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}, logger=<mockbuild.trace_decorator.getLog object at 0x1725dd0>)
| Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target noarch --nodeps builddir/build/SPECS/git-review.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n "<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
| sh: /usr/bin/python: No such file or directory
| sh: /usr/bin/python: No such file or directory
| [...]
Is that to be expected?
Of course, any other advice is also much appreciated.
TIA,
Tim
9 years, 1 month