Manylinux2010 #182

dolang · 2018-04-16T01:07:41Z

Now that there's some activity again here, I figure it's easier to expose the changes I made as a pull request so you can have a look at the diffs.

This is from my manylinux2010 branch which is based on markrwilliams:manylinx2 merged into pypa:master.

I tried to keep this branch close to upstream and just merged the most recent commit to master (4a20e4b) with minor adjustments.

I don't expect this to be merged by itself, but hope it saves you guys some time. Notable:

Removed gpg from PYTHON_COMPILE_DEPS because it's already present on CentOS 6 and its erasure later in the script breaks the build.
Removed ncurses-devel as required by the PEP.
Added perl-devel, seems to be required for the build now.
Added a workaround for libcurl.so incompatibility (see commit notes & comments).
Removed the get-pip.py workaround. That has been fixed (see here) and my build script works again.
Moved libffi-devel from PYTHON_COMPILE_DEPS to the "Development tools and libraries" section.
Changed the x86_64 Docker tag from :6.9 to :6. This mirrors a manylinux1 change intended to reduce the overall image size (see Reduce image size #206 and also :6 Docker branch / :6.9 Docker branch).
Moved from CentOS 6.9 to 6.10
Careful: I also changed occurrences of manylinux1 to either manylinux or manylinux2010. This might be undesired.

Side note: not a fan of the /dev/null out/error stream redirections in the scripts. They just make it harder to debug when something fails. And there definitely are moving parts, as the get-pip.py problem has shown.

…ster - The dockerfiles build successfully. - Compared to current master, there's a new intermediate image for glibc. As the x86_64 build depends on it, this must have a predefined name. In the PR the "naming prefix" is 'markrwilliams/manylinux2', therefore it's assumed for all images. - There's a problem with libcurl which has been (temporarily) resolved with script which redirects yum. See docker/build_scripts/build.sh for details. The following script is proven to work: pushd docker/glibc/ docker build -t markrwilliams/manylinux2:centos-6.9-no-vsyscall popd docker/build_scripts/prefetch.sh curl openssl docker build -t markrwilliams/manylinux2:x86_64 \ -f docker/Dockerfile-x86_64 docker/ docker build -t markrwilliams/manylinux2:i686 \ -f docker/Dockerfile-i686 docker/

- docker/build_scripts/build.sh: - removed libncurses.devel; not part of PEP 571 - removed gpg as dependency, because yum already requires it - removed some /dev/null redirections, because they hinder debugging - docker/build_scripts/manylinux1-check.py - renamed to manylinux-check.py - changed names/comments to new version - the check now targets glibc 2.12 instead of 2.5 - .travis.yml - only changed the image name - TODO: x86_64 still needs a script for the no-vsyscall image dependency - docker/deploy.sh - changed image name - note: .rst files have not been touched

- The freshly released version of pip breaks build_utils.sh which tries to get the latest and greatest. Added a condition to instead use the latest version below v10.

- Incorporated the lastest changes from the official repository. - That cleanup removed two packages from 'yum erase ...' which looks like an oversight. Readded. - Removed the hack which fixed the broken build when the new pip was released. This has been fixed upstream, see here: pypa/get-pip#19

njsmith · 2018-04-16T06:56:32Z

Unfortunately, some amount of > /dev/null redirections are mandatory because Travis unconditionally kills any job that prints too much output.

dolang · 2018-04-16T12:57:03Z

Good thing you mentioned that (I didn't actually know). While I've removed those from my master, I actually tried to not mess with this manylinx2010 branch.

I've just noticed that I've removed two of those in this branch and you're making a very good point for keeping them in. So I'll add them back.

An alternative would be to redirect to e.g. >> /var/log/build.log and remove that file again during the cleanup step. In case the build breaks (locally), one could at least docker commit to inspect the log instead of rerunning it manually. But it's a minor issue anyway.

Just noticed as well that the diffs are not that great because I merged the latest commits into this preexisting branch. You'd have to rebase/merge locally to get a better result, I guess. Sorry about that.

dolang · 2018-05-02T10:26:57Z

Note: The travis CI build does actually run now for this pull request, but despite what it says, it didn't complete successfully.

The newly added build.sh needs a set -e -x or something like that.

I run a local build before each merge commit, however. So it should be fine.

trishankatdatadog · 2018-05-02T14:54:45Z

Sorry about the new build.sh, @dolang, that was me. Want me to add those shell options?

dolang · 2018-05-02T15:10:12Z

Myself, I don't need it because I don't (yet) use travis for anything. I have a small build script in my master branch. But I guess it would be in your interest to add those options (if travis allows them)? In any case, I can't verify that the code for travis is correct.

I'm not really in the loop here, I'm just keeping this pull request up-to-date as a reference/help for you guys once it's time to make the switch to manylinux2010.

trishankatdatadog · 2018-05-02T15:15:44Z

I think I see the problem now. Hopefully fixed in #190...

dolang · 2018-05-03T15:07:12Z

x86_64 still fails, but that's not a surprise because it depends on that third Docker image which is not required for manylinux1. I might try to fix that later.

However, i686 seems to have completed a full build, so #190 definitely helped.

trishankatdatadog · 2018-05-03T15:18:47Z

Glad to hear, let me know if I can help with anything else!

- Add platform-dependent clause - Assign the same prefix to the the no-vsyscall image (quay.io/pypa/...) - The dependent docker/Dockerfile-x86_64 needs this prefix in FROM ...

dolang · 2018-05-03T16:25:15Z

Took a stab at it, but I'm not sure if the no-vsyscall Docker image should eventually get the $TRAVIS_COMMIT tag, too. So I left it out because that's easier.

Edit: Might actually be running fine, but Travis can't deal with the glibc build. Needs less output and more travis_wait time.

- Increase in `travis_wait` time - Shunting build output off into a log file which can be inspected on failure.

is merge is necessary,

- Similar to gpg the libffi-devel package can't be removed after the build, but it looks like this is because it was improperly packaged. - Moved libffi to the "Development tools and libraries" section.

dolang · 2018-06-16T03:00:23Z

I had to move libffi-devel from the PYTHON_COMPILE_DEPS because it can't be removed after the build, breaking the script:

install-info: No such file or directory for /usr/share/info/libffi.info.gz
error: %preun(libffi-devel-3.0.5-3.2.el6.x86_64) scriptlet failed, exit status 1
Error in PREUN scriptlet in rpm package libffi-devel
libffi-devel-3.0.5-3.2.el6.x86_64 was supposed to be removed but is not!
  Verifying  : libffi-devel-3.0.5-3.2.el6.x86_64

Failed:
  libffi-devel.x86_64 0:3.0.5-3.2.el6

It's only 21 Kb in size, so keeping it in the "Development tools and libraries" section is not a big problem anyway.

Like with CentOS 5 there's a CentOS 6 Docker image which is more up to date (tag :6) than the latest release (tag :6.9). See: pypa#206

dolang · 2018-07-04T15:16:00Z

Well, that's odd. It did build on my machine before committing, though. From the Travis log:

$ PLATFORM=$PLATFORM TRAVIS_COMMIT=$TRAVIS_COMMIT travis_wait 60 ./build.sh


Still running (49 of 60): ./build.sh

The job exceeded the maximum time limit for jobs, and has been terminated.

Ran for 49 min 29 sec

dolang · 2018-07-04T15:21:29Z

On another note: Looks like CentOS 6.10 is available now, and I should look through the code again.

I'll have a look at that later.

dolang · 2018-07-11T03:23:55Z

Somehow the Travis build stops at 50 minutes although travis_wait is set to 60. Locally, the images build fine.

I've had a look around, maybe I should try the workaround linked here from this commit?

Previously, vault.centos.org was missing some repository information, which prevented moving to 6.10. This is now available on CentOS 6.10 and it includes a glibc v1.212 (up from 1.209). All changes made are only to bump this version number.

dolang · 2018-07-28T14:37:11Z

I've been able to move to CentOS 6.10 now, previously some repository information was missing (namely the repodata subfolder in http://vault.centos.org/6.10/os/Source/).

There's a new build of glibc in there, so I had to update the version from 1.209 to 1.212. Now here's a question regarding the custom glibc version:

I think I've run into a problem at some point because the new version number that is assigned in the no-vsyscall simply appends a .1 (dot one), i.e. now it's 1.212.1, but I don't quite remember because it's already been a few months. To someone more familiar with RPMs: Wouldn't it be better to append a -1 (dash one) denoting a new build instead of a new version?

Edit: Actually, I'm not quite sure if that's the right way to denote the same version but a different release. I've had a look at this Serverfault question and the linked Fedora Guidelines. The latter seems to indicate one would have to append a .1 at the end. Or maybe I'm not understanding this right.

njsmith · 2018-07-29T01:32:29Z

I can explain the timeout stuff anyway... Travis puts a hard limit of 50 minutes on all (open source) build jobs: https://docs.travis-ci.com/user/customizing-the-build/#build-timeouts

Travis also kills jobs that spend 10 minutes without producing output; the travis_wait script is a hack to avoid hitting this 10 minute timeout, by producing a continuous stream of meaningless output. But it doesn't help with the 50 minute limit.

jcfr · 2018-07-29T08:03:10Z

@njsmith Would you consider switching to CircleCI ? I would be happy to help.

njsmith · 2018-07-29T08:18:20Z

@jcfr The time I have to spend on manylinux-related things has gone down a bunch in the last few months, and I was kind of the only one doing things. So, honestly as far as I'm concerned, anyone who wants to step up and do the work is pretty much welcome to do whatever works for them.

dralley · 2018-09-05T20:04:20Z

Bump: Is this work going to proceed any time soon?

trishankatdatadog · 2018-09-05T20:19:49Z

Sorry, I haven't had a time to look at this either. What do @dolang and others think?

mayeut · 2018-09-06T20:00:43Z

If I'm not mistaken, auditwheel still needs to get updated. c.f. #179

trishankatdatadog · 2018-09-06T20:05:56Z

@mayeut Does that require another PR here?

mayeut · 2018-09-06T20:20:13Z

Once audit wheel gets released - I have no idea when, I commented on a PR there some time ago -, the pyup-bot will open a PR that needs to get merged in master (if CI is ok of course). Then I guess @dolang will have to merge upstream changes once more in this PR.
After that, I think it should be ok to merge if reviewers have nothing more to say. I guess manylinux1 (current master) will still have to be maintained for some time in a maintenance branch.

trishankatdatadog · 2018-09-06T20:32:35Z

Ok, sounds good. I'll try to read up on the PEP and this PR in the meantime.

galv · 2018-10-19T05:35:08Z

docker/build_scripts/build.sh

-cp $MY_DIR/epel-release-5-4.noarch.rpm .
-check_sha256sum epel-release-5-4.noarch.rpm $EPEL_RPM_HASH
+# https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
+cp $MY_DIR/epel-release-6-8.noarch.rpm .


I don't think we should be concerned about this, but note that this doesnot correspond to centos 6.10. I'm not sure what the canonical location for the extended package for enterpriselinux (EPEL) rpm is, myself.

galv · 2018-10-19T05:36:36Z

docker/glibc/README.rst

+*Summary*: Because of
+https://mail.python.org/pipermail/wheel-builders/2016-December/000239.html,
+this a CentOS 6.10 Docker image that rebuilds ``glibc`` without
+*vsyscall* is necessary to reliably run ``manylinux2`` on 64-bit


manylinux2 -> manylinux2010

ehashman · 2018-11-17T18:03:10Z

There is a bit of a bootstrapping problem in which auditwheel is currently testing against a non-official manylinux2010 image because this one hasn't been released 😄 I'll have an auditwheel release candidate up by the end of the weekend.

Edit: Please test this PR by bumping the auditwheel version to 2.0rc1. I don't want to unleash 2.0 on the world unless we're sure it's working okay.

takluyver · 2019-02-14T08:50:44Z

Is someone clear what the next steps are for this PR and/or #252?

auditwheel 2.0 is out now, and as @mayeut said, there is a PR (#262) to update to it in this repository. Does that patch need to be applied to this PR?

What are the relative merits of this and #252? @henriquegemignani mentions on that PR that it uses 'devtoolset 7', and 'another approach to the curl issue', but it is (or was?) less ready for merge than this one.

I'm keen to see manylinux2010 in use, and I think the images are the last crucial part of the toolchain. But I lack the low-level knowledge to evaluate the changes in either PR.

mayeut · 2019-02-16T12:24:21Z

Well, I'm not sure anyone's clear one the next steps. I'm also not sure this PR is the place to discuss it either so I'll answer in #179

mayeut · 2019-04-12T03:35:11Z

Superseded by #279 that's been merged-in.

dolang added 4 commits April 13, 2018 06:16

Fix for new release of pip (v10.0.0) breaking the build script

27e7332

- The freshly released version of pip breaks build_utils.sh which tries to get the latest and greatest. Added a condition to instead use the latest version below v10.

dolang added 5 commits April 16, 2018 15:00

Re-add the two /dev/null redirections in build.sh

54b3c84

Merge upstream changes (6f3bc0b)

dcd4acf

Merge upstream changes (3dd4551)

8f868fb

Merge upstream changes (4132165)

50f4eac

Merge upstream changes (0566338)

0a6c6ee

dolang mentioned this pull request May 3, 2018

Add support for manylinux2010 pypa/cibuildwheel#65

Closed

Merge upstream changes (9f3b52a)

55b3514

Adapt build.sh for the x86_64 two-stage build

87886d4

- Add platform-dependent clause - Assign the same prefix to the the no-vsyscall image (quay.io/pypa/...) - The dependent docker/Dockerfile-x86_64 needs this prefix in FROM ...

dolang added 2 commits May 4, 2018 01:04

Getting Travis to play along

2664c85

- Increase in `travis_wait` time - Shunting build output off into a log file which can be inspected on failure.

Merge upstream changes (e893a63)

67ef9a0

lelit mentioned this pull request May 19, 2018

Add Python 3.7.0b4 #196

Merged

dolang added 3 commits May 21, 2018 11:42

Merge upstream changes (d837450)

05098c8

Merge upstream changes (1971a37)

2ec5c38

is merge is necessary,

Merge upstream changes (96b47a2); move libff-devel

e075849

- Similar to gpg the libffi-devel package can't be removed after the build, but it looks like this is because it was improperly packaged. - Moved libffi to the "Development tools and libraries" section.

dolang added 2 commits June 28, 2018 14:35

Merge upstream changes (46241e9)

24082fe

Merge a0d46fa; mirror base image change :6.9 -> :6

0a31334

Like with CentOS 5 there's a CentOS 6 Docker image which is more up to date (tag :6) than the latest release (tag :6.9). See: pypa#206

mayeut mentioned this pull request Jul 7, 2018

[WIP] Reduce image size #210

Closed

Merge upstream changes (9e82cb0)

e05c365

Merge 46e2d66; update to CentOS 6.10

c39783f

Previously, vault.centos.org was missing some repository information, which prevented moving to 6.10. This is now available on CentOS 6.10 and it includes a glibc v1.212 (up from 1.209). All changes made are only to bump this version number.

dralley mentioned this pull request Jul 30, 2018

Enable building Python packages for PyPI distribution rpm-software-management/createrepo_c#103

Merged

tshirtman mentioned this pull request Oct 10, 2018

Kivy requires Cython to be installed by the user in some situations, which makes depending on it as a package problematic kivy/kivy#5984

Closed

galv reviewed Oct 19, 2018

View reviewed changes

takluyver mentioned this pull request Dec 3, 2018

Manylinux2 #152

Closed

henriquegemignani mentioned this pull request Dec 11, 2018

[WIP] manylinux2010 with devtoolset 7 #252

Closed

ncoghlan mentioned this pull request Jan 25, 2019

Tracking issue for manylinux2010 rollout #179

Closed

14 tasks

mayeut mentioned this pull request Feb 16, 2019

Update manylinux2010 policy with i686 symbol versions pypa/auditwheel#141

Merged

mayeut mentioned this pull request Mar 19, 2019

[WIP] Manylinux2010 #279

Merged

3 tasks

mayeut closed this Apr 12, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Manylinux2010 #182

Manylinux2010 #182

dolang commented Apr 16, 2018 •

edited

Loading

njsmith commented Apr 16, 2018

dolang commented Apr 16, 2018

dolang commented May 2, 2018 •

edited

Loading

trishankatdatadog commented May 2, 2018

dolang commented May 2, 2018

trishankatdatadog commented May 2, 2018

dolang commented May 3, 2018

trishankatdatadog commented May 3, 2018

dolang commented May 3, 2018 •

edited

Loading

dolang commented Jun 16, 2018

dolang commented Jul 4, 2018

dolang commented Jul 4, 2018

dolang commented Jul 11, 2018

dolang commented Jul 28, 2018 •

edited

Loading

njsmith commented Jul 29, 2018

jcfr commented Jul 29, 2018

njsmith commented Jul 29, 2018

dralley commented Sep 5, 2018

trishankatdatadog commented Sep 5, 2018

mayeut commented Sep 6, 2018

trishankatdatadog commented Sep 6, 2018

mayeut commented Sep 6, 2018

trishankatdatadog commented Sep 6, 2018

galv Oct 19, 2018

galv Oct 19, 2018

ehashman commented Nov 17, 2018 •

edited

Loading

takluyver commented Feb 14, 2019

mayeut commented Feb 16, 2019

mayeut commented Apr 12, 2019

Manylinux2010 #182

Manylinux2010 #182

Conversation

dolang commented Apr 16, 2018 • edited Loading

njsmith commented Apr 16, 2018

dolang commented Apr 16, 2018

dolang commented May 2, 2018 • edited Loading

trishankatdatadog commented May 2, 2018

dolang commented May 2, 2018

trishankatdatadog commented May 2, 2018

dolang commented May 3, 2018

trishankatdatadog commented May 3, 2018

dolang commented May 3, 2018 • edited Loading

dolang commented Jun 16, 2018

dolang commented Jul 4, 2018

dolang commented Jul 4, 2018

dolang commented Jul 11, 2018

dolang commented Jul 28, 2018 • edited Loading

njsmith commented Jul 29, 2018

jcfr commented Jul 29, 2018

njsmith commented Jul 29, 2018

dralley commented Sep 5, 2018

trishankatdatadog commented Sep 5, 2018

mayeut commented Sep 6, 2018

trishankatdatadog commented Sep 6, 2018

mayeut commented Sep 6, 2018

trishankatdatadog commented Sep 6, 2018

galv Oct 19, 2018

Choose a reason for hiding this comment

galv Oct 19, 2018

Choose a reason for hiding this comment

ehashman commented Nov 17, 2018 • edited Loading

takluyver commented Feb 14, 2019

mayeut commented Feb 16, 2019

mayeut commented Apr 12, 2019

dolang commented Apr 16, 2018 •

edited

Loading

dolang commented May 2, 2018 •

edited

Loading

dolang commented May 3, 2018 •

edited

Loading

dolang commented Jul 28, 2018 •

edited

Loading

ehashman commented Nov 17, 2018 •

edited

Loading