From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6818960455927595008 X-Received: by 2002:aa7:df8a:: with SMTP id b10mr14034518edy.263.1588882175174; Thu, 07 May 2020 13:09:35 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:aa7:d1ca:: with SMTP id g10ls1821258edp.6.gmail; Thu, 07 May 2020 13:09:34 -0700 (PDT) X-Google-Smtp-Source: APiQypKJWMVGeiEnl72Epr9LKnJjy8aTdp52NaUNvmUrkZc9m+z/hbaH2mYzQSBl4OYGRZXXj1EB X-Received: by 2002:aa7:d783:: with SMTP id s3mr14090739edq.64.1588882174589; Thu, 07 May 2020 13:09:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588882174; cv=none; d=google.com; s=arc-20160816; b=TWWePone0x/SZZLPfVON758PS8IFFFwDH5tS9JsWaRfZGi7GeFPMZgqdrr/fviZwNN eTunk+9HO3Es0eilklo3UwDrooUltTSU3C2WZnMe+W6lIyVYF5f+kB52Sv0x9QqnqdZR jRslveqsU8KennqfqSDLJycC3yPBtJg9tz/cP0p3wNDcUgqVeBdma0iYlOOecgSLeaSe lXyqdFuwpdrt7Tyc/hiBFjA6KplN45XMFdQk/G8/3yj5/hneHI9seADGbNJ4Zha2r/k3 toBJ15eE0eS6DFLJecn98wAt8Aillqo0YuqESn7l2ffusCFZFq5sJTN7htp3NyOV0VB1 CjmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=IK4PlZfB+9lHDvAjMst5Ci36FlKy11dfOyMRjdAv6A4=; b=QpVY2VO0CRytPD0Z4y6stR14reedik0hXyt9zcQJyX8mSozom4lbwoZaNjASoX9PJB kEg5FDJON22/8CcVgbSAdkOWi4xVbuFoPz9D3pknnG8tyJgQqcIO5oIN7T75PV1yXa9G y9kxmLbfYjE8IMBgpEFigQPJ+RAzvHZND7W1isw7dqBTn7t3xmpZJJked64SMKNb3GDo gJvCuVi6MT3zq1JKems7G+sLhAeYXNl5Cshv52pNyoC6p3Nab4PWFRtwrElJ+OSRMIXp 8mDZoUxEwohDoMS+khT5qrJ1Ej+Nwv6G5ffhJe8BGzdquMn2bTmYSuF8Zmpy9fwY2wcq 80jQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id i2si339370edn.2.2020.05.07.13.09.34 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 May 2020 13:09:34 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (dslb-002-207-018-045.002.207.pools.vodafone-ip.de [2.207.18.45]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 047K9VA7010699 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 7 May 2020 22:09:34 +0200 Date: Thu, 7 May 2020 22:09:26 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH] meta-isar: hello: Use in CHANGELOG_V Message-ID: <20200507200926.yht2a3eq2cvaoa7w@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <20200428180026.45a7acf4@md1za8fc.ad001.siemens.net> <4c1fbf72-b59c-9dc4-e8ff-01d0bf8f0674@siemens.com> <20200429075415.25d6d96b@md1za8fc.ad001.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: Uz80KRdeqa3P On Wed, Apr 29, 2020 at 08:10:07AM +0200, Jan Kiszka wrote: > We have two problems to solve here: > > - appending to the exact debian version our own suffix when patching it > - tracking the upstream version under which the source package is > extracted to so that ${S} is set correctly > > The former is addressed by my patch to debianize, for the latter I'm lacking > a good idea. However, that is generally not a bit issue because Debian does > less frequently the update of the major version, often only when switching > its own major release. Also, patches you carry are more likely to require > adjustments anyway in that case. > > The problem for setting S is not the version extraction like we do for the > changelog. It is that this has to happen rather early - but after recipe > parsing where it normally happens. It would require to rewrite do_apt_fetch > so that it identifies the path and sets S, somehow. This is a very typical Debian vs. bitbake problem which falls into the 20% that bitbake doesn't solve nicely. Another example is static DEPENDS of bitbake vs. Debian's dynamic Depends that become known only after fetching. Besides hacking the relevant places like do_apt_fetch, these currently tend to require non-intuitive, hard-to-debug stuff like S="${@...}" or anonymous functions. I think this particular issue is a good minimal example how we could tackle such stuff with bitbake. That said, it requires careful consideration beyond the useful step that the patch addresses. So, I've applied this to next, thanks. With kind regards, Baurzhan.