Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version
On 30.06.2017 22:00, Tristan Seligmann wrote: > Control: severity -1 important > > On Fri, 30 Jun 2017 at 19:33 Scott Kitterman wrote: > >> Technically, it builds, but in a way that's not useful. It would actually >> be >> better if it had failed (I noticed this from reviewing build logs after the >> python3 interpreter depends weren't generated correctly). >> > > In fact, the package works fine on python3.5 as well as python3.6 (the > module imports, and the full test suite passes against the installed > modules), thus I'm downgrading the severity of this bug. > > During the build, the extension modules are first built on python3.5, and > it is these modules that land in /usr/lib/python3, with the "abi3" ABI tag. > The extension modules are then built again on python3.6, but these don't > get moved into /usr/lib/python3 due to the files from the python3.5 build > having the same name, thus landing in an incorrect directory in the final > package and serving no useful purpose. > > The reason the package still works is the "abi3" ABI tag; these modules > (like all CFFI-built modules, by default) are using the Python 3 "stable > ABI"[1] so the modules built on python3.5 work fine when imported on > python3.6, and vice-versa. I think what this means is that we only need to > run the Python 3 build once (using the default version?); also, I think the > interpreter depends are in fact correct in light of this. I tested > downgrading to 1.7.1-3 and the module still imports and works on python3.6, > even though 1.7.1-3 was only ever built against python3.5. > > However, testing against all supported versions at build time is probably > still appropriate. > > I'm looping in debian-python here as others may be surprised by this > combination of effects as well, and we should probably be handling the > issue of modules using the stable ABI consistently. Also, I'm not 100% > certain what the best way forward is here; teach pybuild/dh_python3 about > the stable ABI? I think testing the build against all supported python versions makes sense. But how do we make sure that a package built against the new supported version end up in the archive for a release? Matthias
Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version
Control: severity -1 important On Fri, 30 Jun 2017 at 19:33 Scott Kitterman wrote: > Technically, it builds, but in a way that's not useful. It would actually > be > better if it had failed (I noticed this from reviewing build logs after the > python3 interpreter depends weren't generated correctly). > In fact, the package works fine on python3.5 as well as python3.6 (the module imports, and the full test suite passes against the installed modules), thus I'm downgrading the severity of this bug. During the build, the extension modules are first built on python3.5, and it is these modules that land in /usr/lib/python3, with the "abi3" ABI tag. The extension modules are then built again on python3.6, but these don't get moved into /usr/lib/python3 due to the files from the python3.5 build having the same name, thus landing in an incorrect directory in the final package and serving no useful purpose. The reason the package still works is the "abi3" ABI tag; these modules (like all CFFI-built modules, by default) are using the Python 3 "stable ABI"[1] so the modules built on python3.5 work fine when imported on python3.6, and vice-versa. I think what this means is that we only need to run the Python 3 build once (using the default version?); also, I think the interpreter depends are in fact correct in light of this. I tested downgrading to 1.7.1-3 and the module still imports and works on python3.6, even though 1.7.1-3 was only ever built against python3.5. However, testing against all supported versions at build time is probably still appropriate. I'm looping in debian-python here as others may be surprised by this combination of effects as well, and we should probably be handling the issue of modules using the stable ABI consistently. Also, I'm not 100% certain what the best way forward is here; teach pybuild/dh_python3 about the stable ABI? [1] https://docs.python.org/3/c-api/stable.html
Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version
Package: src:python-cryptography Version: 1.9-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Technically, it builds, but in a way that's not useful. It would actually be better if it had failed (I noticed this from reviewing build logs after the python3 interpreter depends weren't generated correctly). The compiled elements of the python3 package are missing for python3.5 and in the wrong location for python3.6: ./usr/lib/python3.6/dist-packages/ ./usr/lib/python3.6/dist-packages/cryptography/ ./usr/lib/python3.6/dist-packages/cryptography/hazmat/ ./usr/lib/python3.6/dist-packages/cryptography/hazmat/bindings/ ./usr/lib/python3.6/dist-packages/cryptography/hazmat/bindings/_constant_time.abi3.so ./usr/lib/python3.6/dist-packages/cryptography/hazmat/bindings/_openssl.abi3.so ./usr/lib/python3.6/dist-packages/cryptography/hazmat/bindings/_padding.abi3.so https://buildd.debian.org/status/fetch.php?pkg=python-cryptography&arch=amd64&ver=1.9-1&stamp=1498830154&raw=0 They should be in /usr/lib/python3 and ABI tagged. Scott K
