From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6517147827419742208 X-Received: by 10.223.150.47 with SMTP id b44mr1476731wra.0.1517405714301; Wed, 31 Jan 2018 05:35:14 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.214.21 with SMTP id n21ls1099401wmg.0.canary-gmail; Wed, 31 Jan 2018 05:35:13 -0800 (PST) X-Google-Smtp-Source: AH8x226rovozUJMwIe5hJgZLeE84YFPzKGiafw9vF42uDWgsIEY7rz4SNJgqkD+qOSf13qYh8l7R X-Received: by 10.28.156.12 with SMTP id f12mr2038804wme.4.1517405713832; Wed, 31 Jan 2018 05:35:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517405713; cv=none; d=google.com; s=arc-20160816; b=HkReMjLLo8B2Q36Yjnnr68r0gsbvPgKYd5mFupKUZowKN+D/acHrukSfZuVMt9M9SQ fWqaK+JywEbD++p1urIvzd7q5VuSecHWwmNyDFSwZHl5h82hYW6zbMpCfeHR0/Ur95yU x0ooASBEM8yxeerF47x2AtB17EMX5rWKlKctkZFTK4BfCKraymFDSGiuAzU20FBKnLw8 J7Oa3CAkmqqs4pJ+AMAKzGreN+Pf3LGc4arPFf7xS6LszJasoaceWwVpMAZJcfuHyp0y PQ40+QRa3GVFVtsVqGc2X6Mc0theLYl41rAiuWWtQRJ+ZJc+5WR6XHFt8sisJ0KVCZ9+ BUoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date :arc-authentication-results; bh=u/E022hrWnEFbBgG/9Ixf3Fld23zJqENAVdhV89H+p4=; b=qYUmT8syhP1gN2WV0DKaLS1/Nc4tWJ/YedvtnyM9BU9249fD2DY1QikjqHYWsxq9B+ WyVaX9L27bzWLS8QcY5E9uhUoV/xU4pjaG5bbGjMV9LAl5qbB6Vl94Z6/4ZmpbNpHzqE bv828k1zJig525PR97FSjCxaEqaZki0XeIfFX5O84bX4x80zhY8SgRYXl9w/q+RVq8eo A9IpOPXp1TATdUWIiwIxTd6EhK9gNAiYFQnaeKEtCBDv14GkmS/OGSaspm+XHA1jSNsz 1XxR21QsTDSzwEqN66iGlKM53mX1IRGaCV5Tql/Uh5xeqeH6m103ASjWM7mSDik5L+6N LuAw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id r70si281313wmg.2.2018.01.31.05.35.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 05:35:13 -0800 (PST) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.radix50.net (p2E51B2CC.dip0.t-ipconnect.de [46.81.178.204]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w0VDZB30008394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 31 Jan 2018 14:35:12 +0100 Received: from yssyq.radix50.net (localhost [127.0.0.1]) by yssyq.radix50.net (8.14.4/8.14.4/Debian-8) with ESMTP id w0VDZBmL012159 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 31 Jan 2018 14:35:11 +0100 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id w0VDZBH2012158 for isar-users@googlegroups.com; Wed, 31 Jan 2018 14:35:11 +0100 Date: Wed, 31 Jan 2018 14:35:11 +0100 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH 0/9] first wic integration Message-ID: <20180131133511.GE6508@yssyq.radix50.net> Mail-Followup-To: isar-users@googlegroups.com References: <20180131111253.49011346@mmd1pvb1c.ad001.siemens.net> <20180131112421.GA6508@yssyq.radix50.net> <675eeef9-1e24-4784-b894-4ce665da26fb@siemens.com> <20180131120245.GC6508@yssyq.radix50.net> <1a55fba5-e089-5bbe-4f14-e1931dea38dd@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a55fba5-e089-5bbe-4f14-e1931dea38dd@siemens.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: 5QHzqZBFdTdr On Wed, Jan 31, 2018 at 01:15:28PM +0100, Jan Kiszka wrote: > > bf873d3 wic: Use sudo instead of pseudo > > This hacks in wic, and that has to go in order to keep maintainability. > We need to solve that differently, for sure. That is a trade-off between breaking the user experience (which is strategic) and temporary workaround that will go away anyway. Till we get our changes accepted upstream, we have to workaround them locally. This series should remove the biggest hack, sysroot removal. Other changes are one-liners that are easy to port to a new bitbake version. That said, updating wic happens from time to time, but wic is used every day. That is why I'd like to keep the workaround in master till we see what happens with the upstream merge. I'd welcome any suggestions other than "sudo wic". > > Regarding the PRoot PoC... > > I'm happy to discuss the effort you see in resolving that last issue and > will re-prioritize. Ok, will come up with that after the current libhello work hits master. > >>> b1511ec wic: Work around mcopy error > > This issue is not understood yet, thus the commit not ready for > upstream. Furthermore, the log does not describe how to reproduce the > issue. So - how to clarify if we still need it? I'll check how to reproduce that. > >>> 17f9196 wic: Introduce the `WicExecError` exception class > > Can you explain why fsck should return an error at all on a freshly > built file system image? This seems to paper over some issue to me. At the time, it sounded like a bug somewhere in mkfs or fsck, but we haven't digged deeper yet. So yes, that's a workaround. > > Do you mean we should initiate upstreaming that to OE? If yes, I agree with > > you. The only question is point of time. My idea was to wait till Henning > > completes the lifecycle with his OE contribution and learn from his experience. > > If you think we should do that now, please let me know. > > Local hacks can save some time for a while but will shoot back with more > effort eventually. It wasn't about saving time, it was about providing working code first, upstreaming second. > I think we are already at that point, so let's move forward. Ok, let me analyze the issues and come with a proposal. With kind regards, Baurzhan.