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
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
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)
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
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.
ejabberd switched from imagemagick to eimp, which loads libpng, libjpeg
and libwebp at runtime. These were therefore added as dependencies and
the relevant binary was wrapped to be able to find them.
* 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
unix-tools.nix has a collection of tools that are commonly installed
by default in Unix derivatives. This is intended to provide
compatibility between macOS and Linux users. Three Linux-only
derivations are provided for compatbility:
- procps
- utillinux
- nettools
More tools are also provided.
Also: treewide: use unixtools
Non-comprehensive replace of Linux-only procps and util-linux with
'unixtools'.
Semi-automatic update. These checks were done:
- built on NixOS
- ran `/nix/store/ng1gidmaivbb5ngd4awq6wgraa55yjd5-biboumi-7.2/bin/biboumi --help` got 0 exit code
- found 7.2 with grep in /nix/store/ng1gidmaivbb5ngd4awq6wgraa55yjd5-biboumi-7.2
- found 7.2 in filename of file in /nix/store/ng1gidmaivbb5ngd4awq6wgraa55yjd5-biboumi-7.2
* biboumi: init at 6.1
TODO: integrate config in NixOS
* biboumi: remove external buildtime dep
- fetch catch.hpp in a reproducible way
- add maintainer
- enable tests
- remove git dep
- enable parallel building
- add pandoc dep for man page
- nitpicks
* biboumi: refine substitutions
- only CMakeLists.txt has to be patched regarding /etc/biboumi
- substitute /bin/kill in systemd service file
- prepare for configuring policy_directory in a future cfg file
Andreas Rammhold