From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6788114222392803328 X-Received: by 2002:a5d:4091:: with SMTP id o17mr3129964wrp.254.1585135519073; Wed, 25 Mar 2020 04:25:19 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:a98b:: with SMTP id s133ls965131wme.3.gmail; Wed, 25 Mar 2020 04:25:18 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsXdJNUGzIAwEdPcWelkggjJ1AnC6NGkVJSVtSxXTApJR7u+KMkZOU0shtE9yG1EbMCw8+I X-Received: by 2002:a05:600c:228f:: with SMTP id 15mr3124328wmf.140.1585135518417; Wed, 25 Mar 2020 04:25:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585135518; cv=none; d=google.com; s=arc-20160816; b=Nuh+r8BLY/XmeT1mkU385DMwZbMrNTwZVQQowMaVbtsfQeWeJ1KcWaoQcUxh2A++D1 LASyo7z9ZPq1s2aEjKodtGxZVdwuiGBPzK6kCoakEqCJXuoiqrWBjMOXvbGB4FobVpEU VhDdgEYkGs98PD+4zReSYLAAUSPJxxcAgDaaMT1GkXbhw2D/kcibb1Ym8Jbu9QePJwAf OqvPOu3j/T1CnCVLeEvahebbDe+LBr19cEP6LErdRQCvJvtdevO1VkLVy888ZkiJqQQx xDKDHKbyko81HdADRzjcEZB/HiVdCMKLKH5RiZ12Msg2Zh/nR2Sji4o4xAPNGGnVm2Ec OdAQ== 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=0SZZdJKLm3jex9M4NSzyz9sqsXJuNFPpP7zH4DTbwXQ=; b=wQWMRIrL8vq0hv2hfWQivmn/m1i9LSRcUrMtTUBg546vUo3CwFvV+IbM+dpPMrTAME MoT/+a4m18C+8r2nBLyVedAhQy8FuOEcCh7Bfa+t7XsJnWXRsJxB214AuJO9LSuR+I4x AjUthfKUYEPmvrJdH6cvv1Pn2a9sajgP1iWxvgp7UwpXfYbSy12nDcJ9ZyVP8r4xDNA+ m65E8auuroTpawPyyalnmhtuenGBoAurd2sZH1MHNfqzdbCQQFnpTRXYR24H3bAUTK/u uOa5JYz8DtMn3N3bADc5y18qmgmtuFDpdImMrajCJrI08gButIzdbCKSybBSD8XGGS+b wLBA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id q76si291699wme.1.2020.03.25.04.25.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 04:25:18 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 02PBPIc6016867 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Mar 2020 12:25:18 +0100 Received: from md1za8fc.ad001.siemens.net ([167.87.42.150]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 02PBPHpu006098; Wed, 25 Mar 2020 12:25:17 +0100 Date: Wed, 25 Mar 2020 12:25:14 +0100 From: Henning Schild To: Jan Kiszka Cc: Baurzhan Ismagulov , Subject: Re: [PATCHv7 00/29] base-apt-rework Message-ID: <20200325122514.12542375@md1za8fc.ad001.siemens.net> In-Reply-To: <7d4eb625-6d64-43b5-a72a-92e938e21998@siemens.com> 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> <20200325113554.22e1b50c@md1za8fc.ad001.siemens.net> <7d4eb625-6d64-43b5-a72a-92e938e21998@siemens.com> 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: OowquM2Sx9LE On Wed, 25 Mar 2020 12:13:29 +0100 Jan Kiszka wrote: > On 25.03.20 11:35, Henning Schild wrote: > > 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. > > I'm also a big fan of understanding the problem before papering over. > Option 1 can remain on the table, but it should not be picked until > we know what actually happens. > > Can you reproduce the issue locally? Freeze a state that leads to it? I guess i can, just not feasible in the home-office where i am mainly conneted via VPN ... Maybe on another machine or on a machine in the office. I will find a way and dig a bit. Just afraid that this might be a mix of a weird upstream situation and a bug ... and my repro case going away with new upstream ... but i guess i should switch to https://snapshot.debian.org/ which means i have time ;) Henning > Jan >