jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug There is no AWS AMI for NixOS 20.03 To Reproduce Steps to reproduce the behavior: Check or Try find it in AWS AMI console Expected behavior 03 is created and uploaded to AWS
CC I think knows how to do this part.
Yep, I have no idea how to do this for NixOS, so I'd need someone in the know with AWS AMI for 20.03. This actually was one of my concerns for 20.03.
I know how to build the release AMI and put it on a personal AWS S3 bucket (I'm using one now for my NixOps AWS cluster), but do not have the permissions to upload it on the official account. about 2 months ago I followed this process, which you can use if you're looking to unblock yourself: then follow these instructions to upload using : Then on NixOps you set to your custom AMI. You can also use this to bake in pkgs to the AMI so there's less startup time if you know you'll be downloading specific things on provisioning startup otherwise.

Related discussion:
text: "19.09".ap-east-1.hvm-ebs = "ami-055b2348db2827ff1"; "19.09".sa-east-1.hvm-ebs = "ami-018aab68377227e06"; <del> latest = self."19.09"; </del> <ins> # 20.03.1554.94e39623a49 "20.03".eu-west-1.hvm-ebs = "ami-02c34db5766cc7013"; "20.03".eu-west-2.hvm-ebs = "ami-0e32bd8c7853883f1"; "20.03".eu-west-3.hvm-ebs = "ami-061edb1356c1d69fd"; "20.03".eu-central-1.hvm-ebs = "ami-0a1a94722dcbff94c"; "20.03".eu-north-1.hvm-ebs = "ami-02699abfacbb6464b"; "20.03".us-east-1.hvm-ebs = "ami-0c5e7760748b74e85"; "20.03".us-east-2.hvm-ebs = "ami-030296bb256764655"; "20.03".us-west-1.hvm-ebs = "ami-050be818e0266b741"; "20.03".us-west-2.hvm-ebs = "ami-06562f78dca68eda2"; "20.03".ca-central-1.hvm-ebs = "ami-02365684a173255c7"; "20.03".ap-southeast-1.hvm-ebs = "ami-0dbf353e168d155f7"; "20.03".ap-southeast-2.hvm-ebs = "ami-04c0f3a75f63daddd"; "20.03".ap-northeast-1.hvm-ebs = "ami-093d9cc49c191eb6c"; "20.03".ap-northeast-2.hvm-ebs = "ami-0087df91a7b6ebd45"; "20.03".ap-south-1.hvm-ebs = "ami-0a1a6b569af04af9d"; "20.03".ap-east-1.hvm-ebs = "ami-0d18fdd309cdefa86"; "20.03".sa-east-1.hvm-ebs = "ami-09859378158ae971d"; latest = self."20.03"; </ins> }; in self
Code change:
Describe the bug A clear and concise description of what the bug is. The package fails to build. It errors out during the installation of bash completions with "Permissions denied". To Reproduce Steps to reproduce the behavior: -build -A mosh Expected behavior Successful build Notify maintainers Metadata on Maintainer information:
The breaking commit is the bash-completion update from 2.9 to 2.10: . Any idea how to resolve this?
I think you meant to link . Seems to be a regression from incorrectly dropping by ( in ). The "wrong" prefix comes from . A possible alternative would be to drop the dependency on for (if there's a correct fallback - since we don't actually the prefix from anyway).
I think removing this patch was correct, as the functionality introduced in that patch was to 2.10, however a program needs to define instead of when reading variable, which may necessitate patches (which could be upstreamed). It's unfortunate that the upstream decided on different approach than what was done previously, but trying to preserve the old behaviour would cause more issues in long-term. Let's not overcomplicate things when some of upstream projects already have code that uses when using = 2.10. I imagine this is the line that needs changing:
sorry, my assumption about the patch was wrong then :o And thanks for the fix :) Edit: And I agree that we should follow upstream then.

