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

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

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:
''; buildPhase = '' <del> # gcc-6.4.0/include/c++/6.4.0/cstdlib:75:15: fatal error: 'stdlib.h' file not found export NIX_CFLAGS_COMPILE="$(< $NIX_CC/nix-support/libcxx-cxxflags) $NIX_CFLAGS_COMPILE" </del> <ins> # explicitly include C++ headers to prevent errors where stdlib.h is not found from cstdlib export NIX_CFLAGS_COMPILE="$(< ${clang}/nix-support/libcxx-cxxflags) $NIX_CFLAGS_COMPILE" </ins> # During the Swift build, a full local LLVM build is performed and the resulting clang is invoked. # This compiler is not using the Nix wrappers, so it needs some help to find things. export NIX_LDFLAGS_BEFORE="-rpath ${clang.cc.gcc.lib}/lib -L${clang.cc.gcc.lib}/lib $NIX_LDFLAGS_BEFORE"

Related discussion:
text: Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building swift to be used. Notify maintainers Maintainer: Last 4: … Metadata Error
Seems as is used for building rather than . Probably happened during experiments to declare . Apart from that I'm not a swift maintainer, so if the issue is more complex, I can't help I'm afraid.
I think the Python warning is actually benign. I see a build error related to a change in the handling of . Commit appears to break it for me. I can offer a , which you can try like this: But I am not sure what the proper fix is. I would like to ask for comment.
I have pushed a new fix to my . This uses the proper fix as suggested by It would be nice, if someone can confirm it works. I have also opened PR with this fix.
Code change:
rstcheck = with python3Packages; toPythonApplication rstcheck; <ins> rstfmt = callPackage ../development/tools/rstfmt { }; </ins> rt = callPackage ../servers/rt { }; rtmpdump = callPackage ../tools/video/rtmpdump { };

