Warnings and errors mixed up in rpmbuild output #793

voxik · 2019-07-15T14:47:18Z

When I build package, I get following errors:

... snip ...

error: Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/lib64/ruby/enc/trans/cesu_8.so-2.7.0-0.1.git0c6c937904.fc31.x86_64.debug
   /usr/lib64/ruby/enc/trans/cesu_8.so
   /usr/share/ruby/logger/errors.rb
   /usr/share/ruby/logger/formatter.rb
   /usr/share/ruby/logger/log_device.rb
   /usr/share/ruby/logger/period.rb
   /usr/share/ruby/logger/severity.rb
   /usr/share/ruby/logger/version.rb


RPM build errors:
    absolute symlink: /usr/share/ruby/irb.rb -> /usr/share/gems/gems/irb-1.1.0.pre.2/lib/irb.rb
    absolute symlink: /usr/share/ruby/irb/cmd/chws.rb -> /usr/share/gems/gems/irb-1.1.0.pre.2/lib/irb/cmd/chws.rb
    absolute symlink: /usr/share/ruby/irb/cmd/fork.rb -> /usr/share/gems/gems/irb-1.1.0.pre.2/lib/irb/cmd/fork.rb

... snip ...

They look very serious. But once I fix the Installed (but unpackaged) file(s) found issues, the absolute symlink errors are suddenly reported just as warnings:

... snip ...

Processing files: rubygem-irb-1.1.0.pre.2-0.1.git0c6c937904.fc31.noarch
warning: absolute symlink: /usr/share/ruby/irb.rb -> /usr/share/gems/gems/irb-1.1.0.pre.2/lib/irb.rb
warning: absolute symlink: /usr/share/ruby/irb/cmd/chws.rb -> /usr/share/gems/gems/irb-1.1.0.pre.2/lib/irb/cmd/chws.rb
warning: absolute symlink: /usr/share/ruby/irb/cmd/fork.rb -> /usr/share/gems/gems/irb-1.1.0.pre.2/lib/irb/cmd/fork.rb

... snip ...

So what are they, warnings or errors?

$ rpm -q rpm
rpm-4.15.0-0.beta.1.fc31.x86_64

The text was updated successfully, but these errors were encountered:

pmatilai · 2019-07-30T12:01:49Z

It's really just a warning, see 8359ded

The way warnings vs errors are reported could maybe use some tweaking, but I'd expect it to be an old, old issue.

voxik · 2019-08-14T11:18:50Z

Thx for the reference. I'd still appreciate some improvement here, because the behavior is confusing.

pmatilai · 2020-03-05T11:57:23Z

Yeah, warnings and errors should obviously be separated in the output in a manner that they cannot be confused.

Implementation might not be as straightforward as one would think as it links to rpmlog behavior.

) Fixes: rpm-software-management#793

) Currently, we dump the whole log, including warnings, under the "RPM build errors:" section of the output. That's confusing. One solution would be to add a summary for warnings, too, but that needs to be carefully thought out, since a lot of packages would suddenly start showing it due to unresolved warnings, whether overlooked or just long accepted. The easiest and least disruptive fix for now is to simply filter out warnings, which is what this commit does. Fixes: rpm-software-management#793

) Currently, we dump the whole log, including warnings, under the "RPM build errors:" section of the output. That's confusing. One solution would be to add a summary for warnings, too, but that needs to be carefully thought out, since a lot of packages would suddenly start showing such a summary due to unresolved warnings, whether overlooked or just long accepted. The easiest and least disruptive fix for now is to simply filter out warnings, which is what this commit does. Fixes: rpm-software-management#793

In case there were any errors or warnings during rpmbuild, we print a summary at the end where we list them all. This is confusing, however, since a) warnings are only printed when there are some errors and b) warnings are printed under the same "RPM build errors" heading. Let's fix that by only putting errors there. For warnings, we can have a separate heading, which is the subject of the next commit. Fixes: rpm-software-management#793

In case there were any errors or warnings during rpmbuild, we print a summary at the end where we list them all. This is confusing, however, since a) warnings are only printed when there are some errors and b) warnings are printed under the same "RPM build errors" heading. Let's fix that by only putting errors there. For warnings, we can have a separate heading, which is going to be the subject of one of the next commits. Fixes: rpm-software-management#793

