3:57 a.m.
----- 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/b35c26010d67affd5da0305a...),
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