The recently released 0.10.0 doesn't seem to have any actual changes but
has new dependencies which broke the previously working builds.
See #23800.
(cherry picked from commit 55c704a1b404bb302f2fb0a8d9589ab841fcfc92)
Use the key code corresponding to the key in the US keyboard layout for
the key down/up events even when not actually using US layout, as this
is much more useful than simply returning 0 as was done before.
It also is compatible with the behaviour of the other ports.
See #17643, #23379, #23410.
(cherry picked from commit 2c0f6a2aa0c8d0650d1f856aa279ce7495925c17)
Correct path for x64 wxrc.exe file which prevented it from being
included in the vc14x_x64_Dev archive.
See #23122.
(cherry picked from commit 70667fc8ab012fc4ab63d187062e5a28834dc5fc)
Now that we don't use Travis CI any longer (and don't use httpbin on the
other CI providers yet), we can make our life much simpler by just using
Python 3.10 on all platforms instead of trying to find version-specific
workarounds for various python/pip/httpbin incompatibilities.
Closes#22726.
(cherry picked from commit 458dc814c241066323858182e55d2186d396c09d)
This is a backport of the following commits from master:
934aa20d69 Build and run tests on Circle CI too
9f1bf3982d Install RPM required for Shift-JIS support in Fedora
64aefb5f4e Install locales used by the tests under Fedora
84120664ca Make Circe CI script more consistent with Cirrus CI
bf3951866c Install Git before checking out the sources
3eb78a328e Use ccache in Circle CI job
e63fe497ab Install more optional libraries under Fedora
a527b2714d Allow installing extra packages in before_install.sh
b430a6104c Add a minimal Fedora build using Circle CI
382db6439b Install required packages on RedHat-like systems
Installing this package directly fails because of a conflict between one
of its dependencies and the already installed libc++-dev which depends
on another, incompatible, version of the same library.
Work around this by installing libunwind-dev directly, which is enough
to make apt uninstall libc++-dev and libunwind-14-dev that it depends on
instead of just stopping with an error.
It's not really clear how are we supposed to use clang with libc++ in
this environment, but this at least allows to build with gcc.
CONFIG mode uses the <packageName>_DIR variable.
CMake has an error when generating the solution because the
lib/vc_x64_dll/mswud directory does not exist; it is not built and installed.
So only add the used configuration.
They're not handled by the current 7z version under MSW if the user
doesn't have administrative rights and, instead of dealing with this,
it's simpler to just never include any symlinks in the archives as we
don't really need them anyhow.
So add a check ensuring that no symlinks are included in the
distribution archives to avoid more problems such as the one fixed in
the parent commit in the future.
The default httpbin listening port 5000 is used by Monterrey (macOS 12)
Control Center for its own needs, so use another port to avoid conflicts
with it and the resulting failures when running wxWebRequest unit tests
under this macOS version.
Fix the last known working Flask version, the latest one results in the
errors like the following
Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 185, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "/usr/lib/python3.8/runpy.py", line 111, in _get_module_details
__import__(pkg_name)
File "/home/runner/.local/lib/python3.8/site-packages/httpbin/__init__.py", line 3, in <module>
from .core import *
File "/home/runner/.local/lib/python3.8/site-packages/httpbin/core.py", line 22, in <module>
from werkzeug.wrappers import BaseResponse
ImportError: cannot import name 'BaseResponse' from 'werkzeug.wrappers' (/home/runner/.local/lib/python3.8/site-packages/werkzeug/wrappers/__init__.py)
It seems like this function sometimes doesn't return non-zero exit code
even though it fails to fetch some packages (e.g. due to a network
error), so log its status code to check if this is really the case.
This is needed since GitHub CI images update to windows-2022 base image,
which notably changes Python version from 3.7 to 3.9 and requires
building wheels for some of the packages not available on PyPI for this
version.
Closes#22091.
libwebkitgtk-3.0-dev is long deprecated and isn't used anyway.
gstreamer-0.10* no longer exists even on Ubuntu 18.04.
gstreamermm* is not used by wxWidgets.
Closes#22069.
This is not necessary any longer since the changes of 1b76ff4887
(Disable wxWebRequest tests on CI platforms without Python 3,
2021-05-16) as we require Python 3 for httpbin anyhow.
This currently means macOS 10.11 only, which is only used on Travis CI
and Python 2 installation there is broken anyhow, so this doesn't make
anything worse than it already is.
Python package hosting seems to randomly decide which version of the
package to return to pip running under Trusty: in addition to werkzeug
(see last commit), the version of flask has spontaneously changed from
1.0 to 1.2 in the latest build too.
Just hardcode the versions of all dependencies in the last successful
build and hope they keep working for longer than a day.
Crazily, pip installs seem to be non-deterministic as installing httpbin
in https://travis-ci.org/github/wxWidgets/wxWidgets/jobs/765946720
pulled in werkzeug 0.16.1 which works with Python 3.4, but doing it
again tries to use werkzeug 1.x which isn't.
Fix the version explicitly to work around this.
Trying to use Python 2 under Trusty is hopeless, as pythonhosted.org has
already started dropping support for non-SNI clients and will drop it
completely soon, see https://status.python.org/incidents/hzmjhqsdjqgb
and https://github.com/pypa/pypi-support/issues/978, and SNI is not
available in the system Python 2 version (2.7.6, which is less than
2.7.9 in which it was added).
Note that we still can't use Python 3 everywhere as long as we have
macOS 11 builds as it's not available there.