Related discussion:
text: <ins> diff --git a/configure.ac b/configure.ac index 3ad983d..ff8ff96 100644 --- a/configure.ac +++ b/configure.ac @@ -476,13 +476,7 @@ AS_IF([echo "$protobuf_LIBS" | grep -q -- -pthread], # Bash completion needs to ask where it goes if >= 2.0 is installed. AS_IF([test "$install_completion" != no], -  [PKG_CHECK_MODULES([BASH_COMPLETION], [bash-completion >= 2.0], -     [if test "$prefix" = "NONE"; then -        completions="`pkg-config --variable=completionsdir bash-completion`" -      else -        completions="`pkg-config --define-variable=prefix=$prefix --variable=completionsdir bash-completion`" -      fi], -     [completions="${sysconfdir}/bash_completion.d"]) +   [completions="`pkg-config --define-variable=datadir=$datadir --variable=completionsdir bash-completion`"] AC_SUBST([completions])]) AC_CONFIG_FILES([ </ins>
Code change:
Describe the bug A clear and concise description of what the bug is. The package fails to build. It errors out during the installation of bash completions with "Permissions denied". To Reproduce Steps to reproduce the behavior: -build -A mosh Expected behavior Successful build Notify maintainers Metadata on Maintainer information:
The breaking commit is the bash-completion update from 2.9 to 2.10: . Any idea how to resolve this?
I think you meant to link . Seems to be a regression from incorrectly dropping by ( in ). The "wrong" prefix comes from . A possible alternative would be to drop the dependency on for (if there's a correct fallback - since we don't actually the prefix from anyway).
I think removing this patch was correct, as the functionality introduced in that patch was to 2.10, however a program needs to define instead of when reading variable, which may necessitate patches (which could be upstreamed). It's unfortunate that the upstream decided on different approach than what was done previously, but trying to preserve the old behaviour would cause more issues in long-term. Let's not overcomplicate things when some of upstream projects already have code that uses when using = 2.10. I imagine this is the line that needs changing:
sorry, my assumption about the patch was wrong then :o And thanks for the fix :) Edit: And I agree that we should follow upstream then.

Related discussion:
text: url = "https://github.com/mobile-shell/mosh/commit/e5f8a826ef9ff5da4cfce3bb8151f9526ec19db0.patch"; sha256 = "15518rb0r5w1zn4s6981bf1sz6ins6gpn2saizfzhmr13hw4gmhm"; }) <ins> # Fix build with bash-completion 2.10 ./bash_completion_datadir.patch </ins> ]; postPatch = '' substituteInPlace scripts/mosh.pl
Code change:
Describe the bug do not run. To Reproduce Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
meets the same error.
I think I might have the same issue with solargraph: The same command from nixpkgs-19.09 seems fine: Possibly due to the bundler changes in ? EDIT: Hm. But in a docker container (lnl7/nix:2020-03-07), runs fine. Something in my environment? Or darwin weirdness?
I had a similar issue and I found that my global bundler config was the problem. changed the generated binstubs so that the environment variable is no longer set which I think means that bundler will now use from the global config if it exists. This seems to result in bundler looking for gems in the wrong location. A possible workaround is to set using an environment variable instead of using the global config since this value will be unset by the generated binstubs but will still have an effect when bundler is used from somewhere else. There is also the environment variable which causes bundler to ignore all configuration but that might have other unwanted effects.
I marked this as stale due to inactivity. &rarr;
Do you still experience the issue? nixos tests of the service are passing and I'm unable to replicate on the current nixpkgs or even in commit
Yes. and don't run. I'm in nixos-unstable .
I removed in then both programs run fine.
Hopefully or a similar change will get merged and prevent these problems. I've seen a few issues like this get reported.

