jiebi/CodeConvo huggingface dataset:
Code change:
aborts and produces the following error: I suspect it's due to , but when I started building a NixOS vm with the merge commit checked out, Nix started building ; I just don't have the computing resources to build from such a starting point. What I do know is that the problem exists in but not in
It's indeed likely due to that PR. As mentioned in the message, its up to the maintainers/community to fix the usage of the wrapper in the various packages.
Yep. I have a fix for the "Qt platform plugin" error, but the missing Qtml module has stumped me. I've -ed my way toward the culprit, but I'm not there yet; Compiling LLVM, Qt, PyQt... takes a LONG time on my computer ;)
According to git bisect, the first bad commit is This implies that somewhere within that commit the PyQt build changed such that the Qtml module is no longer being built.
Can confirm the issue.
I dug into this further yesterday, and though I don't have a solution, the problem points to three things: package needs to be modified to use . That part is easy, and I already have a commit for it. is building in such a way that not all of its modules are included, namely the QtQml module. This results in another runtime error; visible after has been applied. reason is building with missing modules is because during the build process it uses tooling to determine whether said modules should be built. In the past, the tooling would return in the affirmative, causing the module to be build. However, as of late the tooling returns in the negative, thus the modules don't get built. This can be seen in the trunk/master python37Packages.pyqt5 builds on Hydra; just search for QtQml. It is number 3 above where I'm stuck. It seems like it's due to a change in , but I don't know what that change could be, nor how to test for it. Note: I ruled out the mismatch between PyQt 5.11 and Qt 5.22 as a potential cause by forcing PyQt 5.11 to build against Qt 5.11.
Yeah, I've been at least aware that we needed to update PyQt I think is working on this.
Fix in
Unfortunately, did not fix it. I: out a vm with qutebrowser within the vm The error is the same as I originally reported. I noticed that adds as a dependency to qutebrowser, but doesn't utilize nor . In contrast, my workaround is to --after applying a hack to PyQt 5.11 -- change qutebrowser as follows:
I think the cases were working for me because my environment has the right plugins. But indeed, wrapping should fix this.

Related discussion:
text: ./fix-restart.patch ]; <ins> dontWrapGApps = true; dontWrapQtApps = true; </ins> postPatch = '' substituteInPlace qutebrowser/app.py --subst-var-by qutebrowser "$out/bin/qutebrowser"
Code change:
aborts and produces the following error: I suspect it's due to , but when I started building a NixOS vm with the merge commit checked out, Nix started building ; I just don't have the computing resources to build from such a starting point. What I do know is that the problem exists in but not in
It's indeed likely due to that PR. As mentioned in the message, its up to the maintainers/community to fix the usage of the wrapper in the various packages.
Yep. I have a fix for the "Qt platform plugin" error, but the missing Qtml module has stumped me. I've -ed my way toward the culprit, but I'm not there yet; Compiling LLVM, Qt, PyQt... takes a LONG time on my computer ;)
According to git bisect, the first bad commit is This implies that somewhere within that commit the PyQt build changed such that the Qtml module is no longer being built.
Can confirm the issue.
I dug into this further yesterday, and though I don't have a solution, the problem points to three things: package needs to be modified to use . That part is easy, and I already have a commit for it. is building in such a way that not all of its modules are included, namely the QtQml module. This results in another runtime error; visible after has been applied. reason is building with missing modules is because during the build process it uses tooling to determine whether said modules should be built. In the past, the tooling would return in the affirmative, causing the module to be build. However, as of late the tooling returns in the negative, thus the modules don't get built. This can be seen in the trunk/master python37Packages.pyqt5 builds on Hydra; just search for QtQml. It is number 3 above where I'm stuck. It seems like it's due to a change in , but I don't know what that change could be, nor how to test for it. Note: I ruled out the mismatch between PyQt 5.11 and Qt 5.22 as a potential cause by forcing PyQt 5.11 to build against Qt 5.11.
Yeah, I've been at least aware that we needed to update PyQt I think is working on this.
Fix in
Unfortunately, did not fix it. I: out a vm with qutebrowser within the vm The error is the same as I originally reported. I noticed that adds as a dependency to qutebrowser, but doesn't utilize nor . In contrast, my workaround is to --after applying a hack to PyQt 5.11 -- change qutebrowser as follows:
I think the cases were working for me because my environment has the right plugins. But indeed, wrapping should fix this.

