Question: The rust crate "built" assumes that certain environment variables are always set -- to an empty string if necessary. This is what cargo does, so let's emulate that. See for more details. See I am preparing a patch to fix this, so I skip this.

crateVersion = crate.version; crateDescription = crate.description or ""; crateAuthors = if crate ? authors && lib.isList crate.authors then crate.authors else []; <ins> crateHomepage = crate.homepage or ""; </ins> crateType = if lib.attrByPath ["procMacro"] false crate then ["proc-macro"] else if lib.attrByPath ["plugin"] false crate then ["dylib"] else


Question: The rust crate "built" assumes that certain environment variables are always set -- to an empty string if necessary. This is what cargo does, so let's emulate that. See for more details. See I am preparing a patch to fix this, so I skip this.

inherit crateName buildDependencies completeDeps completeBuildDeps crateDescription crateFeatures libName build workspace_member release libPath crateVersion extraLinkFlags extraRustcOpts <del> crateAuthors verbose colors target_os; </del> <ins> crateAuthors crateHomepage verbose colors target_os; </ins> }; buildPhase = buildCrate { inherit crateName dependencies


Question:
This expression fails to build on 19.03: The problem is that its checkPhase is not correct as the command cannot be found. I believe that should be in the for it to succeed. Run the below inside The error is: Please run and paste the results.
It can be put in as is usual for pytest because we have multiple versions of it within . However, the tests fail:
Not sure what is causing that error, but I use it fine for my purposes.
How do you use it if it doesn't build? Would you mind making a PR with the fix?
It does build, I use a custom pytest- because I was using it before asking it for inclusion in nixpkgs. Anyway it's now being addressed in:

<del> { stdenv, buildPythonPackage, fetchPypi, pytest }: </del> <ins> { stdenv, buildPythonPackage, fetchPypi, fetchpatch, pytest }: </ins> buildPythonPackage rec { version = "0.4.0";


Question:
This expression fails to build on 19.03: The problem is that its checkPhase is not correct as the command cannot be found. I believe that should be in the for it to succeed. Run the below inside The error is: Please run and paste the results.
It can be put in as is usual for pytest because we have multiple versions of it within . However, the tests fail:
Not sure what is causing that error, but I use it fine for my purposes.
How do you use it if it doesn't build? Would you mind making a PR with the fix?
It does build, I use a custom pytest- because I was using it before asking it for inclusion in nixpkgs. Anyway it's now being addressed in:

sha256 = "bda0ef48e6a44c091399b12ab4a7e580d2dd8294c222b301f88d7d57f47ba142"; }; <ins> patches = [ # Fix tests for pytest>=4.2.0. Remove with the next release (fetchpatch { url = "https://github.com/RKrahl/pytest-dependency/commit/089395bf77e629ee789666361ee12395d840252c.patch"; sha256 = "1nkha2gndrr3mx11kx2ipxhphqd6wr25hvkrfwzyrispqfhgl0wm"; excludes = [ "doc/src/changelog.rst" ]; }) ]; </ins> propagatedBuildInputs = [ pytest ]; <ins> checkInputs = [ pytest ]; </ins> checkPhase = '' pytest '';


Question:
build of gpgme-1.13.0 fails on macosx . . . nix-env -i gpgme Please run and paste the results.
I can reproduce this on , but it builds fine on current master
Closing since seems to be fixed after , but feel free to reopen if you continue having issues
i am seeing this again on
bisecting suggests it started with or (in the latter commit, indent fails to build, rather than getting the File name too long error, though)
Same here (seeing this again)
It seems like this is caused by a of unix socket path length limit (which is just 104 on darwin). A workaround that works for me is to build it with a different TMPDIR:
Related to
Thanks for the workaround using it, gpgme install gets stuck at
I had the same problem. I think this might be an unrelated issue. It did build successfully on the second attempt for me.
It would be nice if somebody could investigate how to disable just the problematic tests instead of completely turning them off with .
Turning off the tests didn’t work for me, it seemed to fail on the build step
we could add a patch to disable these tests on darwin:

"--enable-fixed-path=${gnupg}/bin" "--with-libgpg-error-prefix=${libgpgerror.dev}" "--with-libassuan-prefix=${libassuan.dev}" <del> ] ++ lib.optional pythonSupport "--enable-languages=python"; </del> <ins> ] ++ lib.optional pythonSupport "--enable-languages=python" # Tests will try to communicate with gpg-agent instance via a UNIX socket # which has a path length limit. Nix on darwin is using a build directory # that already has quite a long path and the resulting socket path doesn't # fit in the limit. https://github.com/NixOS/nix/pull/1085 ++ lib.optionals stdenv.isDarwin [ "--disable-gpg-test" ]; </ins> NIX_CFLAGS_COMPILE = # qgpgme uses Q_ASSERT which retains build inputs at runtime unless


Question:
application can't find help files Install from nixos release channel, go to main application screen, click on Help menu and select either "tutorial and concepts guide" or "contents". Application complains with a modal reporting "GnuCash could not find the files for the help documentation. This is likely because 'gnucash-docs' package is not installed." system: host os: multi-user?: sandbox: version: channels(root): channels(zarel): nixpkgs:
As a workaround: the very same documentation is available online at this address:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still happening
Pinging maintainers
There is more to it. Gnucash installs its document files into plain without subdirectory. Because of that common files like do have collisions with analogous files in other packages. Edit: Ah, that's another issue. Which was resolved in
Documentation for Gnucash is a separate project: It should be separately build and installed in order for help files to be available.
I marked this as stale due to inactivity. →
I've built the documentation and put the documentation in the XDGDATADIRS. I can browse the manual and the tutorial via but running gnucash in debug mode says "Unsupported action" and according to strace the application doesn't try to open the documentation directories... and the same happens for evince (can see the documentation in yelp but the application won't display it), maybe it's the same issue
Not stale, I'm still having this issue
I marked this as stale due to inactivity. →
issue remains.
Thank you for the fix! Do you think is there a way to warn the user about not having yelp in a profile?
I don't think there are any convenient/good ways to tell the user about it. At best, we could add it to the description?
If gnucash documentation depends on yelp, would it make sense to express this dependency in the gnucash derivation?
Apparently, it must also be in MIME. This sort of stupid behaviour looks like an upstream bug to me.
If an application shipped its help files as HTML and required you to have a web browser installed to view them, I think it would be silly to add a dependency on any specific web browser. Likewise with help files - if (at least theoretically) Yelp is just one of several possible help file viewers, I don't think it makes sense to add a dependency on it. A better indication of what's wrong ("you need to install a help viewer" rather than "couldn't find the docs") would be nice, though, which I presume is only really doable upstream.

{ lib , stdenv <ins> , fetchFromGitHub </ins> , fetchurl , fetchpatch , aqbanking


Question:
application can't find help files Install from nixos release channel, go to main application screen, click on Help menu and select either "tutorial and concepts guide" or "contents". Application complains with a modal reporting "GnuCash could not find the files for the help documentation. This is likely because 'gnucash-docs' package is not installed." system: host os: multi-user?: sandbox: version: channels(root): channels(zarel): nixpkgs:
As a workaround: the very same documentation is available online at this address:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still happening
Pinging maintainers
There is more to it. Gnucash installs its document files into plain without subdirectory. Because of that common files like do have collisions with analogous files in other packages. Edit: Ah, that's another issue. Which was resolved in
Documentation for Gnucash is a separate project: It should be separately build and installed in order for help files to be available.
I marked this as stale due to inactivity. →
I've built the documentation and put the documentation in the XDGDATADIRS. I can browse the manual and the tutorial via but running gnucash in debug mode says "Unsupported action" and according to strace the application doesn't try to open the documentation directories... and the same happens for evince (can see the documentation in yelp but the application won't display it), maybe it's the same issue
Not stale, I'm still having this issue
I marked this as stale due to inactivity. →
issue remains.
Thank you for the fix! Do you think is there a way to warn the user about not having yelp in a profile?
I don't think there are any convenient/good ways to tell the user about it. At best, we could add it to the description?
If gnucash documentation depends on yelp, would it make sense to express this dependency in the gnucash derivation?
Apparently, it must also be in MIME. This sort of stupid behaviour looks like an upstream bug to me.
If an application shipped its help files as HTML and required you to have a web browser installed to view them, I think it would be silly to add a dependency on any specific web browser. Likewise with help files - if (at least theoretically) Yelp is just one of several possible help file viewers, I don't think it makes sense to add a dependency on it. A better indication of what's wrong ("you need to install a help viewer" rather than "couldn't find the docs") would be nice, though, which I presume is only really doable upstream.

# raw source code doesn't work out of box; fetchFromGitHub not usable src = fetchurl { # Upstream uploaded a -1 tarball on the same release, remove on next release <del> url = "https://github.com/Gnucash/gnucash/releases/download/${version}/${pname}-${version}-1.tar.bz2"; </del> <ins> url = "https://github.com/Gnucash/gnucash/releases/download/${version}/gnucash-${version}-1.tar.bz2"; </ins> hash = "sha256-d0EWXW1lLqe0oehJjPQ5pWuBpcyLZTKRpZBU8jYqv8w="; };


Question:
application can't find help files Install from nixos release channel, go to main application screen, click on Help menu and select either "tutorial and concepts guide" or "contents". Application complains with a modal reporting "GnuCash could not find the files for the help documentation. This is likely because 'gnucash-docs' package is not installed." system: host os: multi-user?: sandbox: version: channels(root): channels(zarel): nixpkgs:
As a workaround: the very same documentation is available online at this address:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still happening
Pinging maintainers
There is more to it. Gnucash installs its document files into plain without subdirectory. Because of that common files like do have collisions with analogous files in other packages. Edit: Ah, that's another issue. Which was resolved in
Documentation for Gnucash is a separate project: It should be separately build and installed in order for help files to be available.
I marked this as stale due to inactivity. →
I've built the documentation and put the documentation in the XDGDATADIRS. I can browse the manual and the tutorial via but running gnucash in debug mode says "Unsupported action" and according to strace the application doesn't try to open the documentation directories... and the same happens for evince (can see the documentation in yelp but the application won't display it), maybe it's the same issue
Not stale, I'm still having this issue
I marked this as stale due to inactivity. →
issue remains.
Thank you for the fix! Do you think is there a way to warn the user about not having yelp in a profile?
I don't think there are any convenient/good ways to tell the user about it. At best, we could add it to the description?
If gnucash documentation depends on yelp, would it make sense to express this dependency in the gnucash derivation?
Apparently, it must also be in MIME. This sort of stupid behaviour looks like an upstream bug to me.
If an application shipped its help files as HTML and required you to have a web browser installed to view them, I think it would be silly to add a dependency on any specific web browser. Likewise with help files - if (at least theoretically) Yelp is just one of several possible help file viewers, I don't think it makes sense to add a dependency on it. A better indication of what's wrong ("you need to install a help viewer" rather than "couldn't find the docs") would be nice, though, which I presume is only really doable upstream.

enableParallelChecking = true; checkTarget = "check"; <ins> passthru.docs = stdenv.mkDerivation { pname = "gnucash-docs"; inherit version; src = fetchFromGitHub { owner = "Gnucash"; repo = "gnucash-docs"; rev = version; hash = "sha256-aPxQEcpo8SPv8lPQbxMl1wg8ijH9Rz0oo4K5lp3C/bw="; }; nativeBuildInputs = [ cmake ]; buildInputs = [ libxml2 libxslt ]; }; </ins> preFixup = '' gappsWrapperArgs+=( <ins> # documentation --prefix XDG_DATA_DIRS : ${passthru.docs}/share </ins> # db drivers location --set GNC_DBD_DIR ${libdbiDrivers}/lib/dbd # gsettings schema location on Nix <del> --set GSETTINGS_SCHEMA_DIR ${glib.makeSchemaPath "$out" "${pname}-${version}"} </del> <ins> --set GSETTINGS_SCHEMA_DIR ${glib.makeSchemaPath "$out" "gnucash-${version}"} </ins> ) '';


Question:
On today's master () - and probably others - building the attribute of many package produces an output that differs from the output on another architecture. Nix will display a hash mismatch. I tried with x8664-linux and aarch64-linux. Execute this on aarch64 and x8664. The aarch64 build produces the below output while x8664 is happy with the hash in nixpkgs. Please run and paste the results. system: host os: multi-user?: sandbox: version: nixpkgs: and system: host os: multi-user?: sandbox: version: channels(root): channels(andi): nixpkgs:
x8664 build produces same output for me: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I noticed something similar on macOS in Could some recent change have caused this? Perhaps ?
I reverted in a branch on my fork. My x86_64-linux laptop doesn't complain about the hash sum - as before. The aarch64-linux community box also doesn't complain anymore. Can anyone else confirm this?
I just made a diff of : The left side is aarch64, the right side is x86_64. Both are done on the same git revision ().
What a weird behavior that is missing.
Probably related:
I think this may be related: I also see different hashes on NixOS 19.03 vs. stable. I use the branch, but when CI builds the derivation on 19.03, the hashes do not match. If I build on NixOS 19.03 with from master, the hashes do match. This is quite annoying, because it makes it impossible to have package sets that work on NixOS stable and unstable without using rustPlatform from a nixpkgs newer than 19.03. I'll try to revert and see if I get the same hashes on 19.03 and master.
That's indeed it. When I revert , I get the same as 19.03. Maybe this change should be reverted? Since NixOS is not a rolling distribution and people run both stable and unstable, it would really be nice if package sets and overlays work on both versions. This also makes backporting changes easier.
Diff between the vendored dependencies: Here the differences also seem to be missing dotfiles (e.g. and ). I think this is the upstream PR that changed this behavior: (Edit: oops, I just saw that already mentioned the associated commit.)
is a critical update and reverting it will break multiple Rust packages. Rather I think we should get that change pushed into the channel, and then update any Rust packages whose changes as a result.
The only bummer is that it also breaks people's own packages on the channel as well.
Yeah, it would be bad to break people's derivations as an update to a stable release. At any rate, the 19.09 release notes should probably have a blurb that points out that hashes will change due to changes, so that people who update from 19.03 to 19.09 are prepared. There are probably also derivations in that have incorrect hashes now, since the file that is generated by is now excluded vendored dependencies.
I’ve updated the title of the issue to better reflect what I think we now know. Additionally, I’ve opened to update the hashes for all packages that haven’t been updated in master yet. I would appreciate a review on it. Once that’s merged, I can do the same thing for the affected release branch.
Looks like I misunderstood and this hasn’t made its was into a release branch yet, so we’re almost done here. Somebody just needs to add the release note for 19.09.
with the changelog PR () being merged, is there anything else missing?
Don't think so. :) Somebody can shout if I'm wrong.

sha256 = "1z66m16n4r16zqmnv84a5jndr5x6mdqdq4b1wq929sablwqd2rl4"; }; <del> cargoSha256 = "1xdx0gjqd4zyhnp72hz88rdmgry1m7rcw2j73lh67vp08z74y54y"; </del> <ins> cargoSha256 = "0hp68w5mvk725gzbmlgl8j6wa1dv2fydil7jvq0f09mzxxaqrwcs"; </ins> nativeBuildInputs = [ pkgconfig ];


Question:
. The short of it is that doesn't have a flag on OS X.
The in use is from .
It seems that removing from solves this issue. I'll drop that in a PR to continue the discussion.

<ins> --- crypto++/GNUmakefile 2013-02-20 10:30:52.000000000 -0500 +++ crypto++/GNUmakefile 2015-05-07 18:34:25.000000000 -0500 @@ -87,8 +87,8 @@ endif ifeq ($(UNAME),Darwin) -AR = libtool -ARFLAGS = -static -o +AR = ar +ARFLAGS = cru CXX = c++ IS_GCC2 = $(shell $(CXX) -v 2>&1 | $(EGREP) -c gcc-932) ifeq ($(IS_GCC2),1) </ins>


Question:
. The short of it is that doesn't have a flag on OS X.
The in use is from .
It seems that removing from solves this issue. I'll drop that in a PR to continue the discussion.

sha256 = "0x1mqpz1v071cfrw4grbw7z734cxnpry1qh2b6rsmcx6nkyd5gsw"; }; <del> patches = stdenv.lib.optional (stdenv.system != "i686-cygwin") ./dll.patch; </del> <ins> patches = (stdenv.lib.optional (stdenv.system != "i686-cygwin") ./dll.patch) ++ (stdenv.lib.optional stdenv.isDarwin ./GNUmakefile.patch); </ins> buildInputs = [ unzip libtool ];


Question: Right now if you update the unstable tree and install ddclient the shebang patch is not applied properly and the first line of the script starts with: This reference doesn't exist so the actual binary cannot be started. ) Install ddclient ) Attempt to start ddclient

<del> { stdenv, fetchurl, perlPackages, iproute }: </del> <ins> { stdenv, fetchurl, perlPackages, iproute, perl }: </ins> perlPackages.buildPerlPackage rec { name = "ddclient-${version}";


Question: Right now if you update the unstable tree and install ddclient the shebang patch is not applied properly and the first line of the script starts with: This reference doesn't exist so the actual binary cannot be started. ) Install ddclient ) Attempt to start ddclient

substituteInPlace ddclient  --replace 'in the output of ifconfig' 'in the output of ip addr show'  --replace 'ifconfig -a'               '${iproute}/sbin/ip addr show'  <del> --replace 'ifconfig $arg'             '${iproute}/sbin/ip addr show $arg' </del> <ins> --replace 'ifconfig $arg'             '${iproute}/sbin/ip addr show $arg'  # Until we get the patchShebangs fixed (issue #55786) we need to patch this manually --replace '/usr/bin/perl'		    '${perl}/bin/perl' </ins> ''; installPhase = ''


Question:
In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.

''; }; <ins> generatePeerUnit = { interfaceName, interfaceCfg, peer }: let keyToUnitName = replaceChars [ "/" "-"    " "     "+"     "="      ] [ "-" "x2d" "x20" "x2b" "x3d" ]; unitName = keyToUnitName peer.publicKey; psk = if peer.presharedKey != null then pkgs.writeText "wg-psk" peer.presharedKey else peer.presharedKeyFile; in nameValuePair "wireguard-${interfaceName}-peer-${unitName}" { description = "WireGuard Peer - ${interfaceName} - ${peer.publicKey}"; requires = [ "wireguard-${interfaceName}.service" ]; after = [ "wireguard-${interfaceName}.service" ]; wantedBy = [ "multi-user.target" ]; environment.DEVICE = interfaceName; environment.WG_ENDPOINT_RESOLUTION_RETRIES = "infinity"; path = with pkgs; [ iproute wireguard-tools ]; serviceConfig = { Type = "oneshot"; RemainAfterExit = true; }; script = let wg_setup = "wg set ${interfaceName} peer ${peer.publicKey}" + optionalString (psk != null) " preshared-key ${psk}" + optionalString (peer.endpoint != null) " endpoint ${peer.endpoint}" + optionalString (peer.persistentKeepalive != null) " persistent-keepalive ${toString peer.persistentKeepalive}" + optionalString (peer.allowedIPs != []) " allowed-ips ${concatStringsSep "," peer.allowedIPs}"; route_setup = optionalString (interfaceCfg.allowedIPsAsRoutes != false) (concatMapStringsSep "n" (allowedIP: "ip route replace ${allowedIP} dev ${interfaceName} table ${interfaceCfg.table}" ) peer.allowedIPs); in '' ${wg_setup} ${route_setup} ''; </ins> <del> generateSetupServiceUnit = name: values: </del> <ins> postStop = let route_destroy = optionalString (interfaceCfg.allowedIPsAsRoutes != false) (concatMapStringsSep "n" (allowedIP: "ip route delete ${allowedIP} dev ${interfaceName} table ${interfaceCfg.table}" ) peer.allowedIPs); in '' wg set ${interfaceName} peer ${peer.publicKey} remove ${route_destroy} ''; }; generateInterfaceUnit = name: values: </ins> # exactly one way to specify the private key must be set #assert (values.privateKey != null) != (values.privateKeyFile != null); let privKey = if values.privateKeyFile != null then values.privateKeyFile else pkgs.writeText "wg-key" values.privateKey;


Question:
In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.

path = with pkgs; [ kmod iproute wireguard-tools ]; serviceConfig = { <del> Type = "simple"; Restart = "on-failure"; RestartSec = "5s"; </del> <ins> Type = "oneshot"; </ins> RemainAfterExit = true; };


Question:
In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.

wg set ${name} private-key ${privKey} ${ optionalString (values.listenPort != null) " listen-port ${toString values.listenPort}"} <del> ${concatMapStringsSep "n" (peer: assert (peer.presharedKeyFile == null) || (peer.presharedKey == null); # at most one of the two must be set let psk = if peer.presharedKey != null then pkgs.writeText "wg-psk" peer.presharedKey else peer.presharedKeyFile; in "wg set ${name} peer ${peer.publicKey}" + optionalString (psk != null) " preshared-key ${psk}" + optionalString (peer.endpoint != null) " endpoint ${peer.endpoint}" + optionalString (peer.persistentKeepalive != null) " persistent-keepalive ${toString peer.persistentKeepalive}" + optionalString (peer.allowedIPs != []) " allowed-ips ${concatStringsSep "," peer.allowedIPs}" ) values.peers} </del> ip link set up dev ${name} <del> ${optionalString (values.allowedIPsAsRoutes != false) (concatStringsSep "n" (concatMap (peer: (map (allowedIP: "ip route replace ${allowedIP} dev ${name} table ${values.table}" ) peer.allowedIPs) ) values.peers))} </del> ${values.postSetup} '';


Question:
In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.

###### implementation <del> config = mkIf cfg.enable { </del> <ins> config = mkIf cfg.enable (let all_peers = flatten (mapAttrsToList (interfaceName: interfaceCfg: map (peer: { inherit interfaceName interfaceCfg peer;}) interfaceCfg.peers ) cfg.interfaces); in { </ins> assertions = (attrValues ( mapAttrs (name: value: {


Question:
In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.

mapAttrs (name: value: { assertion = value.generatePrivateKeyFile -> (value.privateKey == null); message = "networking.wireguard.interfaces.${name}.generatePrivateKey must not be set if networking.wireguard.interfaces.${name}.privateKey is set."; <del> }) cfg.interfaces)); </del> <ins> }) cfg.interfaces)) ++ map ({ interfaceName, peer, ... }: { assertion = (peer.presharedKey == null) || (peer.presharedKeyFile == null); message = "networking.wireguard.interfaces.${interfaceName} peer «${peer.publicKey}» has both presharedKey and presharedKeyFile set, but only one can be used."; }) all_peers; </ins> boot.extraModulePackages = [ kernel.wireguard ]; environment.systemPackages = [ pkgs.wireguard-tools ]; <del> systemd.services = (mapAttrs' generateSetupServiceUnit cfg.interfaces) </del> <ins> systemd.services = (mapAttrs' generateInterfaceUnit cfg.interfaces) // (listToAttrs (map generatePeerUnit all_peers)) </ins> // (mapAttrs' generateKeyServiceUnit (filterAttrs (name: value: value.generatePrivateKeyFile) cfg.interfaces)); systemd.paths = mapAttrs' generatePathUnit (filterAttrs (name: value: value.privateKeyFile != null) cfg.interfaces); <del> }; </del> <ins> }); </ins> }


