From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6473366578589073408 X-Received: by 10.46.95.133 with SMTP id x5mr29533lje.19.1508402507706; Thu, 19 Oct 2017 01:41:47 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.93.79 with SMTP id r76ls924995ljb.7.gmail; Thu, 19 Oct 2017 01:41:47 -0700 (PDT) X-Google-Smtp-Source: ABhQp+SGQZC6O2dJNkoe1jM6IGBvMmqVpSgt5eBL2+XSP5TDiOtHu1+DH8udoqc7DTiKiSHx7dSa X-Received: by 10.46.25.137 with SMTP id 9mr29342ljz.5.1508402507301; Thu, 19 Oct 2017 01:41:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508402507; cv=none; d=google.com; s=arc-20160816; b=QAxzfDm/o5hk9RGCxmaJmPAqPS1vXER2ZA1VNtXggtsbKYx4cICykXpQecC/0HS8+v UUPK95dydTYnq9kafJ8OcTjP93pxsfqOc+Rgj3Zjk6CZRhA0wWBxEnfhs4Mwx15WJphN rbTZwPLUpw7hDSwqE6Ix7QYDpyI2u9Tr+25Ck14AtVBM84cR1D7whNE6+73fYn1v0EkY CvzxMQoRsiLejXMXbM4LEOZOIAf/Tr+MD62wSYb+fsECw33cUHbIVEyBc1KPFMtsmjYE OcQxStMPFh9hx8CuJSTIQvrHd/hAhhpCk47W+fqNojlnXyPeQl/gooFmSXv0J1N0/tCm 8mGw== 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=oyRJDsHeCwlDBg9VE6fzhpm+McxAkOwITvWH5YPft7g=; b=m79fUycpEEmP3AptVoLa0p7ehXQQcrbcIp38B9tMvBpgL4zNbnUTxz1MVAj9GAMMll /E3JkVL8oeTpcgfGJiPcVzPbvpivdw4Hjch+z67KnMnswPxjFsnGxw6EXq82abeX3euj 1jkG8kx0XTtmUweaYH/HWiQEUVdm4xAMZCXtp1uACzj6zshjTp5/8C18WyeR7BfVbd1P knl07CASKYNvNBPl49V+sT/xoYH6ZJAH2/79E+PAQh30iPgtKoOPJicme6BVA76OCu9/ 8g2hfExlRnEioF4PqtabvxIu/+JjJ6jV6v/h/sb7OoQenPHVfzRIHSOhTKQ8JPwX257G u7TA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id c23si611633ljf.4.2017.10.19.01.41.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 01:41:47 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v9J8fjr7011505 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Oct 2017 10:41:45 +0200 Received: from md1em3qc ([139.25.68.40]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v9J8fjgU009093; Thu, 19 Oct 2017 10:41:45 +0200 Date: Thu, 19 Oct 2017 10:41:45 +0200 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: [PATCH 0/4 v5] Isar apt deployment Message-ID: <20171019104145.1b985144@md1em3qc> In-Reply-To: References: <20171005100807.3369-1-asmirnov@ilbers.de> <20171009140006.219154c8@md1em3qc> <20171018154404.25953ccd@md1em3qc> 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: +daQoYff1uyE On Wed, 18 Oct 2017 20:10:49 +0300 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. > > 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. I will try to provide you with a way to reproduce the issue and will look at the patch you attached. Still the whole series went into next while it was still under review and still had open points. As far as i can tell the only difference to my build is that BB_NUMBER_THREADS was 1, but i might be missing something here. That said i do not understand why you refuse to take it back out, i can not work on next since these patches are in and i can not even test the new stuff that was merged on top, same might be true for other developers. Also the next q is getting pretty long, as far as i am concerned everything up to 9c6e8a1e2fb6b65 can be rebased on master and master can be advanced to that point. Henning > 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 > >>>> > >>> > >> > > >