pytest-sanic is incompatible with the current version of Sanic, see
sanic-org/sanic#2095 and yunstanford/pytest-sanic#50. While it is
broken, we also need it to run Sanic's tests (for which case it works
just fine).
* matrix-commander: init
* matrix-commander: cleanups & potential dep fixes
apply most SuperSandro2000's review comments;
used python3.withPackages -- this might be the correct
way to get runtime python dependencies to work even
when matrix-commander is a dependency of another packages
(as opposed to testing in nix-shell). I'm not sure though.
aiofiles seemed to be a missing runtime dependency when called
from another (nix-packaged, jvm-based) app -- there was an
import error without it.
cacerts might require explicit pinning, as described here:
https://gist.github.com/CMCDragonkai/1ae4f4b5edeb021ca7bb1d271caca999
(relevant snippet: wrapProgram $out/bin/program \
--set SSL_CERT_FILE "${cacert}/etc/ssl/certs/ca-bundle.crt"
)
* add runHook {pre,post}Install
(suggested by r-rmcgibbo)
* add link to github issue re gpl3{Only,Plus}
* Update pkgs/applications/networking/instant-messengers/matrix-commander/default.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
trollius is deprecated (by upstream) for more than five years,
all Python versions supported by trollius are end-of-life.
There are no more packages depending on trollius.
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
