Re: The transition to add support for Python 3.6 is beginning

On 21 July 2017 at 15:36, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:

On 29 June 2017 at 10:43, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:

On 21 June 2017 at 15:13, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:

Hi all,

An update on the transition to Python 3.6: Python 3.6 is now a supported version in artful release, and almost all packages that build C extensions have been rebuilt (pandas is still a problem).

We have created a PPA where python3.6 is the default and rebuilt all python packages: https://launchpad.net/~canonical-foundations/+archive/ubuntu/python3.6-as-default/+packages and the next step is to fix all the failures this reveals.  The initial failing source packages are listed in http://paste.ubuntu.com/24903638/ although some of those have been fixed now.

 

The 100 or so failures are now summarised in https://docs.google.com/spreadsheets/d/1Y8dy5cyu8DrmTvT4CNSaVSP2ZZT79sYhT_rAQ19bFUQ/edit?usp=sharing, please do check if any packages you care about are on the list and fix any that you can see how to. Uploading fixes direct to the archive is preferred, but if you lack the rights to do that, attaching a bug to a debdiff and subscribe me (mwhudson on lp) and I'll sponsor it v. quickly!

We've fixed many of these now, and I've uploaded the change to make python 3.6 the default version in artful. Next step is getting this to migrate, see http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#python3-defaults for that and please help fix anything that is preventing the migration (like whatever it is that breaks botch with python 3.6 as default...)

We are so very close to this.

The final barrier (assuming that the recently uploaded samba does not drag any new problems in) is that src:yara does not build on armhf. This turns out to be because the codebase is full of code that assumes unaligned access is OK, for example stuff like this https://github.com/VirusTotal/yara/blob/master/libyara/exec.c#L224 but also more subtly stuff like https://github.com/VirusTotal/yara/blob/master/libyara/scan.c#L409 (new_match is only guaranteed to be 4-byte-aligned and crashes when you access an 8 byte field).

This could all be fixed, I'm sure, but I don't know if upstream would be interested and at this stage I wonder if removing the package on armhf is more pragmatic. It has a few rdeps but not all that many. Thoughts?

Cheers,

mwh