| Age | Commit message (Collapse) | Author |
|---|
|
The CheckPlatform macro will prompt the user user to use the 32bit installer
if they are on a 32bit system. But we don't provide a 32bit installer anymore.
This commit changes the OS version check for Qt5 builds to be based on checking
version numbers ourselves too, so that we can have our own error message.
Also moves the Qt5 conditionals to be compile time ones.
|
|
|
|
We dropped 32bit support in #7804 and as a result removed the arch
suffix from the binary that pyinstaller produces. This commit removes it
form the lookup path in the installer too.
Note that we are leaving the arch string in the installer itself for
now. Mostly because it'll be removed as part of a later change when the
installer itself is refreshed. But it might also be useful to clarify in
the installer names what the arch is? Maybe, that reasoning might not
fit with the previous change to remove the arch strings.
|
|
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.
|
|
feat/mac_sandbox_pre_release_pyinstaller
Only conflict was the removal of support for 32bit builds in
build_release.py
|
|
This reverts commit 8715263c757072fcca14d4e543efa631fda149cd.
ref: #7803
|
|
Restored from dd2fc8e10bb9d4a1bd0158110173793a18736d6b
Now that we are putting our data files in the qutebrowser/ directory
again pkgutil/importlib is getting confused by that dir existing and
returning us a FileLoader for `qutebrowser.components`, I think that's
what's happening anyway. Should try reverting that and this commit and
see if extensions get loaded right again.
So bring back this workaround of using the toc on the PyInstaller loader
to get the list of component modules for now.
ref: #7803
|
|
Trying to switch the bundle ID again and see if that makes things work.
Will need to check 5.15 too.
ref: https://github.com/qutebrowser/qutebrowser/pull/7803#issuecomment-1657106925
Closes: #5180
|
|
I don't want to deal with having to review development changes of
pyinstaller every week. So pin to one commit for now that we can
actually test. I'm subscribed to release notifications on github so I'll
manually change this back to point to the pyinstaller pypi package ones
it does.
|
|
|
|
Until we look at #7220 proper (thus splitting this into a qute-start:// which
could probably have more permissions to do remote requests), we'll need to do
with somewhat of a hack to allow this even if QtWebEngine does not.
Given the very limited scope (only from qute://start, only opening the search
engine URL, only with a form submitted request), this should be acceptable
without compromsing security in any way.
Fixes #7790
|
|
With Qt 6.3+, user interaction is required to navigate outside of qute:// from a
qute:// page.
Fixes #7815
See #7220 - should be revisited once we have a qute-bookmarks:// instead where
we can adjust permissions when registering the URL handler.
|
|
Needed mostly for urlmarks BDD tests so they can clear things between tests.
Hopefully with --all, this won't be accidentally triggered by users.
Preparation for #7815
|
|
While not documented that way:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/cwait?view=msvc-170
It looks like that Windows sometimes sets errno to EACCES here (causing a
PermissionError):
> os.waitpid(pid, 0) # pid, options... positional-only :(
E PermissionError: [Errno 13] Permission denied
I have no idea why it happens, but it results in flaky tests on CI.
We aren't particularly interested in this (we just want to make sure the process
is cleaned up before the next test runs...), so let's just ignore this.
|
|
Run package building on CI with warnings turned into errors
|
|
Drop 32bit Windows release support
|
|
See https://github.com/python/mypy/issues/2087
|
|
We got a `DeprecationWarning` during the package build, which we were not able to
reproduce locally. For now we just don't turn this particular `DeprecationWarning` into
an exception to not fail CI.
|
|
We want to run a package build in CI with warnings turned into exceptions, in order to
catch issues in CI (e.g. DeprecationWarning).
|
|
This is still *very* basic, but it serves its purpose of failing for warnings during
package build.
I verified that `tox -e package` is failing by introducing some warnings with this change:
```diff
diff --git a/setup.py b/setup.py
index feb949595..6810eaf1e 100755
--- a/setup.py
+++ b/setup.py
@@ -51,8 +51,7 @@ def _get_constant(name):
try:
common.write_git_file()
setuptools.setup(
- packages=setuptools.find_namespace_packages(include=['qutebrowser',
- 'qutebrowser.*']),
+ packages=setuptools.find_namespace_packages(include=['qutebrowser']),
include_package_data=True,
entry_points={'gui_scripts':
['qutebrowser = qutebrowser.qutebrowser:main']},
```
|
|
See #7801
|
|
|
|
|
|
Catches issues with invalid URLs early instead of later in the code (e.g. when
the brave adblocker runs on the URL).
Hopefully helps catch issues with broken config.py hacks calling redirect().
|
|
If a server gets fixed and now advertises spec 1.2, there is no reason we should
complain about things.
See https://github.com/phuhl/linux_notification_center/commit/5427acd551ce6dc4c74bdf8090904c6d254b74f1
|
|
Update dependencies
|
|
|
|
|
|
|
|
Now that we aren't patching the build we shouldn't have to try to
re-sign in.
|
|
Update dependencies
|
|
When handling the automated dependancy update PR GH warned on push of a
low priority security issue with cryptography. So updating that now.
Rich has an update available too.
ref: https://github.com/qutebrowser/qutebrowser/security/dependabot/32
ref: #7807
|
|
Seems the new flake8 release is pulling down a (somewhat) new
pycodestyle that prefers is/is not over ==/!= when comparing exact
types. They should behave the same.
ref: #7807
|
|
|
|
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.
|
|
|
|
It's a change from before but it's strictly more accurate anyway, in the
application we are always using sip from under the PyQt module, even if
PyQt5 registers it as the plain `sip` too. And now it's consistent with
what we have to do for PyQt6.
|
|
Fixed:
* The `PyQt{5,6}.sip` version is now shown correctly in the
:version|--version output. Previously that showed the version from the
standalone `sip` module which was only set for PyQt5.
|
|
Currently, ":version" fails to show the sip version for Qt6. This is
because the sip module can't imported in the same way as Qt5. In Qt5,
the sip module can be imported after "from PyQt5.QtCore import *". In Qt
6, this is no longer the case,
>>> from PyQt6.QtCore import *
>>> import sip
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'sip'
So let importlib import PyQt6.sip explicitly.
|
|
See #6050, still keeping open to track NSIS changes
|
|
Not that we are looking up resources via importlib_resources for
pyinstaller builds too we need to change where the data files are
installed to to match what importlib_resources is expecting.
There was a comment in the previous resource lookup special case
complaining about the data files being at the top level so it seems this
is a change for the better anyhow.
Observed paths:
requested file: qutebrowser.app/Contents/Frameworks/qutebrowser/config/configdata.yml
actual file : qutebrowser.app/Contents/Frameworks/config/configdata.yml
|
|
pyinstaller patches importlib_resources now so it should transparently
handle this special case for us.
ref: https://pyinstaller.org/en/stable/CHANGES.html?highlight=importlib.resources#id94
|
|
Since we are pulling down PyInstaller off of the develop branch we need
to recompile the bootloader, because upstream only commits a new one
back to the branch on releases. Luckily all the compiler requirements
seem to already be installed on CI.
For the record the macOS CI is currently failing with
dlopen: dlopen(/Users/runner/work/qutebrowser/qutebrowser/dist/qutebrowser.app/Contents/MacOS/libpython3.10.dylib, 10): image not found
And upon inspection of dist/ that file seems to be at
./qutebrowser.app/Contents/Resources/libpython3.10.dylib
./qutebrowser.app/Contents/Frameworks/libpython3.10.dylib
./qutebrowser/_internal/libpython3.10.dylib
|
|
PyInstaller has [recently][symlinks] landed a change that should restore
the webengine sandbox on macOS builds. With a bit more testing we are
hoping that we can go ahead releasing builds based on that
in-development PyInstaller codebase even before they've made a release.
This commit pins our pyinstaller dependency to be the latest commit on
their develop branch.
[symlinks]: https://github.com/pyinstaller/pyinstaller/pull/7619
|
|
Broken in ffc06e58d6d6254d1758f8328f6dc43cc38651d5
|
|
|
|
6.5.2 is out with the fixes in
|
|
This reverts commit 70e8dc63e87a57ecac2b626d496a0bc9517a632d.
We're on PyQt 6.5.2 now, which should fix the segfaults on exit.
|
|
This reverts commit ed70741587d0d7f5cc90b2f510c38474a7ad9375.
|
|
Update dependencies
|
