Bug #7991
closed
[Deployment] Debian package "python-google-api-python-client" egg info should be world-readable
Description
The package render the pip of non-privileged users. "pip list", "pip install xxx" works, but "pip list --outdated" and "pip freeze" broke.
Install python-client directly from pip works for me.
There is already a "python-googleapi" package in Jessie official repo (https://packages.debian.org/jessie/python-googleapi), but it is a bit outdated (v1.2). I'm not sure if it meets the prerequisite of Arvados.
chenchen@shell:~$ pip freeze
Exception:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in main
status = self.run(options, args)
File "/usr/lib/python2.7/dist-packages/pip/commands/freeze.py", line 66, in run
dependency_links.extend(dist.get_metadata_lines('dependency_links.txt'))
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1413, in get_metadata_lines
return yield_lines(self.get_metadata(name))
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1405, in get_metadata
return self._get(self._fn(self.egg_info, name))
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1514, in _get
with open(path, 'rb') as stream:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/google_api_python_client-1.4.2.egg-info/dependency_links.txt'
root@shell:~# apt-cache policy python-arvados-python-client
python-arvados-python-client:
Installed: 0.1.20151210204624-1
root@shell:~# apt-cache policy python-google-api-python-client
python-google-api-python-client:
Installed: 1.4.2-1
Updated by Brett Smith about 9 years ago
- Subject changed from Debain package "python-google-api-python-client" broke pip of non-privileged users to [Deployment] Debian package "python-google-api-python-client" egg info should be world-readable
Confirmed that google-api-python-client is the only backport with this issue, thankfully. We could just extend the fix that we've applied to httplib2, and apply it to this package as well.
Updated by Brett Smith about 9 years ago
- Target version set to Arvados Future Sprints
Updated by Brett Smith about 9 years ago
- Target version changed from Arvados Future Sprints to 2016-01-20 Sprint
Updated by Brett Smith about 9 years ago
A branch with a bugfix for the build is up for review. I built the package, installed it, confirmed the permissions were right, and confirmed that su -c 'pip freeze' nobody produced correct output after installation.
Updated by Tom Clegg about 9 years ago
LGTM.
Closest thing to a complaint is that we aren't fixing what looks to me like an existing bug here:
pyfpm_workdir=$(mktemp ...) && (
set -e
...
)
if [ -n "$pyfpm_workdir" ]; then
rm -rf "$pyfpm_workdir"
fi
Shouldn't this be:
set -e
pyfpm_workdir=$(mktemp ...)
...
rm -rf "$pyfpm_workdir"
If we fail to make a tmpdir, we should probably admit defeat, rather than silently building a package with broken permissions...
Updated by Brett Smith about 9 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados-dev|commit:d42d4368192ec140faf161db6c98a500aa39fdcd.
Updated by Brett Smith about 9 years ago
Tom Clegg wrote:
Closest thing to a complaint is that we aren't fixing what looks to me like an existing bug here:
I know this code is subtle, but I don't think that's right. I think the current code does what you want; and I think it's better than your suggestion. We want to clean the tmpdir, whether the build process succeeds or fails, at any point. The cleanest way to do that from a code perspective is to do that cleanup after the subshell doing the main build is done. If we do that, we can't do the mktemp inside the subshell, because we'll forget where the tmpdir is after the subshell is done.
Chaining the mktemp and the subshell with && means that the build is prevented if making a temporary directory fails. In that case, the subshell doesn't run at all, and $? will have mktemp's exit code when we check that later, so there's an error about it.
Did I understand you right, or did I miss something in your comment?
Updated by Tom Clegg about 9 years ago
No, you're right. Apparently I ignored the if [ 0 != "$?" ] part. Sorry for the noise.