jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { config, lib, pkgs, ... }: with lib; { meta.maintainers = [ maintainers.oxalica ]; ###### interface options = { programs.partition-manager.enable = mkEnableOption "KDE Partition Manager"; }; ###### implementation config = mkIf config.programs.partition-manager.enable { services.dbus.packages = [ pkgs.libsForQt5.kpmcore ]; # `kpmcore` need to be installed to pull in polkit actions. environment.systemPackages = [ pkgs.libsForQt5.kpmcore pkgs.partition-manager ]; }; } </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:
<ins> { config, lib, pkgs, ... }: with lib; { meta.maintainers = [ maintainers.oxalica ]; ###### interface options = { programs.partition-manager.enable = mkEnableOption "KDE Partition Manager"; }; ###### implementation config = mkIf config.programs.partition-manager.enable { services.dbus.packages = [ pkgs.libsForQt5.kpmcore ]; # `kpmcore` need to be installed to pull in polkit actions. environment.systemPackages = [ pkgs.libsForQt5.kpmcore pkgs.partition-manager ]; }; } </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:
name = "${s.name}.tar.bz2"; }; <ins> prePatch = '' # Allow whitelisting ~/.nix-profile substituteInPlace etc/firejail.config --replace  '# follow-symlink-as-user yes'  'follow-symlink-as-user no' ''; </ins> preConfigure = '' sed -e 's@/bin/bash@${stdenv.shell}@g' -i $( grep -lr /bin/bash .) sed -e "s@/bin/cp@$(which cp)@g" -i $( grep -lr /bin/cp .)

Related discussion:
text: firejail bash . Error: cannot establish communication with the parent, exiting. . [milan ~]$ firejail --debug bash ~ Autoselecting /nix/store/fibk8jc2iwswn1q1d7aw98pcw2l3lzjf-bash-4.4-p12/bin/bash as shell Command name #bash# Attempting to find default.profile. Found default profile in /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail directory Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/default.profile Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/disable- Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/disable- Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/disable- Note: you can use --noprofile to disable default.profile DISPLAY :0, 0 Using the local network stack Parent pid , child pid Initializing child process Host network configured PID namespace installed Mounting tmpfs on /run/firejail/mnt directory Mounting read-only /bin, /sbin, /lib, /lib32, /lib64, /usr, /etc, /var Mounting tmpfs on /var/lock Mounting tmpfs on /var/tmp Mounting tmpfs on /var/log Create the new utmp file Mount the new utmp file Cleaning /home directory Sanitizing /etc/passwd, UIDMIN 1000 Sanitizing /etc/group,
Code change:
name = "${s.name}.tar.bz2"; }; <ins> prePatch = '' # Allow whitelisting ~/.nix-profile substituteInPlace etc/firejail.config --replace  '# follow-symlink-as-user yes'  'follow-symlink-as-user no' ''; </ins> preConfigure = '' sed -e 's@/bin/bash@${stdenv.shell}@g' -i $( grep -lr /bin/bash .) sed -e "s@/bin/cp@$(which cp)@g" -i $( grep -lr /bin/cp .)

