Bug 4063

Summary:	pseudo's logging and diagnostics are not very clear
Product:	[Yocto Project Subprojects] Pseudo	Reporter:	Seebs <seebs>
Component:	pseudo	Assignee:	Unassigned <unassigned>
Status:	RESOLVED INVALID	QA Contact:
Severity:	enhancement
Priority:	Medium	CC:	jessica.zhang, juro.bystricky, mark.hatle, pavel, randy.macleod, sgw, yp.pseudo.watcher, yp.watcher
Version:	master
Target Milestone:	Future
Hardware:	All
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

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.