[v4,06/10] webkitgtk: add missing dependencies

When gobject-introspection feature is disabled, gettext and
glib-2.0-native dependencies are not pulled in, which causes failures
in do_compile due to missing xgettext and gdbus-codegen.

Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
---
 meta/recipes-sato/webkit/webkitgtk_2.38.5.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

On Fri, 2023-03-31 at 13:46 +0200, Petr Kubizňák wrote:
> When gobject-introspection feature is disabled, gettext and
> glib-2.0-native dependencies are not pulled in, which causes failures
> in do_compile due to missing xgettext and gdbus-codegen.
> 
> Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
> ---
>  meta/recipes-sato/webkit/webkitgtk_2.38.5.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.38.5.bb b/meta/recipes-sato/webkit/webkitgtk_2.38.5.bb
> index e52920883a..b49ecf2a31 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.38.5.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.38.5.bb
> @@ -17,7 +17,7 @@ SRC_URI = "https://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
>             "
>  SRC_URI[sha256sum] = "40c20c43022274df5893f22b1054fa894c3eea057389bb08aee08c5b0bb0c1a7"
>  
> -inherit cmake pkgconfig gobject-introspection perlnative features_check upstream-version-is-even gi-docgen
> +inherit cmake pkgconfig gobject-introspection perlnative features_check upstream-version-is-even gi-docgen gettext
>  
>  ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
>  REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'opengl', '', d)}"
> @@ -38,6 +38,7 @@ DEPENDS += " \
>            libnotify \
>            gstreamer1.0 \
>            gstreamer1.0-plugins-base \
> +          glib-2.0-native \
>            "
>  
>  PACKAGECONFIG_SOUP ?= "soup3"

If the dependency is just xgettext then it may just be a DEPENDS +=
"gettext-native"  which is a lower requirement than the full gettext
target code?

Cheers,

Richard

Hi Richard,

Yes, that is sufficient. I've prepared an updated patch. In the meantime, I've noticed some of the patches from the series had been merged into master-next, but not to the master yet. Should I now resend the whole series, or filter out these patches, i.e. rebase to master or master-next?

Thanks,
Petr

On Mon, 2023-04-03 at 10:31 +0000, Petr Kubizňák - 2N wrote:
> Hi Richard,
> 
> Yes, that is sufficient. I've prepared an updated patch. In the
> meantime, I've noticed some of the patches from the series had been
> merged into master-next, but not to the master yet. Should I now
> resend the whole series, or filter out these patches, i.e. rebase to
> master or master-next?

Normally I'd suggest rebasing on master unless there is another series
this series depends upon. The ones in master-next were the ones I
thought were simpler/ready and had been through testing in that branch.

I've just gone ahead and merged them so you should find they drop out
naturally now.

I sometimes do this just to reduce the need to resend patches, for me
to re-read/re-test them and make it clearer where the review is still
needed.

Cheers,

Richard