From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B434AE7D0A8 for ; Thu, 21 Sep 2023 20:25:12 +0000 (UTC) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) by mx.groups.io with SMTP id smtpd.web10.6204.1695327909421280564 for ; Thu, 21 Sep 2023 13:25:09 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=none, err=SPF record not found (domain: t-online.de, ip: 194.25.134.18, mailfrom: f_l_k@t-online.de) Received: from fwd75.aul.t-online.de (fwd75.aul.t-online.de [10.223.144.101]) by mailout04.t-online.de (Postfix) with SMTP id 65A341B5E9; Thu, 21 Sep 2023 22:24:54 +0200 (CEST) Received: from [192.168.178.62] ([84.154.174.95]) by fwd75.t-online.de with (TLSv1.3:TLS_AES_256_GCM_SHA384 encrypted) esmtp id 1qjQEG-2JMFpg0; Thu, 21 Sep 2023 22:24:52 +0200 Date: Thu, 21 Sep 2023 22:24:47 +0200 From: Markus Volk Subject: Re: [OE-core] [PATCH v2] adwaita-icon-theme: 43 -> 45.0 To: Alexander Kanavin Cc: Markus Volk , Kai Kang , openembedded-core@lists.openembedded.org Message-Id: In-Reply-To: References: <20230921064727.1260198-1-kai.kang@windriver.com> <3SXB1S.VJD0PU0SDSPS1@t-online.de> X-Mailer: geary/44.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-nG/KxbPrLRjWeBA7WoOI" X-TOI-EXPURGATEID: 150726::1695327893-39C74192-1A26A3D0/0/0 CLEAN NORMAL X-TOI-MSGID: 3ff1ab01-f4d1-4509-a990-6c8db1265f3f List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 21 Sep 2023 20:25:12 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/188023 --=-nG/KxbPrLRjWeBA7WoOI Content-Type: text/plain; charset=us-ascii; format=flowed The refmanual says about allarch: Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes that produce packages that depend on tunings through use of the RDEPENDS and TUNE_PKGARCH variables, should never be configured for all architectures using allarch. This is the case even if the recipes do not produce architecture-specific output. gtk-icon-cache.bbclass adds RDEPENDS and that probably makes the package incompatible with allarch 'gtk_update_icon_cache' is run in meson automatically: I patched meson to not run gtk_update_icon_cache and the test also passed. But this brings me back to my first idea, that it might be the right thing to do to remove inherit allarch? On Thu, Sep 21 2023 at 07:36:39 PM +02:00:00, Alexander Kanavin wrote: > On Thu, 21 Sept 2023 at 17:51, Markus Volk > wrote: >> How did you trace it? That doesn't make sense given what the test >> does, and the task where diverge begins. >> >> but still the test failed. In the next step I excluded inherit >> allarch and the test succeeded >> >> Looking at allarch.bbclass, this was the most suspicious part to me >> and first thing I tried was commenting out >> #addhandler allarch_package_arch_handler > > I see, thanks. Unfortunately I think you went down the wrong path. > > The recipe is meant to be allarch since it doesn't build anything for > the target and only installs pre-built data which is identical on all > targets. This improves sstate reuse for one thing. This worked fine > until this version update, but after the version update the signature > for the newly added task write_config (which I think comes from meson) > differs depending on target. Something creeps in there which varies > between targets, so you need to for example use bitbake-diffsigs to > compare the signatures (the test prints what they are, and > bitbake-diffsigs will tell you what changed). > > Alex --=-nG/KxbPrLRjWeBA7WoOI Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
The refmanual says about allarch:<= /div>
Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes th= at produce packages that depend on tunings through use of the RDEPENDS and = TUNE_PKGARCH variables, should never be configured for all architectures us= ing allarch. This is the case even if the recipes do not produce architectu= re-specific output.

gtk-icon-cache.bbclass adds RD= EPENDS and that probably makes the package incompatible with allarch
<= div>'gtk_update_icon_cache' is run in meson automatically:

<= div>I patched meson to not run gtk_update_icon_cache and the test also pass= ed.
But this brings me back to my first idea, that it might be th= e right thing to do to remove inherit allarch?

On Thu, Sep 21 2023 at 07:36:39 PM +02:00:00, Alexa= nder Kanavin <alex.kanavin@gmail.com> wrote:
On Thu, = 21 Sept 2023 at 17:51, Markus Volk <f_l_k@t-online.de> wrote:
How did you trace it? That doesn't make sense given what the t= est does, and the task where diverge begins. but still the test failed. In the next step I excluded inherit allarch and= the test succeeded Looking at allarch.bbclass, this was the most suspicious part to me and fi= rst thing I tried was commenting out #addhandler allarch_package_arch_handler
I see, thanks. Unfortunately I think you went down the wrong path. The recipe is meant to be allarch since it doesn't build anything for the target and only installs pre-built data which is identical on all targets. This improves sstate reuse for one thing. This worked fine until this version update, but after the version update the signature for the newly added task write_config (which I think comes from meson) differs depending on target. Something creeps in there which varies between targets, so you need to for example use bitbake-diffsigs to compare the signatures (the test prints what they are, and bitbake-diffsigs will tell you what changed). Alex
--=-nG/KxbPrLRjWeBA7WoOI--