Question:
In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.

stdenv.mkDerivation rec { name = "wireguard-tools-${version}"; <del> version = "0.0.20190406"; </del> <ins> version = "0.0.20190531"; </ins> src = fetchzip { url = "https://git.zx2c4.com/WireGuard/snapshot/WireGuard-${version}.tar.xz"; <del> sha256 = "1rqyyyx7j41vpp4jigagqs2qdyfngh15y48ghdqfrkv7v93vwdak"; </del> <ins> sha256 = "0caw6kc0lqsvzvdjpdbdn3r9ff93vdl46616pwlig0rsdjrqnklj"; </ins> }; sourceRoot = "source/src/tools";


Question: The is from over 3 months ago. Some background info: Previously it was updated automatically by bot that runs . But the last builds have failed, e.g.:

, glib , gnome2 , gnome3 <ins> , gsettings-desktop-schemas </ins> , gtk3 , libuuid , libX11


Question: The is from over 3 months ago. Some background info: Previously it was updated automatically by bot that runs . But the last builds have failed, e.g.:

, wrapGAppsHook }: <del> let rpath = lib.makeLibraryPath [ alsaLib at-spi2-atk at-spi2-core atk cairo cups dbus expat fontconfig freetype gdk_pixbuf glib gnome2.GConf gtk3 libX11 libXScrnSaver libXcomposite libXcursor libXdamage libXext libXfixes libXi libXrandr libXrender libXtst libuuid nspr nss pango udev xdg_utils xorg.libxcb zlib </del> <ins> let rpath = lib.makeLibraryPath [ alsaLib at-spi2-atk at-spi2-core atk cairo cups dbus expat fontconfig freetype gdk_pixbuf glib gnome2.GConf gtk3 libX11 libXScrnSaver libXcomposite libXcursor libXdamage libXext libXfixes libXi libXrandr libXrender libXtst libuuid nspr nss pango udev xdg_utils xorg.libxcb zlib </ins> ]; <ins> in </ins> <del> in stdenv.mkDerivation rec { pname = "brave"; version = "0.61.50"; </del> <ins> stdenv.mkDerivation rec { pname = "brave"; version = "0.65.118"; </ins> <del> src = fetchurl { url = "https://github.com/brave/brave-browser/releases/download/v${version}/brave-browser_${version}_amd64.deb"; sha256 = "1lbajxnxqkd422rckfjm65pwwzl66v7anq4jrzxi29d5x7abl3c1"; }; </del> <ins> src = fetchurl { url = "https://github.com/brave/brave-browser/releases/download/v${version}/brave-browser_${version}_amd64.deb"; sha256 = "13bihzf4yfgn01nrw780swhmcdh8gq71jqilhbi04jn1h1pbm3wg"; }; </ins> <del> dontConfigure = true; dontBuild = true; dontPatchELF = true; </del> <ins> dontConfigure = true; dontBuild = true; dontPatchELF = true; </ins> <del> nativeBuildInputs = [ dpkg wrapGAppsHook ]; </del> <ins> nativeBuildInputs = [ dpkg wrapGAppsHook ]; </ins> <del> buildInputs = [ glib gnome3.gsettings_desktop_schemas gnome3.adwaita-icon-theme ]; </del> <ins> buildInputs = [ glib gsettings-desktop-schemas gnome3.adwaita-icon-theme ]; </ins> <del> unpackPhase = "dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner"; </del> <ins> unpackPhase = "dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner"; </ins> <del> installPhase = '' mkdir -p $out $out/bin </del> <ins> installPhase = '' mkdir -p $out $out/bin </ins> <del> cp -R usr/share $out cp -R opt/ $out/opt </del> <ins> cp -R usr/share $out cp -R opt/ $out/opt </ins> <del> export BINARYWRAPPER=$out/opt/brave.com/brave/brave-browser </del> <ins> export BINARYWRAPPER=$out/opt/brave.com/brave/brave-browser </ins> <del> # Fix path to bash in $BINARYWRAPPER substituteInPlace $BINARYWRAPPER  --replace /bin/bash ${stdenv.shell} </del> <ins> # Fix path to bash in $BINARYWRAPPER substituteInPlace $BINARYWRAPPER  --replace /bin/bash ${stdenv.shell} </ins> <del> ln -sf $BINARYWRAPPER $out/bin/brave </del> <ins> ln -sf $BINARYWRAPPER $out/bin/brave </ins> <del> patchelf  --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${rpath}" $out/opt/brave.com/brave/brave </del> <ins> patchelf  --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${rpath}" $out/opt/brave.com/brave/brave </ins> <del> # Fix paths substituteInPlace $out/share/applications/brave-browser.desktop  --replace /usr/bin/brave-browser $out/bin/brave substituteInPlace $out/share/gnome-control-center/default-apps/brave-browser.xml  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/share/menu/brave-browser.menu  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/opt/brave.com/brave/default-app-block  --replace /opt/brave.com $out/opt/brave.com </del> <ins> # Fix paths substituteInPlace $out/share/applications/brave-browser.desktop  --replace /usr/bin/brave-browser $out/bin/brave substituteInPlace $out/share/gnome-control-center/default-apps/brave-browser.xml  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/share/menu/brave-browser.menu  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/opt/brave.com/brave/default-app-block  --replace /opt/brave.com $out/opt/brave.com </ins> <del> # Correct icons location icon_sizes=("16" "22" "24" "32" "48" "64" "128" "256") </del> <ins> # Correct icons location icon_sizes=("16" "22" "24" "32" "48" "64" "128" "256") </ins> <del> for icon in ''${icon_sizes[*]} do mkdir -p $out/share/icons/hicolor/$iconx$icon/apps ln -s $out/opt/brave.com/brave/product_logo_$icon.png $out/share/icons/hicolor/$iconx$icon/apps/brave-browser.png done </del> <ins> for icon in ''${icon_sizes[*]} do mkdir -p $out/share/icons/hicolor/$iconx$icon/apps ln -s $out/opt/brave.com/brave/product_logo_$icon.png $out/share/icons/hicolor/$iconx$icon/apps/brave-browser.png done </ins> <del> # Replace xdg-settings and xdg-mime ln -sf ${xdg_utils}/bin/xdg-settings $out/opt/brave.com/brave/xdg-settings ln -sf ${xdg_utils}/bin/xdg-mime $out/opt/brave.com/brave/xdg-mime ''; </del> <ins> # Replace xdg-settings and xdg-mime ln -sf ${xdg_utils}/bin/xdg-settings $out/opt/brave.com/brave/xdg-settings ln -sf ${xdg_utils}/bin/xdg-mime $out/opt/brave.com/brave/xdg-mime ''; </ins> <del> meta = with stdenv.lib; { homepage = "https://brave.com/"; description = "Privacy-oriented browser for Desktop and Laptop computers"; longDescription = '' Brave browser blocks the ads and trackers that slow you down, chew up your bandwidth, and invade your privacy. Brave lets you contribute to your favorite creators automatically. ''; license = licenses.mpl20; maintainers = [ maintainers.uskudnik ]; platforms = [ "x86_64-linux" ]; }; </del> <ins> meta = with stdenv.lib; { homepage = "https://brave.com/"; description = "Privacy-oriented browser for Desktop and Laptop computers"; changelog = "https://github.com/brave/brave-browser/blob/v${version}/CHANGELOG.md"; longDescription = '' Brave browser blocks the ads and trackers that slow you down, chew up your bandwidth, and invade your privacy. Brave lets you contribute to your favorite creators automatically. ''; license = licenses.mpl20; maintainers = [ maintainers.uskudnik ]; platforms = [ "x86_64-linux" ]; }; </ins> }


Question:
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.

{ 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


Question:
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.

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


Question:
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.

]); nativeBuildInputs = [ <del> makeWrapper wrapGAppsHook asciidoc </del> <ins> wrapQtAppsHook wrapGAppsHook asciidoc </ins> docbook_xml_dtd_45 docbook_xsl libxml2 libxslt ];


Question:
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.

./fix-restart.patch ]; <ins> dontWrapGApps = true; dontWrapQtApps = true; </ins> postPatch = '' substituteInPlace qutebrowser/app.py --subst-var-by qutebrowser "$out/bin/qutebrowser"


Question:
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.

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


Question:
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.

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";


Question:
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

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 = [];


Question:
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!


Question:
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!


Question:
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!


Question:
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!


Question:
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!


Question:
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!


Question:
Describe the bug grpc doesn't build on macOS. To Reproduce Steps to reproduce the behavior: -shell -p grpc Expected behavior Should have built without errors. Additional context Build log here: Metadata system: host os: multi-user?: sandbox: version: channels(kaali): nixpkgs: Maintainer information:
grpc appears to be pretty out of date , so I'm suspecting that updating all of the pieces would resolve this.
Seems to fail in CI even with an updated version:
That particular package requires manual intervention, as that PR was automatically generated by a bot.

{ stdenv, fetchFromGitHub, cmake, zlib, c-ares, pkgconfig, openssl, protobuf, gflags }: stdenv.mkDerivation rec { <del> version = "1.19.1"; </del> <ins> version = "1.22.0"; </ins> name = "grpc-${version}"; src = fetchFromGitHub { owner = "grpc"; repo = "grpc"; rev = "v${version}"; <del> sha256 = "0c0jra4qnd86gyr4rlblic3igb5dpgrldac35myk5i5ia547fdhj"; </del> <ins> sha256 = "10wf9sakkxpcvc09n1h91x6slwwhxblghs4zn95klyc4m6py1gfg"; </ins> }; nativeBuildInputs = [ cmake pkgconfig ]; buildInputs = [ zlib c-ares c-ares.cmake-config openssl protobuf gflags ];


Question:
Describe the bug grpc doesn't build on macOS. To Reproduce Steps to reproduce the behavior: -shell -p grpc Expected behavior Should have built without errors. Additional context Build log here: Metadata system: host os: multi-user?: sandbox: version: channels(kaali): nixpkgs: Maintainer information:
grpc appears to be pretty out of date , so I'm suspecting that updating all of the pieces would resolve this.
Seems to fail in CI even with an updated version:
That particular package requires manual intervention, as that PR was automatically generated by a bot.

"-DgRPC_PROTOBUF_PROVIDER=package" "-DgRPC_GFLAGS_PROVIDER=package" "-DBUILD_SHARED_LIBS=ON" <ins> "-DCMAKE_SKIP_BUILD_RPATH=OFF" </ins> ]; # CMake creates a build directory by default, this conflicts with the


Question:
Describe the bug grpc doesn't build on macOS. To Reproduce Steps to reproduce the behavior: -shell -p grpc Expected behavior Should have built without errors. Additional context Build log here: Metadata system: host os: multi-user?: sandbox: version: channels(kaali): nixpkgs: Maintainer information:
grpc appears to be pretty out of date , so I'm suspecting that updating all of the pieces would resolve this.
Seems to fail in CI even with an updated version:
That particular package requires manual intervention, as that PR was automatically generated by a bot.

<del> { stdenv, buildPythonPackage, fetchPypi, lib, grpcio}: </del> <ins> { stdenv, buildPythonPackage, fetchPypi, protobuf, grpcio }: </ins> buildPythonPackage rec { pname = "grpcio-tools"; <del> version = "1.18.0"; </del> <ins> version = "1.22.0"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "77ec4d3c92ccbbe3de37c457e3c72962e519c36cafb96abe5842bced8eb926fa"; </del> <ins> sha256 = "b5c0fe51a155625c9d1132ab8deb56b3015e111a6961e48aeb9dd89bd7c670ab"; </ins> }; enableParallelBuilding = true; <del> propagatedBuildInputs = [ grpcio ]; </del> <ins> propagatedBuildInputs = [ protobuf grpcio ]; </ins> # no tests in the package doCheck = false; meta = with stdenv.lib; { description = "Protobuf code generator for gRPC"; <del> license = lib.licenses.asl20; </del> <ins> license = licenses.asl20; </ins> homepage = "https://grpc.io/grpc/python/"; maintainers = with maintainers; [ vanschelven ]; };


Question:
Describe the bug grpc doesn't build on macOS. To Reproduce Steps to reproduce the behavior: -shell -p grpc Expected behavior Should have built without errors. Additional context Build log here: Metadata system: host os: multi-user?: sandbox: version: channels(kaali): nixpkgs: Maintainer information:
grpc appears to be pretty out of date , so I'm suspecting that updating all of the pieces would resolve this.
Seems to fail in CI even with an updated version:
That particular package requires manual intervention, as that PR was automatically generated by a bot.

<del> { stdenv, buildPythonPackage, fetchFromGitHub, lib, darwin , six, protobuf, enum34, futures, isPy27, isPy34, pkgconfig </del> <ins> { stdenv, buildPythonPackage, fetchFromGitHub, darwin , six, protobuf, enum34, futures, isPy27, pkgconfig </ins> , cython}: <del> with stdenv.lib; </del> buildPythonPackage rec { pname = "grpcio"; <del> version = "1.18.0"; </del> <ins> version = "1.22.0"; </ins> src = fetchFromGitHub { owner = "grpc"; repo = "grpc"; rev = "v${version}"; fetchSubmodules = true; <del> sha256 = "0cilbhk35gv46mk40jl5f3iqa94x14qyxbavpfq0kh0rld82nx4m"; </del> <ins> sha256 = "093w8mgvl8ylqlqnfz06ijkmlnkxcjszf9zg6k5ybjw7dwal0jhz"; </ins> }; nativeBuildInputs = [ cython pkgconfig ] <del> ++ optional stdenv.isDarwin darwin.cctools; </del> <ins> ++ stdenv.lib.optional stdenv.isDarwin darwin.cctools; </ins> propagatedBuildInputs = [ six protobuf ] <del> ++ lib.optionals (isPy27 || isPy34) [ enum34 ] ++ lib.optionals (isPy27) [ futures ]; </del> <ins> ++ stdenv.lib.optionals (isPy27) [ enum34 futures ]; </ins> <del> preBuild = optionalString stdenv.isDarwin "unset AR"; </del> <ins> preBuild = stdenv.lib.optionalString stdenv.isDarwin "unset AR"; </ins> meta = with stdenv.lib; { description = "HTTP/2-based RPC framework"; <del> license = lib.licenses.asl20; </del> <ins> license = licenses.asl20; </ins> homepage = "https://grpc.io/grpc/python/"; maintainers = with maintainers; [ vanschelven ]; };


Question:
write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?

|---------------------------+--------------------------------------------| | Model                     | Path                                       | |---------------------------+--------------------------------------------| <del> | Acer Aspire 4810T         | ~<nixos-hardware/acer/aspire/4810t>~       | </del> <ins> | [[file:acer/aspire/4810t][Acer Aspire 4810T]]         | ~<nixos-hardware/acer/aspire/4810t>~       | </ins> | Airis N990                | ~<nixos-hardware/airis/n990>~              | <del> | Apple MacBook Pro 10,1    | ~<nixos-hardware/apple/macbook-pro/10-1>~  | </del> <ins> | Apple MacBook Air 4,X     | ~<nixos-hardware/apple/macbook-air/4>~     | | Apple MacBook Air 6,X     | ~<nixos-hardware/apple/macbook-air/6>~     | | [[file:apple/macbook-pro/10-1][Apple MacBook Pro 10,1]]    | ~<nixos-hardware/apple/macbook-pro/10-1>~  | </ins> | Apple MacBook Pro 12,1    | ~<nixos-hardware/apple/macbook-pro/12-1>~  | <del> | Dell XPS 15 9550          | ~<nixos-hardware/dell/xps/15-9550>~        | | Inverse Path USB armory   | ~<nixos-hardware/inversepath/usbarmory>~   | </del> <ins> | [[file:dell/xps/15-9550][Dell XPS 15 9550]]          | ~<nixos-hardware/dell/xps/15-9550>~        | | [[file:inversepath/usbarmory][Inverse Path USB armory]]   | ~<nixos-hardware/inversepath/usbarmory>~   | </ins> | Lenovo IdeaPad Z510       | ~<nixos-hardware/lenovo/ideapad/z510>~     | | Lenovo ThinkPad T410      | ~<nixos-hardware/lenovo/thinkpad/t410>~    | | Lenovo ThinkPad T440p     | ~<nixos-hardware/lenovo/thinkpad/t440p>~   | | Lenovo ThinkPad T460s     | ~<nixos-hardware/lenovo/thinkpad/t460s>~   | | Lenovo ThinkPad X140e     | ~<nixos-hardware/lenovo/thinkpad/x140e>~   | | Lenovo ThinkPad X220      | ~<nixos-hardware/lenovo/thinkpad/x220>~    | <del> | Microsoft Surface Pro 3   | ~<nixos-hardware/microsoft/surface-pro/3>~ | | Raspberry Pi 2            | ~<nixos-hardware/raspberry-pi/2>~          | | Samsung Series 9 NP900X3C | ~<nixos-hardware/samsung/np900x3c>~        | </del> <ins> | Lenovo ThinkPad X250      | ~<nixos-hardware/lenovo/thinkpad/x250>~    | | [[file:microsoft/surface-pro/3][Microsoft Surface Pro 3]]   | ~<nixos-hardware/microsoft/surface-pro/3>~ | | [[file:raspberry-pi/2][Raspberry Pi 2]]            | ~<nixos-hardware/raspberry-pi/2>~          | | [[file:samsung/np900x3c][Samsung Series 9 NP900X3C]] | ~<nixos-hardware/samsung/np900x3c>~        | </ins> | Supermicro A1SRi-2758F    | ~<nixos-hardware/supermicro/a1sri-2758f>~  | | Supermicro X10SLL-F       | ~<nixos-hardware/supermicro/x10sll-f>~     | |---------------------------+--------------------------------------------|


Question:
write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?

<del> { lib, ... }: </del> <ins> { config, lib, ... }: </ins> { <ins> boot.kernelParams = [ "hid_apple.iso_layout=0" ]; hardware.facetimehd.enable = lib.mkDefault (config.nixpkgs.config.allowUnfree or false); </ins> services.mbpfan.enable = lib.mkDefault true; }


Question:
write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?

<ins> { lib, ... }: { imports = [ ../. ]; boot.kernelParams = [ "acpi_backlight=vendor" ]; services.xserver.deviceSection = lib.mkDefault '' Option "TearFree" "true" ''; } </ins>


Question:
write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?

"vm.laptop_mode" = lib.mkDefault 5; }; <ins> # TODO: fix in NixOS/nixpkgs # Disable governor set in hardware-configuration.nix, # required when services.tlp.enable is true: powerManagement.cpuFreqGovernor = lib.mkForce null; </ins> services.tlp.enable = lib.mkDefault true; }


Question:
write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?

<ins> { config, lib, pkgs, ... }: { imports = [ ../. ../../../common/cpu/intel ]; # Thinkfan is enabled by thinkpad profile. # However it requires to set a different `sensor` for this hardware, since there is no /proc/acpi/ibm/thermal # Regulation also works fine without thinkfan daemon though. services.thinkfan.enable = lib.mkOverride 900 false; # maintainers: Mic92 } </ins>


Question:
write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?

<ins> ** Status The code in master as of June 2015 should be able to prepare a bootable NixOS for Raspberry PI 2. There are still some drawbacks: NixOS does not provide a /boot/config.txt (the FAT32 partition). Making NixOS work in the Raspberry PI 2 is mainly the result of the recent work of ambro718, Dezgeg and viric (#nixos@irc.freenode.net). ** Download If you want to test, you can flash this 4GB SD image (DOS partition table + fat32 + ext4 rootfs): magnet:?xt=urn:btih:0def3f6acb3bceddb22cb24098f58e40e2853ec2&dn=rpi2-nixos-4b09501f2-img.xz&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80 Then you should be able to nixos-rebuild any configuration.nix changes. The image is the result of a "nixos-install" alone. No root password has been set, and it does not include a nixpkgs checkout or channel. In fact I (viric) created the FS into a NBD, not a real SD, to create this image. </ins>


Question:
write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?

<del> imported from https://nixos.org/wiki/Raspberry_Pi_2 ** # Status The code in master as of June 2015 should be able to prepare a bootable NixOS for Raspberry PI 2. There are still some drawbacks: NixOS does not provide a /boot/config.txt (the FAT32 partition). Making NixOS work in the Raspberry PI 2 is mainly the result of the recent work of ambro718, Dezgeg and viric (#nixos@irc.freenode.net). # Download If you want to test, you can flash this 4GB SD image (DOS partition table + fat32 + ext4 rootfs): magnet:?xt=urn:btih:0def3f6acb3bceddb22cb24098f58e40e2853ec2&dn=rpi2-nixos-4b09501f2-img.xz&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80 Then you should be able to nixos-rebuild any configuration.nix changes. The image is the result of a "nixos-install" alone. No root password has been set, and it does not include a nixpkgs checkout or channel. In fact I (viric) created the FS into a NBD, not a real SD, to create this image. </del>


Question:
, (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
` will take some effort.

{ lib, stdenv <del> , fetchurl, fetchFromGitHub </del> <ins> , fetchurl, fetchFromGitHub, fetchpatch </ins> , cmake, pkgconfig, unzip, zlib, pcre, hdf5 , glog, boost, gflags, protobuf , config


Question:
, (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
` will take some effort.

cp --no-preserve=mode -r "${contribSrc}/modules" "$NIX_BUILD_TOP/source/opencv_contrib" ''; <ins> patches = [ (fetchpatch { url = "https://github.com/opencv/opencv/commit/5691d998ead1d9b0542bcfced36c2dceb3a59023.patch"; name = "CVE-2019-14493.patch"; sha256 = "14qva9f5z10apz5q0skdyiclr9sgkhab4fzksy1w3b6j6hg4wm7m"; }) ]; </ins> # This prevents cmake from using libraries in impure paths (which # causes build failure on non NixOS) # Also, work around https://github.com/NixOS/nixpkgs/issues/26304 with


Question:
Project description Imageboard/booru downloader which can download thousands of images from multiple boorus very easily. Metadata homepage URL: source URL: license: Apache-2.0 platforms: Windows, Mac, and Linux
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still not packaged for NixOS. So still important (at least to me). I'm trying to package it myself, but it doesn't work due to dependencies on packages from NPM.
Going to take a look at this after I open a PR for .

<ins> { stdenv , cmake , fetchFromGitHub , wrapQtAppsHook , qtmultimedia , qttools , qtscript , qtdeclarative , qtbase , autogen , automake , makeWrapper , catch2 , nodejs , libpulseaudio , openssl , rsync , typescript }: stdenv.mkDerivation rec { name = "imgbrd-grabber"; version = "7.3.2"; src = fetchFromGitHub { owner = "Bionus"; repo = "imgbrd-grabber"; rev = "v${version}"; sha256 = "053rwvcr88fcba0447a6r115cgnqsm9rl066z8d5jacqnhdij58k"; fetchSubmodules = true; }; buildInputs = [ openssl makeWrapper libpulseaudio typescript ]; nativeBuildInputs = [ qtmultimedia qtbase qtdeclarative qttools nodejs cmake wrapQtAppsHook ]; extraOutputsToLink = [ "doc" ]; postPatch = '' # the package.sh script provides some install helpers # using this might make it easier to maintain/less likely for the # install phase to fail across version bumps patchShebangs ./scripts/package.sh # ensure the script uses the rsync package from nixpkgs substituteInPlace ../scripts/package.sh --replace "rsync" "${rsync}/bin/rsync" # the npm build step only runs typescript # run this step directly so it doesn't try and fail to download the unnecessary node_modules, etc. substituteInPlace ./sites/CMakeLists.txt --replace "npm install" "npm run build" # remove the vendored catch2 rm -rf tests/src/vendor/catch # link the catch2 sources from nixpkgs ln -sf ${catch2.src} tests/src/vendor/catch ''; postInstall = '' # move the binaries to the share/Grabber folder so # some relative links can be resolved (e.g. settings.ini) mv $out/bin/* $out/share/Grabber/ cd ../.. # run the package.sh with $out/share/Grabber as the $APP_DIR sh ./scripts/package.sh $out/share/Grabber # add symlinks for the binaries to $out/bin ln -s $out/share/Grabber/Grabber $out/bin/Grabber ln -s $out/share/Grabber/Grabber-cli $out/bin/Grabber-cli ''; sourceRoot = "source/src"; } </ins>


Question:
Project description Imageboard/booru downloader which can download thousands of images from multiple boorus very easily. Metadata homepage URL: source URL: license: Apache-2.0 platforms: Windows, Mac, and Linux
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still not packaged for NixOS. So still important (at least to me). I'm trying to package it myself, but it doesn't work due to dependencies on packages from NPM.
Going to take a look at this after I open a PR for .

img2pdf = with python3Packages; toPythonApplication img2pdf; <ins> imgbrd-grabber = qt5.callPackage ../applications/graphics/imgbrd-grabber/default.nix { typescript = nodePackages.typescript; }; </ins> imgcat = callPackage ../applications/graphics/imgcat { }; imgp = python3Packages.callPackage ../applications/graphics/imgp { };


Question:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps

{ config, stdenv, fetchurl, fetchFromGitHub, makeWrapper <del> , docutils, perl, pkgconfig, python3, which, ffmpeg_4 , freefont_ttf, freetype, libass, libpthreadstubs, mujs </del> <ins> , addOpenGLRunpath, docutils, perl, pkgconfig, python3, which , ffmpeg_4, freefont_ttf, freetype, libass, libpthreadstubs, mujs </ins> , nv-codec-headers, lua, libuchardet, libiconv ? null, darwin , waylandSupport ? stdenv.isLinux


Question:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps

''; nativeBuildInputs = [ <del> docutils makeWrapper perl pkgconfig python3 which </del> <ins> addOpenGLRunpath docutils makeWrapper perl pkgconfig python3 which </ins> ]; buildInputs = [


Question:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps

${wrapperFlags} ''; <ins> # Set RUNPATH so that libcuda in /run/opengl-driver(-32)/lib can be found. # See the explanation in addOpenGLRunpath. postFixup = optionalString stdenv.isLinux '' addOpenGLRunpath $out/bin/.mpv-wrapped ''; </ins> meta = with stdenv.lib; { description = "A media player that supports many video formats (MPlayer and mplayer2 fork)"; homepage = https://mpv.io; license = licenses.gpl2Plus; <del> maintainers = with maintainers; [ AndersonTorres fuuzetsu fpletz globin ]; </del> <ins> maintainers = with maintainers; [ AndersonTorres fuuzetsu fpletz globin ivan ]; </ins> platforms = platforms.darwin ++ platforms.linux; longDescription = ''


Question:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps

<del> { stdenv, fetchurl, pkgconfig, perl, texinfo, yasm </del> <ins> { stdenv, fetchurl, pkgconfig, addOpenGLRunpath, perl, texinfo, yasm </ins> , alsaLib, bzip2, fontconfig, freetype, gnutls, libiconv, lame, libass, libogg , libssh, libtheora, libva, libdrm, libvorbis, libvpx, lzma, libpulseaudio, soxr , x264, x265, xvidcore, zlib, libopus, speex, nv-codec-headers, dav1d


Question:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps

let inherit (stdenv) isDarwin isFreeBSD isLinux isAarch32; <del> inherit (stdenv.lib) optional optionals enableFeature; </del> <ins> inherit (stdenv.lib) optional optionals optionalString enableFeature; </ins> cmpVer = builtins.compareVersions; reqMin = requiredVersion: (cmpVer requiredVersion branch != 1);


Question:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps

"--enable-cross-compile" ] ++ optional stdenv.cc.isClang "--cc=clang"; <del> nativeBuildInputs = [ perl pkgconfig texinfo yasm ]; </del> <ins> nativeBuildInputs = [ addOpenGLRunpath perl pkgconfig texinfo yasm ]; </ins> buildInputs = [ bzip2 fontconfig freetype gnutls libiconv lame libass libogg libssh libtheora


Question:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps

substituteInPlace $pc  --replace "includedir=$out" "includedir=''${!outputInclude}" done <ins> '' + optionalString stdenv.isLinux '' # Set RUNPATH so that libnvcuvid in /run/opengl-driver(-32)/lib can be found. # See the explanation in addOpenGLRunpath. addOpenGLRunpath $out/lib/libavcodec.so* </ins> ''; installFlags = [ "install-man" ];


Question:
Describe the bug A clear and concise description of what the bug is. When running dolphin on plasma5, getting this error: /cc To Reproduce Steps to reproduce the behavior: dolphin "Search for -Document" error Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(mbauer): nixpkgs: Maintainer information:
It looks like adding to systemPackage fixes it.
cc
There is also a similar bug with Kmail if you don't include Akonadi in system path. Something must have changed in the way binaries are found.
We should make sure that puts in ; actually, anything that provides a should.

maintainers = [ lib.maintainers.ttuegel ]; }; nativeBuildInputs = [ extra-cmake-modules kdoctools ]; <ins> propagatedUserEnvPkgs = [ baloo ]; </ins> propagatedBuildInputs = [ baloo baloo-widgets kactivities kbookmarks kcmutils kcompletion kconfig kcoreaddons kdelibs4support kdbusaddons kfilemetadata ki18n kiconthemes


Question:
Describe the bug Currently the python 3.7 module (the other versions likely too, but I have not tested this yet) fails due to some numeric discrepancy caused by a recent upgrade of . This breaks ~26 downstream packages. I'm filing this to keep track of this for and am currently bisecting to confirm and test some other versions too. This is caused by a singular test failure: Upstream issue: Full hydra log: To Reproduce Steps to reproduce the behavior: on or . fails Expected behavior Tests should pass. Maintainer information:
Fixed by

# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}


Question:
Describe the bug Currently the python 3.7 module (the other versions likely too, but I have not tested this yet) fails due to some numeric discrepancy caused by a recent upgrade of . This breaks ~26 downstream packages. I'm filing this to keep track of this for and am currently bisecting to confirm and test some other versions too. This is caused by a singular test failure: Upstream issue: Full hydra log: To Reproduce Steps to reproduce the behavior: on or . fails Expected behavior Tests should pass. Maintainer information:
Fixed by

, lib , buildPythonPackage , fetchPypi <ins> , fetchpatch </ins> , gfortran, glibcLocales , numpy, scipy, pytest, pillow , cython


Question:
Describe the bug Currently the python 3.7 module (the other versions likely too, but I have not tested this yet) fails due to some numeric discrepancy caused by a recent upgrade of . This breaks ~26 downstream packages. I'm filing this to keep track of this for and am currently bisecting to confirm and test some other versions too. This is caused by a singular test failure: Upstream issue: Full hydra log: To Reproduce Steps to reproduce the behavior: on or . fails Expected behavior Tests should pass. Maintainer information:
Fixed by

]; checkInputs = [ pytest ]; <ins> patches = [ # Fixes tests by changing threshold of a test-case that broke # with numpy versions >= 1.17. This should be removed for versions > 0.21.2. ( fetchpatch { url = "https://github.com/scikit-learn/scikit-learn/commit/b730befc821caec5b984d9ff3aa7bc4bd7f4d9bb.patch"; sha256 = "0z36m05mv6d494qwq0688rgwa7c4bbnm5s2rcjlrp29fwn3fy1bv"; }) ]; </ins> LC_ALL="en_US.UTF-8"; doCheck = !stdenv.isAarch64;


Question: , (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.


Question:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

{ fetchFromGitHub, stdenv, cmake, openssl, zlib, libuv }: <del> stdenv.mkDerivation rec { pname = "libwebsockets"; version = "3.2.0"; src = fetchFromGitHub { owner = "warmcat"; repo = "libwebsockets"; rev = "v${version}"; sha256 = "0ac5755h3w1pl6cznqbvg63dwkqy544fqlhvqyp7s11hgs7jx6l8"; </del> <ins> let generic = { version, sha256 }: stdenv.mkDerivation rec { pname = "libwebsockets"; inherit version; src = fetchFromGitHub { owner = "warmcat"; repo = "libwebsockets"; rev = "v${version}"; inherit sha256; }; buildInputs = [ openssl zlib libuv ]; nativeBuildInputs = [ cmake ]; cmakeFlags = [ "-DLWS_WITH_PLUGINS=ON" ]; meta = with stdenv.lib; { description = "Light, portable C library for websockets"; longDescription = '' Libwebsockets is a lightweight pure C library built to use minimal CPU and memory resources, and provide fast throughput in both directions. ''; homepage = "https://libwebsockets.org/"; license = licenses.lgpl21; platforms = platforms.all; }; </ins> }; <del> buildInputs = [ cmake openssl zlib libuv ]; cmakeFlags = [ "-DLWS_WITH_PLUGINS=ON" ]; meta = { description = "Light, portable C library for websockets"; longDescription = '' Libwebsockets is a lightweight pure C library built to use minimal CPU and memory resources, and provide fast throughput in both directions. ''; homepage = https://github.com/warmcat/libwebsockets; license = stdenv.lib.licenses.lgpl21; platforms = stdenv.lib.platforms.all; </del> <ins> in rec { libwebsockets_3_1 = generic { sha256 = "1w1wz6snf3cmcpa3f4dci2nz9za2f5rrylxl109id7bcb36xhbdl"; version = "3.1.0"; </ins> }; <ins> libwebsockets_3_2 = generic { version = "3.2.0"; sha256 = "0ac5755h3w1pl6cznqbvg63dwkqy544fqlhvqyp7s11hgs7jx6l8"; }; libwebsockets = libwebsockets_3_2; </ins> }


Question:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

{ stdenv, lib, fetchFromGitHub, cmake, docbook_xsl, libxslt <del> , openssl, libuuid, libwebsockets, c-ares, libuv </del> <ins> , openssl, libuuid, libwebsockets_3_1, c-ares, libuv </ins> , systemd ? null, withSystemd ? stdenv.isLinux }: stdenv.mkDerivation rec { pname = "mosquitto"; <del> version = "1.6.4"; </del> <ins> version = "1.6.5"; </ins> src = fetchFromGitHub { owner  = "eclipse"; repo   = "mosquitto"; rev    = "v${version}"; <del> sha256 = "1kr1dgc4nzhyg3rzymbv4rka3rpb30rwsy6binb7apnw3n3ff58l"; </del> <ins> sha256 = "0scgsi3rvs9s8vxv4r7d5d9ixbsfg4dwnjcy6zxwdz9dfn8qnngj"; </ins> }; postPatch = ''