From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6473366578589073408 X-Received: by 10.28.144.196 with SMTP id s187mr255389wmd.29.1508426076236; Thu, 19 Oct 2017 08:14:36 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.54.141 with SMTP id y13ls1476899wmh.6.canary-gmail; Thu, 19 Oct 2017 08:14:35 -0700 (PDT) X-Google-Smtp-Source: ABhQp+TQ4ZnemmjzMq9qkgOVPU0XWoTY1E+m90cKjflvptjDzDZ9eAkGExZ8vmGcEHv6ZoSrHEey X-Received: by 10.28.63.86 with SMTP id m83mr264888wma.21.1508426075831; Thu, 19 Oct 2017 08:14:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508426075; cv=none; d=google.com; s=arc-20160816; b=p3E/YKJJ8MtcFp9VfCy95NkRShsWJ69BtDMRqO14/3uFebmSAKRLU9dcyjUvP7cZqL LEbHpGlJjRTeECOw23fCMjabRzQVcNn2ywE7+0Mu+lV8lpX3pmOfh8/I0i0PYxqzGVxV Ium/ayPTPpOQTPkDGAwK42y8PY3bCJ7pQsF9gcIwJUlofC4L4eIEKJxYipVhuPonpQe0 xftbEKWUUpUKYjm/80zcY6/8ggjVTDNWwo1gbY2JpT+wHxmwnxRUVSfeWA4x+bnuurKS VVIUythyFyGOF6HPvTlku96RdZyRr30ccEq1BFJu9ekOhB0scG123VwHDGqATJuReBhq tMiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=VQun692+OtDj6T1SulXnXD1ZceaKsKBdomR2fih3nUA=; b=xY+OtAYMKlSkkgz+3CfyWl1k632YD9MJhVPz1bSzP3bhB8ul/HE4gkFT0cFdPLBEgm D5NqFCl8MiZEhsoWYzwAGGftDaKb8VWHlMRupIonLQD8IlfKvoJ5FBMpNFmmV9lz+idG KKC6GOHXTfA7n1loILCNCw9NuXe2V43zhRPCWBZKbKUq1HwDmhtqyXK3iJ+CKX1TPdDy 0Hg40cjaDG+P/LUQD4VFDEpEroR8KI0CLURmnfCSfwy+dNc1fdcq7zfb7B5itYGZjaTb p7SsA3fVgFyqtI6D8Vdwj1MV81CJffkpRvkiBR2TwFnVM3yRBqa9wGVxV2vlY1VKJMY3 ySGg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id r15si919660wrc.1.2017.10.19.08.14.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 08:14:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v9JFEX55025896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Oct 2017 17:14:34 +0200 Subject: Re: [PATCH 0/4 v5] Isar apt deployment To: Henning Schild Cc: isar-users@googlegroups.com References: <20171005100807.3369-1-asmirnov@ilbers.de> <20171009140006.219154c8@md1em3qc> <20171018154404.25953ccd@md1em3qc> <20171019104145.1b985144@md1em3qc> <20171019095425.GA5691@yssyq.radix50.net> <20171019153000.1ef3f14b@md1em3qc> From: Alexander Smirnov Message-ID: <268cc1cb-0598-3c45-9e0b-f1549f114bfc@ilbers.de> Date: Thu, 19 Oct 2017 18:14:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171019153000.1ef3f14b@md1em3qc> Content-Type: multipart/mixed; boundary="------------681CCC4DC83C696E99DD6EEB" Content-Language: en-US X-TUID: u72DouMvZtRz This is a multi-part message in MIME format. --------------681CCC4DC83C696E99DD6EEB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/19/2017 04:30 PM, Henning Schild wrote: > 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. The series was sent to the list 05.10.2017 at 12:00 CES. Series was pushed to upstream 06.10.2017 after 17:00 CES (don't remember exact local time, sorry). I suppose you look at commit dates, which reflect the time I call 'git commit' on my machine and have nothing common with pushing. So please be more correct next time. > 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. All the issues found in v4 were fixed, features supported by clean Isar were tested and eventually series was published. If later you propose to try another way to do the same things, I'll try it and come back with the results. But upstream tree should not be frozen until all your ideas and proposals will be evaluated. > >> 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. > I've listed the tasks chain and noticed that do_populate has no predecessor what could be the source of your issue. Please confirm if the change attached fixes your issue while I'll update the respective patch in v5 series. Alex >> 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. >> > --------------681CCC4DC83C696E99DD6EEB Content-Type: text/x-patch; name="populate.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="populate.patch" diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index 2284655..3a22b2a 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -71,7 +71,7 @@ do_populate() { fi } -addtask populate before do_build +addtask populate before do_build after do_unpack do_populate[deptask] = "do_deploy_deb" do_copy_boot_files() { --------------681CCC4DC83C696E99DD6EEB--