From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6600694396621946880 X-Received: by 2002:a19:c508:: with SMTP id w8-v6mr250329lfe.2.1536844503542; Thu, 13 Sep 2018 06:15:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:9097:: with SMTP id l23-v6ls613275ljg.8.gmail; Thu, 13 Sep 2018 06:15:02 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbQbAkKeP9JW+qfX9IzDuHzdyyND3TpWiWESvXJFLUl7kET51vwypPBkYBctdXmuVHEIAiK X-Received: by 2002:a2e:7a17:: with SMTP id v23-v6mr191320ljc.18.1536844502891; Thu, 13 Sep 2018 06:15:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536844502; cv=none; d=google.com; s=arc-20160816; b=lCzV8y0mUz90UZPigGNKb0zVnPeEqJeV/gffmcV8CeFarqQE7eZCQWaV8EZbe86tq8 y6BrddrQe0/EjVbvgonly8AHq3GuW5T/ypTE+HeYAadJiLGXvOtA8fTfZGxqdVxqmzSm aFSF87NUrSUfAaB67nX7ufTSAYdaLdShAsN+YWI1SiaAqb2l6GgZw3kz8/XPHo47lorS HAQnMRcodCC8/hF4y3TCaebfAVGElM0U3b+8DlbidFJNaxNVUeQ0cL4Z2zHXDoQ+HGn5 91oWf3MRZ0Sy0anGcudR/m6sbwAIJhzklX9z76Z4Q6v6qPEefdDuuykylzHhFg+xntJb 9rpw== 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; bh=q6NsA9p789n64XFOHpjX/5N54wFJAsmvoJFHhSn/bY4=; b=fBXXZAHWve7mNDlom4jMnSNJPedVXsxVQqE/Xj8HgUv8gvpkIPBs14jFmFO4iv+NjA g2K67MfoSmmLgnO6PZeOPl2s6gi02KZERcvHvanjsEK/DAMyI4sTI/rqnYZKJbxD9AuG czgxdPt9KT2EJ18QnGpGAzXeQBa5nS/Z7aU72oc62F+cPb9OBlmbwsrUw7sd9/bFDMkn DVV5ggTyguogbMFuOAQV1drGF7GWRAdQcSZ7YpcmTFhAwZj8O7PnBlDjbgeHpmmnR9TX du8RAgu4wzlsilGtVL/Omi6oZKGgxzYU+pXcy7O/pmFBBYjB3fMSbxrRvJDkDTzA2tzX hdXQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id n42-v6si180350lfi.2.2018.09.13.06.15.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 06:15:02 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id w8DDF2sb030355 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Sep 2018 15:15:02 +0200 Received: from [139.22.36.75] ([139.22.36.75]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id w8DDF07U004984; Thu, 13 Sep 2018 15:15:01 +0200 Subject: Re: RFC: need to support package builds ala pbuilder? To: "Hombourger, Cedric" , "isar-users@googlegroups.com" References: <5469172f38754fd6b432249a3bd1bd8d@svr-ies-mbx-02.mgc.mentorg.com> From: Jan Kiszka Message-ID: Date: Thu, 13 Sep 2018 15:15:00 +0200 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: <5469172f38754fd6b432249a3bd1bd8d@svr-ies-mbx-02.mgc.mentorg.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: ZzY96Zv9uWkC On 13.09.18 15:05, Hombourger, Cedric wrote: > Hello all, > > I recently came across an interesting case that may require us providing a mechanism to support building packages in their own private buildchroot > Let me first describe the issue: > > # Isar defines two tasks to build Debian packages: (1) do_prepare and (2) do_build > # The former installs build dependencies while the latter does the actual build > # > # The Isar lock is acquired for do_prepare_build to serialize access to the package > # database. While this looks ok, we may have builds fail in the following scenario > # > # core 1 core 2 > # -------------------------------- --------------------------- > # > # recipe1:do_prepare_build > # | download dependencies > # | install libssl-dev > # | task completes > # recipe2:do_prepare_build > # recipe2:do_build | download dependencies > # | autoconf | remove libssl-dev > # | make | install libssl1.0-dev > # > # Running "autoconf" or "make" while libssl-dev gets removed to allow installation of > # libssl1.0-dev may cause either to fail since OpenSSL headers / libraries will be > # temporarily removed If recipe2 (or did you rather meant recipe3?) depends on libssl-dev, and that is built without a proper dependency encoded, that's a recipe bug. that build step must not start prio to the deploy_deb step of the producing recipe is done. > > To keep locking simple and avoid introducing a big fat lock for the entire package build > (do_prepare_build + do_build), adding an option for a recipe to instruct bitbake to create > a buildchroot for a specific package (e.g. tmp/work/my-distro-amd64/my-package/buildchroot) > may be necessary. This would result in something conceptually similar to pbuilder but > integrated into Isar. The downside for those packages is that we would likely end-up > downloading the same packages again (not a big deal for those of you using a local > caching proxy such as apt-cacher-ng) > > I therefore wanted to seek your opinion in either the need for such a mechanism or alternate solutions you may have in mind? The above thing aside, having "clean-room" package built rather than sharing the buildchroot would be a valuable feature, to catch recipe bugs early and more reliably. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux