No problem. It is a bit confusing that it's tagged as though it's going to be uploaded.
On Thu, Feb 27, 2020, at 12:41 PM, Sylvain Corlay wrote: > Thanks Thomas, I was mistaken by the first line of the docker image which > includes a full URL on quay.io > > > FROM quay.io/pypa/manylinux2010_centos-6-no-vsyscall > > We will build this image ourself. > > Best, > > > On Wed, Feb 26, 2020 at 10:38 AM Thomas Kluyver <[email protected]> wrote: >> __ >> To be precise, these are not uploaded at all - there's no hidden repository >> on quay.io AFAICT, and I'm an owner of the pypa team there. >> >> The CI on the manylinux repo always builds both stages one after the other. >> They're split as an implementation detail - if I recall correctly, doing >> everything in one Dockerfile tended to hit a timeout on Travis. So I'm >> inclined to say that the intermediate image is not any kind of a public >> interface, and you should build it from the git repository if you need it. >> >> Thomas >> >> On Wed, Feb 26, 2020, at 9:12 AM, Sylvain Corlay wrote: >>> I am fine with there being a specific base image but I think that it should >>> be pullable. >>> >>> On Wed, Feb 26, 2020, 04:06 Wes Turner <[email protected]> wrote: >>>> >>>> >>>> On Tue, Feb 25, 2020, 10:03 PM Wes Turner <[email protected]> wrote: >>>>> >>>>> Is there a reason the new manylinux does not just extend centos:6? >>>> >>>> https://github.com/pypa/manylinux/blob/master/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 manylinux2010 on 64-bit hosts. This requires >>>> > building the image on a system with vsyscall=emulate but allows the >>>> > resulting container to run on systems with vsyscall=none or >>>> > vsyscall=emulate. >>>> > >>>> > vsyscall is an antiquated optimization for a small number of >>>> > frequently-used system calls. A vsyscall-enabled Linux kernel maps a >>>> > read-only page of data and system calls into a process' memory at a >>>> > fixed address. These system calls can then be invoked by dereferencing a >>>> > function pointers to fixed offsets in that page, saving a relatively >>>> > expensive context switch. [1] >>>> > >>>> > Unfortunately, because the code and its location in memory are fixed and >>>> > well-known, the vsyscall mechanism has become a source of gadgets for >>>> > ROP attacks (specifically, Sigreturn-Oriented Programs). [2] Linux 3.1 >>>> > introduced vsyscall emulation that prevents attackers from jumping into >>>> > the middle of the system calls' code at the expense of speed, as well as >>>> > the ability to disable it entirely. [3] [4] The vsyscall mechanism could >>>> > not be eliminated at the time because glibc versions earlier than 2.14 >>>> > contained hard-coded references to the fixed memory address, >>>> > specifically in time(2). [5] These segfault when attempting to issue a >>>> > vsyscall-optimized system call against a kernel that has disabled it. >>> -- >>> Distutils-SIG mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/[email protected]/message/T6KDLHKSE4DHCVIACR7QQH3XG6RGBRRO/ >>> >> >> -- >> Distutils-SIG mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ >> Message archived at >> https://mail.python.org/archives/list/[email protected]/message/OR3MYEWUCHGHMK6YBJCDBUYIZJ3JJF7P/
-- Distutils-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/A6P3WE2OW7QR7H7C57EKRZYKHURCGIWN/
