Question:
are you on top of this?
Thanks for the heads up, yeah, just waited for the GitHub releases to appear. I’ll create a PR soon.

}: python3.pkgs.buildPythonApplication rec { pname = "salt"; <del> version = "3003.3"; </del> <ins> version = "3003.4"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "pvnIyLXiYA6oYgtKZzcd4XYRvrT42X5LubCzCKN+0eI="; </del> <ins> sha256 = "53uAjlG0HX5Jae4VWIrAT9DbmzPfonEPVEGNfrOHJM0="; </ins> }; propagatedBuildInputs = with python3.pkgs; [


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: lapce <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine

rustPlatform.buildRustPackage rec { pname = "lapce"; <del> version = "0.0.10"; </del> <ins> version = "0.0.12"; </ins> src = fetchFromGitHub { owner = "lapce"; repo = pname; rev = "v${version}"; <del> sha256 = "tOVFm4DFQurFU4DtpPwxXQLbTGCZnrV1FfYKtvkRxRE="; </del> <ins> sha256 = "sha256-ZFQjQ5+G0b0Fgg3+du/drt+62rC/TCNR5MIdJXAkTrE="; </ins> }; <del> cargoPatches = [ ./fix-version.patch ]; cargoSha256 = "BwB3KgmI5XnZ5uHv6f+kGKBzpyxPWcoKvF7qw90eorI="; </del> <ins> cargoSha256 = "sha256-sMTootPsenaWzLLFImo6HWC1pcm2uFupPhVWsUJp1Ak="; </ins> nativeBuildInputs = [ cmake


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: lapce <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine

<del> diff --git a/Cargo.lock b/Cargo.lock index bc9a0f8..45a74ad 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -2165,7 +2165,7 @@ dependencies = [ [[package]] name = "lapce" -version = "0.0.9" +version = "0.0.10" dependencies = [ "lapce-core", "lapce-proxy", @@ -2173,7 +2173,7 @@ dependencies = [ [[package]] name = "lapce-core" -version = "0.0.9" +version = "0.0.10" dependencies = [ "Inflector", "alacritty_terminal 0.15.0", @@ -2233,7 +2233,7 @@ dependencies = [ [[package]] name = "lapce-proxy" -version = "0.0.9" +version = "0.0.10" dependencies = [ "alacritty_terminal 0.16.0-rc2", "anyhow", </del>


Question:
After the update, with an seemingly related build error on . This blocks the channel at the moment. Possibly related: . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc
Note: this affects both unstable and 21.11.
Is there any plan to make a different branch? unstable has been blocked for every platform for half a month because of darwin issues (after just a few days of being working after another blockage of more than a week also because of darwin).
From the perspective of a dual darwin/linux user, the issue seems to be that insufficiently tested PRs keep getting merged to master, which repeatedly regress behavior on darwin and break unstable. I'm not sure how downgrading darwin to not even deserve a place on unstable will do anything to alleviate the deeper issue that the PRs aren't being tested enough in the first place.
If you use a Linux, why don't you use NixOS channels instead? Even if you don't use a NixOS, the packages get extra testing through the NixOS tests.
From the perspective of a person without any Apple devices, testing darwin stuff is quite hard, even though builds work nowadays, at least for small rebuilds. Some people get even annoyed by having to deal with darwin-specific issues, and I have sympathy for that. The zlib update in particular fixes quite a severe security problem. I certainly would not want to delay that on Linux (or even on Darwins) because of this qtbase regression.
That’s fair of course - the status quo has lots of underlying factors! I know it’s outside the scope of this issue, but should we all think about how to use some of the recently Mac build machines to, say, be able to trigger something like a more full nixpkgs-review on packages that could cascade a bunch of failures like this? Barring that, I know that the Darwin maintainers group has grown a lot. If we could find a way to get looped in on some of these changes before merge, that might help avoid the breakage churn. There’s gotta be a way to help Linux-only maintainers and committers prevent regressions more proactively, rather than frantically fixing things after the fact. Sorry I don’t have an obvious solution!
Well, it depends. This regression in particular was known and reported (to a thread with quite many participants) before merging to master.
Is it possible to use nixos-unstable with home-manager in a non nixOS distro? If it is, I had no idea.
I don't think there can be anything preventing it. Though I don't really know home-manager in particular.
I use (along with ) on macOS, so presumably yes. The branch isn’t NixOS-specific. It’s just what criteria are used to advance the branch (so sometimes things are broken on Darwin IME).
Non-NixOS Linuxes use the same binaries as NixOS (contrary to darwin). And you always have the whole binary cache available, not just what's associated with the particular channel.
Thanks a lot, I'm changing to that branch right now, you made my day.
Fwiw, for Darwin in particular, nixpkgs-unstable does run some tests that nixos-unstable doesn't.
Yes, NixOS channels have no dependency on darwin at all.
I did the change and it's working nice, but some packages are not getting downloaded from the cache (till now zathura and llpp) and painfully they also fail while compiling locally no idea why, any pointer to what can I check??. I know this is not the place to ask this kind of questions but I don't know which is the correct one either.
There's no guarantee that everything in nixpkgs is working all the time, for zathura see .

--replace 'ARFLAGS="-o"' 'ARFLAGS="-r"' ''; <ins> patches = [ ./fix-configure-issue-cross.patch ]; </ins> outputs = [ "out" "dev" ] ++ lib.optional splitStaticOutput "static"; setOutputFlags = false;


Question:
After the update, with an seemingly related build error on . This blocks the channel at the moment. Possibly related: . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc
Note: this affects both unstable and 21.11.
Is there any plan to make a different branch? unstable has been blocked for every platform for half a month because of darwin issues (after just a few days of being working after another blockage of more than a week also because of darwin).
From the perspective of a dual darwin/linux user, the issue seems to be that insufficiently tested PRs keep getting merged to master, which repeatedly regress behavior on darwin and break unstable. I'm not sure how downgrading darwin to not even deserve a place on unstable will do anything to alleviate the deeper issue that the PRs aren't being tested enough in the first place.
If you use a Linux, why don't you use NixOS channels instead? Even if you don't use a NixOS, the packages get extra testing through the NixOS tests.
From the perspective of a person without any Apple devices, testing darwin stuff is quite hard, even though builds work nowadays, at least for small rebuilds. Some people get even annoyed by having to deal with darwin-specific issues, and I have sympathy for that. The zlib update in particular fixes quite a severe security problem. I certainly would not want to delay that on Linux (or even on Darwins) because of this qtbase regression.
That’s fair of course - the status quo has lots of underlying factors! I know it’s outside the scope of this issue, but should we all think about how to use some of the recently Mac build machines to, say, be able to trigger something like a more full nixpkgs-review on packages that could cascade a bunch of failures like this? Barring that, I know that the Darwin maintainers group has grown a lot. If we could find a way to get looped in on some of these changes before merge, that might help avoid the breakage churn. There’s gotta be a way to help Linux-only maintainers and committers prevent regressions more proactively, rather than frantically fixing things after the fact. Sorry I don’t have an obvious solution!
Well, it depends. This regression in particular was known and reported (to a thread with quite many participants) before merging to master.
Is it possible to use nixos-unstable with home-manager in a non nixOS distro? If it is, I had no idea.
I don't think there can be anything preventing it. Though I don't really know home-manager in particular.
I use (along with ) on macOS, so presumably yes. The branch isn’t NixOS-specific. It’s just what criteria are used to advance the branch (so sometimes things are broken on Darwin IME).
Non-NixOS Linuxes use the same binaries as NixOS (contrary to darwin). And you always have the whole binary cache available, not just what's associated with the particular channel.
Thanks a lot, I'm changing to that branch right now, you made my day.
Fwiw, for Darwin in particular, nixpkgs-unstable does run some tests that nixos-unstable doesn't.
Yes, NixOS channels have no dependency on darwin at all.
I did the change and it's working nice, but some packages are not getting downloaded from the cache (till now zathura and llpp) and painfully they also fail while compiling locally no idea why, any pointer to what can I check??. I know this is not the place to ask this kind of questions but I don't know which is the correct one either.
There's no guarantee that everything in nixpkgs is working all the time, for zathura see .

<ins> From 05796d3d8d5546cf1b4dfe2cd72ab746afae505d Mon Sep 17 00:00:00 2001 From: Mark Adler <madler@alumni.caltech.edu> Date: Mon, 28 Mar 2022 18:34:10 -0700 Subject: [PATCH] Fix configure issue that discarded provided CC definition. --- configure | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure b/configure index 52ff4a04e..3fa3e8618 100755 --- a/configure +++ b/configure @@ -174,7 +174,10 @@ if test -z "$CC"; then else cc=${CROSS_PREFIX}cc fi +else +  cc=${CC} fi + cflags=${CFLAGS-"-O3"} # to force the asm version use: CFLAGS="-O3 -DASMV" ./configure case "$cc" in </ins>


Question:
Steps to reproduce the behavior: Please run and paste the result.
Thank you for reporting this issue; I can reproduce it. The problem is not in the warning displayed in the last 10 log lines, but in an earlier error: Unfortunately I don't think that I will be able to contribute further to this issue.
I'm aware of this failure, but fixing it will require a bit of patching. Upstream didn't update the package to ghc 9 yet. Right now I don't have much time to do that, so in the meantime you could install it from stable, where it does build. Please change the title to something like "jl: build failure due to ghc 9"
This has been correctly marked broken in . See also where there was a small amount of discussion about marking this broken.
I've created an upstream .
The PR is now merged, and the package is now on Hackage for the first time. However, since it's not been to Stackage Nightly yet, it won't make its way into for quite some time. I'll update the derivation to use the new version directly from Hackage.

}: mkDerivation rec { pname = "jl"; <del> version = "0.0.5"; src = fetchFromGitHub { owner = "chrisdone"; repo = "jl"; rev = "v${version}"; sha256 = "1hlnwsl4cj0l4x8dxwda2fcnk789cwlphl9gv9cfrivl43mgkgar"; }; patches = [ # MonadFail compatibility patch. Should be removed with the next release (fetchpatch { url = "https://github.com/chrisdone/jl/commit/6d40308811cbc22a96b47ebe69ec308b4e9fd356.patch"; sha256 = "1pg92ffkg8kim5r8rz8js6fjqyjisg1266sf7p9jyxjgsskwpa4g"; }) ]; </del> <ins> version = "0.1.0"; sha256 = "15vvn3swjpc5qmdng1fcd8m9nif4qnjmpmxc9hdw5cswzl055lkj"; </ins> isLibrary = true; isExecutable = true; libraryHaskellDepends = [


Question:
Steps to reproduce the behavior: Please run and paste the result.
Thank you for reporting this issue; I can reproduce it. The problem is not in the warning displayed in the last 10 log lines, but in an earlier error: Unfortunately I don't think that I will be able to contribute further to this issue.
I'm aware of this failure, but fixing it will require a bit of patching. Upstream didn't update the package to ghc 9 yet. Right now I don't have much time to do that, so in the meantime you could install it from stable, where it does build. Please change the title to something like "jl: build failure due to ghc 9"
This has been correctly marked broken in . See also where there was a small amount of discussion about marking this broken.
I've created an upstream .
The PR is now merged, and the package is now on Hackage for the first time. However, since it's not been to Stackage Nightly yet, it won't make its way into for quite some time. I'll update the derivation to use the new version directly from Hackage.

description = "Functional sed for JSON"; maintainers = with lib.maintainers; [ fgaz ]; homepage = "https://github.com/chrisdone/jl"; <del> # jl needs to be updated to work with aeson-2.0. # As far as I can tell, there is unfortunately no where to report issues upstream # for us to be able to track when upstream adds aeson-2.0 support. hydraPlatforms = lib.platforms.none; broken = true; </del> }


Question:
While checking why we have two subversion releases I noticed that both releases are LTS versions. They receive 4 years of support and 1.10 was first released on 2018-04-13, so it's probably wise to remove it before the 22.05 release. Originally posted by in
I don't see anything that depends on in nixpkgs (anymore), so IMO we can just remove it now, instead of waiting for some kind of EOL announcement.

}); in { <del> subversion_1_10 = common { version = "1.10.8"; sha256 = "sha256-CnO6MSe1ov/7j+4rcCmE8qgI3nEKjbKLfdQBDYvlDlo="; }; </del> subversion = common { version = "1.14.2"; sha256 = "sha256-yRMOjQt1copm8OcDj8dwUuZxgw14W1YWqtU7SBDTzCg=";


Question:
While checking why we have two subversion releases I noticed that both releases are LTS versions. They receive 4 years of support and 1.10 was first released on 2018-04-13, so it's probably wise to remove it before the 22.05 release. Originally posted by in
I don't see anything that depends on in nixpkgs (anymore), so IMO we can just remove it now, instead of waiting for some kind of EOL announcement.

stanchion = throw "Stanchion was part of riak-cs which is not maintained anymore"; # added 2020-10-14 steam-run-native = steam-run; # added 2022-02-21 stumpwm-git = throw "stumpwm-git has been broken for a long time and lispPackages.stumpwm follows Quicklisp that is close to git version"; # Added 2021-05-09 <ins> subversion_1_10 = throw "subversion_1_10 has been removed as it has reached its end of life"; # Added 2022-04-26 </ins> subversion19 = throw "subversion19 has been removed as it has reached its end of life"; # Added 2021-03-31 sudolikeaboss = throw "sudolikeaboss is no longer maintained by upstream"; # Added 2022-04-16 sundials_3 = throw "sundials_3 was removed in 2020-02. outdated and no longer needed";


Question:
While checking why we have two subversion releases I noticed that both releases are LTS versions. They receive 4 years of support and 1.10 was first released on 2018-04-13, so it's probably wise to remove it before the 22.05 release. Originally posted by in
I don't see anything that depends on in nixpkgs (anymore), so IMO we can just remove it now, instead of waiting for some kind of EOL announcement.

sublime-merge-dev; inherit (callPackages ../applications/version-management/subversion { sasl = cyrus_sasl; }) <del> subversion_1_10 subversion; </del> <ins> subversion; </ins> subversionClient = subversion.override { bdbSupport = false;


Question:
Try to build for . Note, I'm trying staging because is necessary. fails: staging is at :
This was caused by setuptools 60, which now uses bundled distutils. All Python packages with extension modules fail to cross-compile currently, but this will be fixed by . I also noticed that the libbtrfsutil Python bindings are never actually installed, so I also created .

{ stdenv , buildPythonPackage , fetchFromGitHub <ins> , fetchpatch </ins> , python , bootstrapped-pip , lib


Question:
Try to build for . Note, I'm trying staging because is necessary. fails: staging is at :
This was caused by setuptools 60, which now uses bundled distutils. All Python packages with extension modules fail to cross-compile currently, but this will be fixed by . I also noticed that the libbtrfsutil Python bindings are never actually installed, so I also created .

patches = [ ./tag-date.patch ./setuptools-distutils-C++.patch <ins> # Use sysconfigdata to find headers. Fixes cross-compilation of extension modules. # https://github.com/pypa/distutils/pull/145 (fetchpatch { url = "https://github.com/pypa/distutils/commit/aed7294b7b0c228cc0666a8b04f2959bf310ab57.patch"; hash = "sha256-/9+TKv0nllBfnj48zcXLrOgyBj52dBIVbrpnIaQ4O84="; stripLen = 2; extraPrefix = "setuptools/_distutils/"; }) </ins> ]; buildPhase = ''


Question:
For example: fails similarly. The line that causes the failure according to my testing is: A list of some packages that didn't break: Could be this is an upstream issue.
So digging into it, this is an issue raised by Octave's package management system itself. Namely, this -statement from Line 80 in that file is the statement. It expects to remove a file, which is not existing. The reason the other packages did not break was because they either do not have a directory () or they actually do have a generated file (netcdf & control). You can technically solve this by adding an empty script to the directory. I manually did this, and the package built correctly again. As for why this change happened, I cannot tell. The particular statement shown did not change between 6.4.0 and 7.1.0 in the file.
Looks like
That's the exact issue. Seems like we will need to wait for upstream to fix it. How does this usually get handled
Seems like we should apply to the patch:
There are still 5 packages failing to build, but that is a lot fewer than before.

sha256 = "sha256-1KnYHz9ntKbgfLeoDcsQrV6RdvzDB2LHCoFYCmS4sLY="; }; <ins> patches = [ # https://savannah.gnu.org/bugs/?func=detailitem&item_id=62436 ./patches/bug62436.patch ]; </ins> buildInputs = [ readline ncurses


Question:
For example: fails similarly. The line that causes the failure according to my testing is: A list of some packages that didn't break: Could be this is an upstream issue.
So digging into it, this is an issue raised by Octave's package management system itself. Namely, this -statement from Line 80 in that file is the statement. It expects to remove a file, which is not existing. The reason the other packages did not break was because they either do not have a directory () or they actually do have a generated file (netcdf & control). You can technically solve this by adding an empty script to the directory. I manually did this, and the package built correctly again. As for why this change happened, I cannot tell. The particular statement shown did not change between 6.4.0 and 7.1.0 in the file.
Looks like
That's the exact issue. Seems like we will need to wait for upstream to fix it. How does this usually get handled
Seems like we should apply to the patch:
There are still 5 packages failing to build, but that is a lot fewer than before.

<ins> # HG changeset patch # User John Donoghue <john.donoghue@ieee.org> # Date 1652358904 14400 #      Thu May 12 08:35:04 2022 -0400 # Branch stable # Node ID 8c940cfcce257369677c09154da2aab2c56eaa79 # Parent  63710f3bd9811c2d206ac9e7b4f47cf06c47e153 * scripts/pkg/private/build.m: check configure and Makefile exist before trying to unlink them (Bug #62436) diff -r 63710f3bd981 -r 8c940cfcce25 scripts/pkg/private/build.m --- a/scripts/pkg/private/build.m	Wed May 11 09:44:55 2022 -0700 +++ b/scripts/pkg/private/build.m	Thu May 12 08:35:04 2022 -0400 @@ -77,8 +77,12 @@ else arch_abi = getarch (); configure_make (desc, build_root, verbose); -      unlink (fullfile (build_root, "src", "configure")); -      unlink (fullfile (build_root, "src", "Makefile")); +      if exist (fullfile (build_root, "src", "configure"), "file") +        unlink (fullfile (build_root, "src", "configure")); +      endif +      if exist (fullfile (build_root, "src", "Makefile"), "file") +        unlink (fullfile (build_root, "src", "Makefile")); +      endif endif tar_name = [desc.name "-" desc.version "-" arch_abi ".tar"]; tar_path = fullfile (builddir, tar_name); </ins>


Question: Traceback (most recent call last): File "/nix/store/z4sd700l05shq1z72g21w0fav2xs955d-pipenv-2022.1.8/lib/python3.9/site-", line 83, in androidfolder from jnius import autoclass # noqa: SC200 ModuleNotFoundError: No module named 'jnius' The error is belong in pipenv using jnius on Android. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(nix-on-droid): nixpkgs:

githubId = 1550265; name = "Dominic Steinitz"; }; <ins> ifurther = { email = "55025025+ifurther@users.noreply.github.com"; github = "ifurther"; githubId = 55025025; name = "Feather Lin"; }; </ins> igsha = { email = "igor.sharonov@gmail.com"; github = "igsha";


Question: Traceback (most recent call last): File "/nix/store/z4sd700l05shq1z72g21w0fav2xs955d-pipenv-2022.1.8/lib/python3.9/site-", line 83, in androidfolder from jnius import autoclass # noqa: SC200 ModuleNotFoundError: No module named 'jnius' The error is belong in pipenv using jnius on Android. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(nix-on-droid): nixpkgs:

<ins> { buildPythonPackage , cython , fetchPypi , jdk , lib , six }: buildPythonPackage rec { pname = "pyjnius"; version = "1.4.1"; src = fetchPypi { inherit pname version; sha256 = "8bc1a1b06fb11df8dd8b8d56f5ecceab614d4ba70cf559c64ae2f146423d53ce"; }; propagatedBuildInputs = [ six ]; nativeBuildInputs = [ jdk cython ]; pythonImportsCheck = [ "jnius" ]; meta = with lib; { description = "A Python module to access Java classes as Python classes using the Java Native Interface (JNI)"; homepage = "https://github.com/kivy/pyjnius"; license = licenses.mit; maintainers = with maintainers; [ ifurther ]; }; } </ins>


Question: Traceback (most recent call last): File "/nix/store/z4sd700l05shq1z72g21w0fav2xs955d-pipenv-2022.1.8/lib/python3.9/site-", line 83, in androidfolder from jnius import autoclass # noqa: SC200 ModuleNotFoundError: No module named 'jnius' The error is belong in pipenv using jnius on Android. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(nix-on-droid): nixpkgs:

{ lib <ins> , stdenv </ins> , python3 , installShellFiles }:


Question: Traceback (most recent call last): File "/nix/store/z4sd700l05shq1z72g21w0fav2xs955d-pipenv-2022.1.8/lib/python3.9/site-", line 83, in androidfolder from jnius import autoclass # noqa: SC200 ModuleNotFoundError: No module named 'jnius' The error is belong in pipenv using jnius on Android. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(nix-on-droid): nixpkgs:

pip virtualenv virtualenv-clone <ins> ] ++ lib.optionals stdenv.hostPlatform.isAndroid [ pyjnius </ins> ]; pythonEnv = python3.withPackages runtimeDeps;


Question: Traceback (most recent call last): File "/nix/store/z4sd700l05shq1z72g21w0fav2xs955d-pipenv-2022.1.8/lib/python3.9/site-", line 83, in androidfolder from jnius import autoclass # noqa: SC200 ModuleNotFoundError: No module named 'jnius' The error is belong in pipenv using jnius on Android. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(nix-on-droid): nixpkgs:

pyjks = callPackage ../development/python-modules/pyjks { }; <ins> pyjnius = callPackage ../development/python-modules/pyjnius { }; </ins> pyjsparser = callPackage ../development/python-modules/pyjsparser { }; pyjwkest = callPackage ../development/python-modules/pyjwkest { };


Question:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm

inherit (packages) version; format = "wheel"; <del> disabled = pythonAtLeast "3.10"; </del> <ins> # See https://github.com/tensorflow/tensorflow/issues/55581#issuecomment-1101890383 disabled = pythonAtLeast "3.10" && !cudaSupport; </ins> src = let pyVerNoDot = lib.strings.stringAsChars (x: if x == "." then "" else x) python.pythonVersion;


Question:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm

( cd unpacked/tensorflow* # Adjust dependency requirements: <del> # - Relax gast version requirement that doesn't match what we have packaged </del> <ins> # - Relax tensorflow-estimator version requirement that doesn't match what we have packaged </ins> # - The purpose of python3Packages.libclang is not clear at the moment and we don't have it packaged yet # - keras and tensorlow-io-gcs-filesystem will be considered as optional for now. sed -i *.dist-info/METADATA  <del> -e "s/Requires-Dist: gast.*/Requires-Dist: gast/"  </del> <ins> -e "s/Requires-Dist: tf-estimator-nightly.*/Requires-Dist: tensorflow-estimator/"  </ins> -e "/Requires-Dist: libclang/d"  -e "/Requires-Dist: keras/d"  -e "/Requires-Dist: tensorflow-io-gcs-filesystem/d"


Question:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm

pythonImportsCheck = [ "tensorflow" <del> "tensorflow.keras" </del> "tensorflow.python" "tensorflow.python.framework" ];


Question:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm

{ <del> version = "2.7.0"; </del> <ins> version = "2.8.0"; </ins> linux_py_37_cpu = { <del> url = "https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow_cpu-2.7.0-cp37-cp37m-manylinux2010_x86_64.whl"; sha256 = "1irw4ri1fbxbj251cnjbr12gxsyj2k30asxjfxjpxhc9b0cchhx0"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow_cpu-2.8.0-cp37-cp37m-manylinux2010_x86_64.whl"; sha256 = "1nza8i0nvqgrcwj2yy74a3wgpgf52svf0yrz9xd6l18gsifkmkx0"; </ins> }; linux_py_38_cpu = { <del> url = "https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow_cpu-2.7.0-cp38-cp38-manylinux2010_x86_64.whl"; sha256 = "11a1rimr998lvvjdg03rqr8h2h7x6bbd4gyv74biwgaxmjczvjdj"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow_cpu-2.8.0-cp38-cp38-manylinux2010_x86_64.whl"; sha256 = "1li2gllznd5w3hh2w9ibh5lkvvssnwh5vhk7i873dxjjdl1w8sqy"; </ins> }; linux_py_39_cpu = { <del> url = "https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow_cpu-2.7.0-cp39-cp39-manylinux2010_x86_64.whl"; sha256 = "0x1zzmgq7hl2k98p8870h0yhaik39nc1ckvxirjx8simpj8ghsbp"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow_cpu-2.8.0-cp39-cp39-manylinux2010_x86_64.whl"; sha256 = "03swmyak1hb0k6b2fi9a8g76fi57jz30ym015a576iwp42pqcgkq"; }; linux_py_310_cpu = { url = "https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow_cpu-2.8.0-cp310-cp310-manylinux2010_x86_64.whl"; sha256 = ""; </ins> }; linux_py_37_gpu = { <del> url = "https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-2.7.0-cp37-cp37m-manylinux2010_x86_64.whl"; sha256 = "1x5yyxzkly9gdyhcfq4x7w7sqqxh6cw5qnfwbvzj5349xwrm63wi"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-2.8.0-cp37-cp37m-manylinux2010_x86_64.whl"; sha256 = "06q3vjrlqfkqa5r18hla3d8ms1sqa897g7fpnqizgh4k8skhm9fq"; </ins> }; linux_py_38_gpu = { <del> url = "https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-2.7.0-cp38-cp38-manylinux2010_x86_64.whl"; sha256 = "0prxa8yc6lbq62vnh8cw6dhcrnkdjih62kbg6pbw4gmgcbf6v6fg"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-2.8.0-cp38-cp38-manylinux2010_x86_64.whl"; sha256 = "0099aa5g19zi74n6bamhmmcgp096m41fhr61swkwnh92myz1ylgb"; </ins> }; linux_py_39_gpu = { <del> url = "https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-2.7.0-cp39-cp39-manylinux2010_x86_64.whl"; sha256 = "0jjv8vm20d0airml68bxhassp4yg09rcz2a39aa511cz8mavj0l6"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-2.8.0-cp39-cp39-manylinux2010_x86_64.whl"; sha256 = "0zw20yvlqga7znr13pa10qxww42mj64209syiicgvhs74ji1zdca"; }; linux_py_310_gpu = { url = "https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-2.8.0-cp310-cp310-manylinux2010_x86_64.whl"; sha256 = "06kwjlhzl46jhjcg836crys2aw39x0g8s1s9qfscm1kbwzbww1hq"; </ins> }; mac_py_37_cpu = { <del> url = "https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-2.7.0-cp37-cp37m-macosx_10_11_x86_64.whl"; sha256 = "1gr95ck0h4wzhdacjfhkzxdw4zglm85fc54swqhyzzv1f5n9vw8j"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-2.8.0-cp37-cp37m-macosx_10_14_x86_64.whl"; sha256 = "1z5w6wx3h45fz0ji9kn2m2kf963bqbvmqc7cyjv4ixymd0rp4jps"; </ins> }; mac_py_38_cpu = { <del> url = "https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-2.7.0-cp38-cp38-macosx_10_11_x86_64.whl"; sha256 = "1h3qlvlrwyvxynh5flvyqk7grbvyqc21ljqhlvds436hpn2kqrgb"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-2.8.0-cp38-cp38-macosx_10_14_x86_64.whl"; sha256 = "1h5v8flhc5zb038ld0av7638cyqqkrib379lrlzvf8dw7q8ry3yx"; </ins> }; mac_py_39_cpu = { <del> url = "https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-2.7.0-cp39-cp39-macosx_10_11_x86_64.whl"; sha256 = "0pyj1p2yik6ysdqn8n6cz1nqni0s9xx51ifmvdx4dl3hrzp86jz2"; </del> <ins> url = "https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-2.8.0-cp39-cp39-macosx_10_14_x86_64.whl"; sha256 = "0qsmlrf8h2gxkimniyrz9bniaqpdsd92pficmsrq30k8rkz2bwjj"; }; mac_py_310_cpu = { url = "https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-2.8.0-cp310-cp310-macosx_10_14_x86_64.whl"; sha256 = "0lnwbvil6c6ai10lcaj9ay9pya207s9g204273msjalm1hpbmhvq"; </ins> }; }


Question:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm

#!/usr/bin/env bash <del> version="2.7.0" </del> <ins> version="2.8.0" </ins> bucket="https://storage.googleapis.com/tensorflow"


Question:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm

"linux_py_37_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp37-cp37m-manylinux2010_x86_64.whl" "linux_py_38_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp38-cp38-manylinux2010_x86_64.whl" "linux_py_39_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp39-cp39-manylinux2010_x86_64.whl" <ins> "linux_py_310_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp310-cp310-manylinux2010_x86_64.whl" </ins> "linux_py_37_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp37-cp37m-manylinux2010_x86_64.whl" "linux_py_38_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp38-cp38-manylinux2010_x86_64.whl" "linux_py_39_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp39-cp39-manylinux2010_x86_64.whl" <del> "mac_py_37_cpu $bucket/mac/cpu/tensorflow-${version}-cp37-cp37m-macosx_10_11_x86_64.whl" "mac_py_38_cpu $bucket/mac/cpu/tensorflow-${version}-cp38-cp38-macosx_10_11_x86_64.whl" "mac_py_39_cpu $bucket/mac/cpu/tensorflow-${version}-cp39-cp39-macosx_10_11_x86_64.whl" </del> <ins> "linux_py_310_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp310-cp310-manylinux2010_x86_64.whl" "mac_py_37_cpu $bucket/mac/cpu/tensorflow-${version}-cp37-cp37m-macosx_10_14_x86_64.whl" "mac_py_38_cpu $bucket/mac/cpu/tensorflow-${version}-cp38-cp38-macosx_10_14_x86_64.whl" "mac_py_39_cpu $bucket/mac/cpu/tensorflow-${version}-cp39-cp39-macosx_10_14_x86_64.whl" "mac_py_310_cpu $bucket/mac/cpu/tensorflow-${version}-cp310-cp310-macosx_10_14_x86_64.whl" </ins> ) hashfile=binary-hashes.nix


Question:
Build of failed on x86_64-linux as of . This is currently breaking maintainers cc: google-cloud-cpp maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
This has also broken tensorflow-datasets.
Fixed in

google-guest-oslogin = callPackage ../tools/virtualization/google-guest-oslogin { }; <del> google-cloud-cpp = callPackage ../development/libraries/google-cloud-cpp { }; </del> <ins> google-cloud-cpp = callPackage ../development/libraries/google-cloud-cpp { abseil-cpp = abseil-cpp.override { cxxStandard = "14"; }; }; </ins> google-java-format = callPackage ../development/tools/google-java-format { };


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

# external apps shipped with linux-mint hexchat gnome-calculator <ins> gnome-screenshot </ins> ] config.environment.cinnamon.excludePackages; }) ];


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

python3.pkgs.buildPythonApplication rec { pname = "sticky"; <del> version = "1.11"; </del> <ins> version = "1.12"; </ins> format = "other"; src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> hash = "sha256-PXJpNKzF9goQvfh3lUUfOaZFessFNrWtg8nMDxPxRMo="; </del> <ins> hash = "sha256-kAO8Qz4bTn3+YeIXAvPZ1SpKgn+g+rBgi9+TaqL1vOY="; </ins> }; postPatch = ''


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

, cjs , clutter , fetchFromGitHub <ins> , fetchpatch </ins> , gdk-pixbuf <ins> , gettext </ins> , libgnomekbd , glib , gobject-introspection


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

stdenv.mkDerivation rec { pname = "cinnamon-common"; <del> version = "5.4.9"; </del> <ins> version = "5.4.10"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = "cinnamon"; rev = version; <del> hash = "sha256-nM87NO/dwOd+hN5/3zX7XUjyKvXh4uDhLcGFcKE9ccA="; </del> <ins> hash = "sha256-yNjFP32+0LXqHfJUxm1A+CTuwny5/IxxT08689f7VlE="; </ins> }; patches = [ ./use-sane-install-dir.patch ./libdir.patch <ins> # Re-add libsoup 2.4 as dependency - needed by some applets. # Can be removed on next update. (fetchpatch { url = "https://github.com/linuxmint/cinnamon/commit/76224fe409d074f8a44c70e4fd5e1289f92800b9.patch"; sha256 = "sha256-nDt4kkK1kVstxbij63XxTJ2L/TM9Q1P6feok3xlPQOM="; }) # keybindings.js: Use bindings.get(). # Can be removed on next update. # https://github.com/linuxmint/cinnamon/issues/11055 (fetchpatch { url = "https://github.com/linuxmint/cinnamon/commit/7724e4146baf8431bc1fb55dce60984e77adef5a.patch"; sha256 = "sha256-idGtkBa13nmoEprtmAr6OssO16wJwBd16r2ZbbhrYDQ="; }) </ins> ]; buildInputs = [


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

gsound gtk3 json-glib <del> libsoup </del> <ins> libsoup # referenced in js/ui/environment.js </ins> libstartup_notification libXtst libXdamage


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

sed "s| cinnamon-session| ${cinnamon-session}/bin/cinnamon-session|g" -i ./files/usr/bin/cinnamon-session-cinnamon  -i ./files/usr/bin/cinnamon-session-cinnamon2d sed "s|/usr/bin|$out/bin|g" -i ./files/usr/share/xsessions/cinnamon.desktop ./files/usr/share/xsessions/cinnamon2d.desktop <ins> sed "s|msgfmt|${gettext}/bin/msgfmt|g" -i ./files/usr/share/cinnamon/cinnamon-settings/bin/Spices.py </ins> patchShebangs src/data-to-c.pl '';


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

stdenv.mkDerivation rec { pname = "nemo"; <del> version = "5.4.2"; </del> <ins> version = "5.4.3"; </ins> # TODO: add plugins support (see https://github.com/NixOS/nixpkgs/issues/78327)


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

owner = "linuxmint"; repo = pname; rev = version; <del> sha256 = "sha256-Xn9CgGe7j2APaJRLvx58z2w+sN7ZeDScQz53ZBBnsQs="; </del> <ins> sha256 = "sha256-f3rO0lpOcwpSpIpKrslf6/6nqFbbGTwnKbHpWO+Uf+Q="; </ins> }; outputs = [ "out" "dev" ];


Question:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.

stdenv.mkDerivation rec { pname = "xreader"; <del> version = "3.4.3"; </del> <ins> version = "3.4.4"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> sha256 = "sha256-GkJo/wc5StyeQv0pv5XK0Qy3o8EGpfPYY8gOMq0Afgs="; </del> <ins> sha256 = "sha256-uYnQE1GjkUxYlvXSJNmvr6q4OdvAWgv8HqTXk0KkRQM="; </ins> }; nativeBuildInputs = [


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.pytorchWithCuda maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
This looks like another gcc11 failure. could you take a look?
Sure thing
Going to attempt to bump from 2.5.4 (2020) to 2.6.2 (2022)

in majorIs == "9" || majorIs == "10" || majorIs == "11"; let <del> version = "2.5.4"; </del> <ins> version = "2.6.2"; </ins> # We define a specific set of CUDA compute capabilities here, # because CUDA 11 does not support compute capability 3.0. Also,


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.pytorchWithCuda maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
This looks like another gcc11 failure. could you take a look?
Sure thing
Going to attempt to bump from 2.5.4 (2020) to 2.6.2 (2022)

inherit version; src = fetchurl { url = "https://icl.cs.utk.edu/projectsfiles/magma/downloads/magma-${version}.tar.gz"; <del> sha256 = "0rrvd21hczxlm8awc9z54fj7iqpjmsb518fy32s6ghz0g90znd3p"; </del> <ins> hash = "sha256-dbVU2rAJA+LRC5cskT5Q5/iMvGLzrkMrWghsfk7aCnE="; </ins> name = "magma-${version}.tar.gz"; };


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.pytorchWithCuda maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
This looks like another gcc11 failure. could you take a look?
Sure thing
Going to attempt to bump from 2.5.4 (2020) to 2.6.2 (2022)

enableParallelBuilding=true; buildFlags = [ "magma" "magma_sparse" ]; <del> # MAGMA's default CMake setup does not care about installation. So we copy files directly. installPhase = '' mkdir -p $out mkdir -p $out/include mkdir -p $out/lib mkdir -p $out/lib/pkgconfig cp -a ../include/*.h $out/include #cp -a sparse-iter/include/*.h $out/include cp -a lib/*.so $out/lib cat ../lib/pkgconfig/magma.pc.in                   |  sed -e s:@INSTALL_PREFIX@:"$out":          |  sed -e s:@CFLAGS@:"-I$out/include":    |  sed -e s:@LIBS@:"-L$out/lib -lmagma -lmagma_sparse": |  sed -e s:@MAGMA_REQUIRED@::                        > $out/lib/pkgconfig/magma.pc ''; </del> meta = with lib; { description = "Matrix Algebra on GPU and Multicore Architectures"; license = licenses.bsd3;


Question:
Somewhere between and there is a commit that changes the default fonts on NixOS. Most text is just different (I'd say, a bit less readable). But some text in the terminal (gnome-terminal) is completely borked (in regards to positioning): ! Look at how the 's' is drawn on top of the 'M'. And generally the positioning of glyphs is... not right! Compare how fonts look in a few apps on nixpkgs vs . System: x8664-linux NixOS at master branch (). No fonts.* settings in my file (never had that). GNOME3 desktop and gnome-terminal.
My guess is . cc I'll try to switch to master and debug what happens.
Wild guess, is there a and a folder? Could you post the result of ?
Hm, I upgraded another machine to the same commit. Fonts look generally a bit different than they used to (for instance, in chromium + gmail). (I think the glyphs are just thinner and there is a lot of "air" around each letter.) But the horribly broken stuff in gnome-terminal doesn't happen on this machine. What's going on?
Can you try to remove and and do a to see if that improve the situation?
Yes it does! Now all text look like it used to. Thanks! After this, is no more, only /etc/fonts:
Is this something we can fix in the NixOS module that sets up /etc/fonts, so that users upgrading from 16.03 to 16.09 won't hit this?
A heuristic idea for this -- a function : if path is a file, return True iff it's a symlink to . if path is a directory, return True iff for all items in it is True. On any conflicts, if old path is static, it's safe to replace and/or delete stale. Otherwise make a backup and notify the user via a journal entry and console output. What are the possible caveats? This would certainly be nice to implement. I can look into this if it seems a good idea, but I suspect corresponding code is in Perl, which I'm illiterate with. On July 15, 2016 1:25:53 PM GMT+03:00, "Bjørn Forsman" wrote:
Yes, the cause seems to be in the function of .
Truth be told, I like better an idea of making fully static, with several files (like when ) explicitly set as symlinks to somewhere (?). This simplifies the whole bookkeeping a lot, but however is a radical move. I'm eager to try implementing this but we need to survey possible cases when people manually change something in . Maybe I'll get a chance asking in the ML...
in principle I'd like that, but in practice FHS is pretty unclear about whether /etc is supposed to be mutable. Would definitely be interested in what you came up with though. Personally, I'd rather fix more programs to not use /etc and rather to link directly to configuration in the store that they need (since we get more granularity there and know exactly what needs to be mutable), but that's probably a lot of work in some cases.
For input method packages, I used dedicated packages for the and the folders under via . Could a similar approach for be a way to solve this problem? (edit: and accessorily a way to too?)
why would we care what FHS says? :-D
I get this line when switching (and then fonts look ugly): Where 81 line is Next fixes the fonts:
Opened a PR with a fix:
see for read-only /etc
Nice find! I haven't yet done any research, so this thread will come handy.

# current configuration. atomicSymlink $etc, $static or die; <ins> # Returns 1 if the argument points to the files in /etc/static.  That # means either argument is a symlink to a file in /etc/static or a # directory with all children being static. sub isStatic { my $path = shift; if (-l $path) { my $target = readlink $path; return substr($target, 0, length "/etc/static/") eq "/etc/static/"; } if (-d $path) { opendir DIR, "$path" or return 0; my @names = readdir DIR or die; closedir DIR; foreach my $name (@names) { next if $name eq "." || $name eq ".."; unless (isStatic("$path/$name")) { return 0; } } return 1; } return 0; } </ins> # Remove dangling symlinks that point to /etc/static.  These are # configuration files that existed in a previous configuration but not


Question:
Somewhere between and there is a commit that changes the default fonts on NixOS. Most text is just different (I'd say, a bit less readable). But some text in the terminal (gnome-terminal) is completely borked (in regards to positioning): ! Look at how the 's' is drawn on top of the 'M'. And generally the positioning of glyphs is... not right! Compare how fonts look in a few apps on nixpkgs vs . System: x8664-linux NixOS at master branch (). No fonts.* settings in my file (never had that). GNOME3 desktop and gnome-terminal.
My guess is . cc I'll try to switch to master and debug what happens.
Wild guess, is there a and a folder? Could you post the result of ?
Hm, I upgraded another machine to the same commit. Fonts look generally a bit different than they used to (for instance, in chromium + gmail). (I think the glyphs are just thinner and there is a lot of "air" around each letter.) But the horribly broken stuff in gnome-terminal doesn't happen on this machine. What's going on?
Can you try to remove and and do a to see if that improve the situation?
Yes it does! Now all text look like it used to. Thanks! After this, is no more, only /etc/fonts:
Is this something we can fix in the NixOS module that sets up /etc/fonts, so that users upgrading from 16.03 to 16.09 won't hit this?
A heuristic idea for this -- a function : if path is a file, return True iff it's a symlink to . if path is a directory, return True iff for all items in it is True. On any conflicts, if old path is static, it's safe to replace and/or delete stale. Otherwise make a backup and notify the user via a journal entry and console output. What are the possible caveats? This would certainly be nice to implement. I can look into this if it seems a good idea, but I suspect corresponding code is in Perl, which I'm illiterate with. On July 15, 2016 1:25:53 PM GMT+03:00, "Bjørn Forsman" wrote:
Yes, the cause seems to be in the function of .
Truth be told, I like better an idea of making fully static, with several files (like when ) explicitly set as symlinks to somewhere (?). This simplifies the whole bookkeeping a lot, but however is a radical move. I'm eager to try implementing this but we need to survey possible cases when people manually change something in . Maybe I'll get a chance asking in the ML...
in principle I'd like that, but in practice FHS is pretty unclear about whether /etc is supposed to be mutable. Would definitely be interested in what you came up with though. Personally, I'd rather fix more programs to not use /etc and rather to link directly to configuration in the store that they need (since we get more granularity there and know exactly what needs to be mutable), but that's probably a lot of work in some cases.
For input method packages, I used dedicated packages for the and the folders under via . Could a similar approach for be a way to solve this problem? (edit: and accessorily a way to too?)
why would we care what FHS says? :-D
I get this line when switching (and then fonts look ugly): Where 81 line is Next fixes the fonts:
Opened a PR with a fix:
see for read-only /etc
Nice find! I haven't yet done any research, so this thread will come handy.

my $target = "/etc/$fn"; File::Path::make_path(dirname $target); $created{$fn} = 1; <ins> # Rename doesn't work if target is directory. if (-l $_ && -d $target) { if (isStatic $target) { rmtree $target or warn; } else { warn "$target directory contains user files. Symlinking may fail."; } } </ins> if (-e "$_.mode") { my $mode = read_file("$_.mode"); chomp $mode; if ($mode eq "direct-symlink") {


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: haruna <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.7.3 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: I tried to update it myself, but when trying to open the result I get either: or: Some dependencies could be moved to , since they are build time only. The project supports other than . Since uses the former, maybe switching could be considered. The homepage is outdated. It's now "". Please tag this issue in your PR.
Can you (re)produce after this update?
This is an issue requesting an update, not a pull request (edited the title to be more clear). Still, with the update I tried to do by myself I couldn't open Haruna in the first place.

, cmake , extra-cmake-modules , ffmpeg-full <del> , kcodecs </del> , kconfig , kcoreaddons , kfilemetadata , ki18n , kiconthemes , kio <del> , kio-extras </del> , kirigami2 , kxmlgui <ins> , kdoctools </ins> , mpv , pkg-config <ins> , wrapQtAppsHook </ins> , qqc2-desktop-style , qtbase , qtquickcontrols2 <del> , qtwayland , youtube-dl </del> <ins> , yt-dlp </ins> }: mkDerivation rec { pname = "haruna"; <del> version = "0.7.3"; </del> <ins> version = "0.8.0"; </ins> src = fetchFromGitLab { owner = "multimedia"; repo = "haruna"; rev = "v${version}"; <del> sha256 = "sha256-pFrmTaRvsqxJw34VULzfjx2k56kJgkB96nJtai2D1wY="; </del> <ins> sha256 = "sha256-Lom9iQUKH3lQHrVK4dJzo+FG79xSCg0b4gY/KAevL6I="; </ins> domain = "invent.kde.org"; }; buildInputs = [ breeze-icons breeze-qt5 <ins> qqc2-desktop-style yt-dlp </ins> ffmpeg-full <del> kcodecs </del> kconfig kcoreaddons kfilemetadata ki18n kiconthemes kio <del> kio-extras </del> kirigami2 kxmlgui <ins> kdoctools </ins> mpv <del> qqc2-desktop-style </del> qtbase qtquickcontrols2 <del> qtwayland youtube-dl </del> ]; nativeBuildInputs = [ cmake extra-cmake-modules pkg-config <ins> wrapQtAppsHook </ins> ]; meta = with lib; { <del> homepage = "https://github.com/g-fb/haruna"; </del> <ins> homepage = "https://invent.kde.org/multimedia/haruna"; </ins> description = "Open source video player built with Qt/QML and libmpv"; <del> license = with licenses; [ bsd3 cc-by-40 gpl3Plus wtfpl ]; </del> <ins> license = with licenses; [ bsd3 cc-by-40 cc-by-sa-40 cc0 gpl2Plus gpl3Plus wtfpl ]; </ins> maintainers = with maintainers; [ jojosch ]; }; }


Question:
Enabling services.hardware. (as a systemd service) breaks. Steps to reproduce the behavior: error about and several other errors like "has not been declared", "does not name a type", etc. To rebuild xow and everything else without any issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The git not found problem is not fatal and the derivation overrides the version info anyway. Looks like another victim of our stdenv compiler upgrade. Looks like upstream master has a fix for that. Upstream is also orphaned so upgrading the derivation to an unstable revision is going to be needed in the short term and in the long term a replacement should probably be found. I don't have a working controller to test xow with any more so if someone wants to adopt the package, feel free to.

stdenv.mkDerivation rec { pname = "xow"; <del> version = "0.5"; </del> <ins> version = "unstable-2022-04-24"; </ins> src = fetchFromGitHub { owner = "medusalix"; repo = "xow"; <del> rev = "v${version}"; sha256 = "071r2kx44k1sc49cad3i607xg618mf34ki1ykr5lnfx9y6qyz075"; </del> <ins> rev = "d335d6024f8380f52767a7de67727d9b2f867871"; sha256 = "0q5nr21p4dlx2a99hiivwz6qj9anrqqsdhiz6xi375yqkxis4251"; </ins> }; firmware = fetchurl {


Question:
Enabling services.hardware. (as a systemd service) breaks. Steps to reproduce the behavior: error about and several other errors like "has not been declared", "does not name a type", etc. To rebuild xow and everything else without any issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The git not found problem is not fatal and the derivation overrides the version info anyway. Looks like another victim of our stdenv compiler upgrade. Looks like upstream master has a fix for that. Upstream is also orphaned so upgrading the derivation to an unstable revision is going to be needed in the short term and in the long term a replacement should probably be found. I don't have a working controller to test xow with any more so if someone wants to adopt the package, feel free to.

makeFlags = [ "BUILD=RELEASE" <del> "VERSION=${version}" </del> <ins> "VERSION=${version}-${src.rev}" </ins> "BINDIR=${placeholder "out"}/bin" "UDEVDIR=${placeholder "out"}/lib/udev/rules.d" "MODLDIR=${placeholder "out"}/lib/modules-load.d"


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: rtl-sdr <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.6.0 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package is currenty using but it should probably switch to Please tag this issue in your PR.

{ lib , stdenv <del> , fetchgit </del> <ins> , fetchFromGitHub </ins> , cmake , pkg-config , libusb1


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: rtl-sdr <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.6.0 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package is currenty using but it should probably switch to Please tag this issue in your PR.

stdenv.mkDerivation rec { pname = "rtl-sdr"; <del> version = "0.6.0"; </del> <ins> version = "0.8.0"; </ins> <del> src = fetchgit { url = "git://git.osmocom.org/rtl-sdr.git"; rev = "refs/tags/${version}"; sha256 = "0lmvsnb4xw4hmz6zs0z5ilsah5hjz29g1s0050n59fllskqr3b8k"; </del> <ins> src = fetchFromGitHub { owner = "librtlsdr"; repo = "librtlsdr"; rev = "v${version}"; sha256 = "1fgxlkgmdchbrf0nn98ivjr6css5hak3608nr4xrf2qzf7xy2kdk"; </ins> }; postPatch = ''


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: rtl-sdr <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.6.0 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package is currenty using but it should probably switch to Please tag this issue in your PR.

buildInputs = [ libusb1 ]; <del> cmakeFlags = lib.optional stdenv.isLinux "-DINSTALL_UDEV_RULES=ON"; </del> <ins> cmakeFlags = lib.optional stdenv.isLinux [ "-DINSTALL_UDEV_RULES=ON" "-DWITH_RPC=ON" ]; </ins> meta = with lib; { description = "Turns your Realtek RTL2832 based DVB dongle into a SDR receiver";


Question:
For example This test has always been failing: From the logs: /cc
Whoopsie! Maybe instead of keeping hard-coded URL to x86-64's Alpine we could build something dynamically? (this way the test would automatically work on all architectures) I'll try to take a look over the weekend, but feel free to take a shot at it, if you want
Hmm that is a cool idea. Though OTOH it is currently nice that when this test fails it is clear it is a problem with running the image, and not with creating it. Did you get that from somewhere or did you create it? Is it the 'mini root fs' from ?
Yeah, that's the one;

# # I've chosen to import Alpine Linux, because its image is turbo-tiny and, # generally, sufficient for our tests. <del> alpine-meta = pkgs.fetchurl { </del> <ins> alpine-meta-x86 = pkgs.fetchurl { </ins> url = "https://tarballs.nixos.org/alpine/3.12/lxd.tar.xz"; hash = "sha256-1tcKaO9lOkvqfmG/7FMbfAEToAuFy2YMewS8ysBKuLA="; }; <ins> alpine-meta-for = arch: pkgs.stdenv.mkDerivation { name = "alpine-meta-${arch}"; version = "3.12"; unpackPhase = "true"; buildPhase = '' runHook preBuild </ins> <del> alpine-rootfs = pkgs.fetchurl { url = "https://tarballs.nixos.org/alpine/3.12/rootfs.tar.xz"; hash = "sha256-Tba9sSoaiMtQLY45u7p5DMqXTSDgs/763L/SQp0bkCA="; </del> <ins> tar xvf ${alpine-meta-x86} sed -i 's/architecture: .*/architecture: ${arch}/' metadata.yaml runHook postBuild ''; installPhase = '' runHook preInstall tar czRf $out * runHook postInstall ''; </ins> }; <ins> alpine-meta = { x86_64-linux = alpine-meta-x86; aarch64-linux = alpine-meta-for "aarch64"; }.${pkgs.system} or (throw "Unsupported system: ${pkgs.system}"); alpine-rootfs = { x86_64-linux = pkgs.fetchurl { url = "https://tarballs.nixos.org/alpine/3.12/rootfs.tar.xz"; hash = "sha256-Tba9sSoaiMtQLY45u7p5DMqXTSDgs/763L/SQp0bkCA="; }; aarch64-linux = pkgs.fetchurl { url = "https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/aarch64/alpine-minirootfs-3.15.4-aarch64.tar.gz"; hash = "sha256-9kBz8Jwmo8XepJhTMt5zilCaHHpflnUH7y9+0To39Us="; }; }.${pkgs.system} or (throw "Unsupported system: ${pkgs.system}"); </ins> lxd-config = pkgs.writeText "config.yaml" '' storage_pools: - name: default


Question: fails to build. Looking at hydra when it started to fail () it could be due to GCC 11 update. Just adding to the only leads to the next error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

]; configureFlags = [ <ins> "--disable-werror" </ins> "--enable-jtag_vpi" "--enable-usb_blaster_libftdi" (lib.enableFeature (! stdenv.isDarwin) "amtjtagaccel")


Question:
On nixos-unstable it appears that was renamed to . However the config line for applying the option still references the obsolete option name: This means that enabling produces a warning like Relatedly, using this without defining also throws an error ' is used but not defined.confignullOr submodule` with no default value). Steps to reproduce the behavior: should not produce any warnings or errors. Uncommenting the line removes the error but leaves the warning. (though the flake output in question is for )
You used the wrong GitHub handles for some of the maintainers. cc
Oops. I copied the names out of the file as there's no GitHub team for it, but I forgot to indirect through . Is there any simple way to look up the github handles for a given module? I'm not even sure how to get at the module programmatically.
It works, but it isn't pretty.

}; config = mkIf cfg.enable { <del> networking.firewall.allowedTCPPorts = mkIf cfg.openFirewall [ cfg.port ]; </del> <ins> assertions = [ { assertion = cfg.openFirewall -> !isNull cfg.config; message = "openFirewall can only be used with a declarative config"; } ]; networking.firewall.allowedTCPPorts = mkIf cfg.openFirewall [ cfg.config.http.server_port ]; </ins> systemd.services.home-assistant = { description = "Home Assistant";


Question:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

<del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchFromGitHub , cmake , qttools


Question:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

export LC_ALL="en_US.UTF-8" export QT_QPA_PLATFORM=offscreen export QT_PLUGIN_PATH="${qtbase.bin}/${qtbase.qtPluginPrefix}" <del> # testcli and testgui are flaky - skip them both make test ARGS+="-E 'testcli|testgui' --output-on-failure" </del> <ins> # testcli, testgui and testkdbx4 are flaky - skip them all # testautotype on darwin throws "QWidget: Cannot create a QWidget without QApplication" make test ARGS+="-E 'testcli|testgui${lib.optionalString stdenv.isDarwin "|testautotype|testkdbx4"}' --output-on-failure" </ins> runHook postCheck '';


Question:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

dontWrapGApps = true; preFixup = '' qtWrapperArgs+=("''${gappsWrapperArgs[@]}") <ins> '' + lib.optionalString stdenv.isDarwin '' wrapQtApp "$out/Applications/KeePassXC.app/Contents/MacOS/KeePassXC" </ins> ''; buildInputs = [


Question:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

license = licenses.gpl2Plus; maintainers = with maintainers; [ jonafato turion srapenne ]; platforms = platforms.linux ++ platforms.darwin; <del> broken = stdenv.isDarwin;  # see to https://github.com/NixOS/nixpkgs/issues/172165 </del> }; }


Question:
nixpkgs-review stopped working on recent branches, I didn't update nixpkgs-review before it break so I assume something internal in nixpkgs has been broken. Steps to reproduce the behavior: or there is a build failure related to hydra <details<summaryLong output of the failure</summary</detailsit shouldn't fail
This is certainly related to , ping :)
Sorry about that, it's a bit annoying that aliases are allowed locally and not in nixpkgs-review :/.

TermSizeAny TermReadKey Test2Harness <del> TestMore </del> TestPostgreSQL TextDiff TextTable


Question:
, CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. Versions of vyper prior to 0.3.2 suffer from a potential buffer overrun. Importing a function from a JSON interface which returns generates bytecode which does not clamp bytes length, potentially resulting in a buffer overrun. Users are advised to upgrade. There are no known workarounds for this issue. Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. In affected versions, the return of is not validated to fall within the bounds of . This issue can result in a misinterpretation of the integer value and lead to incorrect behavior. As of v0.3.0, is validated in simple expressions, but not complex expressions. Users are advised to upgrade. There is no known workaround for this issue. Scanned versions: nixos-unstable: . Cc
See also:

, buildPythonPackage , fetchPypi , pythonOlder <del> , pythonAtLeast </del> , pythonRelaxDepsHook , writeText , asttokens


Question:
, CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. Versions of vyper prior to 0.3.2 suffer from a potential buffer overrun. Importing a function from a JSON interface which returns generates bytecode which does not clamp bytes length, potentially resulting in a buffer overrun. Users are advised to upgrade. There are no known workarounds for this issue. Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. In affected versions, the return of is not validated to fall within the bounds of . This issue can result in a misinterpretation of the integer value and lead to incorrect behavior. As of v0.3.0, is validated in simple expressions, but not complex expressions. Users are advised to upgrade. There is no known workaround for this issue. Scanned versions: nixos-unstable: . Cc
See also:

, sphinx_rtd_theme , pytest-runner , setuptools-scm <ins> , git </ins> }: let


Question:
, CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. Versions of vyper prior to 0.3.2 suffer from a potential buffer overrun. Importing a function from a JSON interface which returns generates bytecode which does not clamp bytes length, potentially resulting in a buffer overrun. Users are advised to upgrade. There are no known workarounds for this issue. Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. In affected versions, the return of is not validated to fall within the bounds of . This issue can result in a misinterpretation of the integer value and lead to incorrect behavior. As of v0.3.0, is validated in simple expressions, but not complex expressions. Users are advised to upgrade. There is no known workaround for this issue. Scanned versions: nixos-unstable: . Cc
See also:

in buildPythonPackage rec { pname = "vyper"; <del> version = "0.3.1"; </del> <ins> version = "0.3.3"; </ins> format = "setuptools"; <del> disabled = pythonOlder "3.7" || pythonAtLeast "3.10"; </del> <ins> disabled = pythonOlder "3.7"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "sha256-fXug5v3zstz19uexMWokHBVsfcl2ZCdIOIXKeLVyh/Q="; </del> <ins> sha256 = "sha256-BAnNj27B1HAb9VVDA69bFGbQjeOpl0g5EB2juajqBAw="; </ins> }; nativeBuildInputs = [ <ins> # Git is used in setup.py to compute version information during building # ever since https://github.com/vyperlang/vyper/pull/2816 git </ins> pythonRelaxDepsHook pytest-runner setuptools-scm


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

let pname = "zammad"; <del> version = "5.1.0"; </del> <ins> version = "5.1.1"; </ins> src = applyPatches {


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "04vxmjr200akcil9fqxc9ghbb9q0lyrh2q03xxncycd5vln910fi"; </del> <ins> sha256 = "1pfk942d6qwhw151hxaz7n4knk6whyxqvvywdx2cdw9yhykyaqzq"; </ins> type = "gem"; }; <del> version = "6.2.0"; </del> <ins> version = "6.2.1"; </ins> }; factory_bot_rails = { dependencies = ["factory_bot" "railties"];


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "1p6b3q411h2mw4dsvhjrp1hh66hha5cm69fqg85vn2lizz71n6xz"; </del> <ins> sha256 = "1g43ii497cwdqhfnaxfl500bq5yfc5hfv5df1lvf6wcjnd708ihd"; </ins> type = "gem"; }; <del> version = "1.13.3"; </del> <ins> version = "1.13.4"; </ins> }; nori = { groups = ["default"];


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "19mf9f5zx23cjjn0p77wz1igzpfr22mxhljgavffl8fwqq74v4ih"; </del> <ins> sha256 = "01ldw5ba6xfn2k97n75n52qs4f0fy8xmn58c4247xf476nfvg035"; </ins> type = "gem"; }; <del> version = "3.2.5"; </del> <ins> version = "3.2.6"; </ins> }; power_assert = { groups = ["default" "development" "test"];


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "1xvkz9xrd1cqnlm0qac1iwwxzndx3cc17zrjncpa4lzjfwbxhsnm"; </del> <ins> sha256 = "0df9bknc2dllk8v9fhgidzbvbryaxa8fgifrk40cdz9csjsphbky"; </ins> type = "gem"; }; <del> version = "4.3.11"; </del> <ins> version = "4.3.12"; </ins> }; pundit = { dependencies = ["activesupport"];


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

}; version = "2.2.3"; }; <ins> rack-attack = { dependencies = ["rack"]; groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "1rc6simyql7ax5zzp667x6krl0xxxh3asc1av6gcn8j6cyl86wsx"; type = "gem"; }; version = "6.6.0"; }; </ins> rack-livereload = { dependencies = ["rack"]; groups = ["development" "test"];


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "134zg0dzd7216lyczkhv01v27ikkmipjihcy2bzi0qv72p1i923i"; </del> <ins> sha256 = "1wybcipkfawg4pragmayiig03xc084x3hbwywsh1dr9x9pa8f9hj"; </ins> type = "gem"; }; <del> version = "1.1.5"; </del> <ins> version = "1.1.6"; </ins> }; slack-notifier = { groups = ["default"];


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

"stylelint-prettier": "^2.0.0" }, "name": "Zammad", <del> "version": "5.1.0" </del> <ins> "version": "5.1.1" </ins> }


Question: , CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

{ "owner": "zammad", "repo": "zammad", <del> "rev": "eefae45c2ad6e6a96b8df631d2f50f290ecbd27d", "sha256": "EjowvM//+UsAfEH9/0jgLkiD7EWH34M1NQ9U2DotBqc=", </del> <ins> "rev": "d71bd90ef964426230664cdfbaa2572325bfed4f", "sha256": "yzDTkjnRBl71REtSKRblkanJWhj7gp/+exhWjxGCFWw=", </ins> "fetchSubmodules": true }


Question:
Project description KDiskMark is an HDD and SSD benchmark tool with a very friendly graphical user interface. KDiskMark with its presets and powerful GUI calls and handles the output to provide an easy to view and interpret comprehensive benchmark result. The application is written in C++ with Qt and doesn't have any KDE dependencies. Metadata homepage URL: source URL: license: GPL 3.0 platforms: Linux
I am currently trying to work on this. It builds and runs, sometimes I run into a Kauth error
see , please review

<ins> { stdenv , lib , wrapQtAppsHook , qtbase , qttools , fio , cmake , kauth , extra-cmake-modules , fetchFromGitHub }: stdenv.mkDerivation rec { name = "kdiskmark"; version = "2.3.0"; src = fetchFromGitHub { owner = "jonmagon"; repo = "kdiskmark"; rev = version; sha256 = "sha256-9ufRxEbqwcRs+m/YW8D3+1USCJNZEaOUZRec7gvgmtA="; }; nativeBuildInputs = [ cmake wrapQtAppsHook ]; buildInputs = [ qtbase qttools extra-cmake-modules kauth ]; postInstall = '' # so that kdiskmark can be used as unpriviledged user even on non-kde # (where kauth is not in environment.systemPackages) ln -s ${kauth}/share/dbus-1/system.d/org.kde.kf5auth.conf $out/share/dbus-1/system.d/00-kdiskmark-needs-org.kde.kf5auth.conf ''; qtWrapperArgs = [ "--prefix" "PATH" ":" (lib.makeBinPath [ fio ]) ]; meta = with lib; { description = "HDD and SSD benchmark tool with a friendly graphical user interface"; longDescription = '' If kdiskmark is not run as root it can rely on polkit to get the necessary privileges. In this case you must install it with `environment.systemPackages` on NixOS, nix-env will not work. ''; homepage = "https://github.com/JonMagon/KDiskMark"; maintainers = [ maintainers.symphorien ]; license = licenses.gpl3Only; platforms = platforms.linux; }; } </ins>


Question:
Project description KDiskMark is an HDD and SSD benchmark tool with a very friendly graphical user interface. KDiskMark with its presets and powerful GUI calls and handles the output to provide an easy to view and interpret comprehensive benchmark result. The application is written in C++ with Qt and doesn't have any KDE dependencies. Metadata homepage URL: source URL: license: GPL 3.0 platforms: Linux
I am currently trying to work on this. It builds and runs, sometimes I run into a Kauth error
see , please review

buildGoModule = buildGo118Module; }; <ins> kdiskmark = libsForQt5.callPackage ../tools/filesystems/kdiskmark { }; </ins> keepalived = callPackage ../tools/networking/keepalived { }; kexec-tools = callPackage ../os-specific/linux/kexec-tools { };


Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

packages = [ (with dotnetCorePackages; combinePackages [ sdk_3_1 <del> sdk_5_0 </del> <ins> sdk_6_0 </ins> ]) ]; } ``` <del> This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output: </del> <ins> This will produce a dotnet installation that has the dotnet 3.1 6.0 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output: </ins> ```ShellSession $ dotnet --info


Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure. dotnet-sdk = dotnetCorePackages.sdk_3_1; <del> dotnet-runtime = dotnetCorePackages.net_5_0; </del> <ins> dotnet-runtime = dotnetCorePackages.net_6_0; </ins> executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`. executables = []; # Don't install any executables.


Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

<literal>freetype</literal> and others. </para> </listitem> <ins> <listitem> <para> .NET 5.0 was removed due to being end-of-life, use a newer, supported .NET version - https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-23.05-notable-changes">


Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

- Deprecated `xlibsWrapper` transitional package has been removed in favour of direct use of its constitutents: `xorg.libX11`, `freetype` and others. <ins> - .NET 5.0 was removed due to being end-of-life, use a newer, supported .NET version - https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core </ins> ## Other Notable Changes {#sec-release-23.05-notable-changes} <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->