On modern networks, account names are usually separated from your current nick,
so the idea of registering "nicks" is confusing. For instance, you can be using
a grouped nick that is not your main account name, and WHOIS will only ever
show your main account name.
Also, the bot username is optional in the `add` and `remove` commands - update
the docs to reflect that.
self.value should be the deserialized value (because we set
'self.value = default' in registry.close()), so
setValue()/__call__() should return it as-is.
Doing otherwise failed serialization of the default, and crashed
with the same error as in https://github.com/progval/Limnoria/issues/1604
since 8ec873015aac3ba4193a2d498eb294975615b296
We recently got a bug report from someone running Limnoria in Docker, and it turned
out that a plugin's import was segfaulting and Docker silently restarted the process.
I wasted some time figuring out what happened because I didn't notice the process
was being restarted. This should make this more noticeable in the future.
gettext: locales/ru.po:1922: 'msgid' and 'msgstr' entries do not both begin with '\n'
locales/ru.po:1935: 'msgid' and 'msgstr' entries do not both begin with '\n'
msgfmt: found 2 fatal errors
gettext: plugins/Anonymous/locales/ru.po:101: 'msgid' and 'msgstr' entries do not both begin with '\n'
msgfmt: found 1 fatal error
gettext: plugins/NickAuth/locales/ru.po:29: 'msgid' and 'msgstr' entries do not both begin with '\n'
msgfmt: found 1 fatal error
gettext: plugins/PluginDownloader/locales/ru.po:84: 'msgid' and 'msgstr' entries do not both begin with '\n'
msgfmt: found 1 fatal error
Signed-off-by: Mattia Rizzolo <mattia@mapreri.org>
Most commands are decorated with @internationalizeDocstring then with wrap().
wrap() itself calls internationalizeDocstring(), so that plugins
wrapping with @internationalizeDocstring() is now optional; but many
still do it.
This means that docstrings went twice through the
_PluginInternationalization.
This fixes the bug that on the second run, it would try to translate
again the translated message, which fails (because the translated
message is not in English); and then fell back to the original string
(which is in English).
This commit changes the behavior to return the already-translated string
directly instead.
When the first of the two conflicts comes from a transient hostmask set by NickAuth,
the first value in the 'ids' dict would be True, which causes a silly log message,
then Limnoria silently crashes to self.users[id].removeHostmask(hostmask) and then
does not remove the next hostmask which is responsible for the conflict.
1. Display the key itself (in addition to the values), because
searching factoids makes little sense without returning the key
2. Display only matching values, instead of all other values,
because some filters act on values
This allows overriding supybot.reply.mores.instant for private messages, where
it is usually more tolerable to send multiple lines.
However, this still defaults to 1, in order to not be abusable by default.
I can't open .prof files created with 'profile' using pyprof2calltree:
```
Traceback (most recent call last):
File "/home/val/.local/bin/pyprof2calltree", line 8, in <module>
sys.exit(main())
^^^^^^
File "/home/val/.local/lib/python3.11/site-packages/pyprof2calltree.py", line 339, in main
kg = CalltreeConverter(pstats.Stats(args.infile))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/val/.local/lib/python3.11/site-packages/pyprof2calltree.py", line 178, in __init__
self.entries = pstats2entries(profiling_data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/val/.local/lib/python3.11/site-packages/pyprof2calltree.py", line 135, in pstats2entries
cc, nc, tt, ct = call_info
^^^^^^^^^^^^^^
TypeError: cannot unpack non-iterable int object
```
This only happens on the newly introduced account extban (in case the user
does not have an account, or the server does not provide accounts)
so this does not change existing behavior.
Falling back to the host instead of the exact mask makes it less easy
to evade these bans
When a password is added for a nick that is not a valid config entry name,
this causes _getNickServPassword to raise an error; and __call__ needs
to catch it or the bot becomes unusable.
