`use_libevent` config option has been deprecated as there are 3
networking back-ends (see: https://prosody.im/doc/network_backend). It
is probably unwise to stray from the defaults (epoll).
Review instructed to flat-out remove it versus previously making it opt-in.
See https://blog.prosody.im/prosody-0.12.0-released for more
informations.
We remove the various lua wrappers introduced by
6799a91843 and
16d0b4a69f. It seems like we don't need
them anymore. I'm not brave enough to dig into the Lua machinery to
see what resolved that. Sorry, you'll have to trust me on that one.
We should probably think about the migration from http_upload to
http_file_share for the NixOS module. It's not trivial, we need to
make sure we don't break the already uploaded URLs.
Setting up a XMPP chat server is a pretty deep rabbit whole to jump in
when you're not familiar with this whole universe. Your experience
with this environment will greatly depends on whether or not your
server implements the right set of XEPs.
To tackle this problem, the XMPP community came with the idea of
creating a meta-XEP in charge of listing the desirable XEPs to comply
with. This meta-XMP is issued every year under an new XEP number. The
2020 one being XEP-0423[1].
This prosody nixos module refactoring makes complying with XEP-0423
easier. All the necessary extensions are enabled by default. For some
extensions (MUC and HTTP_UPLOAD), we need some input from the user and
cannot provide a sensible default nixpkgs-wide. For those, we guide
the user using a couple of assertions explaining the remaining manual
steps to perform.
We took advantage of this substential refactoring to refresh the
associated nixos test.
Changelog:
- Update the prosody package to provide the necessary community
modules in order to comply with XEP-0423. This is a tradeoff, as
depending on their configuration, the user might end up not using them
and wasting some disk space. That being said, adding those will
allow the XEP-0423 users, which I expect to be the majority of
users, to leverage a bit more the binary cache.
- Add a muc submodule populated with the prosody muc defaults.
- Add a http_upload submodule in charge of setting up a basic http
server handling the user uploads. This submodule is in is
spinning up an HTTP(s) server in charge of receiving and serving the
user's attachments.
- Advertise both the MUCs and the http_upload endpoints using mod disco.
- Use the slixmpp library in place of the now defunct sleekxmpp for
the prosody NixOS test.
- Update the nixos test to setup and test the MUC and http upload
features.
- Add a couple of assertions triggered if the setup is not xep-0423
compliant.
[1] https://xmpp.org/extensions/xep-0423.html
luaPackages replaced by generated ones:
- bit32
- compat53
- cqueues
- luacyrussasl -> cyrussasl (luarocks name)
- luaexpat
- luadbi -> luadbi front-end module + separate backend modules
luadbi-{mysql,postgresql,sqlite3}
- luafilesystem
- luaossl
- luasec
- luasocket
- luastdlib -> stdlib (luarocks name)
- lrexlib -> lrexlib-pcre (we already have lrexlib-gnu and
lrexlib-posix, lrexlib-pcre however appears to be the variant used in
mudlet, which is the only current dep in nixpkgs)
- luasqlite -> luasql-sqlite3 (luarocks name)
- lfs -> luafilesytem (we literally had two manually written
luafilesystem expressions, under different names)
Changes and additions to overrides to generated luarocks packgaes,
including:
- busted: Install bash completions along with the zsh ones
- cqueues:
- Perform minor surgery on the rockspec to allow using a single
rockspec to build for all supported Lua versions
- Add a patch by @vcunat to work around a build issue
- luuid: Wrote a tiny patch to allow for Lua 5.1/Luajit compatibility
- General changes:
- Sorted the packages
- Attempted to make the formatting consistent
- Preferenced `.override` instead of `.overrideAttrs` wherever
possible
Minor changes to other packages to adjust for the Lua package changes:
- luakit expression simplified
- prosody expression simplified; but users will now need to specify the
luadbi backend module they intend to use in withExtraLibs
- knot-resolver inputs correctd
- mudlet inputs corrected (although this package was and should still be
broken)
After the latest automatic updates of the prosody package the community
modules were partially incompatible. The worst effect I suffered was a
very high timeout (hours) on reconnects due to the stanza module throwing a
runtime error on the server.
We should probably try harder to keep them in sync.
* treewide: http -> https sources
This updates the source urls of all top-level packages from http to
https where possible.
* buildtorrent: fix url and tab -> spaces
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/prosody/versions.
These checks were done:
- built on NixOS
- /nix/store/9vcfnh0ghw9qmljbmpb52l5xwq8b8k4i-prosody-0.10.1/bin/prosody passed the binary check.
- Warning: no invocation of /nix/store/9vcfnh0ghw9qmljbmpb52l5xwq8b8k4i-prosody-0.10.1/bin/prosodyctl had a zero exit code or showed the expected version
- /nix/store/9vcfnh0ghw9qmljbmpb52l5xwq8b8k4i-prosody-0.10.1/bin/.prosody-wrapped passed the binary check.
- Warning: no invocation of /nix/store/9vcfnh0ghw9qmljbmpb52l5xwq8b8k4i-prosody-0.10.1/bin/.prosodyctl-wrapped had a zero exit code or showed the expected version
- 2 of 4 passed binary check by having a zero exit code.
- 0 of 4 passed binary check by having the new version present in output.
- found 0.10.1 with grep in /nix/store/9vcfnh0ghw9qmljbmpb52l5xwq8b8k4i-prosody-0.10.1
- directory tree listing: https://gist.github.com/e1e8caae1a498d8e07f1c35d990846d3
- du listing: https://gist.github.com/9b3a9c7a8711da781e548e894e848cdc