Update to v2.10.8

[dschreij]

Checklist

• [x] Used a fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

[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.

[dschreij]

@conda-forge/core I need some help with this update... Is there any place I can go with questions (the google group?). The current status of this build:

• The windows builds fail because of 1) syntax errors for py27 2) unsatisfiable dependencies for py36 and py37, which is weird because everything should be available.
• The Mac builds fail because of a segfault during the building of the python bindings, but that can be expected because I think the paths passed to configure.py may be erroneous; If I build the package locally on my mac using the same script as build.sh in a manually created conda env, then there's no problem and the build script completes just fine.

Is this still correct for MacOS, pathwise?

CONDA_BIN=$PREFIX/bin
QT_MAJOR_VER=`qmake -v | sed -n 's/.*Qt version \([0-9])*\).*/\1/p'`
BUILD_SPEC=macx-clang
...
$PYTHON configure.py --pyqt=PyQt${QT_MAJOR_VER} --sip=${CONDA_BIN}/sip --qsci-incdir=${PREFIX}/include/qt --qsci-libdir=${PREFIX}/lib --spec=${BUILD_SPEC} --no-qsci-api

• Still waiting for the Linux builds, although they first quit on the build number being < 1000, while the checklist of this PR states the build number should be reset to 0 for new versions ;)

UPDATE: Some linux builds fail because of unsatisfiable dependencies (as with Windows), while others fail because of a segfault (as with the Mac build).

[CJ-Wright]

You can always go to the gitter with questions: https://gitter.im/conda-forge/conda-forge.github.io The number should not be reset to 0, the 1000 is there to allow the gcc7 packages to take precedence when we merge the labels.

I'm not certain why those are unavailable, they are up on anaconda.org. https://anaconda.org/conda-forge/pyqt/files https://anaconda.org/conda-forge/sip/files

[dschreij]

@CJ-Wright thanks for your reply. The linux builds failed with a message of only allowing legacy builds with build numbers below 1000, but I can reset the build number to 0 again if that is the convention. I will ask around on gitter to see if someone can get me on track, but otherwise I will have to leave this build attempt for now, and will probably pick it up again somewhere in the near future.

[dschreij]

@conda-forge/core this package need to built against the Qt versions on pkgs/main or anaconda channels. Qt and sip are present with higher versions there (5.9.7 and 4.19) compared to conda-forge (5.6.2 and 4.18). QScintilla 2.10 requires a sip version higher than 4.18, thus can't be built with the packages present on conda-forge. How can I proceed? Is there any chance that the Qt packages (en related) on conda-forge will also be updated to newer versions in the very near future?

[dschreij]

@conda-forge/core. Any updates on the timeline with which newer PyQt versions will become available on conda-forge? I'm curious to why it has been stuck at 5.6 for such a long time, while the main repo has 5.9 already. I'd really love to update this package.

[jakirkham]

Would encourage you to engage with the pyqt maintainers directly and see if there is anyways to move that effort forward.

[dschreij]

@jakirkham thanks for the reply. I've checked the qt and pyqt repositories, and namely the first shows that a lot of work is being done to get qt to 5.12, but that it's very challenging. It's just a matter of patience then, so I'll keep in eye on the progress they make and will work on this after they release the newer qt versions.

[dschreij]

@jakirkham I did read something about setting a strict flag, which would allow conda-forge builds to fetch libraries from anaconda, but I guess that won't do anything here, since the qt packages are also available on conda-forge and thus will have precedence. Or will pinning a version that is not available on conda-forge allow the qt packages to be fetched from anaconda? I just want to check if the build succeeds or needs some more work.

[conda-forge-linter]

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

I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[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.

[dschreij]

@conda-forge/core @ocefpaf I'm trying to upgrade this package, and appear to be succeeding for all platforms except python 2.7 on Windows. There are unsatisfiable dependencies there:

conda.exceptions.UnsatisfiableError: The following specifications were found to be in conflict:
  - qt=5.9 -> vc[version='>=14.1,<15.0a0']
  - vc=9

I do not explicitly state to use vc9, so I guess conda build does this implicitly. Could you help me out with this? I also remember reading the pyqt maintainers to have trouble building their package for Windows python 2.7 and that they were advised to just skip it, but I can't find the reference anymore. Do I remember reading this correctly and does this also apply for this package?

[dschreij]

@conda-forge/core The builds now pass, but I do have a couple of questions:

• Like the pyqt maintainers, I skipped builds for Windows Python 2.7. Is this the correct decision? I guess these are no longer possible since Qt does not support VS2008 any longer?
• I had to add a hacky section, just like pyqt to let Linux find g++. It was not automatically found by the spec or the environment. Please let me know if this is the right way to go (for now), or if this should be solved differently.