The transition to add support for Python 3.6 is beginning
Matthias Klose
doko at ubuntu.com
Wed Jul 26 11:09:13 UTC 2017
On 26.07.2017 11:08, Michael Hudson-Doyle wrote:
> On 21 July 2017 at 15:36, Michael Hudson-Doyle <michael.hudson at canonical.com
>> wrote:
>
>> On 29 June 2017 at 10:43, Michael Hudson-Doyle <
>> michael.hudson at canonical.com> wrote:
>>
>>>
>>>
>>> On 21 June 2017 at 15:13, Michael Hudson-Doyle <
>>> michael.hudson at 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/+arch
>>>> ive/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/1Y8dy5cyu8DrmTvT4CNSa
>>> VSP2ZZT79sYhT_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?
now reported upstream and in Debian, and uploaded to artful to ignore the test
results on armhf; at least you won't see these on a 32bit kernel.
More information about the ubuntu-devel
mailing list