jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: "ftp://ftp.freedesktop.org/pub/mesa/${version}/mesa-${version}.tar.xz" "ftp://ftp.freedesktop.org/pub/mesa/older-versions/${branch}.x/${version}/mesa-${version}.tar.xz" ]; <del> sha256 = "1fqj2xhhd1ary0pfg31jq6fqcnd6qgyrw1445nmz554k8n2ck7rp"; </del> <ins> sha256 = "02z9g6zpkg1p1sm8f84xdi7v2n7x534x9pn565bvcr411527y5qz"; </ins> }; prePatch = "patchShebangs .";
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: url = "https://gitlab.freedesktop.org/mesa/mesa/commit/aebbf819df6d1e.patch"; sha256 = "17248hyzg43d73c86p077m4lv1pkncaycr3l27hwv9k4ija9zl8q"; }) <ins> # For RISC-V support: (fetchpatch { name = "add-riscv-default-selections.patch"; url = "https://gitlab.freedesktop.org/mesa/mesa/-/commit/9908da1b7a5eaf0156d458e0e24b694c070ba345.patch"; sha256 = "036gv95m5gzzs6qpgkydf5fwgdlm7kpbdfalg8vmayghd260rw1w"; }) </ins> ] ++ optionals (stdenv.isDarwin && stdenv.isAarch64) [ # Fix aarch64-darwin build, remove when upstreaam supports it out of the box. # See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1020
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: libpthreadstubs openssl /*or another sha1 provider*/ ] ++ lib.optionals (elem "wayland" eglPlatforms) [ wayland wayland-protocols ] ++ lib.optionals stdenv.isLinux [ libomxil-bellagio libva-minimal ] <ins> ++ lib.optionals stdenv.isDarwin [ libunwind ] </ins> ++ lib.optional withValgrind valgrind-light; depsBuildBuild = [ pkg-config ];
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: #include "pipe/p_compiler.h" #include "pipe/p_state.h" <del> --- ./src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h +++ ./src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h </del> <ins> --- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h +++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h </ins> @@ -28,6 +28,8 @@ #ifndef RADV_AMDGPU_WINSYS_H #define RADV_AMDGPU_WINSYS_H +#include <sys/types.h> + <del> #include "radv_radeon_winsys.h" #include "ac_gpu_info.h" #include "addrlib/addrinterface.h"<Paste> </del> <ins> #include <amdgpu.h> #include <pthread.h> #include "util/list.h" </ins>
Code change:
Drone 2.0 has been released: <!-- Note that these are hard requirements --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.10.0 desired version: 2.0.0 Please tag this issue in your PR.

Related discussion:
text: buildGoModule rec { pname = "drone.io${lib.optionalString (!enableUnfree) "-oss"}"; <del> version = "1.10.0"; </del> <ins> version = "2.0.0"; </ins> <del> vendorSha256 = "sha256-cKHX/GnvGELQBfoo0/1UmDQ4Z66GGnnHG7+1CzjinL0="; </del> <ins> vendorSha256 = "sha256-cnbZSnHU+ORm7/dV+U9NfM18Zrzi24vf7qITPJsusU8="; </ins> doCheck = false;
Code change:
Drone 2.0 has been released: <!-- Note that these are hard requirements --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.10.0 desired version: 2.0.0 Please tag this issue in your PR.

Related discussion:
text: owner = "drone"; repo = "drone"; rev = "v${version}"; <del> sha256 = "sha256-12Jac+mXWdUX8gWvmpdO9ROv7Bi0YzvyqnNDVNJOr34="; </del> <ins> sha256 = "sha256-BxwCJf3uY34rqegZJ6H/zb63orELhq41trOgzGXQe80="; </ins> }; preBuild = ''
Code change:
[ ] It's likely that kodi/xbmc remains vulnerable. [ ] Audacity on 15.09 is older, so the patch used on master doesn't apply and wouldn't be enough anyway.
Well, the two minor issues above remain, so I'll leave this open ATM.
Closing as 15.09 has now been superseded by 16.03 and kodi is using ffmpeg 2.8.6 since

Related discussion:
text: {stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;
Code change:
[ ] It's likely that kodi/xbmc remains vulnerable. [ ] Audacity on 15.09 is older, so the patch used on master doesn't apply and wouldn't be enough anyway.
Well, the two minor issues above remain, so I'll leave this open ATM.
Closing as 15.09 has now been superseded by 16.03 and kodi is using ffmpeg 2.8.6 since

Related discussion:
text: src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Code change:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
09 is EOL

Related discussion:
text: buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {
Code change:
Describe the bug Papermc crashes due to an incompatible Java version To Reproduce Steps to reproduce the behavior: Set Log Excerpt Additional context The vanilla package runs without issues. 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 system: host os: multi-user?: sandbox: version: channels(johannes): channels(root): nixpkgs: Maintainer information:
I couldn't reproduce with this test driver : <details</details
I also get this. I think papermc starts supporting java 16 with build 668 (at least it seems to start working for me after that build), but the current build in nixpkgs is 488 building the latest build (771) works for me. the test you defined doesn't wait long enough to actually start the server Which I think you need to run with since it requires networking to download the vanilla minecraft jar it will then patch. Now the test fails as expected complaining about the java version. But if you overwrite the papermc package with: the test will succeed. (btw is there a smarter way to overwrite these variables?) Metadata: system: host os: multi-user?: sandbox: version: channels(root): channels(kaine): nixpkgs:
Same thing happens with multimc and the new version

Related discussion:
text: { lib, stdenv, fetchurl, bash, jre }: let mcVersion = "1.16.5"; <del> buildNum = "488"; </del> <ins> buildNum = "771"; </ins> jar = fetchurl { <del> url = "https://papermc.io/api/v1/paper/${mcVersion}/${buildNum}/download"; sha256 = "07zgq6pfgwd9a9daqv1dab0q8cwgidsn6sszn7bpr37y457a4ka8"; </del> <ins> url = "https://papermc.io/api/v1/paper/${mcVersion}/${buildNum}/download"; sha256 = "1lmlfhigbzbkgzfq6knglka0ccf4i32ch25gkny0c5fllmsnm08l"; </ins> }; in stdenv.mkDerivation { pname = "papermc";
Code change:
Project description A system for automatically configuring mutt and isync with a simple interface and safe passwords Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin

Related discussion:
text: <ins> { lib , stdenvNoCC , fetchFromGitHub }: stdenvNoCC.mkDerivation rec { pname = "mutt-wizard"; version = "3.2.1"; src = fetchFromGitHub { owner = "LukeSmithxyz"; repo = "mutt-wizard"; rev = "v${version}"; sha256 = "1m4s0vj57hh38rdgdc28p10vnsq80dh708imvdgxbj1i96nq41r8"; }; makeFlags = [ "PREFIX=$(out)" ]; meta = with lib; { description = "System for automatically configuring mutt and isync"; homepage = "https://github.com/LukeSmithxyz/mutt-wizard"; license = licenses.gpl3Plus; maintainers = with maintainers; [ shamilton ]; platforms = platforms.unix; }; } </ins>
Code change:
Project description A system for automatically configuring mutt and isync with a simple interface and safe passwords Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin

Related discussion:
text: mutt-with-sidebar = mutt.override { withSidebar = true; }; <ins> mutt-wizard = callPackage ../tools/misc/mutt-wizard { }; </ins> mwic = callPackage ../applications/misc/mwic { pythonPackages = python3Packages;
Code change:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

Related discussion:
text: , tllist , wayland-protocols , pkg-config <ins> , utf8proc </ins> , allowPgo ? true , python3  # for PGO # for clang stdenv check
Code change:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

Related discussion:
text: }: let <del> version = "1.7.2"; </del> <ins> version = "1.8.0"; </ins> # build stimuli file for PGO build and the script to generate it # independently of the foot's build, so we can cache the result
Code change:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

Related discussion:
text: src = fetchurl { url = "https://codeberg.org/dnkl/foot/raw/tag/${version}/scripts/generate-alt-random-writes.py"; <del> sha256 = "019bdiqfi3wx2lwrv3nhq83knc1r3lmqd5zgisa33wwshm2kyv7p"; </del> <ins> sha256 = "0w4d0rxi54p8lvbynypcywqqwbbzmyyzc0svjab27ngmdj1034ii"; </ins> }; dontUnpack = true;
Code change:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

Related discussion:
text: src = fetchzip { url = "https://codeberg.org/dnkl/${pname}/archive/${version}.tar.gz"; <del> sha256 = "0iabj9c0dj1r0m89i5gk2jdmwj4wfsai8na54x2w4fq406q6g9nh"; </del> <ins> sha256 = "07irlhkvziv51cp5zn1yz8ljfnrnfjcykv5pgfwmpslw3nl5szxv"; </ins> }; nativeBuildInputs = [
Code change:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

Related discussion:
text: wayland libxkbcommon fcft <ins> utf8proc </ins> ]; # recommended build flags for performance optimized foot builds
Code change:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

Related discussion:
text: export AR="${ar}" ''; <del> mesonFlags = [ "--buildtype=release" "-Db_lto=true" ]; </del> <ins> mesonFlags = [ "--buildtype=release" "-Db_lto=true" "-Dterminfo-install-location=${placeholder "terminfo"}/share/terminfo" ]; </ins> # build and run binary generating PGO profiles, # then reconfigure to build the normal foot binary utilizing PGO
Code change:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

Related discussion:
text: llvm-profdata merge default_*profraw --output=default.profdata ''; <ins> outputs = [ "out" "terminfo" ]; # make sure nix-env and buildEnv also include the # terminfo output when the package is installed postInstall = '' mkdir -p "$out/nix-support" echo "$terminfo" >> "$out/nix-support/propagated-user-env-packages" ''; </ins> passthru.tests = { clang-default-compilation = foot.override { inherit (llvmPackages) stdenv;