From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6540161972509343744 X-Received: by 10.80.165.8 with SMTP id y8mr5507790edb.11.1523285253878; Mon, 09 Apr 2018 07:47:33 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.203.73 with SMTP id h9ls5031534edi.4.gmail; Mon, 09 Apr 2018 07:47:33 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+p41dXmi/mqWvlJhkImUbftpgA2NbOCz20EKbhrUxNnbG1GWKcuWX8x81wlGn5jMR3C13w X-Received: by 10.80.245.132 with SMTP id u4mr5539763edm.2.1523285253300; Mon, 09 Apr 2018 07:47:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523285253; cv=none; d=google.com; s=arc-20160816; b=lyCEBDTA/Pl1z9UWv8IgmzbMx8vPcBUozw1ijfb6jmNPQgBHBPsX3VXcMlDK2TNAgg OtDuLEEVKY61tarKY44LX+QOMZUZsPQfLaAUJQKx7DPeoELA4lUH2rc9vEXEMsWfixuF Jhylp6k3pExqWwvtnxv5ePvEyWtacLzukwvLTzwS7rEiEq48d8SsLEGf+p0za2UziW6w U5I9A317ltyAyBOGmu5IiFDnkIehlGceIlfofHmYf0sJBpTN+tU87J8buP0vXdGeYK03 R2Z+h4BV/K8vFzBJCrCLm4uX73n57AwsXD2gG2yZx2/Tyn7ZjfhbXGHCvFvQ8vZsLyhs cFfQ== 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:openpgp:from:references:to:subject :arc-authentication-results; bh=xxWe3KEfrO1qn+QUHKMDgU5HHPgbAxAtewbuN00Npjo=; b=Pdakqi4TXs7qrHLi/KYbfigwfsOxEKxEoQ6BHFKe44xdeSsPqO0MsBJcryWr7wDhqF jgEa730igrWYIossh4sMsbY4pZ4R+5666+u4Eufhj+s+vpJDFLEbWPQbupuv8Qv7Nxhb fKgW2doNJSqkZrJl4xCmT7TN80EtMODh7UTlkstynkMCoawGsS9J4OVJUPEl6V8isL98 OVC31TTrQyJQ3x+gcuFtaTdi0h2eyXuKgnyqoMYptR9CbbXTYm/agZvIQN9WeYEIcgfn iagkIM8yJmOQnJRD+HBnPmMoO4qqk84t50YBKnMuxfkf+hOWwrPVmRB71uxy+NHz41hy uH/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 r15si31303edl.3.2018.04.09.07.47.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 07:47:33 -0700 (PDT) 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 mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w39ElWxC019420 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 9 Apr 2018 16:47:32 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w39ElWH7011420 for ; Mon, 9 Apr 2018 16:47:32 +0200 Subject: Re: [PATCH v5 0/5] Debootstrap integration To: isar-users@googlegroups.com References: <20180403100802.30710-1-claudius.heine.ext@siemens.com> <20180404203434.GC3164@yssyq.radix50.net> <20180409124853.GA4414@yssyq.radix50.net> From: Jan Kiszka Openpgp: preference=signencrypt Message-ID: Date: Mon, 9 Apr 2018 16:47:32 +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: <20180409124853.GA4414@yssyq.radix50.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: aPXl/aQTjFfL On 2018-04-09 14:48, Baurzhan Ismagulov wrote: > On Mon, Apr 09, 2018 at 12:50:56PM +0200, Jan Kiszka wrote: >> what's the status of this series from upstream perspective now? Claudius >> sent a documentation update. Any further requirements that need to be >> fulfilled prior to this becoming ready for merge? > > Sorry for the delay, I'm still investigating the following issues: > > 1. CI fails with the series applied, and > > 2. The series drops Pre-Depends support and daemon starting prevention. > > > Regarding (1): As the series removes hostname setting, the image inherits the > hostname of the build host. I.e., images generated on different build hosts > have different hostnames. CI already checks the hostname and fails. > > I'd suggest to restore at least the one-liner setting the hostname, possibly in > {debian,raspbian}-configscript.sh. This should go into an exemplary customization package in meta-isar. Then you can test if that package is properly installed and has the desired effect of setting the hostname. > > > Regarding (2): The motivation for the old configscript.sh / setup.sh > distinction was to support Pre-Depends. "Sometimes, unpacking one package > requires that another package be first unpacked and configured. In this case, > the depending package must specify this dependency in the Pre-Depends control > field." [1]. > > Besides that, setup.sh prevented daemons from being started during the > configuration, which they otherwise are. > > The series happens to work with Isar's minimal set of packages. ATM, I'm not > sure about the implications for real projects with more packages. What should > we do with this? We either need concrete use cases for both aspects. Can you provide examples that no longer work as expected or have other limitations now? Otherwise, I would postpone these topics until the use cases show up. Maybe that will happen when exposing the patch series to a broader audience, but so far I heard nothing in this direction from our existing users. > > (I still think that in the end, we'll need more features than debootstrap > provides today, but that's a different story). > > > In general, I'm willing to move forward quickly. That said, I'd also like to > understand issues and have consensus when which issues are going to be > addressed. Till now, master has been the stable branch. Maybe we should > introduce an additional staging branch other than next. What do you think? > Well, the way master and next are maintained already differs a bit from common pattern. Master is keep untouched much longer than usual, and next is only updated after integration in Alex branches matured. The more branches you have, the harder it gets for contributors to pick the right one to develop against. If master is updated too infrequently, you cannot use that. If next does not contain enough integration material, you are easily forced to look for the latest staging branch to ensure your patches still apply and work the other day. So I would recommend to update master more frequently and merge patches into next as soon as no review comments are pending any more. If you really do not like to run CI over next (which may enforce some more rebases of that branch - if only CI reveals issues), have a short-living CI branch for that purpose, and only that. Regards, Jan > > References: > > 1. https://www.debian.org/doc/debian-policy/ > > > With kind regards, > Baurzhan. >