[PATCHv2] gcr: add recipe for gcr-4, needed to build with gtk4

gcr-3 recipe is still needed for gnome projects that stick to gtk+3, rename to gcr3.

Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 ...build-fix-one-parallel-build-failure.patch |  0
 ...1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch |  0
 .../gcr/{gcr_3.40.0.bb => gcr3_3.40.0.bb}     |  8 ++-
 meta/recipes-gnome/gcr/gcr_4.0.0.bb           | 58 +++++++++++++++++++
 4 files changed, 64 insertions(+), 2 deletions(-)
 rename meta/recipes-gnome/gcr/{gcr => gcr3}/0001-gcr-meson.build-fix-one-parallel-build-failure.patch (100%)
 rename meta/recipes-gnome/gcr/{gcr => gcr3}/b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch (100%)
 rename meta/recipes-gnome/gcr/{gcr_3.40.0.bb => gcr3_3.40.0.bb} (87%)
 create mode 100644 meta/recipes-gnome/gcr/gcr_4.0.0.bb

libsecret dependency has been moved to PACKAGECONFIG since its only 
needed for the 'ssh_agent'

added the ssh_agent service files to FILES:${PN} to avoid an error if 
ssh_agent PACKAGECONFIG is selected:

ERROR: gcr-4.0.0-r0 do_package: QA Issue: gcr: Files/directories were 
installed but not shipped in any package:
  /usr/lib/systemd
  /usr/lib/systemd/user
  /usr/lib/systemd/user/gcr-ssh-agent.socket
  /usr/lib/systemd/user/gcr-ssh-agent.service


Am Mo, 28. Nov 2022 um 12:22:32 +0100 schrieb Markus Volk 
<f_l_k@t-online.de>:
> gcr-3 recipe is still needed for gnome projects that stick to gtk+3, 
> rename to gcr3.
> 
> Signed-off-by: Markus Volk <f_l_k@t-online.de 
> <mailto:f_l_k@t-online.de>>
> ---
>  ...build-fix-one-parallel-build-failure.patch |  0
>  ...1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch |  0
>  .../gcr/{gcr_3.40.0.bb => gcr3_3.40.0.bb}     |  8 ++-
>  meta/recipes-gnome/gcr/gcr_4.0.0.bb           | 58 
> +++++++++++++++++++
>  4 files changed, 64 insertions(+), 2 deletions(-)
>  rename meta/recipes-gnome/gcr/{gcr => 
> gcr3}/0001-gcr-meson.build-fix-one-parallel-build-failure.patch (100%)
>  rename meta/recipes-gnome/gcr/{gcr => 
> gcr3}/b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch (100%)
>  rename meta/recipes-gnome/gcr/{gcr_3.40.0.bb => gcr3_3.40.0.bb} (87%)
>  create mode 100644 meta/recipes-gnome/gcr/gcr_4.0.0.bb
> 
> diff --git 
> a/meta/recipes-gnome/gcr/gcr/0001-gcr-meson.build-fix-one-parallel-build-failure.patch 
> b/meta/recipes-gnome/gcr/gcr3/0001-gcr-meson.build-fix-one-parallel-build-failure.patch
> similarity index 100%
> rename from 
> meta/recipes-gnome/gcr/gcr/0001-gcr-meson.build-fix-one-parallel-build-failure.patch
> rename to 
> meta/recipes-gnome/gcr/gcr3/0001-gcr-meson.build-fix-one-parallel-build-failure.patch
> diff --git 
> a/meta/recipes-gnome/gcr/gcr/b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch 
> b/meta/recipes-gnome/gcr/gcr3/b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch
> similarity index 100%
> rename from 
> meta/recipes-gnome/gcr/gcr/b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch
> rename to 
> meta/recipes-gnome/gcr/gcr3/b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch
> diff --git a/meta/recipes-gnome/gcr/gcr_3.40.0.bb 
> b/meta/recipes-gnome/gcr/gcr3_3.40.0.bb
> similarity index 87%
> rename from meta/recipes-gnome/gcr/gcr_3.40.0.bb
> rename to meta/recipes-gnome/gcr/gcr3_3.40.0.bb
> index 917be5938b..5318768db6 100644
> --- a/meta/recipes-gnome/gcr/gcr_3.40.0.bb
> +++ b/meta/recipes-gnome/gcr/gcr3_3.40.0.bb
> @@ -20,11 +20,15 @@ GTKDOC_MESON_OPTION = "gtk_doc"
>  inherit gnomebase gtk-icon-cache gtk-doc features_check 
> upstream-version-is-even vala gobject-introspection gettext mime 
> mime-xdg
>  UPSTREAM_CHECK_REGEX = 
> "[^\d\.](?P<pver>\d+\.(?!9\d+)(\d*[02468])+(\.\d+)+)\.tar"
> 
> -SRC_URI += 
> "file://0001-gcr-meson.build-fix-one-parallel-build-failure.patch 
> <file://0001-gcr-meson.build-fix-one-parallel-build-failure.patch/> \
> -            file://b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch" 
> <file://b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch/>
> +SRC_URI = " \
> +	https://download.gnome.org/sources/gcr/3.40/gcr-${PV}.tar.xz;name=archive 
> <https://download.gnome.org/sources/gcr/3.40/gcr-$%7BPV%7D.tar.xz;name=archive> 
> \
> +	file://0001-gcr-meson.build-fix-one-parallel-build-failure.patch 
> <file://0001-gcr-meson.build-fix-one-parallel-build-failure.patch/> \
> +	file://b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch" 
> <file://b3ca1d02bb0148ca787ac4aead164d7c8ce2c4d8.patch/>
> 
>  SRC_URI[archive.sha256sum] = 
> "b9d3645a5fd953a54285cc64d4fc046736463dbd4dcc25caf5c7b59bed3027f5"
> 
> +S = "${WORKDIR}/gcr-${PV}"
> +
>  PACKAGECONFIG ??= " \
>  	${@bb.utils.contains 
> <mailto:${@bb.utils.contains>('DISTRO_FEATURES', 'x11', 'gtk', '', 
> d)} \
>  	${@bb.utils.contains 
> <mailto:${@bb.utils.contains>('DISTRO_FEATURES', 'wayland', 'gtk', 
> '', d)} \
> diff --git a/meta/recipes-gnome/gcr/gcr_4.0.0.bb 
> b/meta/recipes-gnome/gcr/gcr_4.0.0.bb
> new file mode 100644
> index 0000000000..4dede60544
> --- /dev/null
> +++ b/meta/recipes-gnome/gcr/gcr_4.0.0.bb
> @@ -0,0 +1,58 @@
> +SUMMARY = "A library for bits of crypto UI and parsing etc"
> +DESCRIPTION = "GCR is a library for displaying certificates, and 
> crypto UI, \
> +accessing key stores. It also provides the viewer for crypto files 
> on the \
> +GNOME desktop."
> +HOMEPAGE = "<https://gitlab.gnome.org/GNOME/gcr>"
> +BUGTRACKER = "<https://gitlab.gnome.org/GNOME/gcr/issues>"
> +
> +LICENSE = "GPL-2.0-only"
> +LIC_FILES_CHKSUM = 
> "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605" 
> <file://copying;md5=55ca817ccb7d5b5b66355690e9abc605/>
> +
> +DEPENDS = "p11-kit glib-2.0 libgcrypt gnupg-native \
> +           ${@bb.utils.contains 
> <mailto:${@bb.utils.contains>('GI_DATA_ENABLED', 'True', 
> 'libxslt-native', '', d)}"
> +
> +CACHED_CONFIGUREVARS += "ac_cv_path_GPG='gpg2'"
> +
> +CFLAGS += "-D_GNU_SOURCE"
> +
> +GNOMEBASEBUILDCLASS = "meson"
> +GTKDOC_MESON_OPTION = "gtk_doc"
> +inherit gnomebase gtk-icon-cache gtk-doc features_check 
> upstream-version-is-even vala gobject-introspection gettext mime 
> mime-xdg
> +UPSTREAM_CHECK_REGEX = 
> "[^\d\.](?P<pver>\d+\.(?!9\d+)(\d*[02468])+(\.\d+)+)\.tar"
> +
> +SRC_URI[archive.sha256sum] = 
> "c45855924f0ee7bab43e2dd38bfafd2ac815c6e9864341c0161e171173dcec7c"
> +
> +PACKAGECONFIG ??= " \
> +	${@bb.utils.filter <mailto:${@bb.utils.filter>('DISTRO_FEATURES', 
> 'systemd', d)} \
> +	${@bb.utils.contains 
> <mailto:${@bb.utils.contains>('DISTRO_FEATURES', 'x11', 'gtk', '', 
> d)} \
> +	${@bb.utils.contains 
> <mailto:${@bb.utils.contains>('DISTRO_FEATURES', 'wayland', 'gtk', 
> '', d)} \
> +"
> +PACKAGECONFIG[gtk] = "-Dgtk4=true,-Dgtk4=false,gtk4"
> +PACKAGECONFIG[ssh_agent] = 
> "-Dssh_agent=true,-Dssh_agent=false,libsecret,openssh"
> +#'Use systemd socket activation for server programs'
> +PACKAGECONFIG[systemd] = 
> "-Dsystemd=enabled,-Dsystemd=disabled,systemd"
> +
> +FILES:${PN} += " \
> +    ${datadir}/dbus-1 \
> +    ${datadir}/gcr-4 \
> +    ${systemd_user_unitdir}/gcr-ssh-agent.socket \
> +    ${systemd_user_unitdir}/gcr-ssh-agent.service \
> +"
> +
> +# <http://errors.yoctoproject.org/Errors/Details/20229/>
> +ARM_INSTRUCTION_SET:armv4 = "arm"
> +ARM_INSTRUCTION_SET:armv5 = "arm"
> +ARM_INSTRUCTION_SET:armv6 = "arm"
> +
> +EXTRA_OEMESON += "--cross-file ${WORKDIR}/meson-${PN}.cross"
> +do_write_config:append() {
> +    cat >${WORKDIR}/meson-${PN}.cross <<EOF
> +[binaries]
> +gpg2 = '${bindir}/gpg2'
> +EOF
> +}
> +
> +do_configure:prepend() {
> +    sed -i "s|ssh_add_path = find_program('ssh-add', required: 
> get_option('ssh_agent')).full_path()|ssh_add_path = 
> '${bindir}/ssh-add'|" ${S}/meson.build
> +    sed -i "s|ssh_agent_path = find_program('ssh-agent', required: 
> get_option('ssh_agent')).full_path()|ssh_agent_path = 
> '${bindir}/ssh-agent'|" ${S}/meson.build
> +}
> --
> 2.34.1
>

On Mon, 28 Nov 2022 at 12:22, Markus Volk <f_l_k@t-online.de> wrote:

> +do_configure:prepend() {
> +    sed -i "s|ssh_add_path = find_program('ssh-add', required: get_option('ssh_agent')).full_path()|ssh_add_path = '${bindir}/ssh-add'|" ${S}/meson.build
> +    sed -i "s|ssh_agent_path = find_program('ssh-agent', required: get_option('ssh_agent')).full_path()|ssh_agent_path = '${bindir}/ssh-agent'|" ${S}/meson.build
> +}

This needs to be explained. And we need to find a better way to do it,
preferably one that is acceptable upstream.

Alex

Ah is it the same issue? Then please backport.
https://gitlab.gnome.org/GNOME/gcr/-/merge_requests/114

Alex

On Mon, 28 Nov 2022 at 12:28, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
>
> On Mon, 28 Nov 2022 at 12:22, Markus Volk <f_l_k@t-online.de> wrote:
>
> > +do_configure:prepend() {
> > +    sed -i "s|ssh_add_path = find_program('ssh-add', required: get_option('ssh_agent')).full_path()|ssh_add_path = '${bindir}/ssh-add'|" ${S}/meson.build
> > +    sed -i "s|ssh_agent_path = find_program('ssh-agent', required: get_option('ssh_agent')).full_path()|ssh_agent_path = '${bindir}/ssh-agent'|" ${S}/meson.build
> > +}
>
> This needs to be explained. And we need to find a better way to do it,
> preferably one that is acceptable upstream.
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#173908): https://lists.openembedded.org/g/openembedded-core/message/173908
> Mute This Topic: https://lists.openembedded.org/mt/95287600/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Am Mo, 28. Nov 2022 um 12:28:31 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> This needs to be explained. And we need to find a better way to do it,
> preferably one that is acceptable upstream.

Now thats somehow problematic. I had this issue also with seahorse, 
that wants to know at build time what targets ssh-keygen path would be. 
We need a way to look for the targets ssh binary paths but since 
openssh for whatever reason doesn't  support pkgconfig i guess we are 
forced to hack it.
Another possibility would be to add an openssh-native recipe. I sent a 
patch for that but it was rejected for valid reasons.

For gcr I suppose we can just disable the ssh stuff if it's not
strictly required.

Alex

On Mon, 28 Nov 2022 at 12:42, Markus Volk <f_l_k@t-online.de> wrote:
>
> Am Mo, 28. Nov 2022 um 12:28:31 +0100 schrieb Alexander Kanavin <alex.kanavin@gmail.com>:
>
> This needs to be explained. And we need to find a better way to do it, preferably one that is acceptable upstream.
>
>
> Now thats somehow problematic. I had this issue also with seahorse, that wants to know at build time what targets ssh-keygen path would be. We need a way to look for the targets ssh binary paths but since openssh for whatever reason doesn't  support pkgconfig i guess we are forced to hack it.
> Another possibility would be to add an openssh-native recipe. I sent a patch for that but it was rejected for valid reasons.

Am Mo, 28. Nov 2022 um 12:45:54 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> For gcr I suppose we can just disable the ssh stuff if it's not
> strictly required.

I've noticed that you sent a patch to gcr that would fix it but 4.0.0 
will presumably still search for the external ssh programs even if 
ssh_agent is disabled.

It's an optional feature, but not being able to activate it feels like 
a hack as well to me.

It won’t if you add the patch. I have tested that:
https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/package-version-updates-later
(That’s a wip commit just to be aware of issues)

We have plenty of options everywhere that are disabled specifically because
there is no easy way to activate them. There is no promise to fulfil
requirements for every upstream option out there.

If you feel that this one in particular fulfills an important use case then
you need to add a patch that allows setting the location of ssh items with
meson options and submit it upstream.

Alex

On Mon 28. Nov 2022 at 13.07, Markus Volk <f_l_k@t-online.de> wrote:

> Am Mo, 28. Nov 2022 um 12:45:54 +0100 schrieb Alexander Kanavin <
> alex.kanavin@gmail.com>:
>
> For gcr I suppose we can just disable the ssh stuff if it's not strictly
> required.
>
>
> I've noticed that you sent a patch to gcr that would fix it but 4.0.0 will
> presumably still search for the external ssh programs even if ssh_agent is
> disabled.
>
> It's an optional feature, but not being able to activate it feels like a
> hack as well to me.
>

Am Mo, 28. Nov 2022 um 14:13:36 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> We have plenty of options everywhere that are disabled specifically 
> because there is no easy way to activate them.

Fair enough. I've sent a v3 that completely removes the ssh_agent 
settings and includes your patch