From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6818960455927595008 X-Received: by 2002:a50:ef0b:: with SMTP id m11mr818852eds.25.1588918404694; Thu, 07 May 2020 23:13:24 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:c55:: with SMTP id t21ls164841ejf.11.gmail; Thu, 07 May 2020 23:13:24 -0700 (PDT) X-Google-Smtp-Source: APiQypKy9k/hCdpvICFN8znHS4vwjgILPVSCMRLnUpuZyL7J+1PZfkBz0nKIVoUv6SV/9IWLA4QW X-Received: by 2002:a17:906:1fd6:: with SMTP id e22mr580110ejt.150.1588918404138; Thu, 07 May 2020 23:13:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588918404; cv=none; d=google.com; s=arc-20160816; b=YncJ/Q1U8glL+nCRR9qE57vc4vZxtI2cprziCJroTATQnv7Wcih249v4zPiYYSAnCa sk9AoOY8agrQcJuvQBPpvF0BK982W1e68A7++NTRqaUOG1i/4MysG/A8Tj2OFfAgrSaL JOyQF91WtGcIGsqOAhsDxU4R6Bv1b4ZWSbjnhkXkcpC3DCOhtriqH0InPegeB+tX6cPL sEoJjPSk+zD/fzVxwYTDhcA49Chla1/FQiiC8rlo7FnNt7UaR1B8c/AdVrI3Y+SEnkzI ZUBL+oOEQb5FtlbMLq+BjxVF975dh/wrDcrx9gcN8wVGyLhTf15sZik1t62cyYGwKpUL DxmA== 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=MbiiJEBjqVLSEi0vb00t5KX36VHOmkYxqxZF5VBwEbY=; b=QRI6649jlyApuiuMgO8Ycs5hEZygzXKexePN8229me6nK3fGiqS1iOR6wgY45OcLsV y9bCRmO4PSpCU00QZ1HHwuzw5NufpdLwPG1aGDE1Gw3wDDwyXlgFY3SK/n2IlV9L+jfK X697kfPnmaqCHrB2VVJAarKDb4A0rzkLUV0bd291I5rqKzwkJC2hxqfD7tXYddjR5B8V SJigTM0CHWpS/DOH5khQPTPxxWF+lYUaKeHnZMr3227l//ioj1BSS2/Sjh5oYmnqGGVh P6uDtc1R0aITxxWaqehCRL4CLAoofDj/sLgN2MK5ORI3KTbOPfaaw7mBkDsLkvt0czq0 OYCw== 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 by5si45766ejc.0.2020.05.07.23.13.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 May 2020 23:13:24 -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 (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 0486DLWb012553 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 8 May 2020 08:13:23 +0200 Date: Fri, 8 May 2020 08:13:21 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH] meta-isar: hello: Use in CHANGELOG_V Message-ID: <20200508061321.htleuouxxfp2mv4x@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> <20200507200926.yht2a3eq2cvaoa7w@yssyq.m.ilbers.de> <230091c6-9906-9dc5-77cd-66f086b6b99a@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <230091c6-9906-9dc5-77cd-66f086b6b99a@siemens.com> 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: qqlLeLN+61Pg On Fri, May 08, 2020 at 08:05:33AM +0200, Jan Kiszka wrote: > > 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 > > Even that Python inlining won't help because it runs too early, during > parsing, as well and we need that after some tasks have been completed, > namely the apt-src fetching and unpacking. IIRC, we had a PoC that did early pre-fetching, but that goes then completely outside of the bitbake pipeline, which is a hack that would eventually bite, given enough packages to build. So our next step was to look at managing the pipeline dynamically, which would be a major change. With kind regards, Baurzhan.