From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6473366578589073408 X-Received: by 10.25.160.79 with SMTP id j76mr67215lfe.2.1508429781789; Thu, 19 Oct 2017 09:16:21 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.32.224 with SMTP id g93ls1093275lji.13.gmail; Thu, 19 Oct 2017 09:16:21 -0700 (PDT) X-Google-Smtp-Source: ABhQp+Q5QbYBWHPCvXiz8eAvC2KWuwb1QUGGdHrvOIE4hXrrOSTqWGEm3ZoIt2nWfjh3HSRPIu7t X-Received: by 10.46.5.147 with SMTP id 141mr88637ljf.44.1508429781517; Thu, 19 Oct 2017 09:16:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508429781; cv=none; d=google.com; s=arc-20160816; b=JJCFSOB09mPkhv//qMfSFw3kwTWtoUjhv2sLyxMDDi38rbFr3jPRXG4Rk6OE4Vu+/B 1sTEgCtNwco3FM2gXydI1gyJULU95Xw+AC/GF83IAYNVr2nvjWrgS7HR31434EF050hK dDVTHtoro1F/iUitx6kIUJkZAs5kep2Dl191oHPdcwhr+t3LRHCai8rNBsXiltR9aUgz ZYftYcXft16Akb6l+a6lRSJotlxT1Jgy+VFgyllraBfcPpwqMyMaRqIQJnuB+pDnHUKV qL4gISRqiTNQD+6L93j+Rd5yqN288mr2i47b3bGA98n5qxk1SL+D8tjaOiYt0FUHoX5M dZaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=HbWdlJbZSYVbzQ5Pdu4I4ikWAaPxBN3ugSw7uUXtSLc=; b=jPX+xRdmXZtedQ8XYqSFswiGPRwQNdXMGhdgNPawybD2mznkyADF3vW+xUVz4kglls m7EQ4qDJYkAr1KWf4V+DSq5y0Se8Zbm+Stbvr3YVvGHddnh+SHhEsMOsWn3mZXlvb/zl epJCL2LXRAQ+gqWalk86lMIZp3WTQ7MQJzyhFHlOflsVcfZvjPhPoOfod7pR9maEIWa7 t9WK/n5KIer8/Z8JwFPsKeaxs8W80fr4ERBaxniJFbyzGZNQkqFj6mfCJeJeTBexE2WB 3fTABf+xUrLdx5nKfSNHooItRek7kgtg8dwaXnZrqkx01YbUnzY0Ldt3jxKW0jI4XG7E GGQg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id l14si809197lje.1.2017.10.19.09.16.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 09:16:21 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v9JGGKnT010892 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Oct 2017 18:16:20 +0200 Received: from md1em3qc ([139.25.68.40]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id v9JGGKGi012403; Thu, 19 Oct 2017 18:16:20 +0200 Date: Thu, 19 Oct 2017 18:16:19 +0200 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: [PATCH 0/4 v5] Isar apt deployment Message-ID: <20171019181619.1afdb500@md1em3qc> In-Reply-To: <3b0e57a9-b5e2-5fe7-77ae-fd14773bc845@ilbers.de> References: <20171005100807.3369-1-asmirnov@ilbers.de> <20171009140006.219154c8@md1em3qc> <20171018154404.25953ccd@md1em3qc> <3b0e57a9-b5e2-5fe7-77ae-fd14773bc845@ilbers.de> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: ayEPRbfwFo7I On Wed, 18 Oct 2017 20:14:18 +0300 Alexander Smirnov wrote: > On 10/18/2017 08:10 PM, Alexander Smirnov wrote: > > On 10/18/2017 04:44 PM, Henning Schild wrote: > >> On Wed, 18 Oct 2017 14:06:53 +0300 > >> Alexander Smirnov wrote: > >> > >>> Hi, > >>> > >>>> i just tried it and the task do_cache_config was not executed > >>>> before the first do_populate. > >>> > >>> Could you please specify more details: > >>> > >>> - Build command > >> > >> Well i am using layering, and so is Claudius. So the command wont > >> help you much. It should basically boil down to > >> > >> bitbake multiconfig:qemuamd64-stretch:isar-image-base > >> > >>> - Commit ID > >> > >> f33e48bd07039032e3 > >> > >> I am guessing you can not reproduce the issue, we should find out > >> why. But since Claudius confirmend that he can not use these > >> patches either, and there are still some open points, i think you > >> should remove those patches from next. > >> > > > > At first, as I understand you use private layering. So if something > > doesn't work in your custom environment, without details and > > analysis it's not the case to reset 'next' branch. > > > > Before perform any merge, apart from my local builds, the reference > > build on CI machine is also passed. So the upstream Isar does > > support the claimed features. > > > > If I'm not able to reproduce your issue and there is no information > > about problem, then I'm not able to fix it. So if you need > > assistance in resolving the issue, please provide more details. If > > the problem will be found, the fix should be sent. > > Please try the patch attached. That solved the problem but introduced the new problem that do_rootfs could start before do_fetch/unpack. See my fix here: https://github.com/henning-schild-work/isar/commit/1e1092be974dbffbf87ab943031c44481ac0908c btw, that branch is all of current next with only that one fix and the two kernel version detection patches reverted. So you can consider current next tested by me to that degree. Now that it is not broken anymore we can delay the additional changes for the apt stuff to a v2, IMHO.. Henning > > > > Regarding new open points appeared after v5, they contain several > > proposals what to try, but they doesn't influence on apt feature. > > > > I'll try the things you proposed with multiconfig and if they work, > > I'll send updates for current apt implementation. But working > > feature in upstream should not be blocked. > > > Alex > > > >> Henning > >> > >>> Alex > >>> > >>>> > >>>> I would suggest the following changes: > >>>> - create one task in dpkg-base.bbclass that does the following > >>>> - config and init reprepro if no other recipe did that before > >>>> - add package > >>>> - use bitkages task[lockfiles] to deal with races between > >>>> recipes, put distro into lockfile-name so we have one lock per > >>>> distro > >>>> - drop do_populate > >>>> - call the new task instead of, or in do_deploy_deb > >>>> > >>>> Henning > >>>> > >>>> Am Thu, 5 Oct 2017 13:08:03 +0300 > >>>> schrieb Alexander Smirnov : > >>>>> Hi all, > >>>>> > >>>>> this series switch Isar internal binary package processing to > >>>>> apt repository. It performs this following: > >>>>> > >>>>> 1. Create repositories 'tmp/deploy/apt' for all architectures > >>>>> requested by multiconfig. > >>>>> > >>>>> 2. Generate reprepro database. > >>>>> > >>>>> 3. Put all the newly built packages to apt repository. > >>>>> > >>>>> 4. Pass this Isar repository to image multistrap. > >>>>> > >>>>> Documentation will be updated after agreement on this > >>>>> implementation. > >>>>> > >>>>> Changes since v4: > >>>>> - Drop meta-isar-bin layer. > >>>>> > >>>>> With best regards, > >>>>> Alex > >>>>> > >>>>> Alexander Smirnov (4): > >>>>> apt: Generate configs for apt > >>>>> apt: Generate Isar reprepro database > >>>>> apt: Populate Isar apt > >>>>> apt: Install packages via multistrap > >>>>> > >>>>> meta-isar/conf/layer.conf | 13 ++++- > >>>>> meta-isar/conf/local.conf.sample | 4 ++ > >>>>> .../recipes-core/images/files/distributions.in | 3 + > >>>>> .../recipes-core/images/files/multistrap.conf.in | 9 ++- > >>>>> meta-isar/recipes-core/images/isar-image-base.bb | 6 +- > >>>>> meta/classes/ext4-img.bbclass | 2 +- > >>>>> meta/classes/image.bbclass | 65 > >>>>> +++++++++++++++++++--- 7 files changed, 88 insertions(+), 14 > >>>>> deletions(-) create mode 100644 > >>>>> meta-isar/recipes-core/images/files/distributions.in > >>> > >> > > >