Manual rebuild for python310

[h-vetinari]

The migrator seems to have gotten stuck in resolving this somehow. See how far we get manually.

Edit: migrator came by after all: Closes #105

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

@wolfv This looks like a bit of a weird resolver error:

RuntimeError: Solver could not find solution.Mamba failed to solve:
 - [...]
 - qt 5.12.5.* h1b46049_0
 - [...]
 - pyqt-impl 5.12.3.* py39he44290a_8

The reported errors are:
- Encountered problems while solving:
-   - package pyqt-impl-5.12.3-py39he44290a_8 requires qt >=5.12.9,<5.13.0a0, but none of the providers can be installed

In particular, I don't understand why pyqt-impl sometime pulls in qt 5.12.5 instead of 5.12.9 (but even then the runtime req should be >=5.12.5, not >=5.12.9). In any case, forcing the host dep to be up to date fixes it (see CI for last 2 commits).

[h-vetinari]

@conda-forge/pyqt - aside from the long runtime on aarch (same as before), I think this should ready. Not sure why things didn't work without the last commit, happy to adapt if necessary, but I don't think it's bad per se.

[h-vetinari]

Hm, seems cross-compilation needs more work. I suggest to tackle it after the 3.10 migration; will remove the last two commits again.

[h-vetinari]

From the CI in #105 (of the cross-compile commits now cherry-picked here):

import: 'PyQt5.sip'
import: 'PyQt5.QtCore'
import: 'PyQt5.QtGui'
Traceback (most recent call last):
  File "/home/conda/feedstock_root/build_artifacts/pyqt_split_1636582680613/test_tmp/run_test.py", line 8, in <module>
    import PyQt5.QtGui
ImportError: libXext.so.6: cannot open shared object file: No such file or directory

Do we need {{ cdt('libxext-devel') }} as a host dep on aarch, or what's happening here (since it was working in emulation...)?

[h-vetinari]

Got further now; still failing though:

+ DISPLAY=localhost:1.0
+ xvfb-run -a bash -c 'python pyqt_test.py'
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: minimal, offscreen, vnc, webgl, xcb.

/usr/bin/xvfb-run: line 181: 11484 Aborted                 (core dumped) DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1

[h-vetinari]

Unfortunately, the xcb error remains:

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.

[github-actions[bot]]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: failed

Thus the PR was not passing and not merged.

[h-vetinari]

@isuruf @ocefpaf I realised this still has an automerge-label on it. It's perhaps better to remove this for now, because I don't claim that my debugging of the cross-compilation - even though it might lead to green CI - is necessarily correct.

[h-vetinari]

@isuruf, I'm playing a very trivial form of whack-a-mole here. If there's a more systematic way to add the requirements (e.g. all the libX for which there are cdt's in the host reqs), then I'm happy to do it. Right now I'm trying to not add more than necessary, hence the slow iterations.

[h-vetinari]

Seems I whacked all the moles by now! 😅 PTAL if the yum_requirements-approach is correct @isuruf

[ocefpaf]

LGTM now :-) Merge?

[jschueller]

go!