[meta-gnome,1/3] gupnp: dont package source

Source code contains reference to tmpdir. Dont package to avoid
reproducibility issue

Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 meta-multimedia/recipes-connectivity/gupnp/gssdp_1.6.3.bb | 1 +
 meta-multimedia/recipes-connectivity/gupnp/gupnp_1.6.6.bb | 1 +
 2 files changed, 2 insertions(+)

On Wed, Apr 24, 2024 at 3:23 PM Markus Volk via lists.openembedded.org
<f_l_k=t-online.de@lists.openembedded.org> wrote:

> Source code contains reference to tmpdir. Dont package to avoid
> reproducibility issue


Can we root cause it instead ? Removing sources from debug info might fix
this issue but degrade debugging experience

>
>
> Signed-off-by: Markus Volk <f_l_k@t-online.de>
> ---
>  meta-multimedia/recipes-connectivity/gupnp/gssdp_1.6.3.bb | 1 +
>  meta-multimedia/recipes-connectivity/gupnp/gupnp_1.6.6.bb | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/meta-multimedia/recipes-connectivity/gupnp/gssdp_1.6.3.bb
> b/meta-multimedia/recipes-connectivity/gupnp/gssdp_1.6.3.bb
> index f2e27622c..c7fee78a8 100644
> --- a/meta-multimedia/recipes-connectivity/gupnp/gssdp_1.6.3.bb
> +++ b/meta-multimedia/recipes-connectivity/gupnp/gssdp_1.6.3.bb
> @@ -28,5 +28,6 @@ PACKAGECONFIG[sniffer] =
> "-Dsniffer=true,-Dsniffer=false,gtk4,"
>  REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
> 'sniffer', 'opengl', '', d)}"
>
>  PACKAGES =+ "gssdp-tools"
> +PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
>
>  FILES:gssdp-tools = "${bindir}/gssdp* ${datadir}/gssdp/*.glade"
> diff --git a/meta-multimedia/recipes-connectivity/gupnp/gupnp_1.6.6.bb
> b/meta-multimedia/recipes-connectivity/gupnp/gupnp_1.6.6.bb
> index f1628d82e..80d0b3e2d 100644
> --- a/meta-multimedia/recipes-connectivity/gupnp/gupnp_1.6.6.bb
> +++ b/meta-multimedia/recipes-connectivity/gupnp/gupnp_1.6.6.bb
> @@ -18,4 +18,5 @@ gupnp_sysroot_preprocess () {
>
>  FILES:${PN}-dev += "${bindir}/gupnp-binding-tool*"
>
> +PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
>  RDEPENDS:${PN}-dev += "python3-core python3-xml"
> --
> 2.44.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#110125):
> https://lists.openembedded.org/g/openembedded-devel/message/110125
> Mute This Topic: https://lists.openembedded.org/mt/105709729/1997914
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

On Wed, Apr 24 2024 at 04:40:21 PM +02:00:00, Khem Raj 
<raj.khem@gmail.com> wrote:
> Can we root cause it instead ? Removing sources from debug info might 
> fix this issue but degrade debugging experience

I will take a look at it

> On 24 Apr 2024, at 16:14, Markus Volk via lists.openembedded.org <f_l_k=t-online.de@lists.openembedded.org> wrote:
> 
> On Wed, Apr 24 2024 at 04:40:21 PM +02:00:00, Khem Raj <raj.khem@gmail.com> wrote:
>> Can we root cause it instead ? Removing sources from debug info might fix this issue but degrade debugging experience 
> 
> 
> I will take a look at it

The usual culprit is build paths in generated files (like glib-generated headers), which is often a trivial fix to use basename instead.

Ross

On Wed, Apr 24 2024 at 03:42:47 PM +00:00:00, Ross Burton 
<Ross.Burton@arm.com> wrote:
> The usual culprit is build paths in generated files (like 
> glib-generated headers), which is often a trivial fix to use basename 
> instead.
> 
> Ross

Thats right, But it looks like basename wouldn't help here. 
glib-mkenums adds  headers from ${S}:

/* enumerations from 
"/home/flk/poky/build/tmp/work/corei7-64-poky-linux/gupnp/1.6.6/build/../gupnp-1.6.6/libgupnp/gupnp-error.h" 
*/
#include 
"/home/flk/poky/build/tmp/work/corei7-64-poky-linux/gupnp/1.6.6/build/../gupnp-1.6.6/libgupnp/gupnp-error.h"

/* enumerations from 
"/home/flk/poky/build/tmp/work/corei7-64-poky-linux/gupnp/1.6.6/build/../gupnp-1.6.6/libgupnp/gupnp-service-introspection.h" 
*/
#include 
"/home/flk/poky/build/tmp/work/corei7-64-poky-linux/gupnp/1.6.6/build/../gupnp-1.6.6/libgupnp/gupnp-service-introspection.h"

I guess build will break, if the headers are not found. So we need to 
compile, before the buildpaths can be removed?

On Wed, Apr 24 2024 at 06:03:18 PM +02:00:00, Markus Volk 
<f_l_k@t-online.de> wrote:
> I guess build will break

No it doesn't, using @basename@ fixes the issue.

Now it looks like:
/* enumerations from "gupnp-error.h" */
#include "gupnp-error.h"

I'll send this to upstream first. Lets see if this would work for all

On 24 Apr 2024, at 17:31, Markus Volk <f_l_k@t-online.de> wrote:
> 
> On Wed, Apr 24 2024 at 06:03:18 PM +02:00:00, Markus Volk <f_l_k@t-online.de> wrote:
>> I guess build will break
> 
> 
> No it doesn't, using @basename@ fixes the issue.
> 
> Now it looks like:
> /* enumerations from "gupnp-error.h" */
> #include "gupnp-error.h"
> 
> I'll send this to upstream first. Lets see if this would work for all

Yeah that’s the correct fix.

Ross

On Wed, Apr 24, 2024 at 6:31 PM Markus Volk <f_l_k@t-online.de> wrote:
>
> On Wed, Apr 24 2024 at 06:03:18 PM +02:00:00, Markus Volk <f_l_k@t-online.de> wrote:
>
> I guess build will break
>
>
> No it doesn't, using @basename@ fixes the issue.
>
> Now it looks like:
> /* enumerations from "gupnp-error.h" */
> #include "gupnp-error.h"
>
> I'll send this to upstream first. Lets see if this would work for all

you are on right path see a similar fix I did in past

https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/125/commits