From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6788114222392803328 X-Received: by 2002:a5d:52cb:: with SMTP id r11mr2788292wrv.95.1585132558319; Wed, 25 Mar 2020 03:35:58 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:230e:: with SMTP id j14ls908641wmj.0.canary-gmail; Wed, 25 Mar 2020 03:35:57 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuK15Dwv3kh/+joNYiIJGTn93jcgWkYITwAd0ZxxRws4TWxpoZDP/Kd8Zv0FrA+86NGFZph X-Received: by 2002:a1c:5fc5:: with SMTP id t188mr2776094wmb.110.1585132557653; Wed, 25 Mar 2020 03:35:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585132557; cv=none; d=google.com; s=arc-20160816; b=YhdJFWq58M38EtcVzoYPTDrbFxLuGPyKAGnNcDrzyuRDUARZmC1MPVjwc/P48C3L9T zwY7DQ+Zh5Jj7ZlAyLpSoV15IXntI+y5tMTXXlqhlIgkiSkghvq2htM++RxOUEmRpnsl ffW3roWMGIY4LVZApxoTd+Ifn3M0W619WxCWnIVDPOOHu7z+5hncpxM4fvFlxknjaCgz 7tW3W4R9X1blXlVoNsrGRvyYkSES15ItdXIKMiOmWUmqUlHLnIOO+TRtuu2vOsoWrmbA b97JZLQxm6Dq4f6pUz0FWthUG9k8A2iMYxKGxLMQAswqWWZFSNTE8dxdl2HtCVqqt0X4 shKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=SIhLBtpwSCEN/VxovnNTlE9NoRmIZSLMObzzdgdk1hQ=; b=b413M/mdCjdYcOyomKS2mwCARrFDtPOKLqDQHcXdiuyHrLeYaqWlIJPXrsdx4YRBCk NC4uqFIDsCkDgpqdoUEWdFubfFmxoa19GW7po8eRSjHO0dcFgBAn7EOJvS8uLy9eUFaH Bfgo3Nv8UaZNDERZya/y0pvoxOcGaTKRpwIlAvDynebgZzgmmYj3uuPWKBDx9SEIh5u+ RPqZzAF2sq+XJ7YnhKeus9fU43Kw/Sc6pM4DLeJzWuJ7oo44EpJ7P2x4JAuYoe9ZG6Vb LtoflZwPszPgeVJKNMLabjEiIUeUa+q3LPai0rrFoPSZcWgdO0Uzg7gCE7pHLKXpK3gX Bi1A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id v12si1214682wrp.5.2020.03.25.03.35.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 03:35:57 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 02PAZuSN026757 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Mar 2020 11:35:56 +0100 Received: from md1za8fc.ad001.siemens.net ([167.87.42.150]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 02PAZui8025751; Wed, 25 Mar 2020 11:35:56 +0100 Date: Wed, 25 Mar 2020 11:35:54 +0100 From: Henning Schild To: Baurzhan Ismagulov Cc: , "Kiszka, Jan (CT RDA IOT SES-DE)" Subject: Re: [PATCHv7 00/29] base-apt-rework Message-ID: <20200325113554.22e1b50c@md1za8fc.ad001.siemens.net> In-Reply-To: <20200324104942.b5aapbkqzvu2lwxx@yssyq.m.ilbers.de> References: <20200321083148.26160-1-henning.schild@siemens.com> <20200323105653.iw5hlsdgi72qap2w@yssyq.m.ilbers.de> <2048dbe8-a359-fe3e-2295-42168a9a382e@siemens.com> <20200323122238.jut345ldg72kfkpd@yssyq.m.ilbers.de> <20200323162507.11c431d0@md1za8fc.ad001.siemens.net> <20200324104942.b5aapbkqzvu2lwxx@yssyq.m.ilbers.de> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: KNx8lZO62LoO On Tue, 24 Mar 2020 11:49:42 +0100 Baurzhan Ismagulov wrote: > On Mon, Mar 23, 2020 at 04:25:07PM +0100, Henning Schild wrote: > > > > As pointed out in the other thread, we should try hard to > > > > understand why only this series triggers the issue before we > > > > declare it an upstream problem. > > > > > > As I said, I'd like to check what the problem is. > > > > I think i am responsible to do that. A first quick shot at a CI bot > > did not have the wanted effect ... > > > > Please let me know if you plan to look into it as well, we should > > not duplicate the work. I currently assume the ball is on my side > > again ... > > That would be great, please continue. The CI is up again and is > building your branch. From my builds and the nightly ones some > passed, some failed, have to check what is going on. The problem shows when debootstrap works on an imported cache, a think i repaired/enabled in v7. My guess it that it is less strict about the exact versions to install and might be picking a candidate it should not ... false sharing with other archs of the same suite or something like that. I see two ways to proceed: 1. not import the cache for debootstrap 2. have a close look at the logs and identify the false sharing 1 would mean to always download the minbase again, offline would stil work because of base-apt 2 would mean not downloading twice but having to dig deeper. Here my idea would be to also cache the list of file-names of a debootrap run on the debootstrap export step. The next import would only take files from that list. But that could become complicated since the list might differ i.e. gnupg and https support ... i assume What do you guys think? On the one hand i prefer a deep understanding, on the other hand i would like to eventually get this merged and tested more widely. Not everybody does multiconfig ... and dealing with that i keep thinking ... "i told you so" ... remembering my strong words against the complexity we will have to deal with ... and our users. Henning > With kind regards, > Baurzhan. >