Am 11.09.2018 um 20:56 schrieb Alejandro Enedino Hernandez Samaniego <alejandro.enedino.hernandez-samaniego@xilinx.com>:Hey Jens,
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@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.
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.
Cheers,
Alejandro
Please check the submission.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.
I did, its not checking inside recipe-sysroot-native.