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. > > 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. 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. 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? > There should be an option to ignore it though if people don't want. > Miguel, can you add an option similar to listnewconfig_fail? Thanks, Paul Bolle _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
