[PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED
Petr Kubizňák
From: Petr Kubizňák - 2N <kubiznak@...>
When GI_DATA_ENABLED is 'False' (e.g. because 'gobject-introspection-data' is not in DISTRO_FEATURES), gobject-introspection should not be added to DEPENDS. Signed-off-by: Petr Kubizňák <kubiznak@...> --- meta/classes-recipe/gobject-introspection.bbclass | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/meta/classes-recipe/gobject-introspection.bbclass b/meta/classes-recipe/gobject-introspection.bbclass index 0c7b7d200a..10cf79508f 100644 --- a/meta/classes-recipe/gobject-introspection.bbclass +++ b/meta/classes-recipe/gobject-introspection.bbclass @@ -35,7 +35,8 @@ EXTRA_OEMESON:prepend:class-nativesdk = "${@['', '${GIRMESONBUILD}'][d.getVar('G # Generating introspection data depends on a combination of native and target # introspection tools, and qemu to run the target tools. -DEPENDS:append:class-target = " gobject-introspection gobject-introspection-native qemu-native" +DEPENDS:append:class-target = " ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'gobject-introspection', '', d)}" +DEPENDS:append:class-target = " gobject-introspection-native qemu-native" # Even though introspection is disabled on -native, gobject-introspection package is still # needed for m4 macros. @@ -46,10 +47,12 @@ DEPENDS:append:class-nativesdk = " gobject-introspection-native" export XDG_DATA_DIRS = "${STAGING_DATADIR}:${STAGING_LIBDIR}" do_configure:prepend:class-target () { - # introspection.m4 pre-packaged with upstream tarballs does not yet - # have our fixes - mkdir -p ${S}/m4 - cp ${STAGING_DIR_TARGET}/${datadir}/aclocal/introspection.m4 ${S}/m4 + if [ "${@bb.utils.contains('GI_DATA_ENABLED', 'True', '1', '0', d)}" = "1" ] ; then + # introspection.m4 pre-packaged with upstream tarballs does not yet + # have our fixes + mkdir -p ${S}/m4 + cp ${STAGING_DIR_TARGET}/${datadir}/aclocal/introspection.m4 ${S}/m4 + fi } # .typelib files are needed at runtime and so they go to the main package (so -- 2.30.2 |
|
Alexander Kanavin
On Wed, 4 Jan 2023 at 12:46, Petr Kubizňák <kubiznak@...> wrote:
When GI_DATA_ENABLED is 'False' (e.g. becauseWhy? Alex |
|
Alexander Kanavin
I mean, if you want to do this to reduce dependency chains, then
toggle quoted message
Show quoted text
depending on qemu-native and g-i-native isn't necessary either. But the patch as it is seems like going halfway. Alex On Wed, 4 Jan 2023 at 12:54, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@...> wrote:
|
|
Petr Kubizňák
Hi Alex,
Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too.
This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know.
Petr From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, January 4, 2023 12:59:58 PM To: alex.kanavin@... Cc: Petr Kubizňák - 2N; openembedded-core@... Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED I mean, if you want to do this to reduce dependency chains, then
depending on qemu-native and g-i-native isn't necessary either. But the patch as it is seems like going halfway. Alex On Wed, 4 Jan 2023 at 12:54, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@...> wrote: > > On Wed, 4 Jan 2023 at 12:46, Petr Kubizňák <kubiznak@...> wrote: > > When GI_DATA_ENABLED is 'False' (e.g. because > > 'gobject-introspection-data' is not in DISTRO_FEATURES), > > gobject-introspection should not be added to DEPENDS. > > Why? > > Alex > > > |
|
Alexander Kanavin
On Wed, 4 Jan 2023 at 13:24, Petr Kubizňák <kubiznak@...> wrote:
Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too.I'd suggest that you remove all three, then set up a plain poky master build with gobject-introspection-data disabled, and issue bitbake world. Component upstreams generally only test the gi-enabled configuration, so this may reveal incorrect upstream logic when g-i is disabled. Alex |
|
Petr Kubizňák
Is the `bitbake world` command guaranteed to succeed for every commit in the repository? In my case, I end up with failures even with _default_ setup. My point is whether this has to be an issue on my machine (e.g. native tools?), or I should just try a different commit.
Build Configuration:
BB_VERSION = "2.2.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "qemux86-64"
DISTRO = "poky"
DISTRO_VERSION = "4.1"
TUNE_FEATURES = "m64 core2"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "HEAD:2c6f0b9228b47459dd1b67d578792cd017006128"
...
ERROR: rust-1.66.0-r0 do_compile: ExecutionError('/home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/run.do_compile.1080378', 1, None, None)
ERROR: Logfile of failure stored in: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/log.do_compile.1080378
NOTE: recipe rust-1.66.0-r0: task do_compile: Failed
ERROR: Task (/home/kubiznak/projects/poky/meta/recipes-devtools/rust/rust_1.66.0.bb:do_compile) failed with exit code '1'
error: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/libunic_langid_macros_impl-09018f99e8b09dcb.so: undefined symbol: _Ungind_Resume
--> /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/vendor/unic-langid-macros/src/lib.rs:5:9
|
5 | pub use unic_langid_macros_impl::langid;
| ^^^^^^^^^^^^^^^^^^^^^^^
Petr From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, January 4, 2023 1:36:27 PM To: Petr Kubizňák - 2N Cc: openembedded-core@... Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED On Wed, 4 Jan 2023 at 13:24, Petr Kubizňák <kubiznak@...> wrote:
> Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too. > > > This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know. I'd suggest that you remove all three, then set up a plain poky master build with gobject-introspection-data disabled, and issue bitbake world. Component upstreams generally only test the gi-enabled configuration, so this may reveal incorrect upstream logic when g-i is disabled. Alex |
|
Alexander Kanavin
We do run world on every master tip, so yes it should succeed. It
toggle quoted message
Show quoted text
doesn't seem to be related to disabling introspection, but you might want to retry with it enabled to be sure. If target rust continues to fail no matter what you try, then 'bitbake -k world' will continue building what it can when fails occur. Alex On Thu, 5 Jan 2023 at 15:13, Petr Kubizňák <kubiznak@...> wrote:
|
|
Petr Kubizňák
rust_1.66.0 and webkitgtk_2.38.2 keep failing to build in any setup (including g-i enabled and no patch applied) on my side.
What's more interesting, with no patch applied and g-i disabled, graphene_1.10.8 fails to build ("Failed to parse included gir GObject-2.0").
When the patch is _applied_ and g-i is _disabled_, graphene does build, but some other packages don't:
gconf_3.2.6.bb:do_configure:
python3-pygobject_3.42.2.bb:do_configure: Run-time dependency gobject-introspection-1.0 found: NO (tried pkgconfig and cmake) Looking for a fallback subproject for the dependency gobject-introspection-1.0
../pygobject-3.42.2/meson.build:29:0: ERROR: Automatic wrap-based subproject downloading is disabled
/bin/bash: line 2: glib-mkenums: command not found Run-time dependency graphene-gobject-1.0 found: NO (tried pkgconfig and cmake) Looking for a fallback subproject for the dependency graphene-gobject-1.0
../gtk-4.8.2/meson.build:440:0: ERROR: Automatic wrap-based subproject downloading is disabled
This shows that these packages depend on gobject-introspection and/or its dependencies no matter whether introspection is enabled or disabled. I don't know these packages so I don't think I'm able to patch them properly. On the other hand, I still believe it is incorrect to pull in the unnecessary dependencies when g-i is disabled. What do you think?
Petr
From: Alexander Kanavin <alex.kanavin@...>
Sent: Thursday, January 5, 2023 3:17:16 PM To: Petr Kubizňák - 2N Cc: openembedded-core@... Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED We do run world on every master tip, so yes it should succeed. It
doesn't seem to be related to disabling introspection, but you might want to retry with it enabled to be sure. If target rust continues to fail no matter what you try, then 'bitbake -k world' will continue building what it can when fails occur. Alex On Thu, 5 Jan 2023 at 15:13, Petr Kubizňák <kubiznak@...> wrote: > > Is the `bitbake world` command guaranteed to succeed for every commit in the repository? In my case, I end up with failures even with _default_ setup. My point is whether this has to be an issue on my machine (e.g. native tools?), or I should just try a different commit. > > > Build Configuration: > BB_VERSION = "2.2.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "universal" > TARGET_SYS = "x86_64-poky-linux" > MACHINE = "qemux86-64" > DISTRO = "poky" > DISTRO_VERSION = "4.1" > TUNE_FEATURES = "m64 core2" > TARGET_FPU = "" > meta > meta-poky > meta-yocto-bsp = "HEAD:2c6f0b9228b47459dd1b67d578792cd017006128" > ... > ERROR: rust-1.66.0-r0 do_compile: ExecutionError('/home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/run.do_compile.1080378', 1, None, None) > ERROR: Logfile of failure stored in: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/log.do_compile.1080378 > NOTE: recipe rust-1.66.0-r0: task do_compile: Failed > ERROR: Task (/home/kubiznak/projects/poky/meta/recipes-devtools/rust/rust_1.66.0.bb:do_compile) failed with exit code '1' > > The first error in rust log: > > error: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/libunic_langid_macros_impl-09018f99e8b09dcb.so: undefined symbol: _Ungind_Resume > --> /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/vendor/unic-langid-macros/src/lib.rs:5:9 > | > 5 | pub use unic_langid_macros_impl::langid; > | ^^^^^^^^^^^^^^^^^^^^^^^ > > Full logs attached. > > > Petr > > ________________________________ > From: Alexander Kanavin <alex.kanavin@...> > Sent: Wednesday, January 4, 2023 1:36:27 PM > To: Petr Kubizňák - 2N > Cc: openembedded-core@... > Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED > > On Wed, 4 Jan 2023 at 13:24, Petr Kubizňák <kubiznak@...> wrote: > > Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too. > > > > > > This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know. > > I'd suggest that you remove all three, then set up a plain poky master > build with gobject-introspection-data disabled, and issue bitbake > world. > > Component upstreams generally only test the gi-enabled configuration, > so this may reveal incorrect upstream logic when g-i is disabled. > > Alex > > > |
|
Alexander Kanavin
On Fri, 6 Jan 2023 at 19:52, Petr Kubizňák <kubiznak@...> wrote:
When the patch is _applied_ and g-i is _disabled_, graphene does build, but some other packages don't:... This shows that these packages depend on gobject-introspection and/or its dependencies no matter whether introspection is enabled or disabled. I don't know these packages so I don't think I'm able to patch them properly. On the other hand, I still believe it is incorrect to pull in the unnecessary dependencies when g-i is disabled. What do you think?This is what I was worried about. It uncovers a whole list of failures, and creates a new maintenance burden going forward, as fixing them will be an ongoing activity in the absence of an unconditional g-i dependecy.. If you have a bit of time, I'd suggest that you check the failures one by one. Some of it, like missing glib-* executables seems like a trivial missing dependency which was previously pulled in indirectly. Others, like python3-pygobject probably have a hard dependency on g-i. It does require navigating your way around unfamiliar source code, which is a useful skill in yocto regardless. Alex |
|
Petr Kubizňák
I'm slowly progressing with the patch but always end up at the principal issue of hard dependency on g-i being enabled.
For example, graphene recipe does not reflect on "gobject-introspection-data" being/not being in distro features, claiming gtk4 requires build with introspection.
Graphene can be patched to be buildable under both circumstances but gtk4 then (unsurprisingly) fails in do_configure step due to missing graphene-gobject-1.0 if g-i is disabled.
I don't think gtk4 can be patched to build with g-i disabled, do you?
If you agree with me, how can we proceed with the fact that some packages (namely gtk4) basically cannot be built without the feature, while still allowing to disable that feature? Is it really necessary to have everything
buildable with g-i disabled? Apparently, it's not buildable now.
Petr
From: openembedded-core@... <openembedded-core@...> on behalf of Alexander Kanavin <alex.kanavin@...>
Sent: Monday, January 9, 2023 10:20 AM To: Petr Kubizňák - 2N <Kubiznak@...> Cc: openembedded-core@... <openembedded-core@...> Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED On Fri, 6 Jan 2023 at 19:52, Petr Kubizňák <kubiznak@...> wrote:
> When the patch is _applied_ and g-i is _disabled_, graphene does build, but some other packages don't: ... > This shows that these packages depend on gobject-introspection and/or its dependencies no matter whether introspection is enabled or disabled. I don't know these packages so I don't think I'm able to patch them properly. On the other hand, I still believe it is incorrect to pull in the unnecessary dependencies when g-i is disabled. What do you think? > This is what I was worried about. It uncovers a whole list of failures, and creates a new maintenance burden going forward, as fixing them will be an ongoing activity in the absence of an unconditional g-i dependecy.. If you have a bit of time, I'd suggest that you check the failures one by one. Some of it, like missing glib-* executables seems like a trivial missing dependency which was previously pulled in indirectly. Others, like python3-pygobject probably have a hard dependency on g-i. It does require navigating your way around unfamiliar source code, which is a useful skill in yocto regardless. Alex |
|
Alex Kiernan
On Thu, Jan 5, 2023 at 2:13 PM Petr Kubizňák <kubiznak@...> wrote:
Are you building with `DEBUG_BUILD = "1"`? There seem to be a number of tickets out there for this failure if the optimiser isn't running. Full logs attached. -- Alex Kiernan |
|
Petr Kubizňák
This issue was actually caused by missing host dependencies. Shame on me...
From: Alex Kiernan <alex.kiernan@...>
Sent: Tuesday, January 17, 2023 1:52 PM To: Petr Kubizňák - 2N <Kubiznak@...> Cc: openembedded-core@... <openembedded-core@...> Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED On Thu, Jan 5, 2023 at 2:13 PM Petr Kubizňák <kubiznak@...> wrote:
> > Is the `bitbake world` command guaranteed to succeed for every commit in the repository? In my case, I end up with failures even with _default_ setup. My point is whether this has to be an issue on my machine (e.g. native tools?), or I should just try a different commit. > > > Build Configuration: > BB_VERSION = "2.2.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "universal" > TARGET_SYS = "x86_64-poky-linux" > MACHINE = "qemux86-64" > DISTRO = "poky" > DISTRO_VERSION = "4.1" > TUNE_FEATURES = "m64 core2" > TARGET_FPU = "" > meta > meta-poky > meta-yocto-bsp = "HEAD:2c6f0b9228b47459dd1b67d578792cd017006128" > ... > ERROR: rust-1.66.0-r0 do_compile: ExecutionError('/home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/run.do_compile.1080378', 1, None, None) > ERROR: Logfile of failure stored in: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/log.do_compile.1080378 > NOTE: recipe rust-1.66.0-r0: task do_compile: Failed > ERROR: Task (/home/kubiznak/projects/poky/meta/recipes-devtools/rust/rust_1.66.0.bb:do_compile) failed with exit code '1' > > The first error in rust log: > > error: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/libunic_langid_macros_impl-09018f99e8b09dcb.so: undefined symbol: _Ungind_Resume > --> /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/vendor/unic-langid-macros/src/lib.rs:5:9 > | > 5 | pub use unic_langid_macros_impl::langid; > | ^^^^^^^^^^^^^^^^^^^^^^^ > Are you building with `DEBUG_BUILD = "1"`? There seem to be a number of tickets out there for this failure if the optimiser isn't running. > Full logs attached. > > > Petr > > ________________________________ > From: Alexander Kanavin <alex.kanavin@...> > Sent: Wednesday, January 4, 2023 1:36:27 PM > To: Petr Kubizňák - 2N > Cc: openembedded-core@... > Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED > > On Wed, 4 Jan 2023 at 13:24, Petr Kubizňák <kubiznak@...> wrote: > > Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too. > > > > > > This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know. > > I'd suggest that you remove all three, then set up a plain poky master > build with gobject-introspection-data disabled, and issue bitbake > world. > > Component upstreams generally only test the gi-enabled configuration, > so this may reveal incorrect upstream logic when g-i is disabled. > > Alex > > > -- Alex Kiernan |
|
Alexander Kanavin
On Tue, 17 Jan 2023 at 11:57, Petr Kubizňák <kubiznak@...> wrote:
I'm slowly progressing with the patch but always end up at the principal issue of hard dependency on g-i being enabled.It helps if you show the errors you are getting, and source code lines they are coming from, so I do not have to guess what is happening or dig around source code. The way I read gtk4 and graphene source code, what the recipe claims is not true: you can disable introspection in graphene, and it would still build and install graphene-gobject.pc which is what gtk4 is looking for. If the needed piece is not installed, then you need to get to the bottom of why, e.g. specific source code lines where that decision is made. Alex |
|
On 2023-01-17 07:58, Petr Kubizňák via lists.openembedded.org wrote:
This issue was actually caused by missing host dependencies. Shame on me...Do you mean standard host dependencies from our documented list: https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#build-host-packages ? -- # Randy MacLeod # Wind River Linux |
|
Petr Kubizňák
________________________________________
From: Alexander Kanavin <alex.kanavin@...> Sent: Tuesday, January 17, 2023 5:50 PM To: Petr Kubizňák - 2N Cc: openembedded-core@... Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED The way I read gtk4 and graphene source code, what the recipe claimsThat's not really true. If no patches are applied and g-i is disabled, graphene fails in do_compile: [75/75] /home/kubiznak/projects/poky2/build/tmp/work/core2-64-poky-linux/graphene/1.10.8-r0/recipe-sysroot/usr/bin/g-ir-compiler-wrapper src/Graphene-1.0.gir --output src/Graphene-1.0.typelib --includedir=/usr/share/gir-1.0 FAILED: src/Graphene-1.0.typelib /home/kubiznak/projects/poky2/build/tmp/work/core2-64-poky-linux/graphene/1.10.8-r0/recipe-sysroot/usr/bin/g-ir-compiler-wrapper src/Graphene-1.0.gir --output src/Graphene-1.0.typelib --includedir=/usr/share/gir-1.0 Could not find GIR file 'GObject-2.0.gir'; check XDG_DATA_DIRS or use --includedir error parsing file src/Graphene-1.0.gir: Failed to parse included gir GObject-2.0 If the attached patch is applied, graphene builds and yes, graphene-gobject-1.0.pc is then created, too. (Maybe this is the first patch to send individually?) In that case, gtk4 builds fine. Anyway, webkitgtk fails in do_compile, with a failure which I worry I'm not able to resolve (see the attached tail of the log, full log is ~50MiB). Petr |
|
Petr Kubizňák
Hi Alex,
May I kindly ask you for your opinion? Thank you, Petr ________________________________________ From: openembedded-core@... <openembedded-core@...> on behalf of Petr Kubizňák - 2N <Kubiznak@...> Sent: Wednesday, February 1, 2023 5:04 PM To: openembedded-core@... Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED ________________________________________ From: Alexander Kanavin <alex.kanavin@...> Sent: Tuesday, January 17, 2023 5:50 PM To: Petr Kubizňák - 2N Cc: openembedded-core@... Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED The way I read gtk4 and graphene source code, what the recipe claimsThat's not really true. If no patches are applied and g-i is disabled, graphene fails in do_compile: [75/75] /home/kubiznak/projects/poky2/build/tmp/work/core2-64-poky-linux/graphene/1.10.8-r0/recipe-sysroot/usr/bin/g-ir-compiler-wrapper src/Graphene-1.0.gir --output src/Graphene-1.0.typelib --includedir=/usr/share/gir-1.0 FAILED: src/Graphene-1.0.typelib /home/kubiznak/projects/poky2/build/tmp/work/core2-64-poky-linux/graphene/1.10.8-r0/recipe-sysroot/usr/bin/g-ir-compiler-wrapper src/Graphene-1.0.gir --output src/Graphene-1.0.typelib --includedir=/usr/share/gir-1.0 Could not find GIR file 'GObject-2.0.gir'; check XDG_DATA_DIRS or use --includedir error parsing file src/Graphene-1.0.gir: Failed to parse included gir GObject-2.0 If the attached patch is applied, graphene builds and yes, graphene-gobject-1.0.pc is then created, too. (Maybe this is the first patch to send individually?) In that case, gtk4 builds fine. Anyway, webkitgtk fails in do_compile, with a failure which I worry I'm not able to resolve (see the attached tail of the log, full log is ~50MiB). Petr |
|
Alexander Kanavin
On Wed, 15 Feb 2023 at 10:39, Petr Kubizňák - 2N <Kubiznak@...> wrote:
I replicated this locally. graphene isn't being correctly configuredThe way I read gtk4 and graphene source code, what the recipe claimsThat's not really true. If no patches are applied and g-i is disabled, graphene fails in do_compile: when introspection is disabled globally, and the attached patch is correct. Can you resend it as a proper oe-core submission? I haven't seen webkit fail like that before, and it does not fail for me locally this way. Alex |
|