jiebi/CodeConvo huggingface dataset:
Change:
src = fetchFromGitHub { owner = "gradio-app"; repo = "gradio"; <del> rev = "refs/tags/@gradio/client@${version}"; </del> <ins> rev = "refs/tags/gradio_client@${version}"; </ins> sparseCheckout = [ "client/python" ]; <del> hash = "sha256-7oC/Z3YUiOFZdv/60q7PkfluV77broRkHgWiY9Vim9Y="; </del> <ins> hash = "sha256-SVUm9LrjYG0r3U1yOd3rctxVMYlnAOW+Opqy9c3osnw="; </ins> }; prePatch = '' cd client/python

Discussion:
Steps to reproduce the behavior: Gradio / Gradio Client <!-- 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]:
fix for py311
Change:
<ins> diff --git a/builder.go b/builder.go index ed6c5ef..36e8055 100644 --- a/builder.go +++ b/builder.go @@ -200,7 +200,7 @@ func NewReplace(old, new string) Replace { // It is the caller's responsibility to remove the folder when finished. func newTempFolder() (string, error) { var parentDir string -	if runtime.GOOS == "darwin" { +	if false && runtime.GOOS == "darwin" { // After upgrading to macOS High Sierra, Caddy builds mysteriously // started missing the embedded version information that -ldflags // was supposed to produce. But it only happened on macOS after </ins>

Discussion:
Caddy fails to build for riscv64 Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
(please fill out more parts of the bug report template next time) Assuming this is , likely an instance of . Pinging maintainers:
Hi, thanks for the ping :) The fix for this is fairly trivial. Either skip the shell completions/man pages[^1], or use something like But I am upset that you ( didn't even care enough to do the bare minimum and fill out the issue template. [^1]: Technically only the kills the build, not the , because bash pipefail defaults.
i'm sorry for the issue template, it was more of a quick note to myself. i'll do it right next time
Change:
khal = callPackage ../applications/misc/khal { }; <ins> khoj = callPackage ../servers/search/khoj { }; </ins> khard = callPackage ../applications/misc/khard { }; kid3 = libsForQt5.callPackage ../applications/audio/kid3 { };

Discussion:
Project description Natural Language Search Engine for your Org-Mode and Markdown notes, Beancount transactions and Photos Metadata homepage URL: source URL: license: gpl3 , ...
Change:
restartTriggers = [ fail2banConf jailConf pathsConf ]; reloadIfChanged = true; <del> path = [ cfg.package cfg.packageFirewall pkgs.iproute2 ]; </del> <ins> path = [ cfg.package cfg.packageFirewall pkgs.iproute2 ] ++ cfg.extraPackages; </ins> unitConfig.Documentation = "man:fail2ban(1)";

Discussion:
Describe the bug when configured to use ipset actions fail2ban fails to ban because the action script cannot find the ipset binary. To Reproduce Steps to reproduce the behavior: configure fail2ban to use actions, then cause a ban (eg invalid ssh logins) Expected behavior iptables rules and ipsets for the ban are created. Screenshots Additional context 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(root): nixpkgs: Maintainer information:
The fail2ban derivation doesn't bring in ipset, it's also going to need some patching of the fail2ban conf files. Need to research if ipset protocol 6 is availble in nixpkgs, ipset v4 does seem to exist.
unstable has ipset 7.11, 20.03 has ipset 7.5, 20.09 has ipset 7.6. all of those should be protocol version 7 and thus work with the v6 actions i think?
fwiw adding ipset to the fail2ban service path in seems sufficient to get this to work.
In ! lets see if the practise matches up! :-) wow, you joined github 2 days ago... welcome to github!
we've applied that setting locally and so far haven't seen any problems across quite a few restarts and ban/unban actions. seems good! :)
what would be a good way to solve this for the next person? there's two things we could think of: add ipset to path when using iptables as the firewall backend (like sshguard does) extend firewallPackage to firewallPackages and let people who want ipset add it there second one sounds cleaner, not least because using nftables already requires changing firewallPackage. that would require deprecating firewallPackage though, and i don't feel qualified to do that
is extra packages the way to go? ipset is needed by fail2ban, so should it be a dependency by default? I've been flat out working so not had time to look at this. These are just questions not demands!
ipset isn't needed by the default configuration of fail2ban, only if you choose a different ban action.

