jiebi/CodeConvo huggingface dataset:
Code change:
dependencies = []; buildInputs = [ python go cmake <del> (if stdenv.isDarwin then llvmPackages.clang else llvmPackages.clang-unwrapped) llvmPackages.llvm </del> ] ++ stdenv.lib.optional stdenv.isDarwin Cocoa; propagatedBuildInputs = stdenv.lib.optional (!stdenv.isDarwin) rustracerd; patches = [ <del> ./patches/youcompleteme/1-top-cmake.patch </del> ./patches/youcompleteme/2-ycm-cmake.patch ]; <ins> # YCM requires path to external libclang 3.9 # For explicit use and as env variable for ../third_party/ycmd/build.py EXTRA_CMAKE_ARGS="-DEXTERNAL_LIBCLANG_PATH=${llvmPackages.clang.cc}/lib/libclang.${if stdenv.isDarwin then "dylib" else "so"}"; </ins> buildPhase = '' patchShebangs . substituteInPlace plugin/youcompleteme.vim 

Related discussion:
text: Building on Darwin fails. The problem seems very similar to which was solved by —however I do not know how to apply that solution here.
Wasn't this fixed by merging
This issue is fixed, but it broke again recently. Same issue as but we use
Proposed
Fixed by
Code change:
<del> { stdenv, buildPythonPackage, fetchPypi, six }: buildPythonPackage rec { pname = "websocket_client"; version = "0.54.0"; src = fetchPypi { inherit version pname; sha256 = "e51562c91ddb8148e791f0155fdb01325d99bb52c4cdbb291aee7a3563fd0849"; }; prePatch = '' # ssl.match_hostname exists in python2.7 version maintained in nixpkgs, # the dependency is not necessary. sed -e "s/['backports.ssl_match_hostname']/[]/" -i setup.py ''; propagatedBuildInputs = [ six ]; meta = with stdenv.lib; { homepage = https://github.com/liris/websocket-client; description = "Websocket client for python"; license = licenses.lgpl2; }; } </del>

Related discussion:
text: I had i3pystatus fail to build because of a pytest error with praw on unstable. I tried to bump praw from 6.0.0 to 6.3.1 but it requires a new dep websocket-client that doesn't look packaged thus I ended up ditching it from i3pystatus dependencies. Maybe we should do the same upstream and provide a leaner i3pystatus as it's not a core plugin anyway (and fails ). nix build -f channel:nixos-unstable system: host os: multi-user?: sandbox: version: channels(teto): channels(root): nixpkgs:
CC ? what do you think of removing it from i3pystatus default ?
Agree. A user can add manually by overriding of parameter.
is this still relevant now? or can it be closed?
I just removed praw it from i3pystatus default dependencies but itself still won't build. So it makes sense to keep the issue open even if I have no personal interest in praw.
it was irritating me, so i updated it.
Code change:
}) (callPackage ./common-overrides.nix { <del> inherit haskellLib; </del> <ins> inherit haskellLib fetchpatch buildPackages; </ins> }) ghcjsDepOverrides ]);