Related discussion:
text: GIDMIN 1000 Disable /run/firejail/network Disable /run/firejail/bandwidth Disable /run/firejail/name Disable /run/firejail/x11 Remounting /proc and /proc/sys filesystems Remounting /sys directory Disable /sys/firmware Disable /sys/hypervisor Disable /sys/module Disable /sys/power Disable /sys/kernel/debug Disable /sys/kernel/vmcoreinfo Disable /proc/sys/fs/binfmtmisc Disable /proc/sys/kernel/corepattern Disable /proc/sys/kernel/modprobe Disable /proc/sysrq-trigger Disable /proc/sys/vm/paniconoom Disable /proc/irq Disable /proc/bus Disable Disable /proc/timerlist Disable /proc/timerstats Disable /proc/kcore Disable /proc/kallsyms Disable /boot Disable /dev/port Disable /dev/kmsg Disable /proc/kmsg Disable /home/milan/.gnuplothistory Disable /home/milan/.zshhistory Disable /home/milan/.bashhistory Mounting read-only Disable Error: cannot establish communication with the parent, exiting. [milan ~]$ System: (NixOS: , Ubuntu/Fedora: , .) (Hummingbird) Nix version: (run ) nix-env (Nix) 1.11.8 Nixpkgs version: (run ) ""
May be caused by . Does the same occur with , and not with ?
I'm having the same issue on Nixos 17.03. There at least it is exactly as you have described it, hence almost certainly the referenced issue.
Failure: [milan nixpkgs]$ firejail --noprofile -- firefox /etc/nixos/nixpkgs Parent pid , child pid Error: invalid whitelist path Error: cannot establish communication with the parent, exiting... Success: [milan nixpkgs]$ firejail --noprofile firefox /etc/nixos/nixpkgs Parent pid , child pid Child process initialized
Yep, that does look like it's that issue.
Code change:
stdenv.mkDerivation rec { pname = "tutanota-desktop"; <del> version = "3.108.12"; </del> <ins> version = "3.110.0"; </ins> src = fetchurl { url = "https://github.com/tutao/tutanota/releases/download/tutanota-desktop-release-${version}/${pname}-${version}-unpacked-linux.tar.gz"; name = "tutanota-desktop-${version}.tar.gz"; <del> sha256 = "sha256-ZXQCth5nhCkEZI348057cRjzFWl/IEytQmkmBuJzw3w="; </del> <ins> sha256 = "sha256-ufrhJfYolx/O0/a5AU1nuUpQy0Md6TVgmdhTAi9Appo="; </ins> }; nativeBuildInputs = [

Related discussion:
text: Package name: tutanota-desktop Latest released version: 3.110.0 <!-- Search your package here: --- Current version on the unstable channel: 3.108.12 Current version on the stable/release channel: 3.98.20 <!-- 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:
LUAROCKS="$LUAROCKS --verbose" fi <del> patchShebangs . </del> runHook postBuild '';

Related discussion:
text: Describe the bug neovim fails to build with missing , similar to , on . To Reproduce Steps to reproduce the behavior: to from master () Expected behavior The package should successfully build. Metadata On master () Maintainer information:
via in
so you could do until a proper fix.
Reverting the luarocks bump doesn't work for me. That fix is also very surprising to me, since neovim broke (for me) after the latest nixos-unstable channel update.
Interesting. It worked fine for me. Running the above revert command and then (inside my local nixpkgs with it reverted) let me build neovim properly. I don't think it's particularly surprising if updating a channel that happens to include the luarocks bump causes it to break, unless I'm misunderstanding you.
I updated from a channel where the luarocks bump had already happened, and neovim worked on that channel. In fact, I reverted to the previous hydra evaluation to make my system evaluate again.
This was actually before and it was working without problems and then suddenly the problem appeared again. I can also report that I cam getting this in the same way described (updated latest nixos-unstable channel and then neovim stopped building again).
I confirm this fixed by on master (channels may take a while). For now I'll assume that charvp's failure to resolve the issue with that revert was some kind of mistake; we can re-open otherwise, perhaps separately if it's a different kind of error.
Does anyone know why updating the luarocks dependency is so brittle? Is it possible to at least add a test so we don't regress again in the future?
the tool exists (nixpkgs-review) but it takes CPU and disk space to run plus some reviewer time (and was not run in this case). Also for this specific case, the luarocks update broke in subtle ways the build so I wouldn't call it . It is called unstable for a reason. The good thing about nixpkgs is you can pin neovim to an older version while keeping your system on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Are we sure this is fixed on Darwin? still shows failing with logs of: Or is this a different issue?
Code change:
LUAROCKS="$LUAROCKS --verbose" fi <del> patchShebangs . </del> runHook postBuild '';

Related discussion:
text: I think the root problem here is that luarocks has a poor implementation of "move". Combined with the build's behavior being affected by filesystem ordering the result is essentially random. The [implementation of move][] calls out to the operating system commands [][] and [][]. Building with will contain a sequence of , and . I've extracted the [relevant part of the log][]. The critical aspect here is that by default, unix will dereference symlinks and copy their contents. [implementation of move]: []: []: [relevant part of the log]: My theory: luarocks scans the directory for external libraries in filesystem order and attempts to move all shared libraries from to . At which point one of 3! things will happen, but the two main ones are: is copied and deleted and , now broken symlinks, fail to copy and are copied by dereferencing, and deleted is copied and deleted Either way is wrong to some degree, but one of them happens to work well enough for downstream packages to build. If I build locally, the filesystem order I get seems to work, so we can inspect the two results: I've been focusing on this for darwin since the failure case happens to be cached, but I believe it applies equally to linux.
is that sthg you have already witnessed ?
What LuaRocks version is this happening with? I have pushed fixes related to the file deployment stage in 3.3.1.
I've tested 3.2.1 (current nixpkgs master) and 3.3.1 (hasty upgrade locally), they both have similar results, except on 3.3.1 the errors now propagate correctly. I've uploaded a [log of a failed build][] with 3.3.1. [log of a failed build]:
I was hoping to find time to write a proper issue report and a test lua package for this, but haven't yet. My test case would have a directory structure made with , that looks like: In order to succeed the deployment stage would have to produce both the file and its symlink.
Code change:
LUAROCKS="$LUAROCKS --verbose" fi <del> patchShebangs . </del> runHook postBuild '';

Related discussion:
text: Describe the bug I have neovim in my systemPackages, I did and today and it stuck at building luajit: To Reproduce Steps to reproduce the behavior: to Expected behavior The system should upgrade properly. Additional context Output: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kj): nixpkgs: Maintainer information:
Possible fix is in . There was already an open issue about it () but from an unclear reason people have reached the conclusion it was fixed on latest master.
Oh I meant , not .
Well, I agree with that conclusion. For me, on the build is broken with the error above and on current master it isn't. EDIT: note that the channels lag behind, usually less than a couple days, but sometimes we get a week or two due to some harder regression.
Yea right. For me on NixOS I tried with the nixpkgs-unstable channel and could install successfully. The nixos-unstable still fails though.
Code change:
buildPackages.stdenv.cc ]; <del> # Disable an optimisation which seems to cause issues, pending an # upstream fix: https://github.com/xianyi/OpenBLAS/issues/2496 patches = stdenv.lib.optionals stdenv.hostPlatform.isAarch64 [ ./0001-Disable-optimised-aarch64-dgemm_beta-pending-fix.patch ]; </del> makeFlags = mkMakeFlagsFromConfig (config // { FC = "${stdenv.cc.targetPrefix}gfortran"; CC = "${stdenv.cc.targetPrefix}${if stdenv.cc.isClang then "clang" else "cc"}";

