[master,v2] librsvg: Fix do_package_qa error for librsvg

When using meta-rust layer for rust below
do_package_qa error in librsvg is observed

Fix the below error:
ERROR: librsvg-2.52.10-r0 do_package_qa: QA Issue: File /usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) File /usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) [ldflags] ERROR: librsvg-2.52.10-r0 do_package_qa: Fatal QA errors were found, failing task.

Signed-off-by: Nikhil R <nikhil.r@kpit.com>
---
 meta/recipes-gnome/librsvg/librsvg_2.56.3.bb | 2 ++
 1 file changed, 2 insertions(+)

meta-rust is generally seen as obsolete, is there a particular reason
you need to use it with oe-core master, instead of the standard rust
recipes?

Even then, this looks like it needs to be fixed in meta-rust, rather
than individual recipes. The error does not occur with official rust
toolchain, so meta-rust should just copy what that does.

Alex

On Fri, 8 Mar 2024 at 06:03, nikhil <nikhilar2410@gmail.com> wrote:
>
> When using meta-rust layer for rust below
> do_package_qa error in librsvg is observed
>
> Fix the below error:
> ERROR: librsvg-2.52.10-r0 do_package_qa: QA Issue: File /usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) File /usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) [ldflags] ERROR: librsvg-2.52.10-r0 do_package_qa: Fatal QA errors were found, failing task.
>
> Signed-off-by: Nikhil R <nikhil.r@kpit.com>
> ---
>  meta/recipes-gnome/librsvg/librsvg_2.56.3.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
> index 9824b8898d..e6eece6858 100644
> --- a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
> +++ b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
> @@ -77,3 +77,5 @@ FILES:librsvg-gtk = "${libdir}/gdk-pixbuf-2.0/*/*/*.so \
>  RRECOMMENDS:librsvg-gtk = "gdk-pixbuf-bin"
>
>  PIXBUF_PACKAGES = "librsvg-gtk"
> +
> +TARGET_CC_ARCH += "${LDFLAGS}"
> --
> 2.25.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#196846): https://lists.openembedded.org/g/openembedded-core/message/196846
> Mute This Topic: https://lists.openembedded.org/mt/104803790/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Thanks Alex for the reply.
So till now we are using meta-rust master along with the kirkstone yocto layers and are trying to understand if it makes sense to use it further.
We had a few questions for the maintainence of Rust.

1. Can we say, that oe-core will support Rust in future after Kirkstone  as a standalone (without any external dependency )?
2. We assume that kirkstone will stay with 1.59 and those who want later versions (1.68+)can use meta-lts-mixins
3. We have the following assumptions for meta-lts-mixins

a) We see kirkstone/rust-1.68, kirkstone/rust-1.70 branches.
A new branch will be created for a newer and stable rust version for example kirkstone/rust-1.75 .
b)  If *1* is not correct then we assume meta-lts-mixins will cater to all the LTS layers in future. That means we may see branches like scarthgap/rust-***

Thanks in advance for your reply !

regards,
Nisha Parrakat

On Mon, 11 Mar 2024 at 13:15, <Nisha.M.Parrakat@bmw.de> wrote:
> 1. Can we say, that oe-core will support Rust in future after Kirkstone  as a standalone (without any external dependency )?

Yes. Rust is now part of the core, and will stay there.

> 2. We assume that kirkstone will stay with 1.59 and those who want later versions (1.68+)can use meta-lts-mixins

That's right.

> 3. We have the following assumptions for meta-lts-mixins
>
>      a) We see kirkstone/rust-1.68, kirkstone/rust-1.70 branches.
>      A new branch will be created for a newer and stable rust version for example kirkstone/rust-1.75 .

There's also kirkstone/rust which is not tied to a specific rust
version and aims to provide the 'latest'.

>      b)  If 1 is not correct then we assume meta-lts-mixins will cater to all the LTS layers in future. That means we may see branches like scarthgap/rust-***

That will not necessarily happen. It depends on somebody willing to do
the work. But this also means that you can make that contribution.
There are typically two steps:

1. Update master to the needed upstream rust release.
2. Backport those recipes into a branch in meta-lts-mixins.

Keep in mind that this is a community project, and no one owes you
these things. The good news is that you are welcome to handle them and
share with the community.

Alex