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
distutils does not find g++ on Fedora 20
by Brad Bell
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, 1 month
python-sig in pkgdb2?
by Thomas Spura
Hi all,
there just was a request to test groups for pkgdb2 [1] and I thought
it might be a good opportunity to maybe start sharing at least some
core python packages among a few people.
For instance, I maintain ipython and the dependency chain when other
maintainers chose to orphan something I need for it (or ipython
introduces a new dependency). Such packages are good candidates to be
maintained by a group of people, so updates can be managed better and
several people have an eye on them.
What do others think about that? Who else would be interested in
starting a common python-sig group in pkgdb2?
Greetings,
Tom
[1] https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/001...
9 years, 1 month
