continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
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.