Related discussion:
text: Describe the bug On current nixos-unstable Scipy fails to build with a segmentation fault during testing: To Reproduce Steps to reproduce the behavior: the following as Expected behavior Should not segfault during test. Additional context SciPY seems to build just fine on current 20.03 release. Notify maintainers cc , Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(ente): nixpkgs:
Also fails with
Particular stacktrace is:
I believe the fix is contained in: and upstream tracking issue is: and Debian issue:
Opened to bump openblas to a version with that fix
fixes this for me - can you confirm?
builds for me
Works, thanks!
This still affects . Is there a simple fix we can backports (either in nixpkgs, or here locally)?
Backport openblas updates:
Thanks, I’ll try that. Would such a backport be eligible to go to ?
I don't really do backports, but since it fixes something known to be broken I assume it would be fine.
Pull request should target not .
Code change:
owner = "facebookresearch"; repo = "xformers"; rev = "refs/tags/v${version}"; <del> hash = "sha256-G8f7tny5B8SAQ6+2uOjhY7nD0uOT4sskIwtTdwivQXo="; </del> <ins> hash = "sha256-7lZi3+2dVDZJFYCUlxsyDU8t9qdnl+b2ERRXKA6Zp7U="; </ins> fetchSubmodules = true; };

Related discussion:
text: Package name: Latest released version: 0.0.22.post7 <!-- Search your package here: --- Current version on the unstable channel: (This version never existed but whatever!) Current version on the stable/release channel: None <!-- 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 Note for maintainers: Please tag this issue in your PR. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
let me know if you have time to test
Code change:
rustPlatform.buildRustPackage rec { pname = "sequoia"; <del> version = "0.10.0"; </del> <ins> version = "0.11.0"; </ins> src = fetchFromGitLab { owner = "sequoia-pgp"; repo = pname; rev = "v${version}"; <del> sha256 = "0gvczghyik56jlnb8cz7jg2l3nbm519gf19g7l5blxci3009v23d"; </del> <ins> sha256 = "1k0pr3vn77fpfzyvbg7xb4jwm6srsiws9bsd8q7i3hl6j56a880i"; </ins> }; <del> cargoSha256 = "0dk9sjcbmygbdpwqnah5krli1p9j5hahgiqrca9c0kfpfiwgx62q"; </del> <ins> cargoSha256 = "15bhg7b88rq8p0bn6y5wwv2l42kqb1qyx2s3kw0r0v0wadf823q3"; </ins> nativeBuildInputs = [ pkgconfig

Related discussion:
text: Describe the bug See https://nix- The particular cases that fail are I believe rust was updated recently (was that in the release?). It doesn't appear upstream has made a release recently, so perhaps if this report is forwarded to them they can direct us to which patches could fix the test failures etc. cc
According to and bug reports, this seems like a ulimit issue. An interesting workaround for hydra could be using , as suggested in but it's certainly isn't necessary on my machine because I've tested the build and it passed it.
sounds like it would make an already long checkPhase longer :rofl: How about we try ?
We can try this indeed. The question is, what are the default limits of a build user on hydra? Are we sure this might make a difference?
I noticed you've marked sequoia as broken in . Even if a package fails to build on hydra butt doesn't fail locally, does it mean we mark it as broken in its ? Doesn't sound right to me..
That's was the motivation for the issue being opened. If we bump in preCheck and unmark it as broken I think we should be good. ofborg can serve as testing perhaps similar to hydra.
The point is, that we haven't even tried playing with these settings. I would have tried doing it my self but since I know nothing nor I have any effect on Hydra's deployment etc., I wouldn't even know how to test it. What bothers me is the fact it was marked as broken without any attempts by someone with more influence then me to debug it's failure to build only on hydra. Are we even sure this wasn't a failure that happened only once?
Should we close this issue with the PR?
No, it's still failing , at least for hydra, it runs out of file handles
A bit off-topic maybe but I generated a Nix expression for sequoia using , as build times for sequoia where around hours for me. It works now like a charm, as every crate got its own derivation. It can be found here, as a flake: Maybe repackaging with could be an option?
This may be an option, but unpleasant as the generated deps file usually is 1-10k+ of generated noise.
Code change:
rustPlatform.buildRustPackage rec { pname = "sequoia"; <del> version = "0.10.0"; </del> <ins> version = "0.11.0"; </ins> src = fetchFromGitLab { owner = "sequoia-pgp"; repo = pname; rev = "v${version}"; <del> sha256 = "0gvczghyik56jlnb8cz7jg2l3nbm519gf19g7l5blxci3009v23d"; </del> <ins> sha256 = "1k0pr3vn77fpfzyvbg7xb4jwm6srsiws9bsd8q7i3hl6j56a880i"; </ins> }; <del> cargoSha256 = "0dk9sjcbmygbdpwqnah5krli1p9j5hahgiqrca9c0kfpfiwgx62q"; </del> <ins> cargoSha256 = "15bhg7b88rq8p0bn6y5wwv2l42kqb1qyx2s3kw0r0v0wadf823q3"; </ins> nativeBuildInputs = [ pkgconfig

Related discussion:
text: (for local building, this works great)
Yeah, that noise is a bummer. Sometimes I dream of having all of packaged the way we do it with , but I guess that would blow up Nixpkgs indefinitely. But maybe someday when Nix flakes are ready? …
I'm not sure I have enough time to have a good view on this. What's most important about specifically, is the fact we use upstream's to install many other files that should be part of the package's output - files such as libraries, ZSH/Bash completion files and headers. So I'm not sure how will this go together with the approach.
If anyone is interested in a sequoia flake which is built incrementally (vs. everything built in a single derivation), I try to maintain one here:
sequoia , but it hasn't tried 0.16.0 yet - .
Yep, we need to fix it for python 38 though
Code change:
<ins> diff --git a/llm/generate/gen_linux.sh b/llm/generate/gen_linux.sh index 48d08fd0..e50f7b36 100755 --- a/llm/generate/gen_linux.sh +++ b/llm/generate/gen_linux.sh @@ -284,9 +284,6 @@ if [ -z "${OLLAMA_SKIP_ROCM_GENERATE}" -a -d "${ROCM_PATH}" ]; then mkdir -p "${ROCM_DIST_DIR}" for dep in $(ldd "${BUILD_DIR}/bin/ollama_llama_server" | grep "=>" | cut -f2 -d= | cut -f2 -d' ' | grep -v "${GOARCH}/rocm${ROCM_VARIANT}" | grep -e rocm -e amdgpu -e libtinfo -e libnuma -e libelf ); do cp -a "${dep}"* "${ROCM_DIST_DIR}" -        if [ $(readlink -f "${dep}") != "${dep}" ] ; then -            cp $(readlink -f "${dep}") "${ROCM_DIST_DIR}" -        fi done install dist </ins>

Related discussion:
text: Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra can reproduce:
I tracked down the potential source of this failure, and am working on a fix. These builds take 30 minutes for me though, so it's slow going.
Please see for a fix. Testing appreciated.
Thanks for the quick patch. EDIT: My way of installing to profile didn't pull the fix, I'll see if I can figure out a way to do it properly using the pr review package
Builds and runs... seg faults as soon as I load a model, but that's an AMD driver thing (whole WM crashes)... Ship it :laughing:
I did see some segfaults, but was able to restart and get it to load on my 6700xt. “Glad” to know it’s known and common.
Nice! Thanks for this - excited to see it roll into unstable soon. Ollama seems to always have some issue - is there a "working group" that has some focus on this program and nix? Anyway, thanks again!
The problems with crashing aren't nix problems, they're crappy amd driver issues. It doesn't crash if you don't load models close to the max vram available... obviously it shouldn't crash if you do, but amd... so yeah
Code change:
passthru.tests.version = testers.testVersion { package = hwatch; <del> command = "hwatch --version"; version = version; </del> }; meta = with lib; { homepage = "https://github.com/blacknon/hwatch"; <del> description= "Modern alternative to the watch command"; </del> <ins> description = "Modern alternative to the watch command"; </ins> longDescription = '' A modern alternative to the watch command, records the differences in execution results and can check this differences at after. ''; license = licenses.mit; maintainers = with maintainers; [ hamburger1984 ]; <del> platforms = platforms.linux; </del> }; }

Related discussion:
text: Project description hwatch - A modern alternative to the command, records the differences in execution results (Rust, currently distributed via [Homebrew], [MacPorts], [Arch Linux AUR], and [Rust]) At the moment hwatch is only available for on nixpkgs Metadata source URL: license: MIT platforms: All
It has been available since 22.11:
That's weird, it didn't work for me when I tried it last time so I switched it to homebrew via nix-darwin. Let me retry
I see the issue, it's Linux only
updated, thank you!
could you take a look at ?
Approved, thank you for being awesome
Code change:
inherit passthruFun; }; <del> python35 = callPackage ./cpython { self = python35; sourceVersion = { major = "3"; minor = "5"; patch = "9"; suffix = ""; }; sha256 = "0jdh9pvx6m6lfz2liwvvhn7vks7qrysqgwn517fkpxb77b33fjn2"; inherit (darwin) configd; inherit passthruFun; }; </del> python36 = callPackage ./cpython { self = python36; sourceVersion = {

Related discussion:
text: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.
Code change:
# 'runner' scripts. dontWrapPythonPrograms = true; <del> # requires flufl.testing, which the upstream has archived doCheck = false; </del> meta = { homepage = "https://www.gnu.org/software/mailman/"; description = "Free software for managing electronic mail discussion and newsletter lists";

Related discussion:
text: Steps to reproduce the behavior: $ nix build --verbose The interesting thing is that I can build the flask-sqlalchemy package just fine: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: