On Thu, Aug 25, 2016 at 12:08 PM, Laura Abbott labbott@redhat.com wrote:
On 08/25/2016 11:35 AM, Paul Bolle wrote:
On Thu, 2016-08-25 at 09:16 -0700, Laura Abbott wrote:
On 08/25/2016 03:19 AM, Paul Bolle wrote: The issue is that CONFIG_PWM_LPSS was set =m but it wasn't actually set at all. See https://bugzilla.redhat.com/show_bug.cgi?id=1335196 as well.
Yes, I read that report.
We're setting these options so we think they are enabled
but in reality they aren't. This is confusing for both us and the users. The goal here is to catch these problems at build time so they can be corrected sooner.
How does this patch catch these problems? The patch description doesn't tell us that. (Imagine reading the patch description while bugzilla.redhat.com is unreachable. How much does one then know what this patch is actually all about?)
Including an example of the output of "cat .mismatches", say for the issue that this bugzilla link references, might do wonders for people reading this patch description.
That's a good suggestion.
I am guilty of thinking everyone involved in the kernel was aware of this issue, so I figured a short commit message was enough. I will provide more details in future patches.
Thanks Paul!
This terminates the build, doesn't it? But we should only terminate
the build when we're unsure how to continue. Because otherwise we might break people's build for configuration issues they personally couldn't care less about. For instance, I'm running an x86 laptop with CONFIG_PWM not set ever since I run Fedora 24. Why should I care? I have no idea.
We terminate the build because something is misconfigured. If an option is set =m in the config fragments but not in the generated config someone has specified something wrong.
No, we don't. We try to finish the build if that's possible. We might emit warnings, but we try to keep the build going.
We terminate the build for newoptions that aren't specified. I consider this in the same category.
I'm pretty sure these configuration mismatches only happen for rather
obscure corner cases. Serious configuration problems will never hit the tree in the first place.
I consider a case where we have an option specified as =y or =m in our configs and it gets generated as not enabled serious configuration problems. What do you consider a serious configuration issue?
Imagine trying to rebuild the kernel package, for whatever reason,
locally and hitting this build error for something entirely irrelevant. (Like an issue with CONFIG_PWM that is apparently not interesting for your build machine.) Why on earth should we try to make people unhappy by breaking their build for them?
It's not the goal to break a build for anyone. I don't plan on merging or turning this on until existing issues are fixed up. Ultimately people who are making their own builds though have always been, well on their own. I can request people test with their custom configurations to see if there is anything we are missing. There will be an option similar to listnewconfig to skip the error out as well. Do you have other suggestions about minimizing the impact?
There should be an option to ignore it though if people don't want.
Miguel, can you add an option similar to listnewconfig_fail?
Yes! It should be as simple as adding another macro similar to listnewconfig_fail.
Thanks,
Paul Bolle
Thanks, Laura