4063 2013-03-20 01:42:48 +0000 pseudo's logging and diagnostics are not very clear 2026-06-25 15:25:41 +0000 1 1 6 Yocto Project Subprojects Pseudo pseudo master All Multiple RESOLVED INVALID Medium enhancement Future 1 seebs unassigned jessica.zhang juro.bystricky mark.hatle pavel randy.macleod sgw yp.pseudo.watcher yp.watcher --- --- Don't know oldest_to_newest 30877 0 seebs 2013-03-20 01:42:48 +0000 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. 45750 1 seebs 2014-09-22 17:17:07 +0000 Moving to "future". We actually have the better granularity in pseudo 1.6, but the messages are still pretty uninformative. 74241 2 juro.bystricky 2017-06-15 16:16:42 +0000 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 ... 79726 3 seebs 2018-03-06 12:50:40 +0000 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". 106019 4 randy.macleod 2026-06-25 15:25:41 +0000 The description is rather vague. Please open more specific issues if needed.