Re: [bitbake-devel] [PATCH 3/4] bitbake-setup: print plain messages in quiet mode

["Antonin Godard" <antonin.godard@bootlin.com>]

On Tue Feb 17, 2026 at 11:18 AM CET, Alexander Kanavin via lists.openembedded.org wrote:
> On Tue, 17 Feb 2026 at 10:36, Antonin Godard <antonin.godard@bootlin.com> wrote:
>
>> Actually, when I was testing things I was in interactive mode. Previously,
>> passing --quiet in interactive mode would just leave you with nothing printed
>> on the console (only warning and errors), which is strange for an interactive
>> progem. However I forgot than in non-interactive mode you may want that to
>> happen (nothing printed).
>>
>> So maybe, we should look at the --non-interactive option value and print nothing
>> (i.e. leave the current state, only warnings and errors are printed) when True,
>> but raise the loglevel to have at least PLAIN messages when True? Or give the
>> user a warning that running the init command shouldn't be run with --quiet?
>
> I'd suggest that we start with setting clear criteria for using
> various printing/logging levels:
>
> - any interactive selections and prompts should be using
> logger.verbnote (which is higher level than plain or info, but isn't a
> warning).

Agreed. I think verbnote messages appear with a "NOTE: " prefix though, which I
don't think is necessary for bitbake-setup.

> - regular messages right now are using a mix of plain and info -
> what's the difference and criteria for picking one or the other?
> Should they be unified, or do we still need to use both?

It was a bit arbitrary, but info messages seemed less "important" to me than
plain messages (their "NOTE:" prefix is what this feels like to me at least).

> Then, modes could be defined like this: quiet mode prints only
> verbnote and higher. Regular mode prints info and higher. Debug mode
> prints debug and higher.
>
> One possibility with modes is to actually remove --quiet altogether -
> is there really a use case for it? Bitbake-setup doesn't flood the
> console, and what it prints can be useful in finding out what went
> wrong, in addition to the actual error.

I think it's ok to keep it, it shouldn't be hard to support and there might be a
use-case for it for some people.

I will take this out of this series, as this requires more thought-processing. I
will try to follow-up with some proposal when I have some time, including
verbnote, etc.

Thanks!
Antonin