jiebi/CodeConvo huggingface dataset:
Change:
<del> { stdenv, fetchurl, python2, keybinder3, intltool, file, gtk3, gobject-introspection , libnotify, wrapGAppsHook, vte </del> <ins> { stdenv , fetchFromGitHub , python , keybinder3 , intltool , file , gtk3 , gobject-introspection , libnotify , wrapGAppsHook , vte </ins> }: <del> python2.pkgs.buildPythonApplication rec { </del> <ins> python.pkgs.buildPythonApplication rec { </ins> name = "terminator-${version}"; <del> version = "1.91"; </del> <ins> version = "1.92"; </ins> <del> src = fetchurl { url = "https://launchpad.net/terminator/gtk3/${version}/+download/${name}.tar.gz"; sha256 = "95f76e3c0253956d19ceab2f8da709a496f1b9cf9b1c5b8d3cd0b6da3cc7be69"; </del> <ins> src = fetchFromGitHub { owner = "gnome-terminator"; repo = "terminator"; rev = "bb24273eb40dc5eac97de74064488701fa40a743"; sha256 = "105f660wzf9cpn24xzwaaa09igg5h3qhchafv190v5nqck6g1ssh"; </ins> }; <del> nativeBuildInputs = [ file intltool wrapGAppsHook gobject-introspection ]; buildInputs = [ gtk3 vte libnotify keybinder3 </del> <ins> nativeBuildInputs = [ file intltool gobject-introspection wrapGAppsHook ]; buildInputs = [ gtk3 </ins> gobject-introspection # Temporary fix, see https://github.com/NixOS/nixpkgs/issues/56943 <ins> keybinder3 libnotify python vte ]; propagatedBuildInputs = with python.pkgs; [ configobj dbus-python pygobject3 psutil pycairo </ins> ]; <del> propagatedBuildInputs = with python2.pkgs; [ pygobject3 psutil pycairo ]; </del> postPatch = '' patchShebangs . <ins> # dbus-python is correctly passed in propagatedBuildInputs, but for some reason setup.py complains. # The wrapped terminator has the correct path added, so ignore this. substituteInPlace setup.py --replace "'dbus-python'," "" </ins> ''; checkPhase = ''

Discussion:
Project description is already packaged in nixpkgs, but the upstream project has been taken over by new maintainers who have ported it to Python 3 and are continuing development. As far as I know this new version is also used by Debian/Ubuntu (it has python3 dependencies in those distros). I have a local attempt at a new derivation and it Works For Me, but it has a patch in it which I don't think it should need. Also, maybe the original maintainer may want to do the update? If desired I can open a PR with my current state of affairs. Metadata homepage URL: license: GPL2 platforms: Linux
I have limited spare time these days (months), so please be my guest
Change:
url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=d3537a54740d78c5895ec83694a07b3e4f616f61"; sha256 = "1hr8bpi87bbg1kvv28kflmfh1dhzxw66p9q0ddvbrj72qd86p3kx"; }) <ins> (fetchpatch { name = "CVE-2019-3839-part-1"; url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=4ec9ca74bed49f2a82acb4bf430eae0d8b3b75c9"; sha256 = "0gn1n9fq5msrxxzspidcnmykp1iv3yvx5485fddmgrslr52ngcf9"; }) (fetchpatch { name = "CVE-2019-3839-part-2"; url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=db24f253409d5d085c2760c814c3e1d3fa2dac59"; sha256 = "1h6kpwc6ryr6jlxjr6bfnvmmf8x0kqmyjlx3hggqjs23n0wsr9p9"; }) </ins> ]; outputs = [ "out" "man" "doc" ];

Discussion:
, (nixos-unstable, nixos-19.03) Scanned versions: nixos-unstable: ; nixos-19.03: . May contain false positives.
See also
Change:
<ins> { fetchFromGitHub, lib, linux-pam, rustPlatform, }: rustPlatform.buildRustPackage rec { pname = "lemurs"; version = "0.3.1"; src = fetchFromGitHub { owner = "coastalwhite"; repo = "lemurs"; rev = "v${version}"; hash = "sha256-6mNSLEWafw8yDGnemOhEiK8FTrBC+6+PuhlbOXTGmN0="; }; cargoHash = "sha256-nfUBC1HSs7PcIbD7MViJFkfFAPda83XbAupNeShfwOs="; # Fixes a lock issue preConfigure = "cargo update --offline"; buildInputs = [ linux-pam ]; meta = with lib; { description = "A customizable TUI display/login manager written in Rust"; homepage = "https://github.com/coastalwhite/lemurs"; license = with licenses; [asl20 mit]; maintainers = with maintainers; [jeremiahs]; }; } </ins>

Discussion:
Project description <!-- Describe the project a little: --A customizable TUI display/login manager written in Rust. Lemurs provides a Terminal User Interface (TUI) for a Display/Login Managers in Rust for most GNU/Linux and BSD distributions. It can work both with or without SystemD. Lemurs works on most Unix systems including Linux, FreeBSD and NetBSD. Metadata homepage URL: source URL: license: Apache-2.0, MIT platforms: unix, linux
Change:
vimshell            = vimshell-vim; watchdogs           = vim-watchdogs; webapi-vim          = WebAPI; <ins> wombat256           = wombat256-vim; # backwards compat, added 2015-7-8 </ins> yankring            = YankRing; CSApprox = buildVimPluginFrom2Nix { # created by nix#NixDerivation

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:
export AS=$CC export LD=$CC ''; <del> configureFlags = [ "--disable-native-macro" ]; </del> <ins> configureFlags = [ "--disable-native-tests" "--with-systemwide" ]; </ins> buildInputs = [ openssl nss nspr kerberos gmp zlib libpcap re2 ]; nativeBuildInputs = [ gcc python3Packages.wrapPython perl makeWrapper ];

Discussion:
Describe the bug I installed john the ripper from the binary cache, and executing it fails with: I have a recent laptop (Thinkpad T480s) with i7-8550U CPUs, but apparently that's not good enough. It would be good to compile john with less demanding requirements for the benefit of most users, and maybe output a message how to compile it yourself on nix systems.
Yeah it looks like one of the builders has this feature so the configure script requires it: It looks like we need to pass the flag.
cc maintainer
backported to 19.09 in .
Change:
passthru.updateScript = unstableGitUpdater { }; <ins> # Times out otherwise requiredSystemFeatures = [ "big-parallel" ]; </ins> meta = with lib; { description = "Performance portable programming model for machine learning tensor operators"; homepage = "https://github.com/ROCmSoftwarePlatform/composable_kernel";

Discussion:
Composable_kernel , it seems like that the build is so large that 10 hours is not enough. I am not sure what the best solution is, extending the timer or building it with big-parallel. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
inherit (darwin.apple_sdk.frameworks) AppKit; }; <del> stalwart-mail = callPackage ../servers/mail/stalwart { }; </del> jmespath = callPackage ../development/tools/jmespath { }; juicefs = callPackage ../tools/filesystems/juicefs { };

Discussion:
The new version of stalwart mail (0.7.0), has changed a lot and the module needs a rewrite for a while now, for example: I have forked nixpkgs, to remove the standard settings, to allow me to make a more complex setting. issues I see. No way to disable the default options, in: . WebUI is not currently supported The package imports the entire . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If you want to make a contribution, even a small one, im happy to help you get it merged !
I can take a look, as I have written quite extensive configuration for my Stalwart instance. I can check it out to make it available as a NixOS module
That would be amazing ! There is an open pr from the bot for the 0.7 upgrade, you can take over that one or make the update in a new pr. Thank you !
WIP module. I haven't tested it out yet. I will probably do so this evening:
Not yet entirely fixed, module and test need some work to support = 0.7.0
By the way, since migrating to stalwart = 0.7 requires some manual migration in any case, would it be worth setting the default database type to rocksdb instead of sqlite in the module?
In my opinion yes, for the love of Linux or just make it undefined. Do you have a git repo, where I can track your progress and when I have time, give improvements?
Change:
'' runHook preInstall <ins> mv build/linux-${cpu}-server-${buildType}/images/jdk/man build/linux-${cpu}-server-${buildType}/images/${jbrsdkDir} </ins> rm -rf build/linux-${cpu}-server-${buildType}/images/jdk mv build/linux-${cpu}-server-${buildType}/images/${jbrsdkDir} build/linux-${cpu}-server-${buildType}/images/jdk '' + oldAttrs.installPhase + "runHook postInstall";

Discussion:
Maybe related to build from master branch - Hope you don't mind the ping, sorry if you do Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't reproduce this. What does give for you?
My bad in naming the PR, the package does build but the man output of it points to broken symlink I am building on master branch, commit system x86_64-linux.
With some trial and error I was able to pin point the commit which broke it That was merged in See here my build log
Change:
description = "Linux Electron Onenote - A Linux compatible version of OneNote"; license = licenses.mit; maintainers = with maintainers; [ tiagolobocastro ]; <del> platforms = platforms.linux; </del> <ins> platforms = [ "x86_64-linux" "aarch64-linux" "armv7l-linux" ]; </ins> }; }

Discussion:
For some reason i get this error. error: attribute 'i686-linux' missing if that platform is not supported upstream, you might want to disable it or no error This blocks any i686-linux build on master and staging. Seem to be caused by The upgrade dropped i386/i686 support, cc system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Change:
# prevent python tests from running when not building with python configureFlags = lib.optional (!enablePython) "--disable-python"; <del> # example_r13.dxf roundtrip fail: expect 5286, got 5285 entities doCheck = !(stdenv.isLinux && stdenv.isAarch64); </del> <ins> # FAIL: alive.test doCheck = !stdenv.isLinux; </ins> # the "xmlsuite" test requires the libxml2 c library as well as the python module nativeCheckInputs = lib.optionals enablePython [ libxml2 libxml2.dev ];

Discussion:
Package name: libredwg Latest released version: 0.13.2 Current version on the unstable channel: 0.12.5.6313 Current version on the stable/release channel: 0.12.5.6313 Notify maintainers Tag: Changelog : Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
ping
Change:
buildInputs = [ cairo cups <ins> faad2 </ins> ffmpeg glib gst-plugins-base

Discussion:
I reported some flakey test in freerdp upstream and they hinted that maybe we could be building freerdp better: Filing this so I don't forget to look at it.
I use freerdp all the time, so I have patched things up on my side and will open a proper PR when I have been running with it for a while. FYI, we are in fact already building against ffmpeg.
Change:
<ins> { lib , stdenv , fetchFromGitLab , meson , ninja , pkg-config , gjs , gobject-introspection , blueprint-compiler , wrapGAppsHook4 , desktop-file-utils , libadwaita , libgda6 , gsound , gst_all_1 , libportal-gtk4 }: stdenv.mkDerivation { pname = "pomodoro-gtk"; version = "1.4.1"; src = fetchFromGitLab { owner = "idevecore"; repo = "pomodoro"; rev = "44b724557539084991f3eb55b9593053a2c73eba"; # author didn't make a tag fetchSubmodules = true; hash = "sha256-krVRVMrrzuqPY/3P9dCz7rVCCW7/j5cpT95XniGpBEs="; }; postPatch = '' patchShebangs --build troll/gjspack/bin/gjspack ''; nativeBuildInputs = [ meson ninja pkg-config gjs # runtime for gjspack gobject-introspection blueprint-compiler wrapGAppsHook4 desktop-file-utils ]; buildInputs = [ gjs libadwaita libgda6 gsound gst_all_1.gst-plugins-base libportal-gtk4 ]; meta = { description = "A simple and intuitive timer application (also named Planytimer)"; homepage = "https://gitlab.com/idevecore/pomodoro"; license = lib.licenses.gpl3Plus; mainProgram = "pomodoro"; maintainers = with lib.maintainers; [ aleksana ]; platforms = lib.platforms.unix; }; } </ins>

Discussion:
Pomodoro timer for gnome which I think is better than solanum which is already packaged It seems that the project name is Planytimer but the name of the program reports pomodoro
Change:
}; }; <ins> PDFBuilder = buildPerlPackage { pname = "PDF-Builder"; version = "3.021"; src = fetchurl { url = "mirror://cpan/authors/id/P/PM/PMPERRY/PDF-Builder-3.021.tar.gz"; sha256 = "1hc22s5gdspr5nyfmix3cwdzcw7z66pcqxy422ksmbninbzv4z93"; }; checkInputs = [ TestException TestMemoryCycle ]; propagatedBuildInputs = [ FontTTF ]; meta = { description = "Facilitates the creation and modification of PDF files"; license = lib.licenses.lgpl21Plus; }; }; </ins> PDL = buildPerlPackage rec { pname = "PDL"; version = "2.025";

Discussion:
Describe the bug in seems to be broken, in a way (I think) related to how other things have broken in the past, e.g. . From looking at examples of fixes, e.g. , it looks like it might be necessary to patch the Perl source in , but I don't really understand what's going on so I don't know how. To Reproduce Steps to reproduce the behavior: to for this package so that the tests actually run, as in my PR tests fail Expected behavior I tried making a package that depends on , and got the following error at runtime: Maintainer information:
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 . 3. Ask on the on .
Change:
subversion19 = common { version = "1.9.12"; sha256 = "15z33gdnfiqblm5515020wfdwnp2837r3hnparava6m2fgyiafiw"; <ins> knownVulnerabilities = [ "https://subversion.apache.org/security/CVE-2020-17525-advisory.txt" ]; </ins> }; subversion_1_10 = common {

Discussion:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
See also:
This effectively needs a patch for the package in as far as I can see. It would be nice to have a label or something like that :)
Without knowing the internals of the subversion source well, I don't think it's going to be particularly easy to patch. The location to add the nullptr check is easy enough to find, but it's unclear what the right action to take is when the null is detected. The 1.10.x patch in that case calls a function that doesn't exist in 1.9. Without learning more about the subversion internals I'd be afraid of turning a null pointer dereference into something much worse. Or throwing an error that basically just terminates the process anyway, which wouldn't make the situation a whole lot better.
In that case it might make sense to mark it as known vulnerable?
Probably.
This doesn't affect nixos-unstable since has been removed there. Why did you scan a commit from March 19 for nixos-unstable?
Change:
url = "https://gitlab.com/scarpetta/pdfmixtool/-/commit/bd5f78c3a4d977d9b0c74302ce2521c737189b43.diff"; hash = "sha256-h2g5toFqgEEnObd2TYQms1a1WFTgN7VsIHyy0Uyq4/I="; }) <ins> # https://gitlab.com/scarpetta/pdfmixtool/-/merge_requests/14 (fetchpatch2 { url = "https://gitlab.com/scarpetta/pdfmixtool/-/commit/268291317ccd1805dc1c801ff88641ba06c6a7f0.patch"; hash = "sha256-56bDoFtE+IOQHcV9xPfyrgYYFvTfB0QiLIfRl91irb0="; }) </ins> ]; meta = with lib; {

Discussion:
Steps to reproduce the behavior: pdfmixtool on unstable Has not been been build by hydra since 09.2023 Latest error: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> { stdenv, buildPythonApplication, fetchPypi </del> <ins> { stdenv, buildPythonPackage, fetchPypi </ins> , mock, pytest , six }: <del> buildPythonApplication rec { </del> <ins> buildPythonPackage rec { </ins> pname = "PyHamcrest"; version = "1.9.0";

Discussion:
pyhamcrest is packaged using buildPythonApplication. However, pyhamcrest is a library and not an application. Try to install pyhamcrest and then import it. You cannot. Please run and paste the results.
Change:
<del> { lib, stdenv, fetchzip , pkg-config, bmake , cairo, glib, libevdev, libinput, libxkbcommon, linux-pam, pango, pixman , libucl, wayland, wayland-protocols, wlroots, mesa , features ? { gammacontrol = true; layershell   = true; screencopy   = true; xwayland     = true; } }: stdenv.mkDerivation rec { pname = "hikari"; version = "2.3.3"; src = fetchzip { url = "https://hikari.acmelabs.space/releases/${pname}-${version}.tar.gz"; sha256 = "sha256-5Ug0U3ESC5F/gj7bahnLYkeY/weSCj0QASwdFuWwdMI="; }; nativeBuildInputs = [ pkg-config bmake ]; buildInputs = [ cairo glib libevdev libinput libxkbcommon linux-pam pango pixman libucl mesa # for libEGL wayland wayland-protocols wlroots ]; enableParallelBuilding = true; makeFlags = with lib; [ "PREFIX=$(out)" ] ++ optional stdenv.isLinux "WITH_POSIX_C_SOURCE=YES" ++ mapAttrsToList (feat: enabled: optionalString enabled "WITH_${toUpper feat}=YES" ) features; postPatch = '' # Can't suid in nix store # Run hikari as root (it will drop privileges as early as possible), or create # a systemd unit to give it the necessary permissions/capabilities. substituteInPlace Makefile --replace '4555' '555' sed -i 's@<drm_fourcc.h>@<libdrm/drm_fourcc.h>@' src/*.c ''; meta = with lib; { description = "Stacking Wayland compositor which is actively developed on FreeBSD but also supports Linux"; homepage    = "https://hikari.acmelabs.space"; license     = licenses.bsd2; platforms   = platforms.linux ++ platforms.freebsd; maintainers = with maintainers; [ jpotier ]; }; } </del>

Discussion:
With merged we want to eventually drop . That'll take at least a couple of months though and we still have around as well. I'll just open this issue so that we don't forget about it. The affected packages should switch to the latest wlroots release when possible (usually a new upstream release). There's no hurry but let's use this issue to track the current progress. Packages: TODO (currently all packages that depend on wlroots -I'll update this when we're getting closer) Previous issue:
need rebuild [x] waybar [x] mpvpaper [x] qt-video-wlr [x] wl-gammactl [x] hyprpicker TODO [ ] hikari [x] waybox: [x] pywlroots: 0.16 has been released and adapted to wlroots 0.16, but qtile need pywlroots 0.15 [x] qtile [x] phoc [x] cage: [x] cagebreak
Change:
<ins> { buildPythonPackage, fetchFromGitHub, pytestCheckHook, lib }: buildPythonPackage rec { pname = "leb128"; version = "1.0.4"; # fetchPypi doesn't include files required for tests src = fetchFromGitHub { owner = "mohanson"; repo = "leb128"; rev = "v${version}"; sha256 = "040l6fxyzqal841kirf783kk1840gcy1gjd374jfr46v96qc8scm"; }; checkInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "leb128" ]; meta = with lib; { description = "A utility to encode and decode Little Endian Base 128"; homepage = "https://github.com/mohanson/leb128"; license = licenses.mit; maintainers = with maintainers; [ urlordjames ]; }; } </ins>

Discussion:
Project description LEB128 or Little Endian Base 128 is a form of variable-length code compression used to store an arbitrarily large integer in a small number of bytes. LEB128 is used in the DWARF debug file format and the WebAssembly binary encoding for all integer literals. This module makes it easy to encode/decode both signed and unsigned LEB128 integers. Metadata homepage URL: source URL: license: MIT platforms: Linux, all Python
Change:
idna = callPackage ../applications/video/kodi/addons/idna { }; <ins> infotagger = callPackage ../applications/video/kodi/addons/infotagger { }; </ins> inputstream-adaptive = callPackage ../applications/video/kodi/addons/inputstream-adaptive { }; inputstream-ffmpegdirect = callPackage ../applications/video/kodi/addons/inputstream-ffmpegdirect { };

Discussion:
When using Kodi with the YouTube plugin , I get the following error: Steps to reproduce the behavior: The YouTube plugin used to work perfectly. shows that the dependency was but that the dependency is an old one. The wrapper is here:
Thanks for catching this. Looks like a pretty straight forward addon to package. Is this something you'd be interested in tackling
I can, if I find the time! One thing I do not understand is that the dependency is an old one. I could see that the YouTube plugin is failing because the new dependency is missing, but it seems to fail because of (which is also not provided by Nixpkgs, but why didn't it fail before?).
I have tested this and it works for me. Thanks
Change:
nativeBuildInputs = []; buildInputs = []; <ins> outputs = ["out"]; </ins> installPhase = '' runHook preInstall

Discussion:
retains references to packages, bloating the closure massively. I'd expect to see no such results. If comparing to qt5: n/a Seems related to some wrapping issue. For example: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --All examples above were built against Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Do we need the qt6 plugins for designer?
I achieved the following nix diff-closures with the diff: The patch is not perfect but maybe a starting point?
Maybe a separate output that's not $dev for those plugins?
That change brings the closure from (nominally) 1.05 GiB to 925 MiB. I think the other notably sized dependency would be which appears to add 100+ MiB of its own (as it brings along ), but it's indirectly coming from
Change:
<del> {stdenv, fetchurl, cmake, pkgconfig, libelf, zlib, curl, elfutils, python, libiberty, binutils}: </del> <ins> {stdenv, fetchurl, cmake, pkgconfig, zlib, curl, elfutils, python, libiberty, binutils}: </ins> stdenv.mkDerivation rec { name = "kcov-${version}"; version = "29";

Discussion:
The kcov package in nixpkgs is currently broken, as it is unable to find the dwarf debugging sections of executables. See this issue in kcov and notice that the problems happens whether using kcov through nixpkgs, or compiling it by hand on a nixos machine (so fixupPhase is not the culprit).