<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 19, 2023 at 6:47 AM Frank Kühndel <<a href="mailto:frank.kuehndel@embedded-brains.de">frank.kuehndel@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Chris,<br>
Hello Joel,<br>
<br>
On 1/16/23 18:27, Joel Sherrill wrote:<br>
> Subject:<br>
> Re: [PATCH 1/1] RSB: Mitigate too short error reports<br>
> From:<br>
> Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>><br>
> Date:<br>
> 1/16/23, 18:27<br>
> <br>
> To:<br>
> Frank Kühndel <<a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>><br>
> CC:<br>
> Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>, <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <br>
> <br>
> On Mon, Jan 16, 2023 at 8:46 AM Frank Kühndel <<br>
> <a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>> wrote:<br>
> <br>
>> Hi Chris,<br>
>><br>
>> On 1/16/23 01:02, Chris Johns wrote:<br>
>>> Subject:<br>
>>> Re: [PATCH 1/1] RSB: Mitigate too short error reports<br>
>>> From:<br>
>>> Chris Johns<<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>><br>
>>> Date:<br>
>>> 1/16/23, 01:02<br>
>>><br>
>>> To:<br>
>>> Frank Kühndel<<a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>>,<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>><br>
>>><br>
>>> On 22/12/2022 9:09 pm, Frank Kühndel wrote:<br>
>>>> On 12/21/22 00:06, Chris Johns wrote:<br>
>>>>> On 21/12/2022 3:44 am, Frank Kuehndel wrote:<br>
>>>>>> From: Frank Kühndel<<a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>><br>
>>>>>><br>
>>>>>> Close #4642<br>
>>>>>> ---<br>
>>>>>> source-builder/sb/ereport.py | 4 ++++<br>
>>>>>> 1 file changed, 4 insertions(+)<br>
>>>>>><br>
>>>>>> diff --git a/source-builder/sb/ereport.py<br>
>> b/source-builder/sb/ereport.py<br>
>>>>>> index d8fb5f6..d391917 100755<br>
>>>>>> --- a/source-builder/sb/ereport.py<br>
>>>>>> +++ b/source-builder/sb/ereport.py<br>
>>>>>> @@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer =<br>
>> None):<br>
>>>>>> with open(name, 'w') as l:<br>
>>>>>> l.write(os.linesep.join(r))<br>
>>>>>> log.notice(' See error report: %s' % (name))<br>
>>>>>> + log.notice(' (Hint: The first error may be in front of<br>
>> a '<br>
>>>>>> + 'line containing\n'<br>
>>>>>> + ' "Error 1" [GNU make] and may be only in the whole<br>
>> log '<br>
>>>>> Is this too specific to GNU make? What ifs a package uses cmake or<br>
>> something<br>
>>>>> else?<br>
>>>> As the text indicates, this is specific to GNU make. For those using<br>
>> something<br>
>>>> else reading this text will still hint that the first error may not be<br>
>> in the<br>
>>>> end of the report "and may be only in the whole log".<br>
>>>><br>
>>>> Another weak point in this text is that by far not all errors<br>
>> originating from<br>
>>>> "make". Yet, the true trouble is the original "See error report: %s"<br>
>> where it<br>
>>>> can sometimes happen that the error is not in this "error report" at<br>
>> all.<br>
>>>> I found it difficult to find a wording which is short, clear and<br>
>> helpful to the<br>
>>>> reader and at the same time not confusing. I am not perfectly happy<br>
>> with the<br>
>>>> notice above. I just found it a reasonable compromise.<br>
>>>><br>
>>>> If you prefer more generic texts - such as the examples below - I will<br>
>> send a<br>
>>>> new patch with the suggested test.<br>
>>>><br>
>>>> "Hint: The first error may be far way from the end of the<br>
>>>> report and in cases can only be found in the whole build log."<br>
>>>><br>
>>>> "Hint: The error is most likely in the error report otherwise<br>
>>>> see the whole build log [--log option]."<br>
>>>><br>
>>>> If you find any such change might cause more confusion than it might be<br>
>> helpful,<br>
>>>> I think it better to close this bug than to try to fix it.<br>
>>>><br>
>>> I think all you have written is valid and I have found the wording<br>
>> difficult.<br>
>>> There will never be a robust error message scanner or a simple full<br>
>> proof way to<br>
>>> find errors. The parallel builds makes tracking the errors difficult and<br>
>> the<br>
>>> point of error and end of the build a long distance apart.<br>
> I usually search the logs for "rror:" and that's the first time something<br>
> is reported<br>
> whether by make or gcc or whatever. It may not be the root cause but it gets<br>
> me to the first report.<br>
> <br>
> Cutting any of these long reports down is always going to be possible to<br>
> cut out the real issue. It's ok because it it's more than just an odd setup<br>
> issue on the host, someone will have to build locally to reproduce the<br>
> issue.<br>
> And then they will get the full output.<br>
> <br>
> <br>
>>> As a result I question the value of the report and wonder if it should be<br>
>>> removed. The report adds overhead to the build as the logging process<br>
>> needs to<br>
>>> maintain a buffer of lines that is always updating. Your attention and<br>
>> interest<br>
>>> around this feature highlights how problematic it is so maybe it is<br>
>> simpler and<br>
>>> better to remove it and we leave users to find the error in the log file.<br>
>>><br>
>>> I am happy to accept the report has not worked as a feature, remove it<br>
>> and in<br>
>>> the process we recover some overheads in the logging area of the RSB?<br>
>>><br>
>> I am not against the error report and I do not say it is a useless<br>
>> feature. It is just that I found the message ' See error report: %s'<br>
>> confusing in those cases where the report does not contain the error<br>
>> at all because it is too short (the error report consists simply of the<br>
>> last 400 lines of the build log).<br>
>><br>
>> To answer your question, I believe there is always a build log - no<br>
>> matter whether the `--log` option is used or not. In this case, removing<br>
>> the error report and pointing to the build log in case of error (for<br>
>> example like ' See build log: %s') would certainly solve all my concerns.<br>
>><br>
> But on the build@ reports, it is nice to have something. Many times it<br>
> is possible to diagnose the issue. Just in the past fifteen minutes, there<br>
> was one which having the log made it clear that CentOS 7 and other older<br>
> distributions need to use a newer GCC. Having the info in the build@<br>
> message was more than enough to diagnose that.<br>
> <br>
>> On the other hand, implementing the error report took time and was<br>
>> certainly done with good reason. I do not feel like I should be the one<br>
>> deciding to remove it. Changing the message or simply closing<br>
>> <a href="https://devel.rtems.org/ticket/4642" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/4642</a> would also be perfectly valid for me.<br>
>><br>
> Changing the message to encourage --log or whatever guidance for<br>
> debug. I don't even mind it pointing to a URL with guidance on debugging<br>
> RSB build issues.<br>
<br>
When I understand Joel right, he would keep the error report and prefers <br>
to change the message. </blockquote><div><br></div><div>In a perfect world, there would also be improvements on what's reported</div><div>but we know there is no perfect solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This brings the discussion back to decide on an <br>
appropriate text. To make progress, I suggests<br>
<br>
' See error report: %s\n'<br>
' Note: In some cases the error appears only in\n'<br>
' the complete build log (see --log option)'<br>
<br>
If your are OK with this text, I am happy to prepare a patch. I also <br>
welcome any other suggestion. If we cannot find any solution, I prefer <br>
to close my ticket #4642 without any action taken.<br></blockquote><div><br></div><div>I'm happy with text like that. Is there a ticket to improve the message</div><div>or should #4642 have a comment and the message improved?</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Greetings<br>
fk<br>
<br>
> <br>
> --joel<br>
> <br>
> <br>
>> Greetings ... and a happy new year to you<br>
>> Frank<br>
>><br>
>> --<br>
>> embedded brains GmbH<br>
>> Herr Frank KÜHNDEL<br>
>> Dornierstr. 4<br>
>> 82178 Puchheim<br>
>> Germany<br>
>> <a href="mailto:email%3Afrank.kuehndel@embedded-brains.de" target="_blank">email:frank.kuehndel@embedded-brains.de</a><br>
>> phone: +49-89-18 94 741 - 23<br>
>> mobile: +49-176-15 22 06 - 11<br>
>> fax: +49-89-18 94 741 - 08<br>
>><br>
>> Registergericht: Amtsgericht München<br>
>> Registernummer: HRB 157899<br>
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
>> Unsere Datenschutzerklärung finden Sie hier:<br>
>> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
</blockquote></div></div>