jiebi/CodeConvo huggingface dataset:
Change:
{ fetchFromGitHub }: rec { <del> version = "4.1.6"; </del> <ins> version = "4.1.7"; </ins> src = fetchFromGitHub { owner = "NICMx"; repo = "Jool"; rev = "v${version}"; <del> sha256 = "09avkiazpfxzrgr3av58jbina5x9jqvqhjkn39475pfhfhrlv9fv"; </del> <ins> sha256 = "08z23mi6xkr6zzp0hzh1cppvl2y0177s0lnpxqbpy8jiii5fxw8f"; </ins> }; }

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 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: <!-- The current version can be found easily with the same process as 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: 4.1.6 desired version: 4.1.7 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
source = Bundler::Source::Path.new(options) end spec = source.specs.search_all(name).first <del> Bundler.rubygems.with_build_args build_flags do source.install(spec) end </del> <ins> source.install(spec, :build_args => build_flags) </ins> msg = spec.post_install_message if msg

Discussion:
, CVSSv3=7.3 (nixos-21.11, nixos-unstable) is a package for managing application dependencies in Ruby. In versions before 2.2.33, when working with untrusted and apparently harmless 's, it is not expected that they lead to execution of external code, unless that's explicit in the ruby code inside the itself. However, if the includes entries that use the option with invalid, but seemingly harmless, values with a leading dash, this can be false. To handle dependencies that come from a Git repository instead of a registry, Bundler uses various commands, such as . These commands are being constructed using user input (e.g. the repository URL). When building the commands, Bundler versions before 2.2.33 correctly avoid Command Injection vulnerabilities by passing an array of arguments instead of a command string. However, there is the possibility that a user input starts with a dash () and is therefore treated as an optional argument instead of a positional one. This can lead to Code Execution because some of the commands have options that can be leveraged to run arbitrary executables. Since this value comes from the file, it can contain any character, including a leading dash. To exploit this vulnerability, an attacker has to craft a directory containing a file that declares a dependency that is located in a Git repository. This dependency has to have a Git URL in the form of . This URL will be used to construct a Git clone command but will be interpreted as the upload-pack argument. Then this directory needs to be shared with the victim, who then needs to run a command that evaluates the Gemfile, such as , inside. This vulnerability can lead to Arbitrary Code Execution, which could potentially lead to the takeover of the system. However, the exploitability is very low, because it requires a lot of user interaction. Bundler 2.2.33 has patched this problem by inserting as an argument before any positional arguments to those Git commands that were affected by this issue. Regardless of whether users can upgrade or not, they should review any untrustred 's before running any commands that may read them, since they can contain arbitrary ruby code. Scanned versions: nixos-21.11: ; nixos-unstable: .
Actually this still needs a fix for 21.11.
Change:
<del> # Note: this is rakshasa's version of libtorrent, used mainly by rtorrent. # *Do not* mistake it by libtorrent-rasterbar, used by Deluge, qbitttorent etc. { lib , stdenv , fetchFromGitHub , autoconf-archive , autoreconfHook , cppunit , libsigcxx , openssl , pkg-config , zlib }: stdenv.mkDerivation rec { pname = "rakshasa-libtorrent"; version = "0.13.8+date=2021-08-07"; src = fetchFromGitHub { owner = "rakshasa"; repo = "libtorrent"; rev = "53596afc5fae275b3fb5753a4bb2a1a7f7cf6a51"; hash = "sha256-gyl/jfbptHz/gHkkVGWShhv1Z7o9fa9nJIz27U2A6wg="; }; nativeBuildInputs = [ autoconf-archive autoreconfHook pkg-config ]; buildInputs = [ cppunit libsigcxx openssl zlib ]; enableParallelBuilding = true; meta = with lib; { homepage = "https://github.com/rakshasa/libtorrent"; description = "A BitTorrent library written in C++ for *nix, with focus on high performance and good code"; license = licenses.gpl2Plus; maintainers = with maintainers; [ ebzzry codyopel ]; platforms = platforms.unix; }; } </del>

Discussion:
jesec-libtorrent tests fail, making the build fail. Steps to reproduce the behavior: jesec-libtorrent fails, failing the build I expect it to build succesfully ! ! I'm building the package with the help of morph to deploy on a server, though this shouldn't really have an impact.
This happened between and . I'll bisect later, thanks for the heads up!
The test is expecting to be returned by , but is instead getting . I'm... really not sure how to move forward with this, short of disabling the test.
Next time copy-paste the error message.
Perhaps triggered by upgrading glibc from 2.33 to 2.34? (some change in getaddrinfo() behavior)
I ruled that out initially since I didn't see anything mentioned in the changelog about getaddrinfo. I'll give it a try, though.
This has been fixed by .
Change:
''; }; <ins> turbo = mkOption { type = types.nullOr types.int; default = null; description = lib.mdDoc '' Changes the Intel Turbo feature status (1 is disabled and 0 is enabled). ''; }; </ins> p1.limit = mkOption { type = with types; nullOr int; default = null;

Discussion:
Package name: undervolt Latest released version: 0.4.0 <!-- Search your package here: --- Current version on the unstable channel: 0.3.0 Current version on the stable/release channel: 0.3.0 <!-- 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: the update adds a new flag (), it would be nice to make it an option. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
sslmate-agent = callPackage ../development/tools/sslmate-agent { }; <ins> sshocker = callPackage ../tools/security/sshocker { }; </ins> sshoogr = callPackage ../tools/networking/sshoogr { }; ssocr = callPackage ../applications/misc/ssocr { };

Discussion:
Project description ssh + reverse sshfs + port forwarder, in Docker-like CLI Metadata homepage URL: source URL: license: apache platforms: unix, linux, darwin
Change:
, pygments , typing-extensions , pytestCheckHook <ins> , setuptools </ins> # for passthru.tests , enrich

Discussion:
Package name: textual Latest released version: 0.23.0 <!-- Search your package here: --- Current version on the unstable channel: 0.15.1 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: Please tag this issue in your PR.
Does resolve this?
As far as I can tell: yes. Would be great to have it merged into master (so it shows up in nixpkgs-unstable at some point).
And of course there have been two new releases in the meantime....
Was fixed, closing.
Change:
libwebp libheif python <ins> # Duplicated here because python.withPackages does not expose the dev output with pkg-config files python2.pkgs.pygtk </ins> libexif xorg.libXpm glib-networking

Discussion:
I see a lot of dev packages on my system: It seems, most of them are pulled by okteta and yakuake while dev package of gtk2 is pulled by pygtk2 (that is pulled by gimp on my system) Steps to reproduce the behavior: those packages via environment.systemPackages I don't think those packages are required for these applications and pygtk to work, so I expect they don't pull them :) (is pygtk unmaintained?)
Fix in
Now I see there's the same problem with teamviewer :(
if you check my fix I think you can easily make the fixes yourself for other packages where you encounter this issue.
why do they use propagateBuildInputs in first place though? It doesn't look like those applications (except of pygtk of course) are used as buildInputs in other packages.
It's due to how Qt works and how Qt is supported/packaged in Nixpkgs. Not ideal, but it's how it is currently.
Am I missing something? I maintain a Qt-based package myself and don't use propagateBuildInputs yet it works just fine.
That's good to know. It's possible then that these expressions have never been updated. The way Qt is supported has changed several times. I can't tell like this how it's working currently.
can you review ?
Change:
fplll = callPackage ../development/libraries/fplll {}; fplll_20160331 = callPackage ../development/libraries/fplll/20160331.nix {}; <del> freeimage = callPackage ../development/libraries/freeimage { }; </del> <ins> freeimage = callPackage ../development/libraries/freeimage { libraw = libraw_unstable; }; </ins> freetts = callPackage ../development/libraries/freetts { jdk = jdk8; # TODO: remove override https://github.com/NixOS/nixpkgs/pull/89731

Discussion:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.
Change:
./services/desktops/gnome3/gnome-settings-daemon.nix ./services/desktops/gnome3/gnome-user-share.nix ./services/desktops/gnome3/rygel.nix <del> ./services/desktops/gnome3/seahorse.nix </del> ./services/desktops/gnome3/sushi.nix ./services/desktops/gnome3/tracker.nix ./services/desktops/gnome3/tracker-miners.nix

Discussion:
Describe the bug Currently, the gnome3 module automatically adds the following to I know that is still experimental, and probably shouldn't be installed by default. Does GNOME3 document their distribution defaults anywhere? I think we could clean this up slightly. Note that if we remove anything from here it would be a good idea to conditionally add them based off the users . That way current users won't see these packages magically disappear from their machine. Or perhaps it's better document that in the release notes.
cc
If I recall correctly, we should be concerned about core and world:
Ahh, looks like there's a bit to do here. For example should be :wave:
I think it is just CI breakage after they removed , see
So after discussing briefly in irc, I guess we can implement profiles for gnome-world-packages gnome-games-packages And the module will continue to bring in , , and . In the future we can split that up so we can use flashback without gnome3. Then we can eliminate the lists in since that should be in the profiles where it's useful. One thing I'm unclear on is how to organize the profiles, and do they have options to enable?
Thinking about it more, the main benefit of profiles is that they would not need options. But if we want parts of the profiles to be disableable, we would need to have options for them anyway. Also with options, we get generated documentation for free. I am not sure that is a way to go an more. As for the subdivision, maybe it would make more sense to look on it from users’ perspective: Hard-core hacker wants a bare-bones GNOME Shell with minimum necessary services, not even file manager or terminal emulator – they already have favourite ones. Casual user might have some favourite apps but they are generally happy to use whatever comes with the desktop environment. Here we would ship the core apps. An organization such as a library might want a full desktop environment for their shared workstations, with programs for all possible purposes. But they probably have a sysadmin who wants to have a fine control over what gets installed on the workstations. For that reason, creating a profile that bundles all the world apps probably does not make sense.

Non-GNOME users who want to use GNOME apps probably do not want to use all GNOME apps either, so a core collection might not make sense for them. A parent wants to install various games on the children’s computer. This is kind of similar to the organization but here the collection is more useful. …
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
"-Druntime_cxxmodules=OFF" ]; <ins> # suppress warnings from compilation of the vendored clang to avoid running into log limits on the Hydra NIX_CFLAGS_COMPILE = lib.optionals stdenv.cc.isGNU [ "-Wno-shadow" "-Wno-maybe-uninitialized" ]; </ins> # Workaround the xrootd runpath bug #169677 by prefixing [DY]LD_LIBRARY_PATH with ${lib.makeLibraryPath xrootd}. # TODO: Remove the [DY]LDLIBRARY_PATH prefix for xrootd when #200830 get merged. postInstall = ''

Discussion:
root has not been successfully built since 2023-08-27 with version 6.26.10 by hydra.
Change:
"vim-snippets" "vim2hs" "vundle" <del> "wombat256" </del>

Discussion:
nixpkgs version: nixos-unstable (rev: ) configuration: steps: error: If I remove the wombat256 plugin from my configuration, then vim-env builds fine. Currently, wombat256 seems to be the only plugin in nixpkgs affected by this issue. However, I have auto-generated another plugin which is also affected. What these two plugins have in common is that they are both using , and are downloading files rather than archives. cc
Isn't it a better idea to download those plugins from github? And add them to as ? Because I personally don't like fetching from vim site. I can change the behavior to load them from vim-scripts repo.
Yes, downloading from github works well and is better I think. I'll update wombat256 and use github when adding plugins from now on.
Change:
doCheck = true; <ins> passthru = { tests.version = testers.testVersion { inherit version; package = nvtop; command = "nvtop --version"; }; }; </ins> meta = with lib; { description = "A (h)top like task monitor for AMD, Intel and NVIDIA GPUs"; longDescription = ''

Discussion:
When running , I get Restarting the system did not help. Steps to reproduce the behavior: The program should launch without crashing. If applicable, add screenshots to help explain your problem.
Hello Thanks for reporting this issue, and sorry for breaking the nvtop package! I made a pull-request to fix nvtop: What do you think about this fix?
Thank you for your fast reaction ! The PR looks good to me. I hope it will get merged soon :)
Change:
<del> --- direwolf/conf/CMakeLists.txt.orig	2020-12-04 11:12:59.739390894 -0600 +++ direwolf/conf/CMakeLists.txt	2020-12-04 11:23:09.146594795 -0600 @@ -26,7 +26,7 @@ # install udev rules for CM108 if(LINUX) -  install(FILES "${CUSTOM_CONF_DIR}/99-direwolf-cmedia.rules" DESTINATION /etc/udev/rules.d/) +  install(FILES "${CUSTOM_CONF_DIR}/99-direwolf-cmedia.rules" DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/udev/rules.d/") endif() install(FILES "${CMAKE_BINARY_DIR}/direwolf.conf" DESTINATION ${INSTALL_CONF_DIR}) </del>

Discussion:
direwolf does not build. This seems to have been noticed previously as mentioned in this comment on the upgrade of gpsd from 3.22 -3.23: Please run and paste the result.
Thanks for the report. Someone else had pointed this out the other day and I had been looking into it. The current stable version of direwolf doesn't support the latest version of gpsd, but that may only be because of the version check that we could override with a patch until it is fixed upstream. Will try to open a PR when I get a chance, but need to test out my theory first.
Change:
</listitem> <listitem> <para> <ins> The <literal>zramSwap</literal> is now implemented with <literal>zram-generator</literal>, and the option <literal>zramSwap.numDevices</literal> for using ZRAM devices as general purpose ephemeral block devices has been removed. </para> </listitem> <listitem> <para> </ins> The <literal>unifi-poller</literal> package and corresponding NixOS module have been renamed to <literal>unpoller</literal> to match upstream.

Discussion:
Project description In the author says, In 2020 the zram-generator doesn't seem to have had any releases. In the meantime, it's gone from initial release version 0.2.0 up to the somewhat-mature version 1.1.2. It's probably a good time to port this to zram-generator. Metadata homepage URL: source URL: license: mit platforms: linux
Change:
davix = callPackage ../tools/networking/davix { }; <ins> davix-copy = appendToName "copy" (davix.override { enableThirdPartyCopy = true; }); </ins> cantata = libsForQt5.callPackage ../applications/audio/cantata { }; cantoolz = python3Packages.callPackage ../tools/networking/cantoolz { };

Discussion:
Steps to reproduce the behavior: Build the following Nix expression: See error as davixcopy isn't not found Shared library davix_copy (or related symlinks) is in as the Debian package does. 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. Maintainer information:
Change:
<ins> diff a/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp b/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp --- a/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp +++ b/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp @@ -107,8 +107,7 @@ const char *PSInterpreter::PSDEFS = "dmode sysexec<</Normal 0/Compatible 0/Multiply 1/Screen 2/Overlay 3/SoftLight " "4/HardLight 5/ColorDodge 6/ColorBurn 7/Darken 8/Lighten 9/Difference 10/Exclus" "ion 11/Hue 12/Saturation 13/Color 14/Luminosity 15/CompatibleOverprint 16>>exc" -"h get 1(setblendmode)prcmd}def/@pdfpagecount{GS_PDF_ProcSet begin pdfdict begi" -"n(r)file pdfopen begin pdfpagecount currentdict pdfclose end end end}def/@pdfp" -"agebox{GS_PDF_ProcSet begin pdfdict begin(r)file pdfopen begin dup dup 1 lt ex" -"ch pdfpagecount gt or{pop}{pdfgetpage/MediaBox pget pop aload pop}ifelse curre" -"ntdict pdfclose end end end}def DELAYBIND{.bindnow}if "; +"h get 1(setblendmode)prcmd}def/@pdfpagecount{(r)file runpdfbegin pdfpagecount " +"runpdfend}def/@pdfpagebox{(r)file runpdfbegin dup dup 1 lt exch pdfpagecount g" +"t or{pop}{pdfgetpage/MediaBox pget pop aload pop}ifelse runpdfend}def DELAYBIN" +"D{.bindnow}if "; </ins>

Discussion:
I was getting errors with the version of dvisvgm bundled with texlive 2019 so I created a separate, texlive-independent version which works well. (If you're curious about the issue I was seeing it was related to compatibility between ghostscript and dvisvgm. I can be more specific if anyone wants, but reporting that issue is not the main purpose of this). Here's the build expression I'm using ( is ): How would people feel about a PR with a dvisvgm package uncoupled from the texlive version in addition to the one currently there? I could name it or or something like that. Note that I'm currently using this as a separate build expression but for a PR I'd put it in the texlive bin nix file. Note also that this package can be used identically to any other texlive package. The only difference to the end user is to get an option of a newer version.
What is the issue, though?
it's been reported . The issue is apparently fixed in dvisvgm 2.7.2 (ours is 2.6.3). Here's an additional MWE to test. The same example with v2.8.1 (in the build expression above) works fine.
So what you say, is that our dvisvgm is broken because of the incompatible ghostscript version. Then, I think, we should be fixing dvisvgm for all of our users, not just those who opt into using the separate package you propose. I would prefer to just patch the version from texlive, but, unfortunately, doesn't apply cleanly, so we would have to craft our own patch or pin to 2.8.1 (in this case, need to leave a TODO comment to remind to unpin for texlive 2020).
To clarify, the idea is to generate a patch from a newer texlive version of dvisvgm and apply that to the existing derivation (along with the code comment about this being a temporary fix until 2020)?
Does fix the issue for you?
Change:
installPhase = '' runHook preInstall <del> mkdir -p $out/{bin,share/applications,share/feh-client} </del> <ins> mkdir -p $out/{bin,share/applications} </ins> cp fah-client $out/bin/fah-client <del> cp install/lin/fah-client.desktop $out/share/applications/ cp -r images $out/share/feh-client/ sed -e "s|Icon=.*|Icon=$out/share/feh-client/images/fahlogo.png|g" -i $out/share/applications/fah-client.desktop </del> <ins> cp install/lin/fah-client.desktop.in $out/share/applications/fah-client.desktop sed  -e "s|Icon=.*|Icon=$out/share/feh-client/images/fahlogo.png|g"  -e "s|%(PACKAGE_URL)s|https://github.com/FoldingAtHome/fah-client-bastet|g"  -i $out/share/applications/fah-client.desktop </ins> runHook postInstall '';

Discussion:
Steps to reproduce the behavior: <!-- 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]:
Hi! I suggest you edit the title of the issue, naming the actual package.
Can you test this PR please? Not sure why it broke, but instead of debugging this I just went ahead and upgraded the package.
Change:
libschrift = callPackage ../development/libraries/libschrift { }; <ins> libsciter = callPackage ../development/libraries/libsciter { }; </ins> libsearpc = callPackage ../development/libraries/libsearpc { }; libsigcxx = callPackage ../development/libraries/libsigcxx { };

Discussion:
Project description Yet another remote desktop software. I planned to use this as a replacement for Teamviewer, but is required and packaging this seems to be harder than I initially thought it would be. Metadata homepage URL: source URL: license: gpl3 platforms: unix
Change:
}; }; <ins> reditorsupport.r = callPackage ./reditorsupport.r { }; </ins> reloadedextensions.reloaded-cpp = buildVscodeMarketplaceExtension { mktplcRef = { name = "reloaded-cpp";

Discussion:
Project description Adds R language features (e.g. syntax highlighting) to VSCode. Ideally, would also install and automatically configure the extension to use them. Also requires to be installed. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Just open a PR adding the extension, much easier than opening an issue...
If it's that easy, why don't you do it yourself? Okay, sorry for being a little snarky there. But I opened this issue the same day I first installed NixOS, so please forgive my former lack of knowledge. I'll take a look.
I don't need this extension specifically. But I have all the extensions I needed. Sure. Have a look in: Follow and add extension to Git clone nixpkgs. Then, to build your extension, run: Look forward your first PR then. Have fun.
Small nit: It won't be my first PR (, , , , ). It will be my first package creation, though!
My bad. On the good side, it is going to be even easier for you to add the extensions. :-)