Currently, on fatal errors, rpmbuild prints a summary with all the log messages of a priority at least RPMLOG_WARNING, despite of what the heading actually says - "RPM build errors". There are several ways to fix this discrepancy: A) Reword the heading such that it's clear that warnings may be present too, and clearly distinguish them by printing the message prefix ("warning: [message]" or "error: [message]"). B) Limit the summary to errors only. The problem with A) is that the output format of the summary would change quite significantly, potentially breaking some tooling that parses it (it's been this way since commit f2efc72 from the year 2000). Therefore, B) seems like a more reasonable and conservative thing to do, so let's just do that. Note: In addition to this, we could also later add a section called "RPM build warnings", however that has two other drawbacks: 1) For it to make sense, we would have to print it even on successful runs, making the output noisier than necessary. 2) The change of "errors" to "warnings" in the heading would be very subtle and could easily go unnoticed when quickly glancing at the output and looking for "that block of indented lines that have always been errors". Fixes: rpm-software-management#793

Currently, on fatal errors, rpmbuild repeats in a summary all the logged messages of a priority at least RPMLOG_WARNING, despite of what the heading actually says - "RPM build errors". There are several ways to fix this discrepancy: A) Reword the heading such that it's clear that warnings may be present too, and clearly distinguish them by printing the message prefix ("warning: [message]" or "error: [message]"). B) Limit the summary to errors only. The problem with A) is that the output format of the summary would change quite significantly, potentially breaking some tooling that parses it (it's been this way since commit f2efc72 from the year 2000). Therefore, B) would be a safer and more conservative fix, so let's just do that. Note: In addition to this, we could also later add a section called "RPM build warnings", however that has two other drawbacks: 1) For it to make sense, we would have to print it even on successful runs, making the output noisier than necessary. 2) The change of "errors" to "warnings" in the heading would be very subtle and could easily go unnoticed when quickly glancing at the output and looking for "that block of indented lines that have always been errors". Fixes: rpm-software-management#793

Currently, on fatal errors, rpmbuild repeats in a summary all the logged messages of a priority at least RPMLOG_WARNING, despite of what the heading would make you believe - "RPM build errors". There are several ways to fix this discrepancy: A) Reword the heading such that it's clear that warnings may be present too, and clearly distinguish them by printing the message prefix ("warning: [message]" or "error: [message]"). B) Limit the summary to errors only. The problem with A) is that the output format of the summary would change quite significantly, potentially breaking some tooling that parses it (it's been this way since commit f2efc72 from the year 2000). Therefore, B) would be a safer and more conservative fix, so let's just do that. Note: In addition to this, we could also later add a section called "RPM build warnings", however that has two other drawbacks: 1) For it to make sense, we would have to print it even on successful runs, making the output noisier than necessary. 2) The change of "errors" to "warnings" in the heading would be very subtle and could easily go unnoticed when quickly glancing at the output and looking for "that block of indented lines that have always been errors". Fixes: rpm-software-management#793

Currently, on fatal errors, rpmbuild repeats in a summary all the logged messages of a priority at least RPMLOG_WARNING, despite of what the heading would make you believe - "RPM build errors". There are several ways to fix this discrepancy: A) Reword the heading such that it's clear that warnings may be present too, and clearly distinguish them by printing the message prefix ("warning: [message]" or "error: [message]"). B) Keep the heading as is, but limit the summary to errors only. The problem with A) is that the output format of the summary would change quite significantly, potentially breaking some existing tooling out there that might want to parse it (it's been the same since commit f2efc72 from the year 2000). Therefore, B) would be a safer and more conservative choice, so let's just do that. Note: In addition to this, we could also later add a section called "RPM build warnings", however that has two other drawbacks: 1) For it to make sense, we would have to print it even on successful runs, adding unnecessary noise to the output. 2) Replacing "errors" with "warnings" in the heading would be too subtle of a change and could easily go unnoticed when quickly glancing at the output and looking for "that block of indented lines that have always been errors". Fixes: rpm-software-management#793