Related discussion:
text: As a fallout of the migration to GHC 9.0.2 got marked as broken, as it failed to build with GHC 9.0.2 and the Stackage LTS 19 package set we now have. It would be necessary to investigate if survived this (i.e. if it still builds) and if not to get it to work again. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc
should compile again. The bootstrap is additionally built by Hydra, so only the GHC bundled libraries will need to be compiled (which is an improvement to before at least).
Code change:
<ins> { lib , stdenvNoCC , fetchFromGitHub , fetchzip , clickgen }: stdenvNoCC.mkDerivation rec { pname = "bibata-cursors"; version = "2.0.6"; src = fetchFromGitHub { owner = "ful1e5"; repo = "Bibata_Cursor"; rev = "v${version}"; hash = "sha256-iLBgQ0reg8HzUQMUcZboMYJxqpKXks5vJVZMHirK48k="; }; bitmaps = fetchzip { url = "https://github.com/ful1e5/Bibata_Cursor/releases/download/v${version}/bitmaps.zip"; hash = "sha256-8ujkyqby5sPcnscIPkay1gvd/1CH4R9yMJs1nH/mx8M="; }; nativeBuildInputs = [ clickgen ]; buildPhase = '' runHook preBuild ctgen build.toml -p x11 -d $bitmaps/Bibata-Modern-Amber -n 'Bibata-Modern-Amber' -c 'Yellowish and rounded edge bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Modern-Classic -n 'Bibata-Modern-Classic' -c 'Black and rounded edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Modern-Ice -n 'Bibata-Modern-Ice' -c 'White and rounded edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Original-Amber -n 'Bibata-Original-Amber' -c 'Yellowish and sharp edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Original-Classic -n 'Bibata-Original-Classic' -c 'Black and sharp edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Original-Ice -n 'Bibata-Original-Ice' -c 'White and sharp edge Bibata cursors.' runHook postBuild ''; installPhase = '' runHook preInstall install -dm 0755 $out/share/icons cp -rf themes/* $out/share/icons/ runHook postInstall ''; meta = { description = "Material Based Cursor Theme"; homepage = "https://github.com/ful1e5/Bibata_Cursor"; license = lib.licenses.gpl3Only; platforms = lib.platforms.linux; maintainers = with lib.maintainers; [ rawkode AdsonCicilioti ]; }; } </ins>

Related discussion:
text: Package name: bibata-cursors Latest released version: 2.0.4 <!-- Search your package here: --- Current version on the unstable channel: 2.0.3 Current version on the stable/release channel: 2.0.3 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Code change:
inherit (lib) types; cfg = config.services.ollama; <del> ollamaPackage = cfg.package.override { </del> <ins> ollamaPackage = cfg.package.override (prevArgs: { </ins> inherit (cfg) acceleration; <ins> } // lib.optionalAttrs (prevArgs ? linuxPackages) { </ins> linuxPackages = config.boot.kernelPackages // { nvidia_x11 = config.hardware.nvidia.package; }; <del> }; </del> <ins> }); </ins> in { options = {

Related discussion:
text: Steps to reproduce the behavior: unstable defined, enable the ollama service with pkg overridden to point at unstable: without show-trace: with --show-trace: Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi! Can you confirm your nixpkgs revision has this change incorporated and you're not overriding the package manually?
Code change:
dontWrapQtApps = true; meta = with lib; { <del> maintainers = with lib.maintainers; [ peterhoeg ]; </del> <ins> description = "KDE Partition Manager core library"; homepage = "https://invent.kde.org/system/kpmcore"; license = with licenses; [ cc-by-40 cc0 gpl3Plus mit ]; maintainers = with maintainers; [ peterhoeg oxalica ]; </ins> # The build requires at least Qt 5.14: <del> broken = lib.versionOlder qtbase.version "5.14"; </del> <ins> broken = versionOlder qtbase.version "5.14"; </ins> }; }

Related discussion:
text: Describe the bug and failed to build on current master (). (The former depends on the latter.) Build log: To Reproduce Steps to reproduce the behavior: nixpkgs master. (or ) the build error. Expected behavior It builds. 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:
Code change:
dontWrapQtApps = true; meta = with lib; { <del> maintainers = with lib.maintainers; [ peterhoeg ]; </del> <ins> description = "KDE Partition Manager core library"; homepage = "https://invent.kde.org/system/kpmcore"; license = with licenses; [ cc-by-40 cc0 gpl3Plus mit ]; maintainers = with maintainers; [ peterhoeg oxalica ]; </ins> # The build requires at least Qt 5.14: <del> broken = lib.versionOlder qtbase.version "5.14"; </del> <ins> broken = versionOlder qtbase.version "5.14"; </ins> }; }

Related discussion:
text: Describe the bug If you open KDE Partition Manager using its file, it tells you that you aren't running it as root, and you won't be able to make any changes with it (rendering the program useless). The only workaround is running (which is probably unintuitive to people with less linux experience) or changing the file (a bad idea when you want Nix to manage your system) To Reproduce Steps to reproduce the behavior: by adding it to your the file (e.g. in KDE, click on the start menu in the bottom left, type in partition manager, and click on the program) Expected behavior Use when clicking the file for a seamless experience Screenshots ! Additional context The message mentions so I tried adding it to by hand, but that did not work. Metadata Maintainer information:
Looks like the package is out of date. This dialogue does not appear to be part of the latest version:
This might work
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Code change:
disallowedReferences = [ stdenv.cc.cc ]; postFixup = '' <del> remove-references-to -t ${stdenv.cc.cc} "$(readlink -f $out/share/perl6/runtime/dynext/libperl6_ops_moar.so)" </del> <ins> remove-references-to -t ${stdenv.cc.cc} "$(readlink -f $out/share/perl6/runtime/dynext/libperl6_ops_moar${stdenv.hostPlatform.extensions.sharedLibrary})" </ins> ''; meta = with lib; {

Related discussion:
text: = 2021.07 does not build successfully on Darwin. A bisect over commits shows this: 2021.10 - - does not work 2021.07 - - does not work 2021.06 - - works 2020.12 - - works Steps to reproduce the behavior: this repo: on Darwin. (I'm on MacOS Big Sur). line 4 from to . . Observe the build failure in the output: For the full log, see .
Caused by Please use to show the files that a working rakudo contains on darwin
Tested on and it works. Thanks!
Code change:
(if compat185 then "--enable-compat185" else "--disable-compat185") ] ++ lib.optional dbmSupport "--enable-dbm" <del> ++ lib.optional stdenv.isFreeBSD "--with-pic"; </del> <ins> ++ lib.optional stdenv.isFreeBSD "--with-pic" ++ (drvArgs.configureFlags or []); </ins> preConfigure = '' cd build_unix

Related discussion:
text: Steps to reproduce the behavior: 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
mkOptionDefault mkDefault mkImageMediaOverride mkForce mkVMOverride mkFixStrictness mkOrder mkBefore mkAfter mkAliasDefinitions mkAliasAndWrapDefinitions fixMergeModules mkRemovedOptionModule <del> mkRenamedOptionModule mkMergedOptionModule mkChangedOptionModule </del> <ins> mkRenamedOptionModule mkRenamedOptionModuleWith mkMergedOptionModule mkChangedOptionModule </ins> mkAliasOptionModule mkDerivedConfig doRename; inherit (self.options) isOption mkEnableOption mkSinkUndeclaredOptions mergeDefaultOption mergeOneOption mergeEqualOption mergeUniqueOption

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
Code change:
exit 1 fi <ins> # Resolve symlinks in the init parameter. We need this for some boot loaders # (e.g. boot.loader.generationsDir). closure="$(chroot /sysroot ${pkgs.coreutils}/bin/realpath "$closure")" # Assume the directory containing the init script is the closure. closure="$(dirname "$closure")" </ins> # If we are not booting a NixOS closure (e.g. init=/bin/sh), # we don't know what root to prepare so we don't do anything if ! [ -x "/sysroot$(readlink "/sysroot$closure/prepare-root" || echo "$closure/prepare-root")" ]; then

Related discussion:
text: The script does not (consistently) follow symlinks in the parameter, which it uses to locate the system closure to activate. This breaks when used with , which creates a symlink. When the kernel command line has , the script looks for , which does not exist. ~(Workaround: generationsDir users can pass instead.)~ Update: That doesn't work either. with will fail in strange ways, ultimately stemming from not calling . System should boot successfully when using generationsDir and systemd-initrd together. Symlink resolution was partially addressed in , but only for cases where is a symlink. Booting also fails if the given is a symlink, or if any part of the path to is an absolute symlink (because filesystems are mounted at , not ). I took a stab at fixing this in (), but it does not handle absolute symlinks correctly. Since generationsDir creates absolute symlinks to , this fix alone does not fix compatibility. ( changes those symlinks to relative, and together the PRs fix the compatibility issue.) Ideally, the script should follow symlinks in any part of the param, even if they cross filesystems. One option is to resolve the links inside the chroot. I couldn't figure out a clean way to make this work. (Can we trust that will have the we're looking for? We can't use because we're still trying to establish which system that is.) Another option is to somehow . (At time of writing, this question has no answers.) (guessing based on git log):
Code change:
setupHooks = [ ../setup-hooks/role.bash <del> ./setup-hook.sh ]; </del> <ins> ] ++ stdenv.lib.optional (cc.langC or true) ./setup-hook.sh ++ stdenv.lib.optional (cc.langFortran or false) ./fortran-hook.sh; </ins> postFixup = ''

Related discussion:
text: Describe the bug To Reproduce Expected behavior The derivation to build an executable called Additional context It fails with also but succeeds with but so 1.3 seems to be a recent addition even though julia is on 1.4 and about to move to 1.5. Notify maintainers Metadata Please run and paste the result.
Same issue here: system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: This prevents installing GNU octave on MacOS.
FWIW I was able to work around this issue by creating a to disable the checks in arpack: I was able to build octave successfully with that. I had to hack around a runtime issue finding , will log that as a separate issue.
Code change:
setupHooks = [ ../setup-hooks/role.bash <del> ./setup-hook.sh ]; </del> <ins> ] ++ stdenv.lib.optional (cc.langC or true) ./setup-hook.sh ++ stdenv.lib.optional (cc.langFortran or false) ./fortran-hook.sh; </ins> postFixup = ''

Related discussion:
text: Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:
Code change:
pushd "$(dirname "$(find -path '**/repgrep-stamp' | head -n 1)")" installManPage rgr.1 <del> installShellCompletion rgr.{bash,fish} _rgr </del> popd <ins> '' + lib.optionalString (stdenv.hostPlatform.canExecute stdenv.buildPlatform) '' # As it can be seen here: https://github.com/acheronfail/repgrep/blob/0.15.0/.github/workflows/release.yml#L206, the completions are just the same as ripgrep installShellCompletion --cmd rgr  --bash <(${lib.getExe ripgrep} --generate complete-bash | sed 's/-c rg/-c rgr/')  --zsh <(${lib.getExe ripgrep} --generate complete-zsh | sed 's/-c rg/-c rgr/')  --fish <(${lib.getExe ripgrep} --generate complete-fish | sed 's/-c rg/-c rgr/') </ins> ''; meta = with lib; {

Related discussion:
text: Package name: repgrep Latest released version: 0.15.0 <!-- Search your package here: --- Current version on the unstable channel: 0.14.3 Current version on the stable/release channel: 0.14.3 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
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 '';

Related discussion:
text: 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.
Code change:
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 '';

Related discussion:
text: I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:
Code change:
(config: let enabled = getAttrFromPath [ "services" "printing" "gutenprint" ] config; in if enabled then [ pkgs.gutenprint ] else [ ])) <del> (mkRenamedOptionModule [ "services" "ddclient" "domain" ] [ "services" "ddclient" "domains" ]) </del> <ins> (mkChangedOptionModule [ "services" "ddclient" "domain" ] [ "services" "ddclient" "domains" ] (config: let value = getAttrFromPath [ "services" "ddclient" "domain" ] config; in if value != "" then [ value ] else [])) </ins> (mkRemovedOptionModule [ "services" "ddclient" "homeDir" ] "") (mkRenamedOptionModule [ "services" "elasticsearch" "host" ] [ "services" "elasticsearch" "listenAddress" ]) (mkRenamedOptionModule [ "services" "graphite" "api" "host" ] [ "services" "graphite" "api" "listenAddress" ])

Related discussion:
text: option was changed to ddclient.domains, but instead of maintaining backwards compatibility the type was changed to a list of strings, which also was not in the release notes, which makes this a bug. I don't see why the type was not simply changed to an or of a string and a list of strings in order to maintain compatibility. Try to upgrade 18.03 with = ""; Any released 18.03 version.
As this breakage already happened, would there be a point in doing a patch for 18.09? (I could provide one, but I don't know, wether it will be merged into a stable branch.)
It would improve the experience for others (if you make it such that it works for both types). I cannot imagine any reason for it not being merged into a stable branch. I wouldn't mind merging it myself, but since I have no rights to do that you would have to wait longer.
hmm it looks like the module is in a weird state anyway. The config file, which is produced at the moment, doesn't look very useful, as all options will be applied to all domains likewise. So only one protocol can be used in nixos at the moment. If I am not mistaken I will need to change that into a config per domain, with a global part.
Your changes would introduce new features and go beyond what is in 18.09. 19.03 would be a good target. Due to the module system people could already use them in . Even then if would be nice if you could keep it backwards compatible. It's probably also relevant to consider whether there is an actual demand for what you are trying to do. For example, I would not be a potential user and most people would likely only use one protocol.
Not a problem, so I will just make the minimal possible change.
This needs to be reopened, because of a failure to build:
I'll take look. Which commit did you use?
Whatever was newest 15 hours ago in the release channel.
Yes, the change wasn't backported to the release branch :(
: Could you please reopen this and merge the change into release-18.09 ?