From https://docs.docker.com/engine/reference/run/:
```
When the operator executes docker run --privileged, Docker will enable
access to all devices on the host as well as set some configuration in
AppArmor or SELinux to allow the container nearly all the same access to
the host as processes running outside containers on the host.
```
Regards https://github.com/profanity-im/profanity/issues/1294
Some users might want there nick to always stay white (etc) for easier
recognition.
Now we can do `/color own off` to not generate the color based on
xep-0392. The `me=` color (etc) from the theme will then be used.
Once we run this command `theme_load()` is called again.
And the theme looks totally wrong.
We encountered this at other times already and I think it's nothing
wrong with this new code here now but that there seems to be a missing
closing attr for the color when drawing.
Should be investigated seperately.
Fix https://github.com/profanity-im/profanity/issues/1288
Most clients have them enabled by default already for a smoother modern XMPP experience.
Enable by default: allowing message corrections, sending of read
receipts, enabling carbons, typing/chat states.
If users input strange stuff and we can't create a jid from it even the
setting is set to 'user' we still should fallback to the regular
identifer.
For example with `/msg @name%matrix.domain.org@matrix.org hi`.
win_println_incoming_muc_msg() always used the current time. Now let's
use whatever is sent int he message struct (from the delay stanza or
the current time that we set now once the message is received).
No playing with the time upon display anymore.
I suspect this was just a copy paste error.
`_win_create_simple_layout()` is called in other creation functions like
`win_create_config()` or `win_create_private()`.
I suspect when `win_create_muc()` was created it was just copied. But in
this function we actually set the layout ourself later.
So calling the function isn't needed.
Regards https://github.com/profanity-im/profanity/issues/1279
The memory leak happens when a presence is received for a MUC room. The
JID is not present in the roster, so updating its status is ignored. We
have to free resource in this case, because it has no owner and is lost
otherwise.
==25736== 47 (32 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 1,625 of 3,399
==25736== at 0x4A330FF: malloc (vg_replace_malloc.c:309)
==25736== by 0x13A962: resource_new (resource.c:47)
==25736== by 0x145501: _available_handler (presence.c:665)
==25736== by 0x145501: _presence_handler (presence.c:399)
==25736== by 0x145501: _presence_handler (presence.c:358)
==25736== by 0x80D5F34: handler_fire_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80D2B49: _handle_stream_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80E15CE: _end_element (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x843EE9B: doContent (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x843F94B: contentProcessor (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x8441E77: XML_ParseBuffer (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x80D586B: xmpp_run_once (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x13E07E: connection_check_events (connection.c:119)
==25736== by 0x13869C: prof_run (profanity.c:129)
Fixes#1279.
