On Thu, Aug 25, 2016 at 12:08 PM, Laura Abbott <labbott@xxxxxxxxxx> 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 > -- Regards, Miguel _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
