[OE-core] [PATCH v2] python3{,-native}: update to 3.7.0

[Jens Rehsack]

> Am 11.09.2018 um 20:56 schrieb Alejandro Enedino Hernandez Samaniego <alejandro.enedino.hernandez-samaniego at xilinx.com>:
> 
> Hey Jens,
> 
Hey Alejandro,

> On 09/10/2018 11:58 PM, Jens Rehsack wrote:
>> 
>> 
>>> Am 10.09.2018 um 23:33 schrieb Alejandro Enedino Hernandez Samaniego <alejandro.enedino.hernandez-samaniego at xilinx.com <mailto:alejandro.enedino.hernandez-samaniego at xilinx.com>>:
>>> 
>>> Hey Jens,
>>> 
>>> 
>>> As I explained before, when you create a manifest for python (target), it uses the native build as base (it literally runs the native python that was just built), it is assumed its the same version as target and contains all the modules provided by upstream, otherwise the missing modules cannot be checked for dependencies, and the manifest becomes incoherent, so its not an option to have an incomplete python native build.
>>> 
>> In that case, uuid for target never gets deployed, but it is. And I didn't see any packaging issues for `python3` nor for `nativesdk-python3`
> 
> 
> I don't see what that has to do with anything, fixing the native build should not affect what gets deployed on target, thats exactly why we have a manifest, so they user can decide what to install and what not to install.

The manifest isn't used for python3-native.
You try to argue whether there is an error to be fixed - and I don't agree.
Each fix requires effort - and that's why some errors will never become fixed. When the impact is reasonable or high enough, fixes are more likely.

So: before you try to force me into "that's all ugly und must be seriously beautified just because ..." I will not do anything.
When you give me a sane reason, I try to understand and make a decision.

> I know you didn't see any packaging issues, but that doesn't mean they don't exist, just from the log I showed you, I can tell you that the python3-crypt package is not created correctly, for example, if you do:
> 
> IMAGE_INSTALL_append = " python3-crypt"
> 
> Boot the image, run python3 and you try to import sha3, it will fail, because the sha3*.so library won't be on the filesystem.
> 
> 
> And thats because the sha3.*.so library was just introduced in this upgrade, and our manifest isn't aware it exists, hence it'll end up on python3-misc and you have just created an unnecessary dependency from python3-crypt to python3-misc (and worse, a dependency which were not even aware of, until we test it manually), which beats the whole purpose of the manifest.
> 
> The do_package function is not gonna fail just because, so you won't see errors, but the files will be packaged incorrectly, causing runtime errors as a consequence, the create_manifest task tries to solve these runtime issues before they happen.

That's something completely different. I'm not a python guy and I don't get from the ChangeLog what I have to change in the manifest.
I can and will do such stuff when doing the perl update. For python, I ask for review because of things I don't know.

You can give me a reasonable list of such changes and I update the manifest accordingly when I rebase the patch after Ross PGO patches are committed.

> Cheers,
> 
> Alejandro
> 
> 
>>> Yes you probably need a patch to look at the correct directories for the h files, as well as a dependency to make the h files available on recipe-sysroot-native.
>>> 
>> Please check the submission.
> 
> I did, its not checking inside recipe-sysroot-native.

I know. You could check the submission anyway and find the right patch and then argue differently.

Cheers
--
Jens Rehsack - rehsack at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180912/23e9efc5/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180912/23e9efc5/attachment-0002.sig>