- Original Message -
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/b35c26010d67affd5da0305af2c1d9965c571fd3),
so I wanted to solicit some advice on how to do it
right(TM).
Hi Tim,
not sure if my answers will be right(TM), but I hope that they'll be useful, at
least :)
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?
The important thing here is that upstreams do not publish tarballs on Github.
Github dynamically generates tarballs of repos for given tag/commit hash when
you request it. This generally means that the tarball downloaded from Github is
not what upstream meant to release (unlike pypi, which *is* what upstream
released).
The interesting thing about the tarball from pypi is, that all files in the
archive are owned by jenkins user. I didn't check, but my guess is, that when
upstream wants to do a release, they let Jenkins (with access to upstream git
repository, which is what pbr asks you to have) generate the final tarball -
and Jenkins generates all the extra files before packing the tarball. If you
look at the files missing from the first archive, they do look autogenerated,
which seems to confirm my thoughts, but I'm not 100 % sure.
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.?
I'd prepend that to macro, e.g.
SKIP_PIP_INSTALL=1 %{__python2} something
(Note, that it is recommended to use %{__python2} or %{__python3} explicitly,
rather than using %{__python}.)
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?
These lines are usually caused by macro definitions in specfile containing
calls to not yet installed binaries. When Koji creates the minimal mock
buildroot, it tries to expand the specfile to get dependencies (BuildRequires)
to install. Since Python is not in the minimal buildroot when the specfile is
expanded, mock will produce this warning. I'm not sure where exactly this comes
from the git-review specfile, but I'm quite sure that it's not a problem.
Slavek
Of course, any other advice is also much appreciated.
TIA,
Tim
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
