From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6473366578589073408 X-Received: by 10.25.162.201 with SMTP id l192mr54984lfe.39.1508419803070; Thu, 19 Oct 2017 06:30:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.93.79 with SMTP id r76ls1035489ljb.7.gmail; Thu, 19 Oct 2017 06:30:02 -0700 (PDT) X-Google-Smtp-Source: ABhQp+QwCc769TmssqqhswFqgTe3PqwRdk+a0Nyh480HtINNxtuxWZywLJfE8rgyn/u0Tlup0k11 X-Received: by 10.46.23.70 with SMTP id l67mr69117lje.11.1508419802660; Thu, 19 Oct 2017 06:30:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508419802; cv=none; d=google.com; s=arc-20160816; b=u1CsTJuohIlxhqA1ZSx57RutAIHDFWY0Td4cYH4J1omMrHO/Qo7vdYQ5H74oB/JxZs qbo/tbp5ME1GczGaNbXSSaug5s9wqnExhHngMZvRNSbGBuNDf7a650++DwtWGKS8fN13 Byele8RH0lJ1aa0l+guDK2A++THNV7wms30sLeuYcsSV1aCxdEKNQGrytuQUFpamJEu8 T/WA+1XKpwnwDhXsE6iVf7ZDLD0YmRwNYkKKaxLHretSvU2+5X0hYYNmSkRQAtHu0jF7 7AOD0Td8ewtR+iXF2MUp6mjCZzoUtIJtX+Shg9Go7UusN38ItyTnjXuAAhfS977uf/bC Z4pw== 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:arc-authentication-results; bh=SQ4b+Gl94pj+wGUu16B1Y818ojtm+dgtuZ4k2SV6ZOY=; b=bIWsulmNAwo0GAbKWvt4mRv+k+cGC1llAJ+7lGVmLptT3EPLcK3BblzNydqe7rdUwA k5fb6aiQuslxJTEN7oBEVYsBrxExDa707yasWgLR1bGxkAtloRYHxdJV0lDfM2EL8T14 yRHAa8AaTJC7zYm8qB+uXTgvUoGFlaeLKeO+ucW9NHpPs9WXO07DvpiCSHZaMSfd9ufF oZaaiUKloN/++IQkMZ7CFwJ2olTtp8mJetEnuh4+r9ioucsHIzw/J+C6oA6Lna3ZkTfM GnIbcy7r7ss67icfdV7awflttW1sjt4eCRTzbi+Nt3X/xQb5ID4xrr1VSglC585xCRcO cdVQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id g190si116631lfg.4.2017.10.19.06.30.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 06:30:02 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v9JDU1mi022359 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Oct 2017 15:30:01 +0200 Received: from md1em3qc ([139.25.68.40]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id v9JDU1YX006191; Thu, 19 Oct 2017 15:30:01 +0200 Date: Thu, 19 Oct 2017 15:30:00 +0200 From: Henning Schild To: Baurzhan Ismagulov Cc: Subject: Re: [PATCH 0/4 v5] Isar apt deployment Message-ID: <20171019153000.1ef3f14b@md1em3qc> In-Reply-To: <20171019095425.GA5691@yssyq.radix50.net> References: <20171005100807.3369-1-asmirnov@ilbers.de> <20171009140006.219154c8@md1em3qc> <20171018154404.25953ccd@md1em3qc> <20171019104145.1b985144@md1em3qc> <20171019095425.GA5691@yssyq.radix50.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: WRXHBuS6JDed On Thu, 19 Oct 2017 11:54:25 +0200 Baurzhan Ismagulov wrote: > On Thu, Oct 19, 2017 at 10:41:45AM +0200, Henning Schild wrote: > > I will try to provide you with a way to reproduce the issue and will > > look at the patch you attached. > > That would be great. You don't even need to spend time providing a > minimal use case; I suggest that you provide your tree(s) as is > off-list and we look at that with high priority. I will have to look into that, one way or another i can not just give you what i have. > > Still the whole series went into next while it was still under > > review and still had open points. > > The feature was in discussion since 2017-08-27. The last open points > -- EEXIST and meta-isar-bin -- were addressed in v5. After no > comments followed, the series was merged. It's after that that you > report a build problem with an unpublished layer and suggest a > completely new architecture. The series was merged 3h after it was presented for review, my bad for being so slow. Issues not found in earlier rounds of reviews are still issues. And i have heard many comments about that weird retry-loop, unfortunately not everyone is active on the list. > Under these circumstances, my suggestion is to make use of the > existing feature v1 -- CIP and other people need that -- and > implement the new architecture in v2. It is not merged yet, it is just in a rebasing branch where you can just drop it! But if you want to keep a known to be broken v1 go ahead. > > That said i do not understand why you refuse to take it back out, i > > can not work on next since these patches are in and i can not even > > test the new stuff that was merged on top, same might be true for > > other developers. > > Because the series works for all use cases known to us. I would like to understand how the code expresses that do_cache_config has to happen before the first do_populate. As far as i can see it does not do that, so the race is obvious, but might be hard to reproduce. My first guess is that BB_NUMBER_THREADS=1 might help get you there as well. However if it is expressed, i will do my homework and find why that expression does not work in my case. > You are demanding to block the feature till you resolve the problem. > But the win-win solution is to solve your problem. This is what we > should aim at. We get mails from you since ten days, but what we > would like to have is 1. your tree, as is, and 2. feedback to Alex's > patch -- I see that as a homework before demanding the same for the > third time. 1. only works in our intranet, sorry 2. i have provided that feedback several times and suggested [lockfiles] and [depends] as means to deal with races and express deps Henning > > > Also the next q is getting pretty long > > We had intended to do a merge to master in Sep, but failed to do so. > Merging the queues while short is exactly what we are trying to > achieve right now. > > > With kind regards, > Baurzhan. >