[PATCH 0/4] Add -W to treat warnings as errors

[PATCH 0/4] Add -W to treat warnings as errors

[Antonin Godard]

The purpose of this series is to implement the -W option to bitbake to
be able to treat warnings as errors and make the return value 1 in that
case. This is useful in environments that need to make sure the build
passed without warnings. Currently this is usually done by a
post-process task grepping the last log for warnings.

With knotty, the -W/--warnings-as-errors option will turn warning
messages to the red color (useful to know that the option is in use
during the build) and make the return value be 1 in case of warnings. An
additional summary line is displayed at the end to let the user know
that the option was in use for this execution of bitbake.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
Antonin Godard (4):
      main: add an argument for showing warnings as errors
      msg: add a helper to show warnings in red color
      knotty: convert warnings to errors when -W is passed
      doc/bitbake-user-manual-intro.rst: refresh bitbake's help message

 .../bitbake-user-manual-intro.rst                  | 36 ++++++++++++----------
 lib/bb/main.py                                     |  3 ++
 lib/bb/msg.py                                      |  8 +++++
 lib/bb/ui/knotty.py                                | 14 +++++++++
 4 files changed, 45 insertions(+), 16 deletions(-)
---
base-commit: a17e8093fd4d5ed7792df86af8d2d63803dc42a4
change-id: 20260914-warn-as-errors-a9c87a0ad2d9

[PATCH 1/4] main: add an argument for showing warnings as errors

[Antonin Godard]

Add -W/--warnings-as-errors to make it possible to turn warnings into
errors. The werror boolean should be used by UIs to turn their warnings
into errors.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 lib/bb/main.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/bb/main.py b/lib/bb/main.py
index 73a66468fef..7c65dfff1af 100755
--- a/lib/bb/main.py
+++ b/lib/bb/main.py
@@ -256,6 +256,9 @@ def create_bitbake_parser():
                         help="Output less log message data to the terminal. You can specify this "
                              "more than once.")
 
+    logging_group.add_argument("-W", "--warnings-as-errors", action="store_true", dest="werror",
+                        help="Treat warnings as errors.")
+
     logging_group.add_argument("-w", "--write-log", dest="writeeventlog",
                         default=os.environ.get("BBEVENTLOG"),
                         help="Writes the event log of the build to a bitbake event json file. "

-- 
2.55.0

[PATCH 2/4] msg: add a helper to show warnings in red color

[Antonin Godard]

In preparation for the next commit, add a helper that changes the
warning color to be red, when warnings should be treated as errors. This
helps users recognizing that the -W argument was passed while still
being able to differentiate between warning and error messages (thanks
to their levelname).

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 lib/bb/msg.py | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/bb/msg.py b/lib/bb/msg.py
index 4f616ff42e7..02728c44bba 100644
--- a/lib/bb/msg.py
+++ b/lib/bb/msg.py
@@ -102,6 +102,14 @@ class BBLogFormatter(logging.Formatter):
     def enable_color(self):
         self.color_enabled = True
 
+    def set_warn_color_red(self):
+        """
+        Changes the warning messages color to red. Should be
+        used when treating warnings as errors.
+        """
+        self.COLORS[self.WARNING] = self.RED
+        self.COLORS[self.WARNONCE] = self.RED
+
     def __repr__(self):
         return "%s fmt='%s' color=%s" % (self.__class__.__name__, self._fmt, "True" if self.color_enabled else "False")
 

-- 
2.55.0

[PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Antonin Godard]

When -W is passed, modify the handlers to show warnings in red and set
the return value to 1. Add a summary line informing the user that the -W
option was used as it might not be obvious when looking at the bottom
the end of the console log.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 lib/bb/ui/knotty.py | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/lib/bb/ui/knotty.py b/lib/bb/ui/knotty.py
index 1a3198b5c02..a3a5c374a35 100644
--- a/lib/bb/ui/knotty.py
+++ b/lib/bb/ui/knotty.py
@@ -662,6 +662,14 @@ def main(server, eventHandler, params, tf = TerminalFilter):
     # terminal handler
     console_handlers = [h for h in conf.config['handlers'].values() if getattr(h, 'is_console', False)]
 
+    if params.werror:
+        # Change the color of warning/warnonce messages to red when -W is passed
+        for h in console_handlers:
+            try:
+                h.formatter.set_warn_color_red()
+            except AttributeError:
+                pass
+
     bb.utils.set_process_name("KnottyUI")
 
     if params.options.remote_server and params.options.kill_server:
@@ -782,6 +790,8 @@ def main(server, eventHandler, params, tf = TerminalFilter):
                     return_value = 1
                 elif event.levelno == bb.msg.BBLogFormatter.WARNING:
                     warnings = warnings + 1
+                    if params.werror:
+                        return_value = 1
 
                 if event.taskpid != 0:
                     # For "normal" logging conditions, don't show note logs from tasks
@@ -1054,6 +1064,10 @@ def main(server, eventHandler, params, tf = TerminalFilter):
         if return_value and errors:
             summary += pluralise("\nSummary: There was %s ERROR message, returning a non-zero exit code.",
                                  "\nSummary: There were %s ERROR messages, returning a non-zero exit code.", errors)
+
+        if params.werror and warnings:
+            summary += "\nSummary: Warnings were treated as errors (-W)."
+
         if summary and params.options.quiet == 0:
             print(summary)
 

-- 
2.55.0

Re: [bitbake-devel] [PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Richard Purdie]

On Tue, 2026-10-13 at 14:13 +0200, Antonin Godard via lists.openembedded.org wrote:
> When -W is passed, modify the handlers to show warnings in red and set
> the return value to 1. Add a summary line informing the user that the -W
> option was used as it might not be obvious when looking at the bottom
> the end of the console log.

The trouble is this doesn't make warnings behave exactly as errors and
I think that is going to confuse people :/.

Specifically, if an error is encountered in a task, it will error and
fail. The warning will show an error but continue anyway. I also
suspect the warnings will still show as warnings in the log files and
only appear as errors on the console.

Cheers,

Richard

Re: [docs] [bitbake-devel] [PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Antonin Godard]

On Thu Oct 15, 2026 at 10:58 AM CEST, Richard Purdie via lists.yoctoproject.org wrote:
> On Tue, 2026-10-13 at 14:13 +0200, Antonin Godard via lists.openembedded.org wrote:
>> When -W is passed, modify the handlers to show warnings in red and set
>> the return value to 1. Add a summary line informing the user that the -W
>> option was used as it might not be obvious when looking at the bottom
>> the end of the console log.
>
> The trouble is this doesn't make warnings behave exactly as errors and
> I think that is going to confuse people :/.
>
> Specifically, if an error is encountered in a task, it will error and
> fail. The warning will show an error but continue anyway. I also
> suspect the warnings will still show as warnings in the log files and
> only appear as errors on the console.

Good point. So there's two directions this could take (if we want that feature):

- Make this option change the behavior of warnings, and make them _act_ (not
  just look) like errors, so a given task would stop in case of warning.

- Rename the option and make it clearer: warnings are still warnings but the
  return code will be 1 if there are any.

  Maybe "-W,--fail-on-warnings: Make bitbake return 1 if any warning is
  emitted"?

I feel like the second option might be best as the first one is changing the
behavior of tasks and I also think this might not be desirable.

With the second option it allows having a positive exit code on warnings while
still being able to have a look at all of them (not only the single one that
stopped the build as would happen with the first option), just as you would with
a normal bitbake execution.

Antonin

Re: [docs] [bitbake-devel] [PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Richard Purdie]

On Thu, 2026-10-15 at 12:25 +0200, Antonin Godard wrote:
> On Thu Oct 15, 2026 at 10:58 AM CEST, Richard Purdie via lists.yoctoproject.org wrote:
> > On Tue, 2026-10-13 at 14:13 +0200, Antonin Godard via lists.openembedded.org wrote:
> > > When -W is passed, modify the handlers to show warnings in red and set
> > > the return value to 1. Add a summary line informing the user that the -W
> > > option was used as it might not be obvious when looking at the bottom
> > > the end of the console log.
> > 
> > The trouble is this doesn't make warnings behave exactly as errors and
> > I think that is going to confuse people :/.
> > 
> > Specifically, if an error is encountered in a task, it will error and
> > fail. The warning will show an error but continue anyway. I also
> > suspect the warnings will still show as warnings in the log files and
> > only appear as errors on the console.
> 
> Good point. So there's two directions this could take (if we want that feature):
> 
> - Make this option change the behavior of warnings, and make them _act_ (not
>   just look) like errors, so a given task would stop in case of warning.
> 
> - Rename the option and make it clearer: warnings are still warnings but the
>   return code will be 1 if there are any.
> 
>   Maybe "-W,--fail-on-warnings: Make bitbake return 1 if any warning is
>   emitted"?
> 
> I feel like the second option might be best as the first one is changing the
> behavior of tasks and I also think this might not be desirable.
> 
> With the second option it allows having a positive exit code on warnings while
> still being able to have a look at all of them (not only the single one that
> stopped the build as would happen with the first option), just as you would with
> a normal bitbake execution.

I think we need to see if there are others wanting this feature or not.
I think with new option additions like this, we need to see a clear
demand from the userbase for it. That feedback may also make it clearer
which behaviour people would want.

Cheers,

Richard

Re: [docs] [bitbake-devel] [PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Antonin Godard]

On Thu Oct 15, 2026 at 1:49 PM CEST, Richard Purdie wrote:
> On Thu, 2026-10-15 at 12:25 +0200, Antonin Godard wrote:
>> On Thu Oct 15, 2026 at 10:58 AM CEST, Richard Purdie via lists.yoctoproject.org wrote:
>> > On Tue, 2026-10-13 at 14:13 +0200, Antonin Godard via lists.openembedded.org wrote:
>> > > When -W is passed, modify the handlers to show warnings in red and set
>> > > the return value to 1. Add a summary line informing the user that the -W
>> > > option was used as it might not be obvious when looking at the bottom
>> > > the end of the console log.
>> > 
>> > The trouble is this doesn't make warnings behave exactly as errors and
>> > I think that is going to confuse people :/.
>> > 
>> > Specifically, if an error is encountered in a task, it will error and
>> > fail. The warning will show an error but continue anyway. I also
>> > suspect the warnings will still show as warnings in the log files and
>> > only appear as errors on the console.
>> 
>> Good point. So there's two directions this could take (if we want that feature):
>> 
>> - Make this option change the behavior of warnings, and make them _act_ (not
>>   just look) like errors, so a given task would stop in case of warning.
>> 
>> - Rename the option and make it clearer: warnings are still warnings but the
>>   return code will be 1 if there are any.
>> 
>>   Maybe "-W,--fail-on-warnings: Make bitbake return 1 if any warning is
>>   emitted"?
>> 
>> I feel like the second option might be best as the first one is changing the
>> behavior of tasks and I also think this might not be desirable.
>> 
>> With the second option it allows having a positive exit code on warnings while
>> still being able to have a look at all of them (not only the single one that
>> stopped the build as would happen with the first option), just as you would with
>> a normal bitbake execution.
>
> I think we need to see if there are others wanting this feature or not.
> I think with new option additions like this, we need to see a clear
> demand from the userbase for it. That feedback may also make it clearer
> which behaviour people would want.

Ross (copied here) was talking about it on IRC[1]. Hard to say which way or the
other was desired from this conversation though. It did give me the idea to
contribute this feature as I also need it sometimes.

I personally have seen multiple projects where builds started in CI environments
needed to stop when warnings are emitted. I'm happy to keep my scripts as they
are but I thought this series would make things a bit easier for users.

I cannot say which solution for it the userbase would prefer though!

[1]: https://libera.catirclogs.org/yocto/2026-09-03#1788452760-1788454399;

Antonin

Re: [docs] [bitbake-devel] [PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Richard Purdie]

On Thu, 2026-10-15 at 14:23 +0200, Antonin Godard wrote:
> On Thu Oct 15, 2026 at 1:49 PM CEST, Richard Purdie wrote:
> > On Thu, 2026-10-15 at 12:25 +0200, Antonin Godard wrote:
> > > On Thu Oct 15, 2026 at 10:58 AM CEST, Richard Purdie via lists.yoctoproject.org wrote:
> > > > On Tue, 2026-10-13 at 14:13 +0200, Antonin Godard via lists.openembedded.org wrote:
> > > > > When -W is passed, modify the handlers to show warnings in red and set
> > > > > the return value to 1. Add a summary line informing the user that the -W
> > > > > option was used as it might not be obvious when looking at the bottom
> > > > > the end of the console log.
> > > > 
> > > > The trouble is this doesn't make warnings behave exactly as errors and
> > > > I think that is going to confuse people :/.
> > > > 
> > > > Specifically, if an error is encountered in a task, it will error and
> > > > fail. The warning will show an error but continue anyway. I also
> > > > suspect the warnings will still show as warnings in the log files and
> > > > only appear as errors on the console.
> > > 
> > > Good point. So there's two directions this could take (if we want that feature):
> > > 
> > > - Make this option change the behavior of warnings, and make them _act_ (not
> > >   just look) like errors, so a given task would stop in case of warning.
> > > 
> > > - Rename the option and make it clearer: warnings are still warnings but the
> > >   return code will be 1 if there are any.
> > > 
> > >   Maybe "-W,--fail-on-warnings: Make bitbake return 1 if any warning is
> > >   emitted"?
> > > 
> > > I feel like the second option might be best as the first one is changing the
> > > behavior of tasks and I also think this might not be desirable.
> > > 
> > > With the second option it allows having a positive exit code on warnings while
> > > still being able to have a look at all of them (not only the single one that
> > > stopped the build as would happen with the first option), just as you would with
> > > a normal bitbake execution.
> > 
> > I think we need to see if there are others wanting this feature or not.
> > I think with new option additions like this, we need to see a clear
> > demand from the userbase for it. That feedback may also make it clearer
> > which behaviour people would want.
> 
> Ross (copied here) was talking about it on IRC[1]. Hard to say which way or the
> other was desired from this conversation though. It did give me the idea to
> contribute this feature as I also need it sometimes.
> 
> I personally have seen multiple projects where builds started in CI environments
> needed to stop when warnings are emitted. I'm happy to keep my scripts as they
> are but I thought this series would make things a bit easier for users.

Do you really want to "stop" on warnings though? Usually you want a
list of *all* the warnings, not just the first one. You probably do
want to continue through all the rest of the tasks too.



That makes it sound like you want to just change the exit code, which
is a bit of a different discussion...

Cheers,

Richard

Re: [docs] [bitbake-devel] [PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Antonin Godard]

On Thu Oct 15, 2026 at 3:04 PM CEST, Richard Purdie wrote:
> On Thu, 2026-10-15 at 14:23 +0200, Antonin Godard wrote:
>> On Thu Oct 15, 2026 at 1:49 PM CEST, Richard Purdie wrote:
>> > On Thu, 2026-10-15 at 12:25 +0200, Antonin Godard wrote:
>> > > On Thu Oct 15, 2026 at 10:58 AM CEST, Richard Purdie via lists.yoctoproject.org wrote:
>> > > > On Tue, 2026-10-13 at 14:13 +0200, Antonin Godard via lists.openembedded.org wrote:
>> > > > > When -W is passed, modify the handlers to show warnings in red and set
>> > > > > the return value to 1. Add a summary line informing the user that the -W
>> > > > > option was used as it might not be obvious when looking at the bottom
>> > > > > the end of the console log.
>> > > > 
>> > > > The trouble is this doesn't make warnings behave exactly as errors and
>> > > > I think that is going to confuse people :/.
>> > > > 
>> > > > Specifically, if an error is encountered in a task, it will error and
>> > > > fail. The warning will show an error but continue anyway. I also
>> > > > suspect the warnings will still show as warnings in the log files and
>> > > > only appear as errors on the console.
>> > > 
>> > > Good point. So there's two directions this could take (if we want that feature):
>> > > 
>> > > - Make this option change the behavior of warnings, and make them _act_ (not
>> > >   just look) like errors, so a given task would stop in case of warning.
>> > > 
>> > > - Rename the option and make it clearer: warnings are still warnings but the
>> > >   return code will be 1 if there are any.
>> > > 
>> > >   Maybe "-W,--fail-on-warnings: Make bitbake return 1 if any warning is
>> > >   emitted"?
>> > > 
>> > > I feel like the second option might be best as the first one is changing the
>> > > behavior of tasks and I also think this might not be desirable.
>> > > 
>> > > With the second option it allows having a positive exit code on warnings while
>> > > still being able to have a look at all of them (not only the single one that
>> > > stopped the build as would happen with the first option), just as you would with
>> > > a normal bitbake execution.
>> > 
>> > I think we need to see if there are others wanting this feature or not.
>> > I think with new option additions like this, we need to see a clear
>> > demand from the userbase for it. That feedback may also make it clearer
>> > which behaviour people would want.
>> 
>> Ross (copied here) was talking about it on IRC[1]. Hard to say which way or the
>> other was desired from this conversation though. It did give me the idea to
>> contribute this feature as I also need it sometimes.
>> 
>> I personally have seen multiple projects where builds started in CI environments
>> needed to stop when warnings are emitted. I'm happy to keep my scripts as they
>> are but I thought this series would make things a bit easier for users.
>
> Do you really want to "stop" on warnings though? Usually you want a
> list of *all* the warnings, not just the first one. You probably do
> want to continue through all the rest of the tasks too.

No, I don't want to stop on the first warning. I wasn't clear, sorry.

> That makes it sound like you want to just change the exit code, which
> is a bit of a different discussion...

Yes, exactly, the goal would be to return 1 if at least 1 warning is emitted,
which I think is a common use-case.

Antonin

[PATCH 4/4] doc/bitbake-user-manual-intro.rst: refresh bitbake's help message

[Antonin Godard]

Refresh the bitbake help message with all recent changes.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 .../bitbake-user-manual-intro.rst                  | 36 ++++++++++++----------
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/doc/bitbake-user-manual/bitbake-user-manual-intro.rst b/doc/bitbake-user-manual/bitbake-user-manual-intro.rst
index 6801323e2fb..af6dfed8915 100644
--- a/doc/bitbake-user-manual/bitbake-user-manual-intro.rst
+++ b/doc/bitbake-user-manual/bitbake-user-manual-intro.rst
@@ -415,8 +415,8 @@ Following is the usage and syntax for BitBake::
    usage: bitbake [-s] [-e] [-g] [-u UI] [--version] [-h] [-f] [-c CMD]
                   [-C INVALIDATE_STAMP] [--runall RUNALL] [--runonly RUNONLY]
                   [--no-setscene] [--skip-setscene] [--setscene-only] [-n] [-p]
-                  [-k] [-P] [-S SIGNATURE_HANDLER] [--revisions-changed]
-                  [-b BUILDFILE] [-D] [-l DEBUG_DOMAINS] [-v] [-q]
+                  [-k] [-P PROFILE] [-S SIGNATURE_HANDLER] [--revisions-changed]
+                  [-b BUILDFILE] [-D] [-l DEBUG_DOMAINS] [-v] [-q] [-W]
                   [-w WRITEEVENTLOG] [-B BIND] [-T SERVER_TIMEOUT]
                   [--remote-server REMOTE_SERVER] [-m] [--token XMLRPCTOKEN]
                   [--observe-only] [--status-only] [--server-only] [-r PREFILE]
@@ -435,7 +435,7 @@ Following is the usage and syntax for BitBake::
                            set/changed.
      -g, --graphviz        Save dependency tree information for the specified
                            targets in the dot syntax.
-     -u UI, --ui UI        The user interface to use (knotty, ncurses, taskexp,
+     -u, --ui UI           The user interface to use (knotty, ncurses,
                            taskexp_ncurses or teamcity - default knotty).
      --version             Show programs version and exit.
      -h, --help            Show this help message and exit.
@@ -443,11 +443,11 @@ Following is the usage and syntax for BitBake::
    Task control options:
      -f, --force           Force the specified targets/task to run (invalidating
                            any existing stamp file).
-     -c CMD, --cmd CMD     Specify the task to execute. The exact options
+     -c, --cmd CMD         Specify the task to execute. The exact options
                            available depend on the metadata. Some examples might
                            be 'compile' or 'populate_sysroot' or 'listtasks' may
                            give a list of the tasks available.
-     -C INVALIDATE_STAMP, --clear-stamp INVALIDATE_STAMP
+     -C, --clear-stamp INVALIDATE_STAMP
                            Invalidate the stamp for the specified task such as
                            'compile' and then run the default task for the
                            specified target(s).
@@ -471,8 +471,11 @@ Following is the usage and syntax for BitBake::
                            target that failed and anything depending on it cannot
                            be built, as much as possible will be built before
                            stopping.
-     -P, --profile         Profile the command and save reports.
-     -S SIGNATURE_HANDLER, --dump-signatures SIGNATURE_HANDLER
+     -P, --profile PROFILE
+                           Profile the command and save reports. Specify 'main',
+                           'idle' or 'parsing' to indicate which bitbake code to
+                           profile.
+     -S, --dump-signatures SIGNATURE_HANDLER
                            Dump out the signature construction information, with
                            no task execution. The SIGNATURE_HANDLER parameter is
                            passed to the handler. Two common values are none and
@@ -484,7 +487,7 @@ Following is the usage and syntax for BitBake::
                            expected)
      --revisions-changed   Set the exit code depending on whether upstream
                            floating revisions have changed or not.
-     -b BUILDFILE, --buildfile BUILDFILE
+     -b, --buildfile BUILDFILE
                            Execute tasks from a specific .bb recipe directly.
                            WARNING: Does not handle any dependencies from other
                            recipes.
@@ -499,22 +502,24 @@ Following is the usage and syntax for BitBake::
                            -D only affects output to stdout. All debug messages
                            are written to ${T}/log.do_taskname, regardless of the
                            debug level.
-     -l DEBUG_DOMAINS, --log-domains DEBUG_DOMAINS
+     -l, --log-domains DEBUG_DOMAINS
                            Show debug logging for the specified logging domains.
      -v, --verbose         Enable tracing of shell tasks (with 'set -x'). Also
                            print bb.note(...) messages to stdout (in addition to
                            writing them to ${T}/log.do_<task>).
      -q, --quiet           Output less log message data to the terminal. You can
                            specify this more than once.
-     -w WRITEEVENTLOG, --write-log WRITEEVENTLOG
+     -W, --warnings-as-errors
+                           Treat warnings as errors.
+     -w, --write-log WRITEEVENTLOG
                            Writes the event log of the build to a bitbake event
                            json file. Use '' (empty string) to assign the name
                            automatically.
 
    Server options:
-     -B BIND, --bind BIND  The name/address for the bitbake xmlrpc server to bind
+     -B, --bind BIND       The name/address for the bitbake xmlrpc server to bind
                            to.
-     -T SERVER_TIMEOUT, --idle-timeout SERVER_TIMEOUT
+     -T, --idle-timeout SERVER_TIMEOUT
                            Set timeout to unload bitbake server due to
                            inactivity, set to -1 means no unload, default:
                            Environment variable BB_SERVER_TIMEOUT.
@@ -529,11 +534,10 @@ Following is the usage and syntax for BitBake::
                            (cooker) process.
 
    Configuration options:
-     -r PREFILE, --read PREFILE
-                           Read the specified file before bitbake.conf.
-     -R POSTFILE, --postread POSTFILE
+     -r, --read PREFILE    Read the specified file before bitbake.conf.
+     -R, --postread POSTFILE
                            Read the specified file after bitbake.conf.
-     -I EXTRA_ASSUME_PROVIDED, --ignore-deps EXTRA_ASSUME_PROVIDED
+     -I, --ignore-deps EXTRA_ASSUME_PROVIDED
                            Assume these dependencies don't exist and are already
                            provided (equivalent to ASSUME_PROVIDED). Useful to
                            make dependency graphs more appealing.

-- 
2.55.0