Comment # 11 on bug 1157462 from Simon Lees

(In reply to Dr. Werner Fink from comment #10)
> (In reply to Simon Lees from comment #9)
> > (In reply to Dr. Werner Fink from comment #8)
> > > SR#752324 -- could one have a review? Other than me!
> > 
> > Sorry due to timezones I was done for Friday when you sent this, doing the
> > update was on my today list if I hadn't heard a good reason to keep
> > --enable-asserts. 
> > 
> > I this using --disable-asserts would be better then adding another patch,
> > its also now how debian handle it.
> > https://salsa.debian.org/utopia-team/dbus/blob/debian/master/debian/rules
> 
> The udeb_configure_flags rule with --disable-asserts  is used for the udeb
> packages and those type of packages are only for internal build system for
> debian packages.
> 
> The patch is also from debian (not utopia!)

Utopia is the team maintaining dbus within debian according to there
documentation, It can also be confirmed by the fact that almost all the commits
there are from debians dbus maintainer @smcv

> 
>  --- a/dbus/dbus-internals.c
>  +++ b/dbus/dbus-internals.c
>  @@ -185,7 +185,7 @@ const char *_dbus_no_memory_message = "Not enough
> memory";
>  
>   static dbus_bool_t warn_initted = FALSE;
>   static dbus_bool_t fatal_warnings = FALSE;
>  -static dbus_bool_t fatal_warnings_on_check_failed = TRUE;
>  +static dbus_bool_t fatal_warnings_on_check_failed = FALSE;
>  
>   static void
>   init_warnings(void)
> 
> could you please explain what is wrong with this approach? If you like to
> debug you are able to set the environment variable DBUS_FATAL_WARNINGS to 1.
> Currently we do not set DBUS_FATAL_WARNINGS at all, that is with the current
> default all customers and users out there do debugging their systems and do
> not know about nor can handle this.  This causes a lot of trouble and
> bugzilla entries.

Debian dropped this patch at the start of last year (see below), Red Hat
doesn't carry it (atleast centos) which makes me nervous being the only distro
using and testing the patch, it means that no one is really looking at what is
going on after the abort meaning there could end up being any form of data
corruption or security issues hiding after in failure code paths that no one is
testing. I wouldn't really be comfortable without going through and having a
good look at whats happening after. Currently I don't have time for that. 

  * d/p/debian/Don-t-abort-on-fatal-warnings-by-default.patch:
    Remove patch. This was committed not long after the addition of the
    fatal-by-default _dbus_warn_check_failed() checks for programming
    errors, with the changelog message "This will be set to upstream
    default again at some point so if you have an application that
    prints a DBus warning get it fixed".