Related discussion:
text: ENV["BUNDLE_GEMFILE"] = #{gemfile.dump} ENV.delete 'BUNDLE_PATH' ENV['BUNDLE_FROZEN'] = '1' <ins> ENV['BUNDLE_IGNORE_CONFIG'] = '1' </ins> Gem.paths = { 'GEM_HOME' => #{bundle_path.dump} }
Code change:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub </del> <ins> { lib, stdenv, fetchFromGitHub, fetchpatch </ins> , doxygen, fontconfig, graphviz-nox, libxml2, pkg-config, which , systemd }: <del> let version = "2019-12-08"; in stdenv.mkDerivation { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "openzwave"; <del> inherit version; </del> <ins> version = "1.6"; </ins> <del> # Use fork by Home Assistant because this package is mainly used for python.pkgs.homeassistant-pyozw. # See https://github.com/OpenZWave/open-zwave/compare/master...home-assistant:hass for the difference. </del> src = fetchFromGitHub { <del> owner = "home-assistant"; </del> <ins> owner = "OpenZWave"; </ins> repo = "open-zwave"; <del> rev = "2cd2137025c529835e4893a7b87c3d56605b2681"; sha256 = "04g8fb4f4ihakvvsmzcnncgfdd2ikmki7s22i9c6layzdwavbwf1"; </del> <ins> rev = "v${version}"; sha256 = "0xgs4mmr0480c269wx9xkk67ikjzxkh8xcssrdx0f5xcl1lyd333"; </ins> }; <ins> patches = [ (fetchpatch { name = "fix-strncat-build-failure.patch"; url = "https://github.com/OpenZWave/open-zwave/commit/601e5fb16232a7984885e67fdddaf5b9c9dd8105.patch"; sha256 = "1n1k5arwk1dyc12xz6xl4n8yw28vghzhv27j65z1nca4zqsxgza1"; }) (fetchpatch { name = "fix-text-uninitialized.patch"; url = "https://github.com/OpenZWave/open-zwave/commit/3b029a467e83bc7f0054e4dbba1e77e6eac7bc7f.patch"; sha256 = "183mrzjh1zx2b2wzkj4jisiw8br7g7bbs167afls4li0fm01d638"; }) ]; outputs = [ "out" "doc" ]; </ins> nativeBuildInputs = [ doxygen fontconfig graphviz-nox libxml2 pkg-config which ]; buildInputs = [ systemd ];
Code change:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

Related discussion:
text: enableParallelBuilding = true; <del> installPhase = '' runHook preInstall DESTDIR=$out PREFIX= pkgconfigdir=lib/pkgconfig make install $installFlags runHook postInstall ''; </del> <ins> makeFlags = [ "PREFIX=${placeholder "out"}" ]; </ins> FONTCONFIG_FILE="${fontconfig.out}/etc/fonts/fonts.conf"; FONTCONFIG_PATH="${fontconfig.out}/etc/fonts/";
Code change:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

Related discussion:
text: --replace /etc/openzwave $out/etc/openzwave ''; <del> fixupPhase = '' substituteInPlace $out/lib/pkgconfig/libopenzwave.pc  --replace prefix= prefix=$out  --replace dir=    dir=$out substituteInPlace $out/bin/ozw_config  --replace pcfile=${pkg-config} pcfile=$out ''; </del> meta = with lib; { description = "C++ library to control Z-Wave Networks via a USB Z-Wave Controller"; homepage = "http://www.openzwave.net/";
Code change:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

Related discussion:
text: <del> { python_openzwave, fetchPypi }: </del> <ins> { python_openzwave, fetchPypi, openzwave, fetchFromGitHub }: </ins> <del> python_openzwave.overridePythonAttrs (oldAttrs: rec { </del> <ins> (python_openzwave.override { openzwave = openzwave.overrideAttrs (oldAttrs: { version = "unstable-2020-03-24"; src = fetchFromGitHub { owner = "home-assistant"; repo = "open-zwave"; rev = "94267fa298c1882f0dc73c0fd08f1f755ba83e83"; sha256 = "0p2869fwidz1wcqzfm52cwm9ab96pmwkna3d4yvvh21nh09cvmwk"; }; patches = [ ]; }); }).overridePythonAttrs (oldAttrs: rec { </ins> pname = "homeassistant_pyozw"; version = "0.1.10";
Code change:
Describe the bug KDE has trouble with some SVGs, particularly the one bundled in alacritty. To Reproduce Steps to reproduce the behavior: alacritty Expected behavior The icon was properly rendered. Screenshots See picture of gwenview vs. inkscape vs icon in my taskbar. ! Additional context It seems alacritty bundles a png for KDE, as well as a high compat svg, I'm currently trying to make an overlay to fix this. See:

Related discussion:
text: cp -r $releaseDir/osx/Alacritty.app $out/Applications/Alacritty.app '' else '' install -D extra/linux/Alacritty.desktop -t $out/share/applications/ <del> install -D extra/logo/alacritty-term.svg $out/share/icons/hicolor/scalable/apps/Alacritty.svg </del> <ins> install -D extra/logo/compat/alacritty-term.svg $out/share/icons/hicolor/scalable/apps/Alacritty.svg </ins> # patchelf generates an ELF that binutils' "strip" doesn't like: #    strip: not enough room for program headers, try linking with -N
Code change:
Describe the bug Since switching from to I needed to switch from to , otherwise the system does not boot anymore. To Reproduce Steps to reproduce the behavior: system on lvm-inside-luks using either or channel password - gets accepted correctly - LUKS seems to be working does not boot - complains about missing root device Expected behavior Would boot :) Screenshots : ! : ! Additional context All my config for this machine starts from - I link this file in place of Notify maintainers maybe ? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. ^ using channel with kernel right now Happy to help debug this if needed :)
What filesystem are you using? If it's a mainlined filesystem, I don't believe hardened should've broken that. But it's probably depending on which is disabled in hardened.
Thanks so much for the reponse :) It's for , hopefully still mainlined ? ;) I can try to compile the kernel with set but otherwise with hardened settings enabled and see if it helps ?
Sorry, this is my fault! Yeah, my guess is that we need to re-enable AIO. I did notice some additional harmless-seeming warnings at boot that seemed AIO-related when writing (which switched to a patchset that disables AIO by default), but I guess it didn't affect any of my systems because they use ZFS. I was hoping AIO was only required by marginal things (like Oracle...), but LVM is pretty important. Given that nginx also uses AIO per , it might be worth explicitly turning it on in the default shared Kconfig (as I did for System V IPC in the original PR). I'm not sure if the AIO code is known to be particularly crufty by Linux standards or if it's just a general attack surface reduction thing; a few of the linux-hardened defaults are a bit better-suited to the Android environment than a desktop Linux distro. credits to the original linux-hardened author's Android-based which makes me suspect this might be the case here. Here's a nixpkgs diff to re-enable AIO: It'd definitely be good to know if this fixes things for you. should be enough to test this. If you don't want to use a custom nixpkgs then you can do a fiddly thing like the definition of  in .
Also, this would be pretty easy to test for, so if this change fixes it then we should also update the hardened test to use LVM.
Heya, good news ! One kernel compilation later - I'm back to running thanks to you :) I tried the route and indeed it worked. For the test - I think that would be awesome, to catch things like this in the future :)

Related discussion:
text: SYSVIPC            = yes;  # System-V IPC <ins> AIO                = yes;  # POSIX asynchronous I/O </ins> UNIX               = yes;  # Unix domain sockets. MD                 = yes;     # Device mapper (RAID, LVM, etc.)
Code change:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error. Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:

Related discussion:
text: { lib, fetchFromGitHub , makeWrapper, makeDesktopItem, mkYarnPackage , electron, element-web <ins> , callPackage </ins> }: # Notes for maintainers: # * versions of `element-web` and `element-desktop` should be kept in sync.