Bug 4063 - pseudo's logging and diagnostics are not very clear
Summary: pseudo's logging and diagnostics are not very clear
Status: RESOLVED INVALID
Alias: None
Product: Pseudo
Classification: Yocto Project Subprojects
Component: pseudo (show other bugs)
Version: master
Hardware: All Multiple
: Medium enhancement
Target Milestone: Future
Assignee: Unassigned
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-03-20 01:42 UTC by Seebs
Modified: 2026-06-25 15:25 UTC (History)
8 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Seebs 2013-03-20 01:42:48 UTC
The diagnostics pseudo produces, especially the debugging messages, are unclear at best, poorly organized, and so on. These should be improved. Ideally:

* Warnings/errors should be clearer and easier to understand.
* Debugging information should be clearer, and there should be better granularity of control to allow debugging particular aspects of pseudo's behavior.
Comment 1 Seebs 2014-09-22 17:17:07 UTC
Moving to "future". We actually have the better granularity in pseudo 1.6, but the messages are still pretty uninformative.
Comment 2 Juro Bystricky 2017-06-15 16:16:42 UTC
Even as of the latest pseudo 1.8.2 the log messages are far from perfect.
One checks the log files only if there are problems and the problems seem to occur more likely in complex situations. Hence the log files can be huge, up to several GB (in verbose mode in particular) and browsing through the messages is tedious. To allow easier search for things of interest in the log file,  I miss:

1. Error messages should clearly state ERROR, do not assume we know which messages are a result of an error, we may end up with a mix of various messages and it is impossible to differentiate error messages from other "progress" messages:

ERROR: blah blah blah

2. The messages should be prefixed by debug keyword, for easy grepping, something like:

PDBG_CLIENT: blah blah
PDBG_SERVER: blah blah
PDBG_DB: blah blah
...
Comment 3 Seebs 2018-03-06 12:50:40 UTC
I'm currently mostly-okay with the state of the messages. In particular, I'd note that it's not easy to *define* whether or not a message should be considered an "error" in a lot of boundary cases.

The debug keyword prefix idea is interesting, but somewhat difficult to arrange, because there's not necessarily a single debug prefix controlling a line of output. I believe there's at least one case where part of a line is optional based on a different debug flag...

I'm not sure how important this is, but I do want to look at it some day. I'm still thinking about it, I guess that's "in progress design".
Comment 4 Randy MacLeod 2026-06-25 15:25:41 UTC
The description is rather vague.
Please open more specific issues if needed.