Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #9601 > unrolled thread

Re: Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version

Started byMatthias Klose <doko@debian.org>
First post2017-07-01 12:50 +0200
Last post2017-07-01 12:50 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Bug#866668: src:python-cryptography: Misbuild with more than one  supported python3 version Matthias Klose <doko@debian.org> - 2017-07-01 12:50 +0200

#9601 — Re: Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version

FromMatthias Klose <doko@debian.org>
Date2017-07-01 12:50 +0200
SubjectRe: Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version
Message-ID<tYo8p-1X9-13@gated-at.bofh.it>
On 30.06.2017 22:00, Tristan Seligmann wrote:
> Control: severity -1 important
> 
> On Fri, 30 Jun 2017 at 19:33 Scott Kitterman <debian@kitterman.com> 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

[toc] | [standalone]


Back to top | Article view | linux.debian.maint.python


csiph-web