jiebi/CodeConvo huggingface dataset:
Change:
"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 .";

Discussion:
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.
Change:
buildInputs = [ expat libiconv libjpeg libpng libtiff zlib derez rez setfile <del> AGL Cocoa Kernel </del> <ins> AGL Cocoa Kernel WebKit </ins> ]; postPatch = ''

Discussion:
Describe the bug wxPython40, , does not build there likely because it uses wxGTK rather than this prevents kicad from being built on darwin To Reproduce Steps to reproduce the behavior: darwin, Expected behavior wxPython40 to build on darwin and be usable by kicad there Additional context i maintain the kicad package and Notify maintainers while there are no listed maintainers for this package it was initially contributed by (if you already investigated after the kicad PR ping, nothing relevant changed since) and has a fair amount of contributions by Maintainer information:
Hi I don't have/use mac but happy to answer any wxPython questions as I can
I'm experiencing the same issue with Linux, using .
likely a different issue. Stacktrace? What nixpkgs version / commit?
The as of this writing. Here's the output I'm seeing. <details<summarybuild log</summary</detailsIt looks like pkg-config is giving an old version of GTK+?
please use your failure seems the same as which i closed because it's fixed in the branch by and i can confirm at least starts building there (it's still going...) i'm not sure when this fix will get to ...
nice! didn't know about the details tag. Ok yeah that looks like my issue, thanks for pointing me in that direction.
I can reproduce this on 10.14.6. My best take so far was to use and adapt other Darwin requirements. <details<summarydiff against master</summary</detailsUnfortunately it does not build with the same errors as for the .
Bumped to 3.0.5.1, to its , and it builds! was set, but no dependency specified. That's what caused the missing symbols. <details<summaryworking diff</summary</detailsI'm not even sure why this works at all. claims they build from a submodule, but obviously in this setup we take whatever is supplied through . To be pedantic, 4.0.7 is supposed use some specific instead of a release, as you can . That commit is after* 3.0.4 and shortly before 3.0.5. I only skimmed the , but it sounds and looks like backwards-compatible bug fixes. Opinions on how to proceed?

If we follow upstream and choose the intermediate revision, what to specify as the package version?
i've kinda given up on stuff, at least until the next release which i hope will either be built based on a release or be compatible with the latest release (i have no reason to believe this would be the case though) if you have a diff that fixes a package, i recommend you make a PR 4.0.7 seems to work with the 3.0.4, it seems reasonable to assume the same would be true for 3.0.4
Change:
nativeBuildInputs = [ autoreconfHook pkg-config <ins> strip-nondeterminism </ins> zip ];

Discussion:
Building this package multiple times does not yield bit-by-bit identical results, complicating the detection of Continuous Integration (CI) breaches. For more information on this issue, visit . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. This step will build the package. Specific arguments are passed to the command to keep the build artifacts so we can compare them in case of differences. Execute the following command: Or using the new command line style: If the previous command completes successfully, no differences were found and there's nothing to do, builds are reproducible. If it terminates with the error message error: derivation '&lt;X' may not be deterministic: output '&lt;Y' differs from '&lt;Z'diffoscope to investigate the discrepancies between the two build outputs. You may need to add the option to ignore files and directories metadata (e.g. timestamp) differences. To examine the build log, use: Or with the new command line style: After checking out and building , output of was: So it seems to just be some timestamps in the archive . ᵗʰᶦˢ ᵗᵉᵐᵖˡᵃᵗᵉ ᶦˢ ʷᵉᶦʳᵈ Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Recently, I learned, that there's a tool called , which can help get rid of timestamps in archives. I'll try to come up with a fix using that.
Change:
{ stdenv, lib, fetchurl, runCommand, writeText, buildEnv , callPackage, ghostscriptX, harfbuzz , makeWrapper, python3, ruby, perl, gnused, gnugrep, coreutils <ins> , libfaketime </ins> , useFixedHashes ? true , recurseIntoAttrs }:

Discussion:
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ) Tested on nixpkgs Notably the ordering of the words in and similar seem nondeterministic, perhaps the other differences are effects of that.
That is an issue with , respectively the tools called by , so it should be solved upstream.
fmtutil here is coming from texlive-scripts in - but it's the output of that's not reproducible. I'm now sure it's in dumping out the hyphenation exception strings in the (random) order in which they appear in the lua hashtable. I guess we should sort them in dictionary order. There is already a qsort routine, so perhaps we should put the exceptions in an array, sort that array using qsort, and only produce the result from that.
I think this is already referring to .
Huh! Indeed that covers the same issue - I did search before digging into this problem, but not good enough apparently :laughing: .
Change:
substituteInPlace packaging/cmake/Modules/NetdataGoTools.cmake  --replace-fail  'GOPROXY=https://proxy.golang.org'  <del> 'GOPROXY=file://${passthru.netdata-go-modules}' </del> <ins> 'GOPROXY=file://${finalAttrs.passthru.netdata-go-modules}' </ins> # Prevent the path to be caught into the Nix store path. substituteInPlace CMakeLists.txt 

Discussion:
Steps to reproduce the behavior: netdata 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Created a PR to fix the build, can you try it out ?
Change:
<ins> { lib , rustPlatform , fetchFromGitHub , python3 , testers , cringify }: rustPlatform.buildRustPackage rec { pname = "cringify"; version = "0.2.0"; src = fetchFromGitHub { owner = "sansyrox"; repo = "cringify"; rev = "857c2620ac9f1f53139d3a599e55679a75e77053"; hash = "sha256-U0tKYFRZToMALSeItn9yia7Dl7omETDTkuRlWJ8EZEo="; }; cargoHash = "sha256-OQXGn6m6VdSlxaCPRonjvEo/GOpsEiZkqL12UdoLu0Q="; postPatch = '' # Upstream doesn't set the version string itself substituteInPlace src/main.rs --replace '0.0.1' ${version} ''; nativeBuildInputs = [ python3 ]; # No tests are present in the repository doCheck = false; passthru.tests.version = testers.testVersion { package = cringify; }; meta = { description = "Annoy your friends with the cringified text"; homepage = "https://github.com/sansyrox/cringify"; license = lib.licenses.mit; mainProgram = "cringify"; maintainers = with lib.maintainers; [ tomasajt ]; }; } </ins>

Discussion:
Package name: cringify Latest released version: 0.2.0 <!-- Search your package here: --- Current version on the unstable channel: 0.1.1 Current version on the stable/release channel: 0.1.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR. NOTE: it seems that there are no tags on the upstream GitHub repository but it is released on with a new version 0.2.0
Change:
<del> { stdenv, fetchurl, unzip, autoreconfHook, pkgconfig, libsodium, python }: stdenv.mkDerivation rec { name = "libmacaroons-${version}"; version = "0.3.0"; src = fetchurl { url = "https://github.com/rescrv/libmacaroons/archive/releases/${version}.zip"; sha256 = "18c44424jri0p5la6jgrnlz5p937hk7ws2mldhzjwisqyf5qld43"; }; buildInputs = [ unzip autoreconfHook python libsodium pkgconfig ]; meta = with stdenv.lib; { description = ''Macaroons are flexible authorization credentials that support decentralized delegation, attenuation, and verification.''; homepage = https://github.com/rescrv/libmacaroons; license = licenses.bsd3; }; } </del>

Discussion:
Starting the HyperDex coordinator by running does most of its work by , which must be on . This does not work with the current derivation. This could be fixed either by ensuring replicant is to PATH (would making it a propagated build input be sufficient?) or patching hyperdex to exec replicant by its store path. Install hyperdex, run . It fails. System: 16.03.1242. (Emu) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: 16.03.1242.
Thanks! Upstream hyperdex is not super maintained and in my experience not stable enough to be used in production. I vote for removing it from nixos. are you relying in hyperdex in nixos or is are you just testing? [1]
I was just testing, not relying on it. Removal sounds okay to me. Alternately, I tested and adding to (in addition to ) fixes the problem.
Change:
makeAutostartItem = callPackage ../build-support/make-startupitem { }; <del> makeInitrd = { contents, compressor ? "gzip -9n", prepend ? [ ] }: callPackage ../build-support/kernel/make-initrd.nix { inherit contents compressor prepend; }; </del> <ins> makeInitrd = callPackage ../build-support/kernel/make-initrd.nix; # Args intentionally left out </ins> makeWrapper = makeSetupHook { deps = [ dieHook ]; substitutions = { shell = pkgs.runtimeShell; }; } ../build-support/setup-hooks/make-wrapper.sh;

Discussion:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.
Change:
hardeningDisable = [ "format" ]; postBuild = '' <del> cp ${gamecontrollerdb} ${gamecontrollerdb.name} </del> <ins> cp ${finalAttrs.gamecontrollerdb} ${finalAttrs.gamecontrollerdb.name} </ins> pushd ../OTRExporter <del> ${lib.optionalString oot.enable "python3 ./extract_assets.py -z ../build/ZAPD/ZAPD.out ${oot.rom}"} ${lib.optionalString ootMq.enable "python3 ./extract_assets.py -z ../build/ZAPD/ZAPD.out ${ootMq.rom}"} </del> <ins> python3 ./extract_assets.py -z ../build/ZAPD/ZAPD.out --norom --xml-root ../soh/assets/xml --custom-assets-path ../soh/assets/custom --custom-otr-file soh.otr --port-ver ${finalAttrs.version} </ins> popd '';

Discussion:
Package name: shipwright Latest released version: 8.0.4 <!-- Search your package here: --- Current version on the unstable channel: 7.1.1 Current version on the stable/release channel: 7.0.2 <!-- 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 I tried updating myself and found 8.0.4 fails building with error I bisected to upstream commit and the file but I'm not sure how to resolve right now. <!-- If the result shows no maintainers, tag the person that last updated the package. --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:
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

Discussion:
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.
Change:
"${source}/${location}" ; <ins> NIX_CFLAGS_COMPILE = lib.optionalString stdenv.isDarwin "-I${lib.getDev libcxx}/include/c++/v1"; </ins> buildInputs = [ tree-sitter ]; dontUnpack = true;

Discussion:
Describe the bug grammars that have a C++ scanner () fail to build on darwin because is used to build them instead of . It complains about missing C++ headers like and . To Reproduce Steps to reproduce the behavior: to build on Darwin Expected behavior grammars should all build on darwin. Additional context I've fixed the issue in my config by overriding the in the derivation like this: Compared to the current : Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(sandhose): channels(root): nixpkgs: Maintainer information:
PR welcome
I don’t have a MacOS to test it, but I will merge PRs that make the tests pass on our CI infrastructure.
I can test, is this issue at all related to this: The build succeeds with the following on mac, it just does not in the derivation.
For now you can find the workaround I'll create a pull request to address this soon.
Change:
preBuild = lib.optionalString (conf != null) "cp ${finalAttrs.configFile} src/nnn.h"; nativeBuildInputs = [ installShellFiles makeWrapper pkg-config ]; <del> buildInputs = [ readline ncurses ] ++ lib.optional stdenv.hostPlatform.isMusl musl-fts; </del> <ins> buildInputs = [ readline ncurses ] ++ lib.optional stdenv.hostPlatform.isMusl musl-fts ++ lib.optional withPcre pcre; </ins> env.NIX_CFLAGS_COMPILE = lib.optionalString stdenv.hostPlatform.isMusl "-I${musl-fts}/include"; NIX_LDFLAGS = lib.optionalString stdenv.hostPlatform.isMusl "-lfts";

Discussion:
It would be great to have option to fetch nnn plugins with nxpkgs or with additional package instead of manually fetching it like developer advise. And second is it possible to implement some option to include icons support from nerdfont to nnn binary file instead of recompiling it? Thanks.
I think this issue was closed preemptively by the line in the PR, there doesn't seem to be any way to include plugins as of now
nnn seems to expect plugins in . This might work better as a home-manager module, maybe with the plugins themselves as an output of nixpkgs. I might take a look at this next week.
I marked this as stale due to inactivity. &rarr;
I've recompiled nnn with icons, by using unstable branch and overriding nnn-package:
I marked this as stale due to inactivity. &rarr;
Change:
{ <del> "version": "1.7.0", "srcHash": "sha256-9ILP2HH7p8ELwrQOBnqPbvHdUnNrqEkA4OmxOuhNbEc=", "yarnSha256": "1ygb8pmwra570wmdkn7mxv9j90cgjh063b9cl0wl9hsmg687sk9h" </del> <ins> "version": "1.8.1", "srcHash": "sha256-B8Hnpi4XwK0WrHRgj7OSVUh49oRH9SVEHdzGbnDa8p8=", "yarnSha256": "ME19kHlVw0Q5oCytYQCUj4Ek0+712NkqB6eozOtF6/k=" </ins> }

Discussion:
Package name: Jellyseerr Latest released version: 1.8.1 <!-- Search your package here: --- Current version on the unstable channel: 1.7.0 Current version on the stable/release channel: 1.7.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 for maintainers: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> {lib, stdenv, fetchurl, perl }: </del> <ins> {lib, stdenv, fetchFromGitHub, perl }: </ins> stdenv.mkDerivation rec { pname = "redo"; version = "1.4"; <del> src = fetchurl { url = "https://jdebp.eu./Repository/freebsd/${pname}-${version}.tar.gz"; sha256 = "1c8gr5h77v4fw78zkhbm9z9adqs3kd7xvxwnmci2zvlf4bqqk4jv"; </del> <ins> src = fetchFromGitHub { owner = "jdebp"; repo = "redo"; rev = "91f5462339ef6373f9ac80902cfae2b614e2902b"; hash = "sha256-cA8UN4aQnJ8VyMW3mDOIPna4Ucw1kp8CirZTDhSoCpU="; </ins> }; nativeBuildInputs = [ perl /* for pod2man */ ]; <del> sourceRoot = "."; </del> buildPhase = '' <del> ./package/compile </del> <ins> package/compile </ins> ''; installPhase = '' <del> ./package/export $out/ </del> <ins> package/export $out/ </ins> ''; meta = {

Discussion:
The redo build manager may no longer work: The source is pulled from , a domain which is no longer registered, therefore the tarball is no longer available. N/A N/A N/A The source is available on github: , we should consider pulling it from there (alternatively consider removing abandonware from nixpgks, if nothing depends on this) <-- seems inactive <-- probably not your fault I am not sure who to tag here, so: N/A
Change:
<ins> { stdenv, fetchFromGitHub }: stdenv.mkDerivation rec { pname = "jtc"; version = "1.74"; src = fetchFromGitHub { owner = "ldn-softdev"; repo = pname; rev = version; sha256 = "04hzamgs4k0x58cf4dw0a46kyw79yvcd5vazbklbjl6ap3rmnrx3"; }; buildPhase = '' runHook preBuild $CXX -o jtc -Wall -std=gnu++14 -Ofast jtc.cpp runHook postBuild ''; installPhase = '' runHook preInstall install -Dm755 -t $out/bin jtc runHook postInstall ''; meta = with stdenv.lib; { description = "JSON manipulation and transformation tool"; homepage = "https://github.com/ldn-softdev/jtc"; license = licenses.mit; maintainers = [ maintainers.marsam ]; platforms = platforms.all; }; } </ins>

Discussion:
Project description A CLI tool to extract, manipulate and transform source JSON. offers a powerful way to select one or multiple elements from a source JSON and apply various actions on the selected elements at once (wrap selected elements into a new JSON, filter in/out, update elements, insert new elements, remove, copy, move, compare, transform and swap around). Utility ideology: is a stateful processor with own DSL, variables, operations, control flow logic, IO system, etc., etc. is a Unix utility confining its functionality to operation types with its data model only (as per Unix ideology). performs one operation at a time and if successive operations required, then CLI to be daisy-chained over the pipe symbol . Metadata homepage URL: source URL: license: MIT platforms: Unix
I have never contributed a derivation before, but here is my attempt: It works on my machine.
Change:
<del> { stdenv, fetchurl, jre, makeWrapper, bash }: </del> <ins> { stdenv, fetchurl, jre, makeWrapper, bash, coreutils }: </ins> stdenv.mkDerivation rec { name = "zookeeper-${version}";

Discussion:
We currently have a nice ZooKeper module and package, but apparently all the cool kids run ZK via , which we don't have packaged or any module around. Anyone feel like packaging and/or writing a module for it? cc who have dealt with ZK
I would like to own this. Thank you for bringing this up.
Let's assign it to you then &ndash; informally, as GitHub only allows that for organization members (or some similar condition).
Thanks
is this happening?
Sorry for the delay. Yes I am working on this.
any progress?
FYI, I took a crack at this in