Related discussion:
text: Project description Formatter for rst (reStructuredText) files Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, ...
Code change:
, wayland , wayland-protocols , qtwayland <ins> , cairo </ins> }: mkDerivation rec {

Related discussion:
text: OpenSCAD seems to be built without support for PDF exports. (This is a very useful feature to print projections on paper to check the dimensions of a design for example). Version: OpenSCAD version 2021.01 On nixpkgs: master (2022-09-18) Open OpenSCAD Go to File -Export -Export as PDF… Save to some file Observe the following error in the OpenSCAD console: CC package maintainers:
Any idea what dependency they need for PDF? (image file export has been enough for me so I never looked)
I think cairo. (I was looking into this earlier today.)
Yes, cairo was missing:
Code change:
tmpFile="$tmpPath/$(get_name $finalImageName $finalImageTag)" if test -z "$QUIET"; then <del> "$skopeoCmd" --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" </del> <ins> skopeo --insecure-policy --tmpdir=$TMPDIR --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" </ins> else <del> "$skopeoCmd" --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" > /dev/null </del> <ins> skopeo --insecure-policy --tmpdir=$TMPDIR --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" > /dev/null </ins> fi # Compute the hash.

Related discussion:
text: Describe the bug Running fails with To Reproduce Extra info On of that script scopeoCmd isn't called correctly. Seems like introduced the problem in this PR
Code change:
nvmetcfg = handleTest ./nvmetcfg.nix {}; nzbget = handleTest ./nzbget.nix {}; nzbhydra2 = handleTest ./nzbhydra2.nix {}; <ins> ocis = handleTest ./ocis.nix {}; </ins> oh-my-zsh = handleTest ./oh-my-zsh.nix {}; ollama = handleTest ./ollama.nix {}; ombi = handleTest ./ombi.nix {};

Related discussion:
text: "ownCloud Infinite Scale Stack" or owncloud rewritten in Go. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: asl20 platforms: unix
There are some hassles to deal with on this one. PNPM usage: Image assets downloaded with curl (and no hashes or revisions) Code generation tools and code repositories downloaded by
Note that ownCloud provide prebuilt binaries for oCIS. It's fairly simple to get these working on NixOS: Perhaps this can be used as a temporary solution until we can build it ourselves?
I used your derivation and opened . I tested it a bit, and will work on a proper module over next few days/weeks, can you share if you are already using above derivation, and if yes, how stable are rc releases?
I've been using the rc for a while and haven't had any major issues. It's probably better to go with the stable release by default though. Perhaps we could package both?
Has the situation changed where the OCIS can be built from source now? I'd rather not use a proprietary binary.
Code change:
}; config = mkIf cfg.server.enable { <ins> assertions = [ { assertion = !(cfg.server.exports ? "generic"); message = "services.nbd.server exports must not be named 'generic'"; } ]; </ins> boot.kernelModules = [ "nbd" ]; systemd.services.nbd-server = {

Related discussion:
text: Configuration snippet like this: yield a configuration like: However nbd-server expects section to always appear before export sections, otherwise it complains about not being able to find general section. I'd say this is upstream's fault because this order should not matter, but here we are. section to always appear before export sections. <!-- 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.
This looks like it should be easy to fix. I'll probably get around to it tomorrow morning.
For reference, the error looks like this:
Code change:
<ins> { stdenv, lib, fetchFromGitHub, bash, wget, makeWrapper }: stdenv.mkDerivation rec { pname = "ipfetch"; version = "unstable-2022-03-24"; src = fetchFromGitHub { owner = "trakBan"; repo = "ipfetch"; rev = "fc295bfda4f9fea6eee9f6f3f2dabc26b6f25be4"; sha256 = "sha256-YKQ9pRBj2hgPg2ShCqWGxzHs/n7kNhKRNyElRDwHDBU="; }; strictDeps = true; buildInputs = [ bash wget ]; nativeBuildInputs = [ makeWrapper ]; patchPhase = '' patchShebangs --host ipfetch # Not only does `/usr` have to be replaced but also `/flags` needs to be added because with Nix the script is broken without this. The `/flags` is somehow not needed if you install via the install script in the source repository. substituteInPlace ./ipfetch --replace /usr/share/ipfetch $out/usr/share/ipfetch/flags ''; installPhase = '' mkdir -p $out/bin mkdir -p $out/usr/share/ipfetch/ cp -r flags $out/usr/share/ipfetch/ cp ipfetch $out/bin/ipfetch wrapProgram $out/bin/ipfetch --prefix PATH : ${ lib.makeBinPath [ bash wget ] } ''; meta = with lib; { description = "Neofetch but for ip adresses"; license = licenses.gpl3Only; platforms = platforms.all; maintainers = with maintainers; [ papojari ]; }; } </ins>

Related discussion:
text: Project description Neofetch like tool that can lookup IPs. :earth_americas: Metadata homepage URL: source URL: license: gpl3 platforms: posix shell
I'll do this myself.
Code change:
[ CoreAudio AudioToolbox ]; # propagation is needed for Security.framework to be available when linking <del> propagatedBuildInputs = [ aws-c-cal aws-c-event-stream aws-c-io aws-c-common aws-checksums s2n-tls ]; </del> <ins> propagatedBuildInputs = [ aws-crt-cpp ]; </ins> cmakeFlags = [ "-DBUILD_DEPS=OFF"

Related discussion:
text: When I update nix I can't copy to our binay cache anymore. All I get is I bisected nixpkgs and found that the bug was introduced by . Run The parent commit works: This error here is fine because our cache has a different name of course. Please run and paste the result.
Just wondered if here is the right place for the issue but I’m quite lost on this. Maybe this is a nix bug?
No you're correct to open this here, this is a good place to start. I'll try to bisect further to see which aws-sdk-cpp commit broke this functionality, hopefully that will tell us more about how to proceed.
Bisected to , but unfortunately the commit is very large so I don't see an obvious cause. Maybe it's best to take this upstream to the Nix repo now.
Thanks for reporting, and sorry if this broke your workflow. I've bookmarked this issue and I'm going to look into adding an installCheck regression test to ensure s3 stays functional on future updates.
Thank you all for the quick response. This was a really sneaky one. Luckily nix allows rollbacks. That would be great. I’m sorry I cannot think of anything better than checking the error message of . When I do I let you know.
Code change:
platforms = platforms.unix ++ platforms.windows; <ins> priority = 10; </ins> maintainers = [ maintainers.eelco ]; };

Related discussion:
text: I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.
Code change:
platforms = platforms.unix ++ platforms.windows; <ins> priority = 10; </ins> maintainers = [ maintainers.eelco ]; };

Related discussion:
text: The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.
Code change:
platforms = platforms.unix ++ platforms.windows; <ins> priority = 10; </ins> maintainers = [ maintainers.eelco ]; };

Related discussion:
text: 0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.
Code change:
, stdenv , curl , Security <del> , runCommand </del> <ins> , version ? "0.2.87" , hash ? "sha256-0u9bl+FkXEK2b54n7/l9JOCtKo+pb42GF9E1EnAUQa0=" , cargoHash ? "sha256-AsZBtE2qHJqQtuCt/wCAgOoxYMfvDh8IzBPAOkYSYko=" </ins> }: rustPlatform.buildRustPackage rec { pname = "wasm-bindgen-cli"; <del> version = "0.2.84"; </del> <ins> inherit version hash cargoHash; </ins> src = fetchCrate { <del> inherit pname version; sha256 = "sha256-0rK+Yx4/Jy44Fw5VwJ3tG243ZsyOIBBehYU54XP/JGk="; </del> <ins> inherit pname version hash; </ins> }; <del> cargoSha256 = "sha256-vcpxcRlW1OKoD64owFF6mkxSqmNrvY+y3Ckn5UwEQ50="; </del> nativeBuildInputs = [ pkg-config ]; buildInputs = [ openssl ] ++ lib.optionals stdenv.isDarwin [ curl Security ]; nativeCheckInputs = [ nodejs ]; <del> # other tests require it to be ran in the wasm-bindgen monorepo cargoTestFlags = [ "--test=interface-types" ]; </del> <ins> # tests require it to be ran in the wasm-bindgen monorepo doCheck = false; </ins> meta = with lib; { homepage = "https://rustwasm.github.io/docs/wasm-bindgen/";

Related discussion:
text: Package name: wasm-bindgen-cli Latest released version: 0.28.4 Current version on the unstable channel: 0.2.84 Current version on the stable/release channel: 0.2.84 Notify maintainers and I'd really appreciate an update it's causing me problems with a trunk build similar to Note for maintainers: Please tag this issue in your PR.
Code change:
postInstall = '' HOST_PATH=$out/bin patchShebangs --host $out <ins> ${lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' $out/bin/${self.meta.mainProgram} --completion-bash > ${self.meta.mainProgram}.bash installShellCompletion ${self.meta.mainProgram}.bash ''} </ins> ${lib.optionalString (enableNpm) '' mkdir -p $out/share/bash-completion/completions ln -s $out/lib/node_modules/npm/lib/utils/completion.sh 

Related discussion:
text: The package (and the related ones) don't offer completions, only Npm's. At least for bash Node offers it through . I'd like this bash completion to be . Install Node, see that there is no completion in the completions dir (I'm using home-manager, so that'd be ).
Fixed by
Code change:
json-glib ]; <ins> patches = [ # needed for compiling pdfpc 4.6.0 with vala 0.56.7, see # https://github.com/pdfpc/pdfpc/issues/686 # https://github.com/pdfpc/pdfpc/pull/687 (fetchpatch { url = "https://github.com/pdfpc/pdfpc/commit/d38edfac63bec54173b4b31eae5c7fb46cd8f714.diff"; hash = "sha256-KC2oyzcwU2fUmxaed8qAsKcePwR5KcXgpVdstJg8KmU="; }) ]; </ins> cmakeFlags = lib.optional stdenv.isDarwin "-DMOVIES=OFF"; meta = with lib; {

Related discussion:
text: none Please run and paste the result.
I started to bisect this with at nix started to download ~4GB of derivations and I aborted the process. The is
it seems like the issue already got fixed upstream in but there is no new release yet. We either have to target commit which contains the fix, or wait for the new release.
you are right, pdfpc/pdfpc fixes this. I tried it with this patch on nixpkgs:
Code change:
--prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS:${gtk3.out}/share:${gsettings-desktop-schemas}/share:$out/share:$GSETTINGS_SCHEMAS_PATH"  --add-flags "-Dsun.java2d.opengl=true -jar $out/share/java/${module}-${version}.jar -cp $out/share/java/Furniture.jar:$out/share/java/Textures.jar:$out/share/java/Help.jar -d${toString stdenv.hostPlatform.parsed.cpu.bits}" <ins> # remember the store paths found inside the .jar libraries. note that # which file they are in does not matter in particular, just that some # file somewhere lists them in plain-text mkdir -p $out/nix-support cp .jar-paths $out/nix-support/depends </ins> runHook postInstall '';

Related discussion:
text: Describe the bug I copied a closure from one system (19.03) to a USB thumb drive and from that to another system (19.09), but the program don't work. I think nix packages should be pure and work also on another system running a different NixOS channel. (Right?) To Reproduce Steps to reproduce the behavior: sweethome3d installed in thumb drive thumb drive (i use pantheons files app and open a terminal from there, then ) a folder on the thumb drive. mine is "nixpkgs" to that folder: the nix store path of the program: the usb drive into another system and mount it, get the path the nix store path to your system: you can install it for the current user if you like: or just open a nix shell: run the program: Expected behavior Program just work. Additional context I moved to a new flat with most of my computers and want to plan where to put my furniture. I installed sweethome3d on my notebook, but it is not powerfull enough. So i want to copy the program to my iMac. I have internet from my tethered mobile phone, so i can't just install it from the internet! sweethome3d is about 500 MB, that would be 1/4 of my data plan!!! Metadata X230: system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs: imac: system: host os: hangs after that Maintainer information:
Looks like this problem again: cc
When i run the package from unstable on stable, i get the same error: (but it will hopefully work on the imac when i copy it there again)
I get the same error when i run the package from unstable on my 19.09 branch. So it might be generally broken on unstable.
Yes, looks like be some kind of impurity. It runs on my NixOS 19.03 system, both from the stable and unstable channels. And I did the "nix run" thing you said and it works there too (I'm not sure how much isolation gives, apparently not enough).