From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6739560601010307072 X-Received: by 2002:a17:906:828c:: with SMTP id h12mr20300374ejx.155.1569861244261; Mon, 30 Sep 2019 09:34:04 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:aa7:daca:: with SMTP id x10ls2314358eds.13.gmail; Mon, 30 Sep 2019 09:34:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4nuP+QeLLwWw4yHb5XNHIKcZY4IZH1VE/eBAeB+5shbOH5nnId7haO7K0kZOfFlHQy8xT X-Received: by 2002:a50:93a4:: with SMTP id o33mr21246398eda.0.1569861243623; Mon, 30 Sep 2019 09:34:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569861243; cv=none; d=google.com; s=arc-20160816; b=TGA3plbbGnYZPYAWxlleCB3MsDSLnO+UjBzM60SehIP2ObnRr+YdbLrXTjNIOPjLLE ngOb4HW5OBKVfB+j9n5vF2dog73hLIdXS7ulHNB3Zq7PofqaUaEjxuAiE1LmtJJgBLHf 0QwxOiHIDIJssL3mn9MAtjvqsyc2LaDEN/wItTLMxDvJFymdBV/hxCEXBzB+aklXgZLV p2G8+2uKiDTYcN2HeQ/nFPfjzRKqsbR18lyMfNqxZy5GZGIpFqSd8GQu85IoTKemIoeV 7/Uguu8/XrIAvwD4BTk1mls1dx8+ckQXUexMyA3ES3m/1mA/RzLGJAJhnuhnuJA/Um3D 2KcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=KDBuhSG6PtgN8N0JHO6Fz4AlvSaowZ1AgDBZ9V82sHk=; b=bC3H3nZ+2Rq7X3Wan6OZ8I/kmXXzs9KgtPzvKzcf/8ZL3MBLzz7wtwdWwxD7bmbAd9 mpUKuCKm6mYrtQIh7oE3I5np/Hv2k+7ARHCaDNSGnxFzbBIoZvh9WIezh/T3UH+262B+ vNV2SjVSj4QZh0C+7rr+JiNM3OblKqLGERi4WNfuSi/L+uxzwugQvubWkDcSUsAA4OON mCDhERsSBbOpMJDSYWNer7+fF15KodSFUXYCwLUvjyexn0t5dgvmjezZWzami4nZJWSs g3yPuJR6BZlzW/ixmuWYsx6KEqpcWn9JaJj7XZow+l2LwpTFC6Jk0WZDI/dj+wOZ/eDQ dftg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id y11si790515edq.1.2019.09.30.09.34.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Sep 2019 09:34:03 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x8UGY3XZ022213 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 30 Sep 2019 18:34:03 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x8UGY2Bv028509 for ; Mon, 30 Sep 2019 18:34:02 +0200 Subject: Re: [PATCH v6 12/27] Detect false sharing of recipes To: isar-users References: <5a2e329b881ec0b392d0f1abd116f1deeee0f66f.1569176231.git.jan.kiszka@siemens.com> <20190929145700.ads3zbq7hz77olcw@yssyq.m.ilbers.de> <248aa6db-6327-9604-40b6-e7135a5f9961@siemens.com> <20190930095610.shyewhozb46dautr@yssyq.m.ilbers.de> <20190930145326.prsfzcxogzebwbll@yssyq.m.ilbers.de> <5cb07f77-c81f-53ee-7b4c-183e5609ae4c@siemens.com> <20190930153937.n4rvim46yz7k2vc4@yssyq.m.ilbers.de> From: Jan Kiszka Message-ID: Date: Mon, 30 Sep 2019 18:34:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190930153937.n4rvim46yz7k2vc4@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: a57g84FXRAqP On 30.09.19 17:39, Baurzhan Ismagulov wrote: > On Mon, Sep 30, 2019 at 05:26:07PM +0200, Jan Kiszka wrote: >>> Ok, thanks for the explanation. You unshared the host rootfses for Debian armhf >>> and Raspbian armhf. After that, the locks in isar_bootstrap() and >>> do_apt_config_prepare() are indeed not necessary. >>> >>> Actually, sharing both was an intended optimization because the resulting host >>> rootfses are identical. However, the implementation drops one via locking and >>> not via bitbake pipeline, and isn't executed on config change. Not sure how >>> difficult it would be to do that right. I can merge #9 and #10 for now. >> >> As the commit log stated, this assumption ("are identical") was wrong in the >> first place. > > To make it clear, that was just an explanation why it had been done, I didn't > intend to challenge your motivation. > > With stock Isar and your both series applied, a quick cd tmp/deploy/bootstrap; > sudo diff -Nrq debian-stretch-host_debian-stretch-armhf > debian-stretch-host_raspbian-stretch-armhf results in: > > diff: debian-stretch-host_debian-stretch-armhf/lib64/ld-linux-x86-64.so.2: No such file or directory > diff: debian-stretch-host_raspbian-stretch-armhf/lib64/ld-linux-x86-64.so.2: No such file or directory > Files debian-stretch-host_debian-stretch-armhf/var/cache/apt/pkgcache.bin and debian-stretch-host_raspbian-stretch-armhf/var/cache/apt/pkgcache.bin differ > Files debian-stretch-host_debian-stretch-armhf/var/cache/apt/srcpkgcache.bin and debian-stretch-host_raspbian-stretch-armhf/var/cache/apt/srcpkgcache.bin differ > Files debian-stretch-host_debian-stretch-armhf/var/cache/ldconfig/aux-cache and debian-stretch-host_raspbian-stretch-armhf/var/cache/ldconfig/aux-cache differ > Files debian-stretch-host_debian-stretch-armhf/var/log/alternatives.log and debian-stretch-host_raspbian-stretch-armhf/var/log/alternatives.log differ > Files debian-stretch-host_debian-stretch-armhf/var/log/apt/history.log and debian-stretch-host_raspbian-stretch-armhf/var/log/apt/history.log differ > Files debian-stretch-host_debian-stretch-armhf/var/log/apt/term.log and debian-stretch-host_raspbian-stretch-armhf/var/log/apt/term.log differ > Files debian-stretch-host_debian-stretch-armhf/var/log/bootstrap.log and debian-stretch-host_raspbian-stretch-armhf/var/log/bootstrap.log differ > Files debian-stretch-host_debian-stretch-armhf/var/log/dpkg.log and debian-stretch-host_raspbian-stretch-armhf/var/log/dpkg.log differ > > I.e., no differences. For my understanding, do you have host bootstrap > differences downstream? What are they? Maybe we could add a test case for that. The differences can come from different HOST_DISTRO_* settings. Those are applied on a per target distro/arch basis. Locking papered over this. And it broke rebuilding on changes. We didn't trigger that issue with CI, well, maybe except for the case when you activated the bananapi. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux