infinite recursion was due to autoPatchelfHook being in buildInputs of
platform-tools, i will add a lint for it in nix-community/nixpkgs-lint.
```
$ nix build ".#pkgsCross.aarch64-android-prebuilt.hello" --show-trace 2>&1 | rg 'while evaluating the attr.+deriv'
… while evaluating the attribute 'stdenv' of the derivation 'zlib-aarch64-unknown-linux-android-1.2.13'
… while evaluating the attribute 'CPPFLAGS' of the derivation 'python3-aarch64-unknown-linux-android-3.10.8'
… while evaluating the attribute 'setuptools' of the derivation 'python-catch-conflicts-hook'
… while evaluating the attribute 'nativeBuildInputs' of the derivation 'python3.10-pyelftools-0.28'
… while evaluating the attribute 'passAsFile' of the derivation 'python3-3.10.8-env'
… while evaluating the attribute 'pythonInterpreter' of the derivation 'auto-patchelf-hook'
… while evaluating the attribute 'buildInputs' of the derivation 'platform-tools-33.0.2'
… while evaluating the attribute 'installPhase' of the derivation 'ndk-24.0.8215888'
… while evaluating the attribute 'installPhase' of the derivation 'aarch64-unknown-linux-android-ndk-toolchain-24.0.8215888'
… while evaluating the attribute 'bintools_bin' of the derivation 'aarch64-unknown-linux-android-ndk-toolchain-wrapper-24.0.8215888'
… while evaluating the attribute 'bintools' of the derivation 'aarch64-unknown-linux-android-ndk-toolchain-wrapper-24.0.8215888'
… while evaluating the attribute 'defaultNativeBuildInputs' of the derivation 'stdenv-linux'
… while evaluating the attribute 'stdenv' of the derivation 'hello-aarch64-unknown-linux-android-2.12.1'
```
stdenv -> stdenv.cc -> bintools -> android-ndk-toolchain -> ndk -> platform-tools -> auto-patchelf-hook -> python3 -> zlib -> stdenv -> stdenv.cc -> ...
autoPatchelfHook was in buildInputs of platform-tools so we needed the host tools to build
it but platform-tools was a required tool
Note: I DO NOT resign from nixpkgs, not at all!
However, I like a clean notification inbox and I get a lot of stuff for
packages where I'm only an end-user or don't use them anymore and thus
can't help out that much.
So please consider it a measure to reduce the mental load for me when
going through my notifications ;-)
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: src/host/usb-linux.c:82: multiple definition of `t_recovery_queue';
src/host/recovery.c:45: first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: ../ipsw-patch/libxpwn.a(libxpwn.c.o):(.bss+0x4): multiple definition of
`endianness'; CMakeFiles/xpwn-bin.dir/src/xpwn.cpp.o:(.bss+0x0): first defined here
This is supposed to fix an issue caused by this PR:
https://github.com/NixOS/nixpkgs/pull/163924
Which made `autoPatchelfHook` available only on Linux, resulting in
builds of Android packages failing with:
```
error: Package ‘auto-patchelf-hook’ in /nix/store/...-nixpkgs-source/pkgs/build-support/trivial-builders.nix:73
is not supported on ‘x86_64-darwin’, refusing to evaluate.
```
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Currently trying to run Genymotion on Plasma 5 fails at all, Genymotion
itself complaining about libqtquickcontrols2materialstyleplugin.so using
"incompatible Qt library".
As it turns out, this package ships its own
version of Qt but does not ignore any environment variables related to
Qt, which results in Genymotion's Qt using (apparently incompatible)
QML plugins from user's system. This can be fixed quite easily by
unsetting `QML2_IMPORT_PATH` in a wrapper, which this patch does.
There might be more such problems, but I haven't encountered them yet,
so fixing those will be up to someone else ;)
The last repo.json update in a0f6a8af81 removed the default emulator version, so it had to be changed (or the repo.json had to be overwritten) for it to work.
Instead use the most recent available emulator version
