Re: [PATCH 0/4 v5] Isar apt deployment

[Alexander Smirnov <asmirnov@ilbers.de>]

[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]

On 10/19/2017 04:30 PM, Henning Schild wrote:
> On Thu, 19 Oct 2017 11:54:25 +0200
> Baurzhan Ismagulov <ibr@radix50.net> 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.
>>
> 

[-- Attachment #2: populate.patch --]
[-- Type: text/x-patch, Size: 362 bytes --]

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() {