Confusingly, the "RPM build errors" section also includes messages logged as warnings. That gives the false impression that they somehow contributed to the actual build failure and therefore were turned into errors. This appears to be a historical artifact; when a message passes through the logging system and is of the priority RPMLOG_WARNING or higher, we save it in a global buffer, which is then simply dumped in the error summary, as is. This was probably good enough when the summary was introduced (commit f2efc72, year 2000), as there were almost no warnings generated by RPM at that time, however as they became more abundant, the dumping logic was never revisited. It may seem that the easiest way to fix this would be to simply remove the summary altogether, as it usually just repeats the last error anyway. However, there are good reasons to keep the summary: - Not all errors terminate a build right away, so they can get drown in the output that follows after. Example: "File not found" in rpmInstall(). - It makes it immediately obvious that something went wrong when examining build logs, and the current title undoubtedly has become the "standard" text string to search for. Another possibility would be to just remove the warnings from the summary, but that's not ideal either; we don't want to hide potentially useful information, and some warnings are worth repeating at the end. That leaves us with the following solution: move warnings into their own summary and make sure that: - It only shows when the error summary does. This is to follow the UNIX rule of silence where, if everything goes well (warnings or not), no necessary information (like summaries) is shown. Moreover, there could be packages with long-standing warnings that are unfeasible to fix for some reason, and having an indented block of text resembling "RPM build errors" on every successful build would do no good. - The error summary still goes last, as that's where people automatically tend to look for it. Effectively, this commit is just cosmetic - it reorganizes the existing text, without changing *when* it is printed. Fixes: rpm-software-management#793

