The manylinux images can take over a minute to start on spinning disks
(not SSDs) because pre_exec.sh is changing the ownership of all the
python install directories to be writable by the BUILDER_UID. This is
detailed further in #853.
I changed the build steps for manylinux images to add a group called
`builder`, then change the python directories to be owned by the
`builder` group, and group writable. I then changed pre_exec.sh to add
BUILDER_USER to the builder group prior to the gosu switch to become
BUILDER_USER. The result is that BUILDER_USER is in the `builder`
group that can write to the python directories, allowing the user to
install python packages without permission denied errors.
There was one additional change to support this, and that was the
arguments to `gosu` in entrypoint.sh. Previously the arguments were
`$BUILDER_UID:BUILDER_GID`, but providing the gid prevents `gosu` from
loading additional groups (such as `builder`) from /etc/group. I
removed the GID argument to allow `gosu` to pick up additional groups
from /etc/group.
fixes#853
Only move `/root/.rustup` and `/root/.cargo` directories if they exist.
This prevents errors when re-using the script in environments where
Rust is not installed (e.g. https://github.com/dockbuild/dockbuild).
Previously, `mv` would fail if either directory was missing:
```
mv: cannot stat '/root/.rustup': No such file or directory
mv: cannot stat '/root/.cargo': No such file or directory
```
This commit is a follow up of b7028af (entrypoint.sh: Update help
text so that current image name is used)
It ensures that the suggested script in the help text doesn't include ":"
in its name.
Assuming DEFAULT_DOCKCROSS_IMAGE is set to "dockcross/imagename:latest"
Instead of suggesting:
[...]
# docker run --rm dockcross/imagename:latest > dockcross-imagename:latest
# chmod +x dockcross-imagename:latest
[...]
it will now suggest
[...]
# docker run --rm dockcross/imagename:latest > dockcross-imagename-latest
# chmod +x dockcross-imagename-latest
[...]
xref https://github.com/dockbuild/dockbuild/issues/30
[ci skip]
BUG:
Creating a new directory under /home/<user>/ from the /work folder does
not work. In fact, going into the home directory and trying to run mkdir
fails as well.
SOLUTION:
Turns out chown -R <user>:<user> was run on $HOME/* instead of on $HOME.
This means that /home/<user> was still under the ownership of root:root,
hence preventing any writes to non-root users.
This commit fixes the following error specific to AUFS:
/dockcross/entrypoint.sh: line 47: /usr/bin/gosu: Text file busy
/dockcross/entrypoint.sh: line 47: /usr/bin/gosu: Success
Thanks @sobolevn
See https://github.com/moby/moby/issues/13594#issuecomment-262441366
While the use of sudo (made possible by 53cf084) allows to install
additional packages, the warning copied below was still reported.
To avoid this warning and streamline the installation of new packages,
this commit (1) introduces the concept of "pre_exec" entrypoint hook
and (2) adds such a hook to change the ownership of python "bin" and
"site-packages" directories for the manylinux images.
Warning reported are similar to this one:
```
The directory '/home/jcfr/.cache/pip/http' or its parent directory is
not owned by the current user and the cache has been disabled. Please
check the permissions and owner of that directory. If executing pip
with sudo, you may want sudo's -H flag.
```
Note that the sudo "-H" flag suggested in the warning is not available
in centos.
This will allow build script like "build-wheels.sh" to run command like
the following (see [1]):
sudo yum install -y atlas-devel
It will also allow to pip install using sudo and avoid error reported in [3].
That said, instead of running pip using sudo, the recommended approach
is to specify the "--user" flag [2]
[1] https://github.com/pypa/python-manylinux-demo/blob/893d92517e9e289b9d2ee063f19c3216a39534ab/travis/build-wheels.sh
[2] http://stackoverflow.com/questions/7143077/how-can-i-install-packages-in-my-home-folder-with-pip#7143496
[3] Error reported when running pip without "sudo pip install <packagename" or "pip install --user <packagename>"
```
Exception:
Traceback (most recent call last):
File "/opt/_internal/cpython-2.7.11-ucs2/lib/python2.7/site-packages/pip/basecommand.py", line 215, in main
status = self.run(options, args)
File "/opt/_internal/cpython-2.7.11-ucs2/lib/python2.7/site-packages/pip/commands/install.py", line 317, in run
prefix=options.prefix_path,
File "/opt/_internal/cpython-2.7.11-ucs2/lib/python2.7/site-packages/pip/req/req_set.py", line 736, in install
requirement.uninstall(auto_confirm=True)
File "/opt/_internal/cpython-2.7.11-ucs2/lib/python2.7/site-packages/pip/req/req_install.py", line 742, in uninstall
paths_to_remove.remove(auto_confirm)
File "/opt/_internal/cpython-2.7.11-ucs2/lib/python2.7/site-packages/pip/req/req_uninstall.py", line 115, in remove
renames(path, new_path)
File "/opt/_internal/cpython-2.7.11-ucs2/lib/python2.7/site-packages/pip/utils/__init__.py", line 267, in renames
shutil.move(old, new)
File "/opt/_internal/cpython-2.7.11-ucs2/lib/python2.7/shutil.py", line 303, in move
os.unlink(src)
OSError: [Errno 13] Permission denied: '/opt/_internal/cpython-2.7.11-ucs2/bin/easy_install'
```
David M. Lary
Bensuperpc