jiebi/CodeConvo huggingface dataset:
Change:
sed -e "1s@.*@#! ${lua}/bin/lua$LUA_SUFFIX@" -i "$out"/bin/* substituteInPlace $out/etc/luarocks/*  --replace '${lua.luaOnBuild}' '${lua}' <ins> '' + lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' installShellCompletion --cmd luarocks  --bash <($out/bin/luarocks completion bash)  --fish <($out/bin/luarocks completion fish)  --zsh <($out/bin/luarocks completion zsh) installShellCompletion --cmd luarocks-admin  --bash <($out/bin/luarocks-admin completion bash)  --fish <($out/bin/luarocks-admin completion fish)  --zsh <($out/bin/luarocks-admin completion zsh) '' + '' </ins> for i in "$out"/bin/*; do test -L "$i" || { wrapProgram "$i" 

Discussion:
Another Problem:
patch welcome !
in , the call to generate completion should be moved to before the wrapping. And it should be called for luarocks-admin too thanks for noticing. Let me know if you wanna do it.
If u wanna test
Change:
<ins> { lib , stdenv , fetchFromGitHub , appstream-glib , desktop-file-utils , gobject-introspection , meson , ninja , pkg-config , wrapGAppsHook4 , gjs , gtk4 , libadwaita , libportal-gtk4 }: stdenv.mkDerivation rec { pname = "junction"; version = "1.5.0"; src = fetchFromGitHub { owner = "sonnyp"; repo = "junction"; rev = "v${version}"; sha256 = "sha256-jS4SHh1BB8jk/4EP070X44C4n3GjyCz8ozgK8v5lbqc="; }; nativeBuildInputs = [ appstream-glib desktop-file-utils gobject-introspection meson ninja pkg-config wrapGAppsHook4 ]; buildInputs = [ gjs gtk4 libadwaita libportal-gtk4 ]; postInstall = '' # autoPatchShebangs does not like "/usr/bin/env -S gjs" substituteInPlace $out/bin/re.sonny.Junction --replace "/usr/bin/env -S gjs" "/usr/bin/gjs" ''; meta = with lib; { description = "Choose the application to open files and links"; homepage = "https://apps.gnome.org/en/app/re.sonny.Junction/"; license = licenses.gpl3Plus; maintainers = with maintainers; [ hqurve ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description Junction lets you choose the application to open files and links. Junction will pop up automatically when you open a link in a desktop application. Use the mouse or keyboard navigation to choose the application to open the link or file with. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Change:
patches = [ ./no-ldconfig.patch <ins> ./ld_library_path.patch </ins> ]; postPatch = ''

Discussion:
doesn't return anything on Python 3.4 and 3.5. This breaks which is needed for TensorFlow on Python 3 (prebuilt TensorFlow doesn't support Python 3.6). Nixpkgs version: (run ) cc
Yea, I noticed this. I think its caused by .
What did this function returned before? I think we can hard-code this information as it seems to already set at build time (location of libc and so on)
See result from above (Python 3.6 works okay). Hardcoding this is impossible as should resolve libraries from and other sources (if I understand correctly).
I have tried adding LDLIBRARYPATH to the cffi derivation, to no avail. Also, reverting commit does not change the test failures in cffi. My revert was on top of .
what's the plan? Should we revert the commit you linked?
Seems like I tested the wrong commit. Please ignore my previous comment.
reverting that commit does fix cffi on 3.4 but it does not fix cffi on 3.5
you would need to revert also , I suppose that it should be fine then.
that's what I did today because I noticed my mistake. I have checked out release-17.09 (at commit ) and then reverted . Doing so makes cffi build on python 3.4 but not on python 3.5. I am now building cffi on python 3.5 with reverted.
Ok, that solves the problem. Reverting both and fixes the problems on 3.4 and 3.5, but 3.6 does not need these reverts, so this needs some more manual work. Perhaps you can see what's different between these python versions, ? I suppose it's best that you fix it, because you seem to be more familiar with these changes and the reasons behind.
Yes, I'm going to have a look at this, but likely not until Wednesday.
FYI: this is blocking the darwin channel
sounds good :)
Either we hardcode paths (preferable) or we set , in which case should work. That was unrelated (Python 3.6 cffi). The seems to have caused this regression. The reason is that prior to 3.6 was not checked.

It did work before, but maybe that was because it used linker to find it? That code seems to have changed between 2.7 and 3.x. In any case, we should be able to backport the portion in 3.6 that checks .
Note that on Darwin it does not check for . We may in the future choose to support this.
Fix in
Change:
python3Packages.buildPythonApplication rec { pname = "gnome-secrets"; <del> version = "6.1"; </del> <ins> version = "6.4"; </ins> format = "other"; strictDeps = false; # https://github.com/NixOS/nixpkgs/issues/56943

Discussion:
When trying to start gnome-secrets it fails with the message: Steps to reproduce the behavior: -shell -p gnome-secrets --run "secrets" Please run and paste the result.
Also gnome-secrets 6.4 is available. Updating it to the latest version doesn't solve the issue :(
Fixed by
Thank you for your work!
Change:
imgp = python3Packages.callPackage ../applications/graphics/imgp { }; <del> imhex = callPackage ../applications/editors/imhex { }; </del> inframap = callPackage ../applications/networking/cluster/inframap { }; inkcut = libsForQt5.callPackage ../applications/misc/inkcut { };

Discussion:
Package name: imhex Latest released version: 1.31.0 <!-- Search your package here: --- Current version on the unstable channel: 1.30.1 Current version on the stable/release channel: 1.30.1 <!-- 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.
Change:
license = stdenv.lib.licenses.mit; platforms = stdenv.lib.platforms.unix; maintainers = with maintainers; [ fuuzetsu ]; <ins> broken = true; </ins> }; })

Discussion:
As of Agda 2.5.1 (which comes on the latest nixos-unstable release), both nixpkgs' agda-stdlib (from git nominally at version 2.4.2.3) and an updated version (v0.12, the most recent release) fail to build. Some modules are checked successfully, but it gets stuck at (the first builtin module it finds). For this module only, it tries to write to . Output: System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""
has the same issue, meaning that there has probably been some change in Agda. The problem seems to be that writes a file for each file it checks, and some files it's checking are in the Nix store (specifically, in ). I think it's to do with . Maybe it would work if these were checked when building .
Current status: .
Fixed by .
Let's keep this open until the fix lands in master.
Change:
postInstall = '' install -Dm755 -t $client/bin $out/bin/tsh <ins> wrapProgram $out/bin/tsh --prefix PATH : ${xdg-utils}/bin </ins> ''; doInstallCheck = true;

Discussion:
Describe the bug Browser page fails to open if no installed on the system. To Reproduce Steps to reproduce the behavior: teleport using SAML (might need enterprise license) using tsh + SAML errors thrown, but the browser page doesn't open Expected behavior Browser page should open and ask for credentials. 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:
Change:
gettext pkg-config wrapGAppsHook3 <ins> gobject-introspection.setupHook autoreconfHook </ins> ]; buildInputs = [

Discussion:
Build on master Steps to reproduce the behavior: Full log: it builds successfully with python39 <!-- 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]:
It builds successfully with python39
Change:
{ lib <del> , stdenv </del> , rustPlatform , fetchFromGitHub <del> , openssl , pkg-config , installShellFiles </del> <ins> , stdenv </ins> , enableCompletions ? stdenv.hostPlatform == stdenv.buildPlatform <ins> , installShellFiles , pkg-config </ins> , Security , libiconv <ins> , openssl </ins> }: rustPlatform.buildRustPackage rec { pname = "himalaya"; <del> version = "0.4.0"; </del> <ins> version = "0.5.1"; </ins> src = fetchFromGitHub { owner = "soywod"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-6RgT/SxO4vsk8Yx2AbaNIFvnAvgDmeTXvb/v6nUJxhc="; </del> <ins> sha256 = "sha256-BmV4kekl0QDbX/ueSrWM5jRvqr6WQeZIs7hiXhiHBSI="; </ins> }; <del> cargoSha256 = "sha256-NEuIh7FwIdAWzlChna3+G0VukfV8nYZfVWa+3LxQCIA="; # use --lib flag to avoid test with imap server # https://github.com/soywod/himalaya/issues/145 cargoTestFlags = [ "--lib" ]; </del> <ins> cargoSha256 = "sha256-lu5xVuAw9yTeQr3gpiW5g5bdm7Alf0YXmlbSkPaXhk0="; </ins> <del> nativeBuildInputs = [ ] ++ lib.optionals (enableCompletions) [ installShellFiles ] </del> <ins> nativeBuildInputs = lib.optionals enableCompletions [ installShellFiles ] </ins> ++ lib.optionals (!stdenv.hostPlatform.isDarwin) [ pkg-config ]; buildInputs =

Discussion:
<!-- 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 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: himalaya <!-- The current version can be found easily with the same process than 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.4.0 desired version: 0.5.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: I tried this but didn't work for me. I don't know anything about Rust tooling.
Change:
buildGoModule rec { pname = "apx"; <del> version = "1.4.2"; </del> <ins> version = "1.7.0-1"; </ins> src = fetchFromGitHub { owner = "Vanilla-OS"; repo = pname; <del> rev = version; sha256 = "sha256-BswX4Jo/RReM/tXo29V9rIvKjN8ylECPe0oo0FCQcGY="; </del> <ins> rev = "v${version}"; hash = "sha256-tonI3S0a08MbR369qaKS2BoWc3QzXWzTuGx/zSgUz7s="; </ins> }; vendorSha256 = null;

Discussion:
Package name: apx Latest released version: 1.7.0-1 <!-- Search your package here: --- Current version on the unstable channel: 1.4.2 Current version on the stable/release channel: <!-- 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:
Looks like they as a package manager to itself and made some other changes too. I am going to take a look at this by tomorrow.
I have created a PR but have not tested the package extensively myself. Could you please test it?
I have tried these two pr and by and it seams works well
Change:
materialx = callPackage ../development/python-modules/materialx { }; <ins> materialyoucolor = callPackage ../development/python-modules/materialyoucolor { }; </ins> matchpy = callPackage ../development/python-modules/matchpy { }; mathlibtools = callPackage ../development/python-modules/mathlibtools { };

Discussion:
Project description for python! <!-- Describe the project a little: --It is built in reference with offical except it's color quantization part, which is based on thanks to . Metadata homepage URL: source URL: license: mit platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> { lib, mkDerivation, fetchFromGitHub, cmake, qtbase }: mkDerivation rec { pname = "kcolorpicker"; version = "0.1.6"; src = fetchFromGitHub { owner = "ksnip"; repo = "kColorPicker"; rev = "v${version}"; sha256 = "1167xwk75yiz697vddbz3lq42l7ckhyl2cvigy4m05qgg9693ksd"; }; nativeBuildInputs = [ cmake ]; buildInputs = [ qtbase ]; meta = with lib; { description = "Qt based Color Picker with popup menu"; homepage = "https://github.com/ksnip/kColorPicker"; license = licenses.lgpl3Plus; maintainers = with maintainers; [ fliegendewurst ]; platforms = platforms.linux; }; } </ins>

Discussion:
Describe the bug Starting with version 20.12, Spectacle has annotation support, utilizing . Most big distributions already ship Spectacle with the feature enabled. I assume kImageAnnotator needs to be packaged and integrated with the existing Spectacle package. Screenshots Screenshot of the functionality from the official KDE docs: ! Additional context Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
Change:
{ stdenv, substituteAll , fetchurl, perl, gcc, llvm , ncurses5, gmp, glibc, libiconv <ins> , llvmPackages </ins> }: # Prebuilt only does native assert stdenv.targetPlatform == stdenv.hostPlatform; let <ins> useLLVM = !stdenv.targetPlatform.isx86; </ins> libPath = stdenv.lib.makeLibraryPath ([ ncurses5 gmp ] ++ stdenv.lib.optional (stdenv.hostPlatform.isDarwin) libiconv);

Discussion:
On current master (). Fails with See also the . Additional context The hscolour derivation mentioned here does not contain in its . It seems sufficient to make be a propagated build input for , after doing so I can build ghc itself. There's a lot of Metadata Maintainer information:
Can you send a PR fixing this?
Done, see
[ ] port to
Since this issue was opened the situation has changed. There's still no ghc on aarch64, but now it fails due to [the lack of aarch64 support][] in (aka ). [the lack of aarch64 support]:
After PR the default ghc builds for aarch64 (, ATM only in branch).
Change:
Log1(PCSC_LOG_INFO, "Disabling USB support for pcscd"); return 0; diff --git a/src/hotplug_libusb.c b/src/hotplug_libusb.c <del> index eff8519..8dd496d 100644 </del> <ins> index 0ada9f5..d49a407 100644 </ins> --- a/src/hotplug_libusb.c +++ b/src/hotplug_libusb.c <del> @@ -138,7 +138,8 @@ static LONG HPReadBundleValues(void) </del> <ins> @@ -142,7 +142,8 @@ static LONG HPReadBundleValues(void) </ins> if (hpDir == NULL) {

Discussion:
The package installs that contains an unconfigured variable: This results in the following message in system journal: Obviously, not critical, but still this doesn’t sound right. The contains , so it looks like gets replaced by literal , but I am not sure where this happens or why. Steps to reproduce the behavior: There should be no unsubstituted variables in the installed unit. Maintainer information:
Looks like this line was upstream in 1.9.2 and the version in nixpkgs was upgraded from 1.9.1 to 1.9.4 in October ().
Ok, I am not particularly good with Autotools, but it seems to me that it is an upstream bug. The generate does this replacement, but I think it is supposed to happen only in a context in which this will be further expanded, not in plaintext files intended to be simply copied to their final install location.
Yes, it’s definitely an upstream issue. This usage of is explicitly called out as incorrect in Autconf docs:
Reported upstream:
Fixed in 1.9.5 (just released):
Keep in mind that this needs to point at if it is to be used for anything instead of into the nix store.
Can we make an option to allow specific ? I can help to make a PR if you agree : )
Send a PR I guess? Although, I am not sure how useful this option will be, given that, I assume, all other packages have to be linked to the same pcsc that provides the daemon. On the other hand, many other packages have this option, and I don’t know if there is some pattern or policy in NixOS.
The fixes PR is merged, but if a stable user (, etc.) wants to solve these issues, he could be: nix overlays, let = the package from newer channel, this will cause rebuild of all package that depends on it. to override attribute of , which is tedious and error-prone. So I suggest either we add an option to allow specific the package,or backport the changes to stable branch...?
Change:
}) ]; <ins> # https://github.com/imageio/imageio-ffmpeg/issues/59 postPatch = '' sed -i '/setup_requires=["pip>19"]/d' setup.py ''; </ins> checkPhase = '' runHook preCheck

Discussion:
I'm confused about this issue. I didn't open it
You might have accidentally clicked the "Convert to issue" button: <img width="1078" alt="Screenshot 2023-08-22 at 10 58 41 AM" src=""
Possible
Change:
writeText "davinci-wrapper" '' export QT_XKB_CONFIG_ROOT="${xkeyboard_config}/share/X11/xkb" <ins> export QT_PLUGIN_PATH="${davinci}/libs/plugins:$QT_PLUGIN_PATH" </ins> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${davinci}/libs ${davinci}/bin/resolve ''

Discussion:
Whenever I try to launch DaVinci Resolve, it crashes. Console logs are attached below. Steps to reproduce the behavior: DaVinci Resolve runs ! ! Console logs in text form: console davinci-resolve ActCCMessage Already in Table: Code= c005, Mode= 13, Level= 1, CmdKey= -1, Option= 0 ActCCMessage Already in Table: Code= c006, Mode= 13, Level= 1, CmdKey= -1, Option= 0 ActCCMessage Already in Table: Code= c007, Mode= 13, Level= 1, CmdKey= -1, Option= 0 ActCCMessage Already in Table: Code= 2282, Mode= 0, Level= 0, CmdKey= 8, Option= 0 PnlMsgActionStringAdapter Already in Table: Code= 615e, Mode= 0, Level= 0, CmdKey= -1, Option= 0 0010 Linux/Clang x86_64 Main thread starts: log4cxx: setFile(,true) call failed. log4cxx: IO Exception : status code = 30 0x7fd616033680
log4cxx: No output stream or file set for the appender named [RollLogAppender]. 0x7fd616033680 Loaded log config from 0x7fd616033680
console nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(flexagoon): nixpkgs:
Could you include your file? I had the similar problem and it was fixed by correcting the QTPLUGINPATH in davinci-resolve package. Perhaps your problem is related.
I can't, because I am no longer using NixOS. Should I close this issue?
I have no idea, probably better not to. I've made a pull request that fixed the issue for me, and the issue looked exactly like yours. When somebody reviews my PR, I'll ask them about closing this issue.
this issue persist
Change:
"fs.inotify.max_queued_events" = 1048576; "fs.inotify.max_user_instances" = 1048576; "fs.inotify.max_user_watches" = 1048576; <del> "vm.max_map_count" = 262144; </del> <ins> "vm.max_map_count" = 262144; # TODO: Default vm.max_map_count has been increased system-wide </ins> "kernel.dmesg_restrict" = 1; "net.ipv4.neigh.default.gc_thresh3" = 8192; "net.ipv6.neigh.default.gc_thresh3" = 8192;

Discussion:
Applications are starting to allocate more times than allowed by the default value of vm.maxmapcount, . For instance, this situation arises in applications such as Ryujinx () and newer Windows games like Hogwarts Legacy (). SteamOS has already addressed this matter by augmenting the aforementioned value, while Fedora intends to implement the same modification in Fedora 39 (, ).
Please feel free to send PRs, it's hard to track those issues as you don't mention any owner.
The line to add is: The questions are: How big should n be? ? ? In which file should I add it? At the bottom of
You mentioned other distros were thinking about bumping it, let's follow Fedora lead In the relevant file, a quick grep shows indeed that sysctl is one of the best candidate. :)
For the policy discussion: I'm all in favor of doing this soon(m). It is not really dangerous and as people have explained to me the previous default has been there for historical reasons and 32 bit systems.
Change:
{ lib , stdenv , fetchurl <ins> , writeScript </ins> , libX11 , libXext , alsa-lib

Discussion:
404 when trying to install. Version is out of date on both stable / unstable. Current version is 1.3.5 aka <

<] Trying to install this and get failure due to bad URL. Probably due to a stale version number, this should target the most recent version or redux
Change:
patches = [ ./cmake-dirs.patch <del> # fix cmake config (fetchpatch { url = "https://github.com/aws/aws-sdk-cpp/commit/b102aaf5693c4165c84b616ab9ffb9edfb705239.diff"; sha256 = "sha256-38QBo3MEFpyHPb8jZEURRPkoeu4DqWhVeErJayiHKF0="; }) </del> ]; # Builds in 2+h with 2 cores, and ~10m with a big-parallel builder.

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking maintainers cc: aws-sdk-cpp maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag: -
Managed to bisect this down to would you mind taking a look?
Sure thing
There are commits between the release on nixpkgs (1.9.150) and the latest release (1.9.238) that fixes gcc11 / c++17 issues. : Testing building latest release; if it isn't something that can be considered (incompatibilities?) then adding them as patches should work.
Change:
{ lib, stdenv, fetchurl, makeWrapper , haskellPackages, haskell <del> , which, swiProlog, rlwrap, tk </del> <ins> , which, swi-prolog, rlwrap, tk </ins> , curl, git, unzip, gnutar, coreutils, sqlite }: let

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
stdenv.mkDerivation rec { pname = "p11-kit"; <del> version = "0.23.21"; </del> <ins> version = "0.23.22"; </ins> src = fetchFromGitHub { owner = "p11-glue"; repo = pname; rev = version; <del> sha256 = "1w24brn8j3vwfp07p2hldw2ci06pk1cx1dvjk8jjxkccp20fk958"; </del> <ins> sha256 = "sha256-erWqElJr0iESNUk9EZiJRmSMYhns8GxuFLNw7mIIIWs="; </ins> }; outputs = [ "out" "dev"];

Discussion:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=5.3 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: .