ZNC 1.6.0 fails to start when the config file loads awaynick and then simple_away later on because the module is already loaded. Looks identical to the second report here: https://github.com/znc/znc/pull/663#issuecomment-57011375
awaynick automatically loads simple_away instead in 1.6.0. I'd expect it to either not automatically load a different module than requested (just have it do nothing) or ignore the second simple_away load because the first wasn't user-requested.
My two cents are that loading an altogether different module than requested is overzealous. Either ignore the LoadModule or fail outright, this feels like a half-baked compromise to make the awaynick removal easier to swallow, especially when it breaks otherwise-good configs. (This wasn't my config and I have no love for awaynick, kill it with fire.)
ZNC 1.6.0 fails to start when the config file loads awaynick and then simple_away later on because the module is already loaded. Looks identical to the second report here: https://github.com/znc/znc/pull/663#issuecomment-57011375
awaynick automatically loads simple_away instead in 1.6.0. I'd expect it to either not automatically load a different module than requested (just have it do nothing) or ignore the second simple_away load because the first wasn't user-requested.
My two cents are that loading an altogether different module than requested is overzealous. Either ignore the LoadModule or fail outright, this feels like a half-baked compromise to make the awaynick removal easier to swallow, especially when it breaks otherwise-good configs. (This wasn't my config and I have no love for awaynick, kill it with fire.)
<!-- github-sync-id:71443216 -->
Hm, this case was especially handled...
Please paste the relevant parts of config, e.g. what is in User, what is in Network
Hm, this case was especially handled...
Please paste the relevant parts of config, e.g. what is in User, what is in Network
<!-- github-comment-id:96955255 -->
Ignoring LoadModule isn't very good, because user could compile awaynick.so and put to the right place manually, as an external module. In such case ZNC shouldn't prevent user from loading it.
Ignoring LoadModule isn't very good, because user could compile awaynick.so and put to the right place manually, as an external module. In such case ZNC shouldn't prevent user from loading it.
<!-- github-comment-id:96955602 -->
Looks like it can still fail under certain circumstances: http://paste.thezomg.com/18344/14408714/ (running latest from git).
<!-- github-comment-id:136021124 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
ZNC 1.6.0 fails to start when the config file loads awaynick and then simple_away later on because the module is already loaded. Looks identical to the second report here: https://github.com/znc/znc/pull/663#issuecomment-57011375
awaynick automatically loads simple_away instead in 1.6.0. I'd expect it to either not automatically load a different module than requested (just have it do nothing) or ignore the second simple_away load because the first wasn't user-requested.
My two cents are that loading an altogether different module than requested is overzealous. Either ignore the LoadModule or fail outright, this feels like a half-baked compromise to make the awaynick removal easier to swallow, especially when it breaks otherwise-good configs. (This wasn't my config and I have no love for awaynick, kill it with fire.)
Hm, this case was especially handled...
Please paste the relevant parts of config, e.g. what is in User, what is in Network
Ignoring LoadModule isn't very good, because user could compile awaynick.so and put to the right place manually, as an external module. In such case ZNC shouldn't prevent user from loading it.
I can reproduce the problem with a combination of user-level LoadModule=simple_away and network-level LoadModule=awaynick.
Looks like it can still fail under certain circumstances: http://paste.thezomg.com/18344/14408714/ (running latest from git).