Unfortunately there is no way to get this information from Qt, so I had to
resort to some funny low-level C-like Python programming to directly use
libwayland-client and Xlib. Fun was had! Hopefully this avoids having to ask
for this information every time someone shows a bug/crash report, as there
are various subtleties that can be specific to the Wayland compositor in use.
Packages are slowly migrating to not having a __version__ attribute anymore,
instead relying on importlib.metadata to query the installed version.
jinja2 now shows a deprecation warning when accessing the __version__
attribute: https://github.com/pallets/jinja/pull/2098
For now we keep accessing __version__ for other packages (we still need the
logic for PyQt and its special version attributes anyways), but we fall back on
importlib.metadata.version if we can't get a version that way, and we stop
trying __version__ for jinja2.
We already had all this information in a comment anyways.
I made it machine-readable using:
s/#\s+(\d*)\.(\d*)\.(\d*): Security fixes up to ([^ ]*)\s+\((.*)\)/utils.VersionNumber(\1, \2, \3): (_BASES[XX], '\4'), # \5
plus some manual post-processing.
Thanks to that, we can now get the security version from that data even on
QtWebEngine < 6.3, if that information is known. When we fall back to a base
version (e.g. 6.7.99 -> 6.7), we make sure to not pretend that we have the .0
state of things, though.
Finally, we cross-check the information against the current Qt version if we
have the API, which mostly ensures the data is accurate for human readers.
See #7187 and #8139.
More readable now that we have more information in it.
Also always show the source, now that we have the space for it, and "UA" isn't
the obvious default anymore anyways.
Webengine added a getter for their chromium patch level back in Qt 6.3,
since they backport security fixes from chromium in the periods between
doing major chromium feature upgrades.
It's pulled from a hardcoded string in the webengine source
`src/core/web_engine_context.cpp` that's manually updated when they
backport something.
The "(plus any distribution patches)" bit in there is because it was
pointed out that some distributions backport their own security patches
or even use webengine from a branch when the hardcoded string only gets
updated at release time, despite patches being backported in the
meantime.
Closes: https://github.com/qutebrowser/qutebrowser/issues/7187
pdfjs.get_pdf_basename() returned None, causing in a TypeError. Instead of
throwing mocker.patch at it, fix the underlying issue.
Given we made the same mistake in three places:
- :version
- test_real_file for PDF.js
- is_available() in pdfjs.py (calls the function but doesn't use the result, so
is a nop now, even if PDF.js wasn't found)
...evidently we need to change the API so it still raises an exception if no
PDF.js is available.
Amends 0144ae3576.
Now that pdf.js could be shipped with either js or mjs file extensions we
shouldn't hardcode the filename. Call the function for detecting the filename
instead. And make it public.
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.
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.
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'
```
We don't actually need those values anywhere, and parsing can be tricky
as there isn't a fixed format for those version numbers. Let's just not
do it at all. See #6354.
Florian Bruhin
toofar
Coiby Xu
Philipp Albrecht
kt programs