[Buildroot] [PATCH 2/2] package/kmsxx: update to latest

[Tomi Valkeinen]

Hi,

On 10/08/2021 22:39, Yann E. MORIN wrote:
> Tomi, All,
> 
> On 2021-08-09 09:23 +0300, Tomi Valkeinen spake thusly:
>> And I'd love to enable the python bindings for kms++ in buildroot, but I
>> didn't manage to get meson find buildroot's pybind11. I'll look at that more
>> at some point. I think the problem is that meson should find pybind11 using
>> cmake (apparently that can be used to find dependencies...), but when
>> building kms++, meson just says:
>>
>> CMake binary for MachineChoice.HOST is not cached
>> CMake binary missing from cross or native file, or env var undefined.
>> Default target is not allowed for cross use
>> Found CMake: NO
> 
> Could you try to add:
> 
>      KMSXX_DEPENDENCIES += $(BR2_CMAKE_HOST_DEPENDENCY)
> 
> To see if that would solve the issue?

I did get a bit forward, but not much. I think this also needs to be 
added, to package/meson/cross-compilation.conf.in:

cmake = '@HOST_DIR@/bin/cmake'

This helps meson to find cmake, but then the problems wrt. pybind11 and 
python started. I don't think cmake managed to find the .cmake files 
installed by buildroot's pybind11 package, so I just hacked and copied

<output>/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/python3.9/site-packages/pybind11/share/cmake/pybind11

to

<output>/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/cmake/

so that they are in similar place as from Ubuntu's pybind11 package.

I think that helped cmake find them, but then I'm seeing "Python config 
failure: Python is 64-bit, chosen compiler is 32-bit" error from 
pybind11's cmake files.

I also tried to change buildroot's python-pybind package to be a 
cmake-package, instead of python-package (thinking that perhaps it'll 
install the files to correct place), but again go the 64/32-bit error.

At this point I gave up, as I don't have much experience with cmake (and 
it's horrible =).

>> On 08/08/2021 23:33, Yann E. MORIN wrote:
>>> I am by far not a meson expert, so when you say "the fallback-to-subproject
>>> can be managed with meson commandline options", I'd be much interested
>>> in hos to do that, so that in Buildrot we know how to forcibly forbid
>>> bundled sub-projects (or wraps?) to be used...
>> https://mesonbuild.com/Subprojects.html#commandline-options
>> So, buildroot could globally define "--wrap-mode=nodownload" for meson to
>> prevent download of the subprojects.
> 
> Shouldn't we instead use:   --wrap-mode=nofallback
> 
> This entirely prevent use of wraps, even those that are already present
> (e.g. because an upstream packager would have added them when generating
> the release tarball for example).

Yes, I that makes sense too. I was thinking that the reason to avoid 
fallback is to avoid downloading unverified source code. nodownload does 
that, as if the subproject is packaged in the release tarball, it's 
"verified" in the same way the source of the package itself is, i.e. the 
exact code is known at the time the buildroot package is made, and the 
hash file checks the subproject too.

But if the intention is to make sure all packages use the same version 
of a library, then nofallback is better.

>> Developers who need the functionality
>> of 'use-system-pybind11' option can use
>> "--force-fallback-for=list,of,dependencies".
> 
> This should only be done in conjunction with --wrap-mode=nodownload
> 
>> And at least for me, the download doesn't even work inside buildroot:
>>
>> Downloading pybind11 source from
>> https://github.com/pybind/pybind11/archive/v2.6.0.zip
>> <urlopen error unknown url type: https>
>                              ,------^^^^^
> I think the error lies there: meson is written in python3, and is
> executed with our host-python3, which we only conditionally build it
> with support for TLS:
> 
>     package/python3/python3.mk:
>     46 ifeq ($(BR2_PACKAGE_HOST_PYTHON3_SSL),y)
>     47 HOST_PYTHON3_DEPENDENCIES += host-openssl
>     48 else
>     49 HOST_PYTHON3_CONF_OPTS += --disable-openssl
>     50 endif
> 
> So, this is a good thing that this is not available by default: wraps
> can only be downloaded from insecure sites, which if the meson wrapDB is
> properly curated, should not happen. And thus, it should not be possible
> to ever download any wrap at all! Aha. Aha! AHA! MUAHAHA! ;-]
> 
> But jokes aside, try setting BR2_PACKAGE_HOST_PYTHON3_SSL=y, and I would
> guess downloading wraps would be come possible (although this would be a
> very bad idea).

Then I get:

<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify 
failed: unable to get local issuer certificate (_ssl.c:1129)>

I guess root certs are missing?

This would be nice to have working for the cases where buildroot doesn't 
have the subproject package available (or working, as is the case here 
with pybind11). Even if mainline buildroot doesn't allow subproject 
downloads, it's nice to have it locally.

In my case, I had to remove the subproject stuff from kms++, add 
pybind11 back as a git submodule (which does work in buildroot), and 
then use that kms++ version with buildroot to get a rootfs with kms++ 
with py-bindings.

But I also understand that this is probably a bit of a corner case, and 
no one else is interested =).

  Tomi