Related discussion:
text: postInstall = '' install -Dm644 doc/qutebrowser.1 "$out/share/man/man1/qutebrowser.1" <del> install -Dm644 misc/qutebrowser.desktop  "$out/share/applications/qutebrowser.desktop" </del> <ins> install -Dm644 misc/org.qutebrowser.qutebrowser.desktop  "$out/share/applications/org.qutebrowser.qutebrowser.desktop" </ins> # Install icons for i in 16 24 32 48 64 128 256 512; do
Code change:
aborts and produces the following error: I suspect it's due to , but when I started building a NixOS vm with the merge commit checked out, Nix started building ; I just don't have the computing resources to build from such a starting point. What I do know is that the problem exists in but not in
It's indeed likely due to that PR. As mentioned in the message, its up to the maintainers/community to fix the usage of the wrapper in the various packages.
Yep. I have a fix for the "Qt platform plugin" error, but the missing Qtml module has stumped me. I've -ed my way toward the culprit, but I'm not there yet; Compiling LLVM, Qt, PyQt... takes a LONG time on my computer ;)
According to git bisect, the first bad commit is This implies that somewhere within that commit the PyQt build changed such that the Qtml module is no longer being built.
Can confirm the issue.
I dug into this further yesterday, and though I don't have a solution, the problem points to three things: package needs to be modified to use . That part is easy, and I already have a commit for it. is building in such a way that not all of its modules are included, namely the QtQml module. This results in another runtime error; visible after has been applied. reason is building with missing modules is because during the build process it uses tooling to determine whether said modules should be built. In the past, the tooling would return in the affirmative, causing the module to be build. However, as of late the tooling returns in the negative, thus the modules don't get built. This can be seen in the trunk/master python37Packages.pyqt5 builds on Hydra; just search for QtQml. It is number 3 above where I'm stuck. It seems like it's due to a change in , but I don't know what that change could be, nor how to test for it. Note: I ruled out the mismatch between PyQt 5.11 and Qt 5.22 as a potential cause by forcing PyQt 5.11 to build against Qt 5.11.
Yeah, I've been at least aware that we needed to update PyQt I think is working on this.
Fix in
Unfortunately, did not fix it. I: out a vm with qutebrowser within the vm The error is the same as I originally reported. I noticed that adds as a dependency to qutebrowser, but doesn't utilize nor . In contrast, my workaround is to --after applying a hack to PyQt 5.11 -- change qutebrowser as follows:
I think the cases were working for me because my environment has the right plugins. But indeed, wrapping should fix this.

Related discussion:
text: done ''; <ins> postFixup = '' wrapProgram $out/bin/qutebrowser  "''${gappsWrapperArgs[@]}"  "''${qtWrapperArgs[@]}" ''; </ins> meta = with stdenv.lib; { homepage    = https://github.com/The-Compiler/qutebrowser; description = "Keyboard-focused browser with a minimal GUI";
Code change:
Currently python packages in propagatedBuildInputs are included into PYTHONPATH and are referenced by a file in the output (propagated-build-native-inputs), which makes them run-time dependencies: For ELF programs nix can figure out the run-time dependencies by scanning the executables, this fails for python as the dependencies are not referenced in any file. DISCUSSION: pth files could include such references and would handle PYTHONPATH manipulation a nix-support/python-build-inputs could list python buildInputs, turning them into run-time dependencies and further they would be used in the above _addToPythonPath
pth files it is

Related discussion:
text: stdenv.mkDerivation rec { name = "${pname}-${version}"; pname = "clingo"; <del> version = "5.2.2"; </del> <ins> version = "5.3.0"; </ins> src = fetchzip { url = "https://github.com/potassco/clingo/archive/v${version}.tar.gz"; <del> sha256 = "04rjwpna37gzm8vxr09z3z6ay8y8cxbjd8lga7xvqfpn2l178zjm"; </del> <ins> sha256 = "01czx26p8gv81ahrh650x208hjhd8bx1kb688fmk1m4pw4yg5bfv"; </ins> }; buildInputs = [];
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: { stdenv, lib, fetchurl, fetchzip, python3Packages <del> , makeWrapper, wrapGAppsHook, qtbase, glib-networking </del> <ins> , mkDerivationWith, wrapQtAppsHook, wrapGAppsHook, qtbase, glib-networking </ins> , asciidoc, docbook_xml_dtd_45, docbook_xsl, libxml2 , libxslt, gst_all_1 ? null , withPdfReader        ? true
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: ]); nativeBuildInputs = [ <del> makeWrapper wrapGAppsHook asciidoc </del> <ins> wrapQtAppsHook wrapGAppsHook asciidoc </ins> docbook_xml_dtd_45 docbook_xsl libxml2 libxslt ];
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: ./fix-restart.patch ]; <ins> dontWrapGApps = true; dontWrapQtApps = true; </ins> postPatch = '' substituteInPlace qutebrowser/app.py --subst-var-by qutebrowser "$out/bin/qutebrowser"
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: postInstall = '' install -Dm644 doc/qutebrowser.1 "$out/share/man/man1/qutebrowser.1" <del> install -Dm644 misc/qutebrowser.desktop  "$out/share/applications/qutebrowser.desktop" </del> <ins> install -Dm644 misc/org.qutebrowser.qutebrowser.desktop  "$out/share/applications/org.qutebrowser.qutebrowser.desktop" </ins> # Install icons for i in 16 24 32 48 64 128 256 512; do
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: done ''; <ins> postFixup = '' wrapProgram $out/bin/qutebrowser  "''${gappsWrapperArgs[@]}"  "''${qtWrapperArgs[@]}" ''; </ins> meta = with stdenv.lib; { homepage    = https://github.com/The-Compiler/qutebrowser; description = "Keyboard-focused browser with a minimal GUI";