From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6506467811408216064 X-Received: by 10.46.25.200 with SMTP id 69mr2784164ljz.40.1514909356003; Tue, 02 Jan 2018 08:09:16 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.109.2 with SMTP id i2ls3398412ljc.14.gmail; Tue, 02 Jan 2018 08:09:15 -0800 (PST) X-Google-Smtp-Source: ACJfBovirsLRAMqbARd8zZlZRQdWyrkj2z30ZIJV+29Y1Wirmqw7Z/YydwG4A8iYpthIrz+kISdu X-Received: by 10.25.77.148 with SMTP id a142mr227836lfb.9.1514909355523; Tue, 02 Jan 2018 08:09:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1514909355; cv=none; d=google.com; s=arc-20160816; b=ywcYMaDYv44fnT4d/1R2UsV8cTp7s21u1S4N5TuKMF8iPE2ITiywmXPLREHr/1dJ2t bacY4n0opnmOaUl2twFjg9oKC9Nh9ujtkL71Pa4VG82FDwL+DTL8CaDLd9zeRW4Jl0gQ vGJF76m02saVK9AMu9jOEacglT7a6Z43GTae8UZ77D8s+ePErhU5ZnVUvJ3TABarXdY+ D6/QK5ih/1RUALeO83z8YQUohhIiwFnkZiLRFhin2kUPZD+E9xV8Kn301Kbqnp7+a2k/ L9tRdNYL6CKgycz/GuBpzMMEN2jBsgG6Ycczf6SD6rgqU/JX6JuxeDoImem0QJW/zYrL xE1g== 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=nOMnn01CjfqZcwePC49QNaO3Gzs5nWmqy1bGASXyIKw=; b=Vp1VDfLhTJ88v1OOG8hVWAiDDaq0BAthUHGr6F9aXScbVdFEZyiP9IIuRVfC84mykx 67Y7+QUMWNqKS3xbjwYYQGgMK9Z+SYsTrvTYwwI74QUH7Wo+UdwKCowWTb4GURR4j9nn 6wpEL4Q25DZW9DJxp/Y4LKNyPZ7TP7AOvmdvIRyJcqYfsHYPcTA8Ely1zVFX4tLIJE4+ rPLGVD4REpSYA7A5Wjt+rUyrizQjMbly2XKVrzkSE+vTOtW5KTRqgpi2yuo3LI9v/Av5 hOcZm3yRzsBGcqsFSUuFXqeWLm2Q0Y8jrNEwpvW87c90NrnE/9Tn+FfnpR2PJp7qi50t iu+Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id 198si1958ljj.1.2018.01.02.08.09.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 08:09:15 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w02G9EZ6008183 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 2 Jan 2018 17:09:14 +0100 Received: from md1f2u6c.ww002.siemens.net (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w02G9Ed7021378; Tue, 2 Jan 2018 17:09:14 +0100 Subject: Re: [RFC][PATCH 0/6] Isar build reproducibility To: Alexander Smirnov , isar-users@googlegroups.com References: <20180102145744.21814-1-asmirnov@ilbers.de> From: Jan Kiszka Message-ID: Date: Tue, 2 Jan 2018 17:09:14 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20180102145744.21814-1-asmirnov@ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: gZmIjvCCSO7o Hi Alex, On 2018-01-02 15:57, Alexander Smirnov wrote: > Hello all, > > this series proposes the way how build reproducibility could be implemented > in Isar. General idea is to get the list of all the necessary packages for > build, fetch them and create local repo, that will be used for further > builds/ > > Briefly speeking, it works like the following: > > 1. User sets the list of images that should be 'reproducible' in > BASE_APT_IMAGES variable in local.conf file. What speaks against making every image reproducible? I strongly assume this is the common case. There should be a way to disable that, and that could be local.conf controlled. Is there a technical reason the core needs to know the name of the reproducible image? Or can be control this on a per-build basis, including all images of that build? And will all images of the same bitbake run (thinking of multiconfig...) share also the same base-apt repo, or is that per image? > > 2. Based on the list of images above, Isar will derive all the run-time and > build dependencies for these images. > > 3. Using multistrap, Isar will fetch the list of packages and create base-apt > local repository. > > 4. Now buildchroot and image root filesystems are generated using base-apt. > > Some notes: > > 1. base-apt repository is mounted to buildchroot, so Isar packages are > able to install necessary deps via apt-get. This does not your provide the packages a way to feed their own build results into the same repo, does it? I'm referring to the issue that Christian described (https://groups.google.com/forum/#!msg/isar-users/efer3RF989o/r-zfUNNDAgAJ) and which I ran into as well meanwhile. > > 2. bitbake events are used to clean up buildchroot. I haven't found another > way how base-apt could be unmounted. So it's mounted once before any > package starts building and unmounted by bitbake event: > bb.event.BuildCompleted. What is the implication of that? At least to me (without detailed understanding of bitbake), this remains unclear. > > This series works good with latest next. Any comments are welcome. > > Happy New Year 2018! :-) Same to you. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux