From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6517546778931232768 X-Received: by 10.80.202.11 with SMTP id d11mr13339041edi.9.1517492632810; Thu, 01 Feb 2018 05:43:52 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.158.236 with SMTP id a99ls4418769edf.7.gmail; Thu, 01 Feb 2018 05:43:52 -0800 (PST) X-Google-Smtp-Source: AH8x227ledI9lyVPdmuNk0E7vGuggjbc6hhSzvFqVlDMsJk8aOI+xf/agtrysMGqVOxRz9GTbjWe X-Received: by 10.80.201.74 with SMTP id p10mr13347454edh.7.1517492632237; Thu, 01 Feb 2018 05:43:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517492632; cv=none; d=google.com; s=arc-20160816; b=AG4I1WKLHxC0CUHZFZjz726ZDf7QpI9Q1fwYFzKyhGfyLZ6mYdojNbqYb5+a3BRQxn T5yJwtZSdvAt8/5Lq6E7zWPYCyXvwvK0pzLkFapB/hRnEg4/mRSdolJJO6PZRgqy8x63 Gu+6ZEYhCX53cuSv9xjy+/sDtTDH/WkLT3xy5UvCHWzgjTzfzWh/pPPFpT3V+3WdAFJd nY422CtOK06chApuuBPyYoKuxt0kBF0X7bujFtYY32dU8QcpBHlRFxVmSwGWRBuzA+Fo LkIK+0Gh2O7HQVJ+grybg+4i9SKsN7RLuTWy2YixZ2tO5eEsO9IF8HpUW8ASRR80V8s/ XcDg== 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=OJw3GhOZbxsAWISF2qsd1qh1fPmC4jySI+Zzk21NS5Y=; b=ZF9wM0LRGaWpVSRdDAhhgdTPy0McZdrg3clhf7m1PHpkr/cE0hA4TjV2NEKooY/OaP 05zQzSdd0e8wm5+XGLW8cAlhL10GloyZEIe+urgI3IYLj0275u8nD5rcVm6ROIE+WXzo b4XNlks2G88pwFbA5cefqnE01Gxm3sjhPj3PLLU9ypGBA4c+1VmYilE7aYLDy7sOJgHH HHfPCive3L8GsjOhXHAAKsg7EEeAFzhNy4k/xXsQWgwPtuFlYfUBD37Rtk+JYMJ2vEbR w8sfuNDUyZzuSlYI0NKdryM2w3qhyNSSWxm42NYZjoQRCHiwzx9RIw1do4Vhz39kuEP4 Q5xg== 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 n22si1816317edb.5.2018.02.01.05.43.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 05:43:52 -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 w11Dhnm1011925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Feb 2018 14:43:51 +0100 Subject: Re: [PATCH 3/4] build.sh: Update apt sources To: Jan Kiszka , isar-users@googlegroups.com References: <20180201112944.7877-1-asmirnov@ilbers.de> <20180201112944.7877-4-asmirnov@ilbers.de> <6a256d50-9bd9-cad6-e4d6-9fabf19570d8@ilbers.de> From: Alexander Smirnov Message-ID: <846567dc-92de-8dc6-e532-342dcc00b26c@ilbers.de> Date: Thu, 1 Feb 2018 16:43:43 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: hCvPkLvozqgL On 02/01/2018 04:13 PM, Jan Kiszka wrote: > On 2018-02-01 12:48, Alexander Smirnov wrote: >> On 02/01/2018 02:40 PM, Jan Kiszka wrote: >>> On 2018-02-01 12:29, Alexander Smirnov wrote: >>>> Trigger apt sources update before building the package to be sure that >>>> we are in sync with isar-apt content. >>>> >>>> Signed-off-by: Alexander Smirnov >>>> --- >>>>   meta/recipes-devtools/buildchroot/files/build.sh | 3 +++ >>>>   1 file changed, 3 insertions(+) >>>> >>>> diff --git a/meta/recipes-devtools/buildchroot/files/build.sh >>>> b/meta/recipes-devtools/buildchroot/files/build.sh >>>> index 77e0fdd..5c59193 100644 >>>> --- a/meta/recipes-devtools/buildchroot/files/build.sh >>>> +++ b/meta/recipes-devtools/buildchroot/files/build.sh >>>> @@ -3,6 +3,9 @@ >>>>   # This software is a part of ISAR. >>>>   # Copyright (C) 2015-2017 ilbers GmbH >>>>   +# Make sure that we have latest isar-apt content >>>> +apt-get update >>>> + >>> >>> Can we confine this to the isar-apt repo? Or is there no risk that an >>> upstream repo update will result in a buildchroot change that is >>> inconsistent with an earlier build stage? >> >> That's a good point, I've already checked it, it seems to be possible like: >> >> sudo apt-get update -o Dir::Etc::sourcelist="sources.list.d/${source}" \ >> -o Dir::Etc::sourceparts="-" -o APT::Get::List-Cleanup="0" >> >> [https://askubuntu.com/questions/65245/apt-get-update-only-for-a-specific-repository] >> >> >> But I decided that it makes no sense, because target image will be >> generated later and use upstream apt. So if something has been changed >> during buildchroot operating, this will affect target image anyway. > > buildchroot shall not deviate from target rootfs. We will eventually > (rather sooner than later) have to provide it for SDK use, and than you > definitely don't want surprises, but actually already earlier. > I mean that the issue is not in buildchroot, I'll fix this line to update isar-apt only, but this doesn't solve the issue of atomic upstream fetch. You can't generate target image using only buildchroot. So for example: - You've generated buildchroot SDK in Feb. - You want to use this SDK and build target image in March. No warranty that this will work until you prefetch packages for *both* target image and buildchroot. >> >> Again I think this should be handled outside buildchroot by caching >> upstream apts. > > Well, do you plan to /always/ cache them? Last time I asked you said we > need both cases, cached and "live" ;). But even when live, we must keep > things atomic over a single build at least. No, I meant a bit different thing: if build_rep assumes to cache *everything* exists in Isar tree, I'd like to have an option to disable it, I don't want to waste the time by downloading tons of unneeded packages. In my opinion reproducibility should be always enabled and should cache everything needed for *the current* bitbake target, i.e.: 1. $ bitbake example-hello Isar prefetches everything needed to build example-hello (buildchroot + build deps) and use local cache only. 2. $ bitabke isar-image-base Isar prefetches everything needed to build target image (buildchroot + build deps + target image packages) and use local cache only. Without this Isar reproducibility and build correctness will be based on user's hopes and prays :-) > > So, if you can avoid pulling from upstream here, please add that. We can > still drop it again when the external infrastructure can always > guarantee atomicity in the repo state. > Ok. Alex