From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6521574339082452992 X-Received: by 10.31.203.71 with SMTP id b68mr2348495vkg.43.1518617000512; Wed, 14 Feb 2018 06:03:20 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.159.62.1 with SMTP id o1ls1269817uai.20.gmail; Wed, 14 Feb 2018 06:03:19 -0800 (PST) X-Google-Smtp-Source: AH8x227wpxLbzgRW3PCw042hjHYa5QC8fElHf8S7CEzAzIgb7GpBJGhiGonzfdoaQSd4Pc2cJI64 X-Received: by 10.176.32.19 with SMTP id v19mr1768545uak.124.1518616999974; Wed, 14 Feb 2018 06:03:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518616999; cv=none; d=google.com; s=arc-20160816; b=cgXFuLzZmTHUHcLFDV0+RCnAMG1+uhSQ+LYQyLkDEaSvYnNUdXQqXxQKB4MAFuXITS CcUkIlUqQwD3yUleQxEOVlL1cnJ9Nuk9OmJZzN00sFkfzLdqi/+MmS3zuupLM/ZFdEiD BOYlNcYBrtOvGEeobYFKGX3yBr+ANmbkE17ZPKg7TcthHcJjHNFOlx7JqRhsfYOfQOlV au9+ucZ+qBW0hqB6TWeHjKmNJhpCoiG73i+qQsdPozWiZakdLNqRRtYbNwk+Vxh6W5Ye ij+hQAXoeDlwmQTA/CyaHoJte5zOzH6L3ovvShBev6CtzEQlHESok4nP7JPnDLzSJzlh qF7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=zqgPg3Ji+O1XzitQvMaqjxZ+uOugDJXsol88Rg91Mjc=; b=ROEOKpqJ0l6tH4gidDPKa00CdyKzBOf+2VQWrOyzaqjEIA44Kn+DpFhUQNj+/+pYkH RhIP65Z9TLqV8RH7rh4QqvvXfumk67qCdbcLqVuzRITWDf3jF6dfXxD0NWDPiIAbxyBC qyhSvowgvrfrPiv5VWkY7Mhvzx1opTUoXT6PaYI8I4S0UlAdioIWu/G9PWkL4gbeegZ1 rg334IH1ExWb9x8B5p8BHrCeFlGtPqMawk39Bdr+hWp+t1Vi8P3C6enVJdcvkHIpzUCs 2lzyiJwIfvqcQEBL4pvZskp7YtOnmCrrUHvXiAQTO1BHcM9BYr5TlWkHbkiLClBQYCS/ 0xDQ== 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 r9si896268uad.5.2018.02.14.06.03.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 06:03:19 -0800 (PST) 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 w1EE3C6f010357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Feb 2018 15:03:14 +0100 Subject: Re: [PATCH v2 0/9] Add support for automatic partial rebuilds on recipe changes To: Jan Kiszka , isar-users References: <96a5d7df-b7a3-08ec-3c28-85ecf332d32b@siemens.com> <01a34333-06a2-4df0-a51e-17aced9f9ee3@ilbers.de> <7bd0cc56-0dba-6a04-767a-de4edcc3be1e@siemens.com> <96dd5116-fc00-d5df-d48b-c91b6d332cae@siemens.com> From: Alexander Smirnov Message-ID: Date: Wed, 14 Feb 2018 17:03:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <96dd5116-fc00-d5df-d48b-c91b6d332cae@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: W5u5Ix1HqHN3 On 02/14/2018 04:38 PM, Jan Kiszka wrote: > On 2018-02-14 14:29, Jan Kiszka wrote: >> On 2018-02-14 14:10, Jan Kiszka wrote: >>> On 2018-02-14 13:57, Alexander Smirnov wrote: >>>> On 02/14/2018 03:41 PM, Jan Kiszka wrote: >>>>> On 2018-02-14 12:33, Alexander Smirnov wrote: >>>>>> On 02/13/2018 11:05 PM, Jan Kiszka wrote: >>>>>>> Yeah, finally Yocto/OE-like usability: This ensures for many cases that >>>>>>> changes to recipes lead to rebuilds of dependent recipes, including the >>>>>>> final image. Some extra measures are needed so that those rebuilds work >>>>>>> with clean dirs. >>>>>>> >>>>>>> And if the change detection should not work, e.g. changes to file:// >>>>>>> resources are not detected, then a clean or cleanall task is now >>>>>>> available and ensures a proper manual rebuild. >>>>>>> >>>>>>> This massively increases the fun factor when developing Isar projects. >>>>>> >>>>>> >>>>>> Wow, just noticed that with this series bitbake has started to run tasks >>>>>> in parallel.. How it's working? :-) >>>>>> >>>>>> >>>>>> Currently  4 running tasks (54 of 217)  24% >>>>>> |######################################## >>>>>>                       | >>>>>> 0: mc:rpi-jessie:buildchroot-1.0-r0 do_build - 101s (pid 3271) >>>>>> 1: mc:qemui386-stretch:buildchroot-1.0-r0 do_build - 101s (pid 3336) >>>>>> 2: mc:qemui386-jessie:buildchroot-1.0-r0 do_build - 100s (pid 3457) >>>>>> 3: mc:qemuarm-wheezy:buildchroot-1.0-r0 do_build - 100s (pid 3524) >>>>> >>>>> Didn't notice that this wasn't the case before (most of my workload had >>>>> linear ordering), but I could imagine that the lacking signatures forced >>>>> bitbake to serialize. Just guessing. >>>>> >>>> >>>> There is still the same build problem as reported yesterday, log is >>>> attached. Dropping patch #3 fixes it. >>>> >>>> Line I used to build: >>>> >>>> $ time bitbake multiconfig:qemuarm-wheezy:isar-image-base >>>> multiconfig:qemuarm-jessie:isar-image-base >>>> multiconfig:qemuarm-stretch:isar-image-base >>>> multiconfig:qemui386-jessie:isar-image-base >>>> multiconfig:qemui386-stretch:isar-image-base >>>> multiconfig:qemuamd64-jessie:isar-image-base >>>> multiconfig:qemuamd64-stretch:isar-image-base >>>> multiconfig:rpi-jessie:isar-image-base >>>> >>>> Just for sure stated build in CI server: >>>> http://isar-build.org:8080/job/isar_asmirnov_devel/8/console >>>> >>>> Also failed. Could I dropped this patch from the series? >>> >>> Not before you can explain why things fail and why that patch causes >>> this. We need to understand the problem. Let me reproduce... >> >> Yeah, I get some bug as well, but a different & well-known one: >> >> dpkg: error: dpkg status database is locked by another process >> >> So, I'm afraid we will find more of these sporadic breakage, now that >> parallelization works better.... > > BTW, I'm testing with > https://github.com/siemens/isar/commits/jan/staging, i.e. the sum of all > my misdoing. > > Good news is that I just reproduced your issue, now digging into what > corrupts the isar-apt repo /wrt libhello-dev. Bad news: I had to restart > 5 times due to the contention bug above. > I think that the issue is in repo_clean function. "isar_apt" splits databases by ${DISTRO}: builder@zbook:~/isar/build$ ls tmp/deploy/apt/ -1 debian-jessie debian-stretch debian-wheezy raspbian-jessie And each distro could contains packages of whatever arch. I suppose that clean_repo() as it's called, remove all the architectures for specified package name. So building for ARM erases content for AMD and i386. Looking into the manual, -A option should be passed to reprepro. Alex