From: Baurzhan Ismagulov <ibr@radix50.net>
To: isar-users@googlegroups.com
Subject: Re: [PATCH 0/9] first wic integration
Date: Wed, 31 Jan 2018 14:35:11 +0100 [thread overview]
Message-ID: <20180131133511.GE6508@yssyq.radix50.net> (raw)
In-Reply-To: <1a55fba5-e089-5bbe-4f14-e1931dea38dd@siemens.com>
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.
next prev parent reply other threads:[~2018-01-31 13:35 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 9:41 Henning Schild
2018-01-31 9:41 ` [PATCH 1/9] classes: image: introduce size measuring function, for before do_*_image Henning Schild
2018-01-31 9:41 ` [PATCH 2/9] images: new class wic-img for wic intregration Henning Schild
2018-02-13 14:44 ` Alexander Smirnov
2018-02-13 16:06 ` Henning Schild
2018-01-31 9:41 ` [PATCH 3/9] wic: add a bootimg-efi-isar plugin outside the wic tree Henning Schild
2018-02-12 17:48 ` Jan Kiszka
2018-01-31 9:41 ` [PATCH 4/9] Revert "wic: Make the bootimg-efi plugin generate usable images" Henning Schild
2018-01-31 9:41 ` [PATCH 5/9] Revert "wic: Introduce the `WicExecError` exception class" Henning Schild
2018-01-31 9:41 ` [PATCH 6/9] Revert "wic: Work around mcopy error" Henning Schild
2018-01-31 9:41 ` [PATCH 7/9] Revert "wic: Use sudo instead of pseudo" Henning Schild
2018-01-31 9:41 ` [PATCH 8/9] Revert "wic: Remove sysroot support" Henning Schild
2018-01-31 9:42 ` [PATCH 9/9] wic: now truly go for the wic version we claim to have Henning Schild
2018-01-31 10:11 ` Alexander Smirnov
2018-01-31 10:55 ` Jan Kiszka
2018-01-31 11:11 ` Alexander Smirnov
2018-01-31 11:43 ` Jan Kiszka
2018-01-31 11:53 ` Baurzhan Ismagulov
2018-01-31 12:01 ` Jan Kiszka
2018-01-31 12:28 ` Baurzhan Ismagulov
2018-01-31 13:53 ` Henning Schild
2018-01-31 14:01 ` Baurzhan Ismagulov
2018-01-31 14:21 ` Henning Schild
2018-01-31 10:02 ` [PATCH 0/9] first wic integration Alexander Smirnov
2018-01-31 10:12 ` Henning Schild
2018-01-31 11:24 ` Baurzhan Ismagulov
2018-01-31 11:47 ` Jan Kiszka
2018-01-31 12:02 ` Baurzhan Ismagulov
2018-01-31 12:15 ` Jan Kiszka
2018-01-31 13:30 ` Jan Kiszka
2018-01-31 13:41 ` Baurzhan Ismagulov
2018-01-31 14:01 ` Jan Kiszka
2018-01-31 15:21 ` Baurzhan Ismagulov
2018-01-31 15:46 ` Henning Schild
2018-01-31 16:13 ` Jan Kiszka
2018-01-31 13:35 ` Baurzhan Ismagulov [this message]
2018-01-31 13:47 ` Henning Schild
2018-01-31 14:00 ` Baurzhan Ismagulov
2018-01-31 13:46 ` Henning Schild
2018-01-31 13:36 ` Henning Schild
2018-01-31 13:40 ` Baurzhan Ismagulov
2018-01-31 13:05 ` Henning Schild
2018-02-01 12:41 ` [PATCH] images: wic: limit use of sudo and enable manual call again Henning Schild
2018-02-01 12:44 ` Henning Schild
2018-02-01 16:09 ` Baurzhan Ismagulov
2018-02-01 18:10 ` Henning Schild
2018-02-01 18:55 ` Henning Schild
2018-02-12 19:07 ` Henning Schild
2018-02-12 17:27 ` [PATCH 0/9] first wic integration Henning Schild
2018-02-12 18:21 ` Alexander Smirnov
2018-02-12 18:30 ` Henning Schild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180131133511.GE6508@yssyq.radix50.net \
--to=ibr@radix50.net \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox