[travis] Use Qt 5.7 #3400
[travis] Use Qt 5.7 #3400
Conversation
| @@ -21,5 +21,5 @@ export CCACHE_TEMPDIR=/tmp | |||
|
|
|||
| DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" | |||
|
|
|||
| xvfb-run ctest -V -E "qgis_openstreetmaptest|qgis_wcsprovidertest|$(cat ${DIR}/blacklist.txt | paste -sd '|' -)" -S ./qgis-test-travis.ctest --output-on-failure | |||
| # xvfb-run ctest -V -E "qgis_openstreetmaptest|qgis_wcsprovidertest" -S ./qgis-test-travis.ctest --output-on-failure | |||
| # xvfb-run ctest -V -E "qgis_openstreetmaptest|qgis_wcsprovidertest|$(cat ${DIR}/blacklist.txt | paste -sd '|' -)" -S ./qgis-test-travis.ctest --output-on-failure | |||
There was a problem hiding this comment.
wouldn't it be nicer to have blacklisted tests listed in a file rather than hard written in a command line?
i.e. keep the blakclist.txt file and move openstreetmap and wcs in the file
There was a problem hiding this comment.
We can do that once all others are ok to flag flaky tests (like these).
Until all tests are ok on Qt5 I'll occasionally run them all and copy paste the failing ones into blacklist.txt. In this case I don't want to take care of manually addiong osm and wcs tests.
There was a problem hiding this comment.
Speaking of flaky tests - I regularly see failures of the WFS tests on unrelated commits. Should these be blacklisted until the tests are made more robust?
There was a problem hiding this comment.
I think so, at least the failing bits. I realize myself that I start to ignore test results because of too many false alarms.
OgcUtils is also a candidate. CC @rouault
|
I wonder what's going on here. Travis gets a https://dash.orfeo-toolbox.org/viewBuildError.php?buildid=248994 This destructor has been dropped between Qt 5.6 and Qt 5.7. What I don't know is where this could still be declared, everything was built from Qt 5.7 source using the osgeo4travis scripts, so no trace of Qt 5.6 should be left, ccache has been cleaned before the test to avoid leftovers from previous builds on the travis infrastructure... If anyone has a pointer towards how to solve these issues, this would help greatly to finally get a test infrastructure with fixed rounding issues (and a recent gdal RC). |
|
I've struggled with building QGIS on 5.7 too. On Ubuntu I got a bunch of very cryptic errors within the qt headers themselves, which I couldn't find any mention of on any search. I know Nathan struggled with a 5.7 build (windows) too. I wonder if there's some remnant of the old qt4 stuff still hanging around in the cmake files somewhere which could be contributing to this... It's the only thing which jumps to mind. |
|
It worked for Android using the sdk downloaded directly from Qt with this cmake config. |
|
Finally working! Thanks to e9c4090 and a small missing fix for the pyqt resource generator! But, we've got a small problem with some tests: seems all our rendered images are one pixel higher than before... https://dash.orfeo-toolbox.org/viewTest.php?onlyfailed&buildid=251862 |
|
Whenever, we get this merged, shall we have a Qt 5.2 running on Travis as this is our requirement? |
Not sure, but I've been thinking we could bump the min to 5.3 since trusty is now unsupported (lack of Qca/QSci stuff) |
Hmmm... it's not just that. Check out https://dash.orfeo-toolbox.org/testDetails.php?test=48632817&build=251862 or https://dash.orfeo-toolbox.org/testDetails.php?test=48632837&build=251862 . Seems like something's change in how images are initialised... |
|
This is very odd - the images are definitely initialised, eg https://github.com/qgis/QGIS/blob/master/tests/src/core/testqgspainteffect.cpp#L336 |
|
Looking into this, I suspect the problem is QgsRenderChecker::drawBackground. That could account for the apparent 1 pixel shift in composition tests too. |
|
The tests qgis_painteffecttest and qgis_imageoperationtest pass with Qt 5.7 here locally (Fedora 25) |
No description provided.