On Tue, Jun 15, 2021 at 02:29:16PM +0100, Richard Purdie wrote:
I should apologise for being a little grumpy in some of my replies,
it is fair to say that everything is getting to me a little as continual
build failures and being continually asked for reasoned arguments for
saying "no" to things is wearing me down. We have bugs in many core pieces
of the system (pseudo, patchelf, prelink, ltp, oeqa, devtool, eSDK and so
on) and currently it feels like I'm the only person with the domain
knowledge to try and attempt to look into them. This shouldn't ripple
out into emails though.
The context of this issue is probably important and I didn't really
I've been asked about a "bitbake bug" a lot on irc recently and asked
for help in trying to resolve it. I spent quite a bit more time than
expected (on my weekend) trying to understand the issue and it wasn't
the issue as reported but a lot more subtle. In the emails here I've
spelt out the problem but the way it becomes exposed to the end user
is a lot more insidious.
I don't think the BSP was doing anything wrong using a MACHINE override
on a variable. The initramfs recipe was also not really doing anything
wrong trying to set the fstypes to the initramfs ones.
The interaction between the two things is rather unfortunate and in this
case the BSP maintainer could not see why it was breaking and even me, with
a few years experience with bitbake couldn't immediately understand what
was wrong or how my own fix was going to break.
Even now I think broken "fixes" are being spread around in attempts to try
and work around the issue which swap on machine's breakage for another
(collie works but qemux86 using image-live then doesn't).
It does worry me a lot that the issue is so obtuse to debug and that whilst
we can patch this one up, someone else can/will hit it again. The potential
to hit it with some other variable also remains. I don't like issues that
few people can "see" into and understand.
For that reason I would like to change the initramfs recipe somehow to
improve usability and ensure people don't hit this. Right now I can't see
any way to do that other than to say "don't do that". I can't even add
anything to tell the user there is a problem. This was the spirit the
proposal was born from. I understand why people don't like any new operator,
I'm not thrilled either but what I'm not seeing are alternatives to improve
Thanks for all the details here. Since this is stemming from a specific
BSP, I think at this point it might be good to share what exactly it is,
and it wouldn't be seen as "shaming" that BSP at this point as it's
exposed a rather, as you note, obtuse problem.
I have another "could we just ..." idea on this, but I could answer that
myself maybe with the exact problem laid out.