Code change:
Describe the bug qutebrowser doesn't start To Reproduce Steps to reproduce the behavior: the latest nixos-unstable qutebrowser Expected behavior qutebrowser starts Screenshots ! Metadata system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs: Maintainer information:
The issue is present since I will figure out what commit from staging it was, but for now my computer is busy compiling :)
maintainers:
Related to
And
Thanks to for this valuable piece of information: Adding wrapQtAppsHook only address plugins, such as xcb, not loading. It does not address the missing PyQt5.QtQml module. According to a working build of qutebrowser, that module is actually missing from PyQt5. This can be seen by comparing the PyQt5 referenced by working and non-working builds of qutebrowser. In the working build you'll see the files and in `/nix/store/PyQt/lib/python*/site-packages/PyQt5/. In the non-working build those two files will not be present. In fact, I recall seeing other missing files, such as QtWebEngine. I tried some stuff and it seems like since the propagatedBuildInputs are somehow ignored and can not find webengine or qml, even when adding qtdeclarative to propagatedBuildInputs. I have no idea why, but only when I put them in nativeBuildInputs, can pick up those dependency and will produce a pyqt version with webengine and qml modules and qutebrowser will start successfully. I know this is wrong, so maybe someone can find the cause of this and a proper solution.
fixes this, but it is not a proper fix.
Fix in
Does anyone know a way to work around this bug, and get a working Qutebrowser, without having to compile it?
You can install a qutebrowser version from an old nixpkgs revision to your user profile. If you have cloned nixpkgs somewhere:
Cool, thanks. But doesn't that build the whole thing? Building a web browser like this takes several hours, no?
This package should have a binary cache now.
Not really: the engine (QtWebEngine) does, but the browser itself is just a relatively small collections of python scripts, so it's pretty fast. QtWebEngine, being part of the base Qt package set should always be cached, even if you modify qutebrowser.
When I installed the version mentioned above, it was still cached. Usually old packages are removed from the cache quite a while after they were replaced. But as worldofpeace mentioned in current unstable qutebrowser should work just fine again.
Cool, I didn't know about that. Thanks!

Related discussion:
text: let pdfjs = let <del> version = "1.10.100"; </del> <ins> version = "2.1.266"; </ins> in fetchzip rec { name = "pdfjs-${version}"; url = "https://github.com/mozilla/pdf.js/releases/download/v${version}/${name}-dist.zip"; <del> sha256 = "04df4cf6i6chnggfjn6m1z9vb89f01a0l9fj5rk21yr9iirq9rkq"; </del> <ins> sha256 = "1ybbnpz2jcdikzwr7r13lq528vxj3bpms1fqmg3n1zgs30cqpkby"; </ins> stripRoot = false; }; <del> in python3Packages.buildPythonApplication rec { </del> <ins> in mkDerivationWith python3Packages.buildPythonApplication rec { </ins> pname = "qutebrowser"; <del> version = "1.6.3"; </del> <ins> version = "1.7.0"; </ins> # the release tarballs are different from the git checkout! src = fetchurl { url = "https://github.com/qutebrowser/qutebrowser/releases/download/v${version}/${pname}-${version}.tar.gz"; <del> sha256 = "0z9an14vlv0r48x7fk0mk7465gnhh19dx1w63lyhsgnfqy5pzlhy"; </del> <ins> sha256 = "0wyjmb2qvnw3gn0ypgckwblmn7kasi12dfwp343hi6wscqripw7i"; </ins> }; # Needs tox