Confusingly, the "RPM build errors" section also includes messages logged as warnings. That gives the false impression that they somehow contributed to the actual build failure and therefore were turned into errors. This appears to be a historical artifact; when a message passes through the logging system and is of the priority RPMLOG_WARNING or higher, we save it in a global buffer, which is then simply dumped in the error summary, as is. This was probably good enough when the summary was introduced (commit f2efc72, year 2000), as there were almost no warnings generated by RPM at that time, however as they became more abundant, the dumping logic was never revisited. It may seem that the easiest way to fix this would be to simply remove the summary altogether, as it usually just repeats the last error anyway. However, there are good reasons to keep the summary: - Not all errors terminate a build right away, so they can get drown in the output that follows after. Examples: "File not found" in rpmInstall(), or macro expansion errors (these don't terminate the build at the moment, but we may fix that in the future). - It makes it immediately obvious that something went wrong when examining build logs, and the current title undoubtedly has become the "standard" text string to search for. Another possibility would be to just remove the warnings from the summary, but that's not ideal either; we don't want to hide potentially useful information, and some warnings are worth repeating at the end. That leaves us with the following solution: move warnings into their own summary and make sure that: - It only shows when the error summary does. This is to follow the UNIX rule of silence where, if everything goes well (warnings or not), no necessary information (like summaries) is shown. Moreover, there could be packages with long-standing warnings that are unfeasible to fix for some reason, and having an indented block of text resembling "RPM build errors" on every successful build would do no good. - The error summary still goes last, as that's where people automatically tend to look for it. Effectively, this commit is just cosmetic - it reorganizes the existing text, without changing *when* it is printed. Fixes: rpm-software-management#793

Confusingly, the "RPM build errors" section also includes messages logged as warnings. That gives the false impression that they somehow contributed to the actual build failure and therefore were turned into errors. This appears to be a historical artifact; when a message passes through the logging system and is of the priority RPMLOG_WARNING or higher, we save it in a global buffer, which is then simply dumped in the error summary, as is. This was probably good enough when the summary was introduced (commit f2efc72, year 2000), as there were almost no warnings generated by RPM at that time, however as they became more abundant, the dumping logic was never revisited. It may seem that the easiest way to fix this would be to simply remove the summary altogether, as it usually just repeats the last error anyway. However, there are good reasons to keep the summary: - Not all errors terminate a build right away, so they can get drown in the output that follows after. Examples: "File not found" in rpmInstall(), or macro expansion errors (these don't terminate the build at the moment, but we may fix that in the future). - It makes it immediately obvious that something went wrong when examining build logs, and the current title undoubtedly has become the "standard" text string to search for. Another possibility would be to just remove the warnings from the summary, but that's not ideal either; we don't want to hide potentially useful information, and some warnings are worth repeating at the end. That leaves us with the following solution: move warnings into their own summary and make sure that: - It only shows when the error summary does. This is to follow the UNIX rule of silence where, if everything goes well (warnings or not), no unnecessary information (like summaries) is shown. Moreover, there could be packages with long-standing warnings that are unfeasible to fix for some reason, and having an indented block of text resembling "RPM build errors" on every successful build would do no good. - The error summary still goes last, as that's where people automatically tend to look for it. Effectively, this commit is just cosmetic - it reorganizes the existing output, without changing *when* it is printed. Fixes: rpm-software-management#793

Confusingly, the "RPM build errors" section also includes messages logged as warnings. That gives the false impression that they somehow contributed to the actual build failure and therefore were turned into errors. This appears to be a historical artifact; when a message passes through the logging system and is of the priority RPMLOG_WARNING or higher, we save it in a global buffer (ctx->recs), which is then simply dumped with rpmlogPrint() in the error summary. This was probably good enough when the summary was introduced (commit f2efc72, year 2000), as there were almost no warnings generated by RPM at that time, however as they became more abundant, the summary code was never revisited. There are 3 ways to fix this discrepancy: 1) Change the summary's title to "RPM build problems" 2) Remove the summary altogether 3) Don't show warnings in it Options #1 and #2 would be too disruptive. The error summary needs to stay as is, for the following reasons: - While it usually just repeats the last error, not all errors terminate a build right away, so those can get drown in the output that follows after. Examples: "File not found" in rpmInstall(), or macro expansion errors (note: we may have these terminate a build in the future). - It makes it immediately obvious that something went wrong when examining build logs, and the title "RPM build errors" undoubtedly has become the de-facto text string to search for. That leaves us with option #3. To further lessen the disruption, do keep a summary of warnings, but put them under their own heading, and only show it on build failures. That way, we restrict all the extra verbosity to error time (as it is now) and don't pollute the output of otherwise good builds. There may be packages with long-standing warnings that are not feasible to fix for any reason, and having an indented block of text resembling "RPM build errors" at the end of every build would do no good. Effectively, this commit is just cosmetic - it splits the error summary into two, without any functional or API changes (apart from two function additions). Fixes: rpm-software-management#793

Confusingly, the "RPM build errors" section also includes messages logged as warnings. That gives the false impression that they somehow contributed to the actual build failure and therefore were turned into errors. This appears to be a historical artifact; when a message passes through the logging system and is of the priority RPMLOG_WARNING or higher, we save it in a global buffer (ctx->recs), which is then simply dumped with rpmlogPrint() in the error summary. This was probably good enough when the summary was introduced (commit f2efc72, year 2000), as there were almost no warnings generated by RPM at that time, however as they became more abundant, the summary code was never revisited. There are 3 ways to fix this discrepancy: 1) Change the summary's title to "RPM build problems" 2) Remove the summary altogether 3) Don't show warnings in it Options #1 and #2 would be too disruptive. The error summary needs to stay as is, for the following reasons: - While it usually just repeats the last error, not all errors terminate a build right away, so those can get drown in the output that follows after. Examples: "File not found" in rpmInstall(), or macro expansion errors (note: we may have these terminate a build in the future). - It makes it immediately obvious that something went wrong when examining build logs, and the title "RPM build errors" undoubtedly has become the de-facto text string to search for. That leaves us with option #3. To further lessen the disruption, do keep a summary of warnings, but put them under their own heading, and only show it on build failures. That way, we restrict all the extra verbosity to error time (as it is now) and don't pollute the output of otherwise good builds. There may be packages with long-standing warnings that are not feasible to fix for any reason, and having an indented block of text resembling "RPM build errors" at the end of every build would do no good. Effectively, this commit is just cosmetic - it splits the error summary into two, without any functional or API changes (apart from two function additions). Fixes: #793

Confusingly, the "RPM build errors" section also includes messages logged as warnings. That gives the false impression that they somehow contributed to the actual build failure and therefore were turned into errors. This appears to be a historical artifact; when a message passes through the logging system and is of the priority RPMLOG_WARNING or higher, we save it in a global buffer (ctx->recs), which is then simply dumped with rpmlogPrint() in the error summary. This was probably good enough when the summary was introduced (commit f2efc72, year 2000), as there were almost no warnings generated by RPM at that time, however as they became more abundant, the summary code was never revisited. There are 3 ways to fix this discrepancy: 1) Change the summary's title to "RPM build problems" 2) Remove the summary altogether 3) Don't show warnings in it Options #1 and #2 would be too disruptive. The error summary needs to stay as is, for the following reasons: - While it usually just repeats the last error, not all errors terminate a build right away, so those can get drown in the output that follows after. Examples: "File not found" in rpmInstall(), or macro expansion errors (note: we may have these terminate a build in the future). - It makes it immediately obvious that something went wrong when examining build logs, and the title "RPM build errors" undoubtedly has become the de-facto text string to search for. That leaves us with option #3. To further lessen the disruption, do keep a summary of warnings, but put them under their own heading, and only show it on build failures. That way, we restrict all the extra verbosity to error time (as it is now) and don't pollute the output of otherwise good builds. There may be packages with long-standing warnings that are not feasible to fix for any reason, and having an indented block of text resembling "RPM build errors" at the end of every build would do no good. Effectively, this commit is just cosmetic - it splits the error summary into two, without any functional or API changes (apart from two function additions). Fixes: rpm-software-management#793 (cherry picked from commit 7fd7a60)

Confusingly, the "RPM build errors" section also includes messages logged as warnings. That gives the false impression that they somehow contributed to the actual build failure and therefore were turned into errors. This appears to be a historical artifact; when a message passes through the logging system and is of the priority RPMLOG_WARNING or higher, we save it in a global buffer (ctx->recs), which is then simply dumped with rpmlogPrint() in the error summary. This was probably good enough when the summary was introduced (commit f2efc72, year 2000), as there were almost no warnings generated by RPM at that time, however as they became more abundant, the summary code was never revisited. There are 3 ways to fix this discrepancy: 1) Change the summary's title to "RPM build problems" 2) Remove the summary altogether 3) Don't show warnings in it Options #1 and #2 would be too disruptive. The error summary needs to stay as is, for the following reasons: - While it usually just repeats the last error, not all errors terminate a build right away, so those can get drown in the output that follows after. Examples: "File not found" in rpmInstall(), or macro expansion errors (note: we may have these terminate a build in the future). - It makes it immediately obvious that something went wrong when examining build logs, and the title "RPM build errors" undoubtedly has become the de-facto text string to search for. That leaves us with option #3. To further lessen the disruption, do keep a summary of warnings, but put them under their own heading, and only show it on build failures. That way, we restrict all the extra verbosity to error time (as it is now) and don't pollute the output of otherwise good builds. There may be packages with long-standing warnings that are not feasible to fix for any reason, and having an indented block of text resembling "RPM build errors" at the end of every build would do no good. Effectively, this commit is just cosmetic - it splits the error summary into two, without any functional or API changes (apart from two function additions). Fixes: #793 (cherry picked from commit 7fd7a60)

pmatilai changed the title ~~"absolute symlink" warning or error?~~ Warnings and errors mixed up in rpmbuild output Mar 5, 2020

dmnks self-assigned this Sep 28, 2020

dmnks added a commit to dmnks/rpm that referenced this issue Oct 19, 2020

Only print errors in rpmbuild error summary (rpm-software-management#793

c9f194a

) Fixes: rpm-software-management#793

dmnks added a commit to dmnks/rpm that referenced this issue Oct 19, 2020

Only print errors in rpmbuild error summary (rpm-software-management#793

67134f2

) Fixes: rpm-software-management#793

dmnks mentioned this issue Nov 9, 2020

rpmbuild logging tweaks #1429

Closed

7 tasks

dmnks mentioned this issue Mar 22, 2021

Separate build warnings from error summary #1590

Merged

pmatilai closed this as completed in #1590 Dec 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Warnings and errors mixed up in rpmbuild output #793

Warnings and errors mixed up in rpmbuild output #793

voxik commented Jul 15, 2019

pmatilai commented Jul 30, 2019

voxik commented Aug 14, 2019

pmatilai commented Mar 5, 2020 •

edited

Loading

Warnings and errors mixed up in rpmbuild output #793

Warnings and errors mixed up in rpmbuild output #793

Comments

voxik commented Jul 15, 2019

pmatilai commented Jul 30, 2019

voxik commented Aug 14, 2019

pmatilai commented Mar 5, 2020 • edited Loading

pmatilai commented Mar 5, 2020 •

edited

Loading