Regressed in c2210539a9e2be1deacf8df8f432e035d9b9b9f0:
The current NSIS installer still adds the suffix. Let's keep it there for now
until we switch to the rewritten one.
See #6050
The Qt docs for 6.5 say that the minimum supported version is Windows 10
1809.
Experimentally it seems qutebrowser and it's dependencies work fine on a
version as early 1607.
There should be no change in OS version requirements for the Qt5 build,
although we've dropped 32 bit support already and in a future version of
the installer we may bring the minimum OS version support in line with
the Qt6 requirements for simplicity too.
Added a new QT5 version into the NSIS scripts so we can do the different
version check per installer build. It just uses the python bool
serialization format so should always be "True" or "False", but I've
added a fallback anyway for consistency.
In the past various workarounds have been put in place to move/copy/symlink
files in the macOS app build to make PyQt work and let us sign it.
As of https://github.com/pyinstaller/pyinstaller/pull/7619 our downstream
patching should not be required.
The application seems to run fine.
The app size is 155 MB.
Signing is still to be verified.
git ls-files | \
xargs grep -l "This file is part of qutebrowser" | \
xargs grep -l SPDX-License-Identifier | \
xargs sed -i '/# This file is part of qutebrowser\./,/along with qutebrowser\. If not, see <https:\/\/www\.gnu.org\/licenses\/>./d'
Right now the version of PyQT available on PyPI is 6.5.1 and it's buggy with
Qutebrowser, this is a quick hack to get it working until it's released early next week.
We're deprecating vim modelines in favor of `.editorconfig`.
Removing vim modelines could be done using two one-liners. Most of the vim modelines
were followed by an empty line, so this one-liner took care of these ones:
```sh
rg '^# vim: .+\n\n' -l | xargs sed -i '/^# vim: /,+1d'
```
Then some of the vim modelines were followed by a pylint configuration line, so running
this one-liner afterwards took care of that:
```sh
rg '^# vim:' -l | xargs sed -i '/^# vim: /d'
```
Since Archlinux upgraded to Python 3.11, we need to downgrade Python
to 3.10 too, and install tox via pip instead.
This starts becoming somewhat questionable, but if this approach still
does indeed work, let's go for it.
Although we updated the tox requirements files for tox4 in December, it
looks like the docker containers (or at least the one(s) that call this
script) are still using tox3. `.tox-config1` isn't written anymore with
tox4 (although my git-fu isn't strong enough to find the commit that
removed it).
The "Rebuild Docker CI images" run 912 was the last to have tox 3.26.0-2
and run 913 had version 4.4.12-1.
I'm not sure the new change does the same thing as whatever the old code
did. I honestly have no idea why we can't just follow the python symlink
and have to go to a config file. In what case does the python binary not
link to the system one?
In addition to this `.tox-info.json` file there is also the more
standard `pyvenv.cfg` file. I would prefer to use that over the tox
thing as generally I find tox to be a high barrier of entry for
contributors. But in that case the pyvenv one doesn't seem to be well
documented either...
Anyway, if anyone knows any cases where following the symlink of the
python in the venv isn't reliable that would be great. Because that
seems like the simpler method.
Pin Flask and Werkzeug for py3.7
They've removed compatibility upstream.
Added example to readme file because I had to go dig for one in the
commit history.
Add blinker to changelog URLs as it's a required dependency of Flask
now.
Looks like we have some failing smoke tests with:
[6636:16643:0329/041427.206197:ERROR:command_buffer_proxy_impl.cc(141)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
On CI were were getting "Could not import sip" because link_pyqt was
looking for PyQt5.sip.
I made that look at QUTE_QT_WRAPPER since that's being set already on
tox.ini
There are probably a few other changes around link_pyqt and the makefile
etc we need to change when we switch the default wrapper.
I overrode the default `py` tox environment with py-qt6 to override
those wrapper related variables. I probably could have done something
sneaky with curly braces to make it so we don't have to add a few more
lines to the file. But in my opinion in config file is far to obfuscated
and hard to maintain already.
I changed the docker file to call the new py-qt6 env if it's a qt6
container. I'm not 100% sure that is required though since there is also
a tox invocation in the GH action definition, maybe that overrides the
container entrypoint? Also changed the indentation in the dockerfile
template a bit to make it easier to see where the conditionals start and
end.
Speaking of which I changed the matrix definition and tox invocation to
match a later one to hopefully make it so we can invoke different tox
environments in the containers without having to rebuild the containers.
Not sure I did that right, I'll see soon.
I added the unstable-qt6 container generation line so we can use it in
the future, and to match the not-qt6 one. I'm not switching to that in
CI though because the pyqt used by that is broken at the moment
(ref https://www.riverbankcomputing.com/pipermail/pyqt/2023-March/045214.html)
Also fixed the vim modeline in generate.py so my syntax highlighting
works.
In doc/help/index.asciidoc, we have links like this:
* link:../quickstart{outfilesuffix}[Quick start guide]
That is correct in e.g. the GitHub file structure, as those files are
stored in e.g. doc/quickstart.asciidoc indeed.
It's *no* longer true when we view the built files via qute://help,
however: There, this turns into a flat file structure, with those pages
being at qute://help/index.html and qute://help/quickstart.html,
respectively.
It looks like QtWebEngine < 6.5 did just ignore the
<a href="../quicktart.html"> and pointed from qute://help/index.html to
qute://help/quickstart.html anyways, weirdly.
With QtWebEngine 6.5, however, this is now interpreted as a link
pointing to qute://quickstart.html instead, which is clearly wrong.
Until we have a less messy doc generation (probably as part of #345),
let's just patch the link to be correct.
See #7624
Mostly pretty lazy fixes. Most of the places in the tests we were
already matching on error message, a couple of places we weren't. The
tick-tock one was the only one that wasn't being used right where it was
raised.
Some of them I just changed to RuntimeError because it was shorter than
adding the pylint directive.
This is actually the renamed pep517, but I'm not removing that as
pyorama still depends on it. Even though pyproject_hooks got added to
the pyorama requirements file, huh???
This fails now with 'failed with env name pyinstaller-32 conflicting with base python C:\hostedtoolcache\windows\Python\3.10.9\x86\python.exe'
See https://github.com/tox-dev/tox/pull/2824
For three reasons:
- There are only 31 of them, and we don't really expect any more to
turn up (last happened in 2013, and we have a test for it happening)
- It makes for nicer debug output
- It always felt strange to only have a small subset in the enum
Florian Bruhin
toofar
bitraid
Philipp Albrecht
Paul Mairo
Kian-Meng Ang