if the default action and ipset were the only options i'd totally agree that ipset should be a dependency, but there's quite a few more actions: some send mail, some call into shorewall, or curl something to cloudflare, or even call into BIND to update a dns zone. since we'd need some extraPackages mechanism to support those properly anyway it didn't feel quite right to elevate one action to default-dependency and leaving out all the others (especially since nftables doesn't even need ipset to provide the same functionality). but i've got no feelings on this. if y'all want ipset to be a default dependency i'm perfectly fine doing that instead. would very much like to keep extraPackages though for the stated reasons.
Change:
rubyMinimal = ruby.override { # gem support is minimal overhead rubygemsSupport = true; <ins> removeReferenceToCC = true; JitSupport = false; </ins> useRailsExpress = false; zlibSupport = false; opensslSupport = false;

Discussion:
Describe the bug I'm hunting down packages that reference gcc. One of them is (maintainers: & ). Here's why: The fault is the fact that the build flag doesn't remove all references, as one might expect (EDIT, see: ). I'm up to including this feature, but I was wondering perhaps it'd be legit to disable this feature for the derivation? I opened a PR at (EDIT).
But that would mean gems that require a compiler would no longer work.
The suggestion is for , not . Isn't the derivation that's used to build the gems? According to:
It still has support for gems, so some will fail with gcc. What exactly is the use case for ?
Technically it's not used anywhere, according to .
I'd like to make my - with an overlay. The goal is to make the 1 or 2 pure ruby scripts I have on my system not pull , as they do today.
But what is the reason? You're likely to have a version of ruby that includes gcc on your system anyway, so you don't really save any space. And the use-case would be plain ruby scripts with only the gems that don't require system libraries. We have no users in nixpkgs of presumably because it's rather pointless. And while of course we can strip gcc from rubyMinimal (there's no harm), I'd rather say drop instead.
Not If I'll apply and this overlay: This allows me to not need GCC for for example - which is the only ruby gem I use. For example, run with this PR and that overlay applied: And you should get: And without , (and without the overlay because it would fail) you should get: is the only derivation that needs ruby that I actually use. I've updated the 1st comment in to exemplify this overlay as a possible usecase. Well I tend to agree - even for asciidoctor which should be pretty much a pure ruby gem, it still required and which aren't enabled in current . Hence I tend to agree. OK so I've updated to include a drop to , including release notes and an alias. Waiting for your review :crossed_fingers: .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
hardeningDisable = [ "bindnow" ]; <del> preConfigure = '' # Don't record the configure flags since this causes unnecessary # runtime dependencies </del> <ins> preConfigure = # Don't record the configure flags since this causes unnecessary # runtime dependencies '' </ins> for i in main/build-defs.h.in scripts/php-config.in; do substituteInPlace $i  --replace '@CONFIGURE_COMMAND@' '(omitted)' 

Discussion:
Describe the bug Error build php packages. To Reproduce Steps to reproduce the behavior: Run Notify maintainers Build error occurs after this PR Build log:
After this PR error build php. cc
fixes it
Change:
stdenv.mkDerivation rec { name = "libva-${lib.optionalString minimal "minimal-"}${version}"; <del> version = "2.6.1"; </del> <ins> version = "2.7.1"; # Also update the hash for libva-utils! </ins> # update libva-utils and vaapiIntel as well src = fetchFromGitHub { <del> owner  = "01org"; </del> <ins> owner  = "intel"; </ins> repo   = "libva"; rev    = version; <del> sha256 = "1x34kf38p5rf52bf54ljr9f7knnbilm7kbszqnfk3lzsqrfc7r2g"; </del> <ins> sha256 = "0ywasac7z3hwggj8szp83sbxi2naa0a3amblx64y7i1hyyrn0csq"; </ins> }; outputs = [ "dev" "out" ];

Discussion:
Describe the bug libva tries to find and use instead of like before To Reproduce Steps to reproduce the behavior: nixos-unstable channel vlc on console to see log any video in vlc Expected behavior is used and no vlc crash happens Additional context Add any other context about the problem here. 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(gnidorah): channels(root): nixpkgs: Maintainer information:
Seems to be an upstream issue that affects only X11 (DRI 2): After we update to this should be fixed. As a temporary workaround it should work via (or , depending on which driver you prefer).
I opened a PR for the update: Note: I the regression label as is the new default since Mesa 20 (the previous default driver was ). As a result NixOS shouldn't be affected by this as we stayed on Mesa 19.
Change:
plex = callPackage ../servers/plex { }; plexRaw = callPackage ../servers/plex/raw.nix { }; <ins> psitransfer = callPackage ../servers/psitransfer { }; </ins> tab = callPackage ../tools/text/tab { }; tabview = with python3Packages; toPythonApplication tabview;

Discussion:
Project description Simple open-source self-hosted file sharing solution. Metadata homepage URL: source URL: license: bsd platforms: linux
I may have a go at this myself over the next few weeks but figured I'd start by posting it here.
I marked this as stale due to inactivity. &rarr;
Looks like you contributed this in :)
Change:
src = fetchFromGitHub { owner = "maxcurzi"; repo = "tplay"; <del> rev =  "v${version}"; </del> <ins> rev = "v${version}"; </ins> hash = "sha256-/3ui0VOxf+kYfb0JQXPVbjAyXPph2LOg2xB0DGmAbwc="; }; cargoHash = "sha256-zRkIEH37pvxHUbnfg25GW1Z7od9XMkRmP2Qvs64uUjg="; checkFlags = [ <del> # requires network access </del> <ins> # requires network access </ins> "--skip=pipeline::image_pipeline::tests::test_process" "--skip=pipeline::image_pipeline::tests::test_to_ascii" "--skip=pipeline::image_pipeline::tests::test_to_ascii_ext"

Discussion:
I think this is not actually a build failure, but it does make the package unusable without manually specifying an additional dependency. Steps to reproduce the behavior: using the package on a system without a pre-existing ffprobe installation (for example in a ) on a local mp4 or png file To try and solve the problem, I read the error message and tried to install ffprobe, so I searched for in nix packages, and tried re-running with the first result : , and it worked fine. So I hope the fix is trivial and can be done quickly. As I'm a newcomer to nix and NixOS, I prefer not to try and fix it myself, but i'll make sure to read the PR to hopefully by able to make such a simple fix myself next time <!-- 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]:
Change:
<del> diff -ur mosh-1.3.2/src/frontend/mosh-server.cc mosh-1.3.2.patched/src/frontend/mosh-server.cc --- mosh-1.3.2/src/frontend/mosh-server.cc	2017-07-22 23:14:53.000000000 +0200 +++ mosh-1.3.2.patched/src/frontend/mosh-server.cc	2018-06-06 10:45:50.725352804 +0200 @@ -351,6 +351,10 @@ } } +#ifdef HAVE_UTEMPTER +    utempter_set_helper( "utempter" ); +#endif + try { return run_server( desired_ip, desired_port, command_path, command_argv, colors, verbose, with_motd ); } catch ( const Network::NetworkException &e ) { </del>

Discussion:
A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- 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.
Change:
description = "Enable the OCI seccomp BPF hook"; }; <del> containersConf = mkOption { default = {}; </del> <ins> containersConf.settings = mkOption { type = toml.type; default = { }; </ins> description = "containers.conf configuration"; <del> type = types.submodule { options = { extraConfig = mkOption { type = types.lines; default = ""; description = '' Extra configuration that should be put in the containers.conf configuration file ''; }; }; }; </del> }; registries = {

Discussion:
Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this
Change:
let thunderbird-unwrapped = thunderbirdPackages.thunderbird-115; <del> version = "115.9.0"; </del> <ins> version = "115.14.0"; </ins> majVer = lib.versions.major version; betterbird-patches = fetchFromGitHub { owner = "Betterbird"; repo = "thunderbird-patches"; <del> rev = "${version}-bb26-build2"; </del> <ins> rev = "${version}-bb31"; </ins> postFetch = '' echo "Retrieving external patches"

Discussion:
Steps to reproduce the behavior: betterbird Please run and paste the result.
I don't see any error, so likely your machine is just to weak. You can try reducing cores/max-jobs for nix.
I think job on hydra also failed, which cause a rebuild on my laptop. See Not sure if I'm making any mistake here?
There the error is: error[E0635]: unknown feature which means we need to update betterbird to be hopefully based on a newer thunderbird version which supports a newer rust version

Package name: betterbird Latest released version: 115.12 <!-- Search your package here: --- Current version on the unstable channel: 115.9 Current version on the stable/release channel: 115.9 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Could you create a PR, please?
I can try but I don't understand what file is the hash of line 39 from?
You just delete it (let it be ) and run the build, it will fail with the right hash. Before submitting PRs you may also read
Thank you. I opened it here :
Change:
<del> { stdenv, lib, bower2nix }: </del> <ins> { stdenv, lib, bower2nix, cacert }: </ins> let bowerVersion = version: let

Discussion:
fetch-bower produces truncated nix-store entry when run under nix-build: Looking into the retrieved jquery in the nix store you can see jquery is actually missing: It works fine when trying to manually run it as a regular user: bower- generated by : run nix-build System: (16.09beta172. (Flounder)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: (16.09beta172.)
ping
Sorry for the delay I will test and merge today.
Hello thanks for your detailed report. I am getting slightly different results to you, so more investigation will be necessary. In my environment (NixOS 16.09 channel), there was no hash mismatch. Possibly something caused git to fail to download the jquery package. If it silently fails producing an incorrect result, then that is a bug in bower2nix which could be reported at
I am not sure this due to bower2nix. Fetch-bower is calling git and should handle the error's accordingly, no?
It consistently fails for me both on the latest unstable and 16.09 channels. Can you try updating your channels? My suspect was commit but I wasn't able to revert it cleanly to try it out.
By , I also mean . I have rolled the two programs into one repo. You are definitely right, is calling (indirectly, through the API), and should handle the error. I'm an avid subscriber to 16.09 and especially nixos-unstable, so have tested on those. Obviously it would be easier to fix the error handling if I can make fail myself. Do you have any further info about your setup which might be relevant? E.g. any proxy settings required for git to work. Can I also confirm that you are running before retrying ?
I don't have any proxy settings. Is it possible GitHub is rate limiting requests from bower? I found this thread interesting And yes I am running nix-store --delete before trying nix-build.
Hi are there any additional details I can provide? I am not that familiar with typescript or javascript, but I could try to narrow the issue down with some help.
How to reproduce: Expected output: bower package info json.

Actual output: nothing, not even an error message.
This problem is back. I can reproduce it by following the steps outlined in the top message. (latest nixpkgs-unstable) It did work for me a while ago though, so it looks like a regression. Did some digging around but I cannot figure it out. cc
Good catch, I think I've seen the same issue as well, but didn't bother (lack of time). Could be a different cause, but we have to start somewhere :)
Running produces correct result while -ing the following produces an output without jquery (just meta data)
Figured it out. Git doesn't see SSL certificates. I made it run with this expression I'll try to open a PR to fix this in nixpkgs. I'll also try to open a PR to bower2nix because there is a bug in it - missing SSL cert should not result in exit code 0.
Change:
config = mkIf cfg.enable { <del> # This is enough to make a symlink because the xserver # module already links all /share/X11 paths. </del> environment.systemPackages = [ x11Fonts ]; <ins> environment.pathsToLink = [ "/share/X11/fonts" ]; </ins> services.xserver.filesSection = '' FontPath "${x11Fonts}/share/X11/fonts"

Discussion:
The description of the options says: but since NixOS 21.05 it does not do that, when set to . Steps to reproduce the behavior: the following configuration: Accordingly to the documentation, and what happened before 21.05, the set of default fonts should be collected inside a subdirectory of . Commit removed the , replacing that with a new entry in the option. Given that my usage does not involve the X server at all (it's a web application that requires some of those fonts to build a report), as a workaround I re- that setting in the app configuration. Am I missing something, or should the documentation be rectified? author of ref'ed commit committer
I did remove the line because the fonts directory has been moved to and if is true, that directory is already being symlinked. The problem is that I (wrongly) assumed fontdir would only be used with X.org/wayland. The solution is exactly what you did: just add back . I'll open a pull request later to fix it. Thank you for reporting this.
Change:
cups-bjnp = callPackage ../misc/cups/drivers/cups-bjnp { }; <ins> dcp9020cdwlpr = (pkgsi686Linux.callPackage ../misc/cups/drivers/brother/dcp9020cdw { }).driver; dcp9020cdw-cupswrapper = (callPackage ../misc/cups/drivers/brother/dcp9020cdw { }).cupswrapper; </ins> cups-brother-hl1110 = pkgsi686Linux.callPackage ../misc/cups/drivers/hl1110 { }; cups-brother-hl1210w = pkgsi686Linux.callPackage ../misc/cups/drivers/hl1210w { };

Discussion:
CUPSwrapper printer driver for Brother 9020CDW Metadata homepage URL: source URL: license: gpl2 platforms: linux
Well, I've managed to do it on my own, but it would be very nice to have it in the tree. Formula: Put it into and then then add it into
Make a PR?
Have no idea how/where to do it properly
Not sure if I did it right but whatever.
I'm not sure what is wrong with you, though I don't think you have use such rude language. This is my first time when I try to deliver a patch and developers speak with me using imperative-command language. Not sure why you want to be hostile to your users/contributors but good luck with that.
I wasnt being hostile, I just suggested that you could make a pr since youve already packaged it?
I'm talking about your imperative language in the comment to my PR. That doesn't sound nice, sorry.
I don't understand I just told you stuff you needed to know
Of course feedback is needed to improve your PR and get it merged
I didn't mean to be offensive, sorry
Okay, will try.
Change:
statserial = callPackage ../tools/misc/statserial { }; <del> steampipe = callPackage ../tools/misc/steampipe { }; </del> step-ca = callPackage ../tools/security/step-ca { inherit (darwin.apple_sdk.frameworks) PCSC; };

Discussion:
Steps to reproduce the behavior: steampipe Occurred after a and a . <!-- 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]:
It seems that the is invalid: I’ll open a PR to fix this.
The same problem happened to the package last week: They merged the r-ryantm auto-update PR for hugo package, and then the build fails on Hydra with an invalid . Explaination: has been updated to (2 weeks ago) targeting the branch: -ryantm opened the auto-update PR for package compiled with : the staging-next PR was merged with as default: the steampipe auto-update PR was merged with an outdated because Go has been upgraded to 1.22 and the being outdated.
My fault, sorry. Just a question for the explanation, Should it then be supposed that a large proportion of Go packages have hash mismatches on master, but are not detected because go-modules are fixed-output derivations?
No problem, thanks for the help :) I'm not sure if this is already the case on master, but what I do know is that this has happened to other packages like , and . All PRs (not just those of the r-ryantm bot), created before this merge on staging-next (for Go 1.21) and merged now without having a updated for Go 1.22 are potentially impacted. Because :
Change:
{ lib , stdenv <del> , mkDerivation , fetchurl </del> <ins> , fetchFromGitHub </ins> , cmake , doxygen , graphviz

Discussion:
Package name: gplates Latest released version: 2.4 Current version on the unstable channel: 2.3 Current version on the stable/release channel: 2.3 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: