jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { lib, buildGoModule, fetchFromGitHub }: let version = "1.2.0"; src = fetchFromGitHub { owner = "tynany"; repo = "frr_exporter"; rev = "v${version}"; hash = "sha256-sjC6ee7VMbr5zlahAA/i4wrZIu8CBUF+LYaq6uEvukk="; }; in buildGoModule { pname = "prometheus-frr-exporter"; vendorHash = "sha256-xckGN/FKN2bwFPll6IRDBOGGUm2JTzoZDwKC6ZkoD/Y="; inherit src version; ldflags = [ "-X github.com/prometheus/common/version.Version=${version}" "-X github.com/prometheus/common/version.Revision=${src.rev}" "-X github.com/prometheus/common/version.Branch=unknown" ]; meta = with lib; { description = "Prometheus exporter for FRR version 3.0+"; longDescription = '' Prometheus exporter for FRR version 3.0+ that collects metrics from the FRR Unix sockets and exposes them via HTTP, ready for collecting by Prometheus. ''; homepage = "https://github.com/tynany/frr_exporter"; license = licenses.mit; maintainers = with maintainers; [ javaes ]; mainProgram = "frr_exporter"; }; } </ins>

Related discussion:
text: Project description Prometheus exporter for Free Range Routing Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
<del> { python3Packages, fetchFromGitHub, lib, yubikey-personalization, libu2f-host, libusb1 }: </del> <ins> { python3Packages, fetchFromGitHub, lib, yubikey-personalization, libu2f-host, libusb1, procps }: </ins> python3Packages.buildPythonPackage rec { pname = "yubikey-manager";

Related discussion:
text: crashes as is fails to find the path Steps to reproduce the behavior: shows some info Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
Code change:
"--email" data.email "--key-type" data.keyType ] ++ protocolOpts <del> ++ optionals data.ocspMustStaple [ "--must-staple" ] </del> ++ optionals (acmeServer != null) [ "--server" acmeServer ] ++ concatMap (name: [ "-d" name ]) extraDomains ++ data.extraLegoFlags; <ins> # Although --must-staple is common to both modes, it is not declared as a # mode-agnostic argument in lego and thus must come after the mode. </ins> runOpts = escapeShellArgs ( commonOpts ++ [ "run" ] <ins> ++ optionals data.ocspMustStaple [ "--must-staple" ] </ins> ++ data.extraLegoRunFlags ); renewOpts = escapeShellArgs ( commonOpts ++ [ "renew" "--reuse-key" ] <ins> ++ optionals data.ocspMustStaple [ "--must-staple" ] </ins> ++ data.extraLegoRenewFlags );

Related discussion:
text: Describe the bug causes Lego to fail. To Reproduce Steps to reproduce the behavior: set on an enabled certificate. to this configuration. fail. Lego complains about an unrecognized (really misplaced) flag. Expected behavior The certificate will be successfully fetched, with Must-Staple enabled. Screenshots Additional context I think the problematic code is here: should not be in commonOpts, it should instead be in runOpts and renewOpts. Lego runs successfully when is to and . Notify maintainers (the acme team) Metadata Maintainer information:
Thanks for the report :) It appears that the --must-staple option is common to both "run" and "renew" modes, but is not actually a common option that can be specified before the mode. I'll get a PR ready for this.
Code change:
<ins> { lib , stdenv , fetchFromGitHub }: stdenv.mkDerivation rec { pname = "tbox"; version = "1.7.3"; src = fetchFromGitHub { owner = "tboox"; repo = pname; rev = "v${version}"; hash = "sha256-6SqMvwxKSiJO7Z33xx7cJoECu5AJ1gWF8ZsiERWx8DU="; }; configureFlags = [ "--hash=y" "--charset=y" "--float=y" "--demo=n" ]; postInstall = '' mkdir -p $out/lib/pkgconfig substituteAll ${./libtbox.pc.in} $out/lib/pkgconfig/libtbox.pc ''; meta = with lib; { description = "A glib-like multi-platform c library"; homepage = "https://docs.tboox.org"; license = licenses.asl20; platforms = platforms.linux; maintainers = with maintainers; [ rewine ]; }; } </ins>

Related discussion:
text: Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix
Code change:
githubId = 37185887; name = "Calvin Kim"; }; <ins> keenanweaver = { email = "keenanweaver@protonmail.com"; name = "Keenan Weaver"; github = "keenanweaver"; githubId = 37268985; }; </ins> keksbg = { email = "keksbg@riseup.net"; name = "Stella";

Related discussion:
text: Project description udev rules to make supported controllers available with user-grade permissions Metadata homepage URL: source URL: license: mit platforms: linux
Code change:
"-Dtests=false" "-Dtracker3=${lib.boolToString trackerSupport}" "-Dbroadway_backend=${lib.boolToString broadwaySupport}" <ins> "-Dx11_backend=${lib.boolToString x11Support}" "-Dquartz_backend=${lib.boolToString (stdenv.isDarwin && !x11Support)}" </ins> ]; doCheck = false; # needs X11

Related discussion:
text: is built without X11 support on darwin because the Meson build file disables it. The GTK build system was changed to Meson by , and it removed the configure flags that enabled X11 on darwin: But the file of GTK3 disables X11 support on darwin, and : should provide X11 support on darwin. I was trying to fix on darwin and I found that is marked as broken () because of a missing GKT/X11 header. It seems that it is the same problem that motivated to change Vim to use "gtk2" (same missing header ). Maintainer information:
In that case I'd probably take the discussion upstream.
It was disabled in 3.24.9 by commit , without much explanation. But that commit never landed into master and GTK 4.x does build with X11 support as I understand ( and ).
Code change:
"-Dtests=false" "-Dtracker3=${lib.boolToString trackerSupport}" "-Dbroadway_backend=${lib.boolToString broadwaySupport}" <ins> "-Dx11_backend=${lib.boolToString x11Support}" "-Dquartz_backend=${lib.boolToString (stdenv.isDarwin && !x11Support)}" </ins> ]; doCheck = false; # needs X11

Related discussion:
text: Describe the bug peek fails to build on macOS To Reproduce Clone then Notify maintainers Log
I marked this as stale due to inactivity. &rarr;
sadly its not supported though getting keybinder3 to compile would be good
I marked this as stale due to inactivity. &rarr;
Code change:
hash = "sha256-pve2f+XMfFokMCtW3KdeOJ9Ey330Gwv/dk1+WBtrBEQ="; }; <ins> nativeBuildInputs = [ copyDesktopItems qt5.wrapQtAppsHook ]; buildInputs = [ qt5.qtbase qt5.qtwayland ]; </ins> propagatedBuildInputs = with python3Packages; [ editdistance pyqt5 translitcodec ]; <del> doCheck = false; </del> <ins> dontWrapQtApps = true; </ins> <del> nativeBuildInputs = [ copyDesktopItems qt5.wrapQtAppsHook ]; </del> <ins> preFixup = '' makeWrapperArgs+=("''${qtWrapperArgs[@]}") ''; doCheck = false; </ins> desktopItems = [ (makeDesktopItem {

Related discussion:
text: When trying to run , I am with the following Qt error: I'm fairly new to nix in general, and definitely not familiar enough with the Qt wrapping mechanism. I would expect the derivation to somehow set the "Qt plugin path" (?) properly so that is found upon startup of the application. I've found the section in the NixOS Qt documentation page which recommends using the in your derivation, but as far as I can tell, the derivation ? A dirty workaround I've found is to manually specify as follows, after which the application can be successfully launched: I've looked for a way to patch this properly into 's derivation, but I'm not comfortable enough with nix to figure out how to do this. I've found that other packages such as QGIS do : but it seemed to have no effect in , maybe because the derivation uses , and not ? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Please test
I merged the above PR. please give it a try once it hits the channel you follow:
It works like a charm, many thanks for your fix :heart:
Code change:
mesonFlags = [ "-D systemdunitdir=lib/systemd/user" <del> ]; </del> <ins> ] ++ lib.optional waylandSupport "-Dwl=true"; </ins> passthru.providedSessions = [ "enlightenment" ];

Related discussion:
text: I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
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 .
It would be nice to hear about the recent progress.
Code change:
extraCommands = "mkdir -p proc sys dev"; }; <ins> system.build.installBootLoader = pkgs.writeScript "install-lxd-sbin-init.sh" '' #!${pkgs.runtimeShell} ln -fs "$1/init" /sbin/init ''; </ins> # Add the overrides from lxd distrobuilder # https://github.com/lxc/distrobuilder/blob/05978d0d5a72718154f1525c7d043e090ba7c3e0/distrobuilder/main.go#L630 systemd.packages = [

Related discussion:
text: consider the following which is running inside of a container: and the corresponding system profile: the original produces a store path of now let's modify to add a simple file to : instead of immediately ing to this new configuration, let's set it to activate on : looking at the system profile it looks like everything is in order here... the symlink has been switched appropriately: the new produces a store path of let's , the new profile, and look at the file we to : :thinking: what happened? what does our system profile say? :explodinghead: somehow an additional system generation, the old system generation, was created, symlinked, and activated! additionally worth noting is that + works absolutely fine at this point i'm completely lost :manshrugging: any help? :bowing_man: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --... maybe has run into this before and has some insight because he seems to know what he is doing with running on ? or at least he can confirm whether he has this issue as well? :heart: Please run and paste the result.
I can confirm I'm seeing the same thing. I followed basically the steps you laid out for testing this. Before running , I am on . My profiles look like this: I then run , and I'm now on . I then run , and my profiles look like: I then run and restart the LXC container. After logging back in, I can confirm a new profile has been created and it is pointing to the previous profile for some reason: Although, at this point, if I jump into and look at the nixos version, it does appear to be pointing to the latest NixOS version (which is system-16-link in my example). So this at least looks correct?? I'm not sure I understand exactly the semantics of vs , or how exactly the works. It is not clear to me what is the "correct" thing to happen at each of these steps. edit: Oh, I did a little more digging and I think I know why gives the seemingly correct nixpkgs version.
Code change:
extraCommands = "mkdir -p proc sys dev"; }; <ins> system.build.installBootLoader = pkgs.writeScript "install-lxd-sbin-init.sh" '' #!${pkgs.runtimeShell} ln -fs "$1/init" /sbin/init ''; </ins> # Add the overrides from lxd distrobuilder # https://github.com/lxc/distrobuilder/blob/05978d0d5a72718154f1525c7d043e090ba7c3e0/distrobuilder/main.go#L630 systemd.packages = [

Related discussion:
text: After I've rebooted, still has the correct channel setup: So 's channel does seem like it is setup correctly, it is just the system that is not: Here, you can see that both and are pointed at the previous version (as you would expect from the state of the directory, as shown above).
I should add the following two things: I can also confirm that doing followed by , and then booting the machine back up does get the correct profile setup, as reported.I'm not able to confirm that was ever working for me in my LXC container. Looking at some of my previous system profiles, I see the same Nixpkgs commit hash being reused over and over again (corresponding to the bug you'd expect). It is possible that has never worked in an LXC container. I don't have any ideas here, except that maybe the module is doing something bad?
Thanks for looking and confirming I'm not sure the answer lies in the script... but it is somewhere down that path so I'll ping our expert in case they can take a look and provide any useful insight. I'm also not exactly sure who else to ping specifically about this... so I'll just ping some random people who know a fair bit about the lower levels of NixOS in case they can provide any insight ping
Could you comment the switch-to-configration output as well?
I don't know a lot about lxc, but these unconditional commands look rather suspicious:
Thanks for the comments everyone! I spent a few minutes poking around and found a few things. By commenting out this line the new generation is not created, though + still doesn't activate the new generation. More on that below... The doesn't do much when called via - it . The script, which calls , looks to be as it should. Our module includes which will use to boot the new system... but since we are running this replacement of never happens, which is the cause of the problem here! I confirmed that if I manually replace and reboot everything regarding works as expected. I don't think will execute any code from the module system directly (ie. activation scripts). So how do we teach to run ? I appreciate any and all thoughts on this topic :bowing_man:
I found some time to dig into the depths of how NixOS builds systems and now have the understanding I was missing to solve this problem.
Code change:
, buildEnv, bundler, bundix , libiconv, libobjc, libunwind, Foundation , makeWrapper, buildRubyGem, defaultGemConfig <del> , baseRuby ? buildPackages.ruby.override { </del> <ins> , baseRuby ? buildPackages.ruby_3_1.override { </ins> useRailsExpress = false; docSupport = false; rubygemsSupport = false;

Related discussion:
text: 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 ...) Seems to be a file ordering issue while generating : vs
Looks like this list is generated with the standard Ruby function, which in 2.x leaves the sorting up to the filesystem, but from 3.x onwards itself. So perhaps we should just update to Ruby 3.x. In general 2.7 is in mode, so it will only receive security updates and we should probably plan to move things to 3.x
Code change:
stdenv.mkDerivation rec { pname = "gnunet-gtk"; <del> version = "0.13.1"; </del> <ins> version = "0.14.0"; </ins> src = fetchurl { url = "mirror://gnu/gnunet/${pname}-${version}.tar.gz"; <del> sha256 = "1zdzgq16h77w6ybwg3lqjsjr965np6iqvncqvkbj07glqd4wss0j"; </del> <ins> sha256 = "18rc7mb45y17d5nrlpf2p4ixp7ir67gcgjf4hlj4r95ic5zi54wa"; </ins> }; nativeBuildInputs= [

Related discussion:
text: Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers and edited it last Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I really have no idea, contains it, even bumping gnunet-gtk to be the same release version still doesn't fix it.
Have you tried applying
Code change:
, buildPythonPackage , pythonOlder , fetchFromGitHub <del> , pythonRelaxDepsHook </del> , which # runtime dependencies , numpy , torch <del> , pyre-extensions </del> # check dependencies , pytestCheckHook , pytest-cov

Related discussion:
text: Package name: Latest released version: 0.0.22.post7 <!-- Search your package here: --- Current version on the unstable channel: (This version never existed but whatever!) Current version on the stable/release channel: None <!-- 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. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
let me know if you have time to test
Code change:
version = "14.11.5"; src = fetchurl { <del> url = "http://www.schedmd.com/download/latest/slurm-${version}.tar.bz2"; </del> <ins> url = "http://www.schedmd.com/download/archive/slurm-${version}.tar.bz2"; </ins> sha256 = "0xx1q9ximsyyipl0xbj8r7ajsz4xrxik8xmhcb1z9nv0aza1rff2"; };

Related discussion:
text: Steps to reproduce the behavior: Notable part: @ lines 43..48: Looks like a cmake incompatibility?? possibly connected to ? <!-- 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. system: host os: multi-user?: sandbox: version: channels(root): channels(anna): nixpkgs:
Can you try building it manually against the latest nixpkgs-unstable revision using ?
This is really weird. Looks like something went and replace the first occurrence of in the source files with in . This is how it's supposed to look:
This was already built against the latest at the time, around an hour ago. My system flake registry pins to it. I get the same result with .
this looks completely normal. what is going on?
I have done a bisection and it appears that the first bad commit was
After bisecting Meson, this bug was introduced by and is still present in master.
Yes, I am writing a fix right now
has been merged, but do you think you could make a PR to master to have prismlauncher use its own overriden meson and another PR to staging to undo that change, so that way prismlauncher is at least fixed in the master branch sooner than a few weeks from now and when staging hits master, it won't have that temp fix anymore? Thank you again!
Note that the package that's actually broken here is . But yes using a fixed version of Meson for this sounds like a good idea.
Code change:
"is_clang=${lib.boolToString stdenv.cc.isClang}" "use_sysroot=false" # "use_system_icu=true" <ins> "clang_use_chrome_plugins=false" </ins> "is_component_build=false" "v8_use_external_startup_data=false" "v8_monolithic=true"

Related discussion:
text: Describe the bug Since upgrading v8 to 8.4 () it no longer builds on darwin (at least on my 11.2.3 machine) To Reproduce Steps to reproduce the behavior: Expected behavior A successful v8 build Additional context By default it fails when trying to find the macos sdk, which I patched around with: This then gets as far as , which is avoidable with: which then produces ... and I had to admit defeat. Notify maintainers Metadata Maintainer information:
Hi! Thanks for reporting this! I've opened which I hope fixes this - at least it builds fine for me on 10.15. Please give it a try on your machine too.
Yep, looks good!
Code change:
# See also https://kernelnewbies.org/BuildId sed -i Makefile -e 's|--build-id|--build-id=none|' <del> sed -i scripts/ld-version.sh -e "s|/usr/bin/awk|${buildPackages.gawk}/bin/awk|" </del> <ins> patchShebangs scripts/ld-version.sh </ins> ''; postPatch = ''

Related discussion:
text: The latest major version 5.9 of the Linux kernel . Apparently, zstd compressed things decompress much faster and can cut boot times substantially, hence it seems worthwhile for us to support this scheme. Currently we are using bzip2. Unfortunately, I probably won't find time to work on this myself, but thought to open this issue to track progress.
I've [probably] been using it through a xanmod patch, not recently since the 5.9 release though. What I have in my files are and adding to of the kernel derivation
For the initrd image: For me (which might differ from the stock kernel NixOS provides): is already enabled, so set This enables ZSTD compression for initrd. However, which will need to as mentioned above.
I was wondering if zstd should be made a part of stdenv. are all available in stdenv on linux and with slowly becoming more common by being available in the kernel and used by various distribution's packaging it should make sense to include it.
Can this be closed? Did cover it all?
Yes, it did! Closing this issue. Thank you for pointing that out, didn't notice before.
Code change:
sha256 = "063fg8adx23l4irrh5kn57hsmi1xvjkar4vm4k6g94ppan4hcyw4"; }; <del> patches = ./zenmap.patch; </del> <ins> patches = [ ./zenmap.patch ] ++ optionals stdenv.cc.isClang [( # Fixes a compile error due an ambiguous reference to bind(2) in # nping/EchoServer.cc, which is otherwise resolved to std::bind. # Also fixes a missing include. # https://github.com/nmap/nmap/pull/1363 fetchpatch { url = "https://github.com/nmap/nmap/commit/5bbe66f1bd8cbd3718f5805139e2e8139e6849bb.diff"; sha256 = "088r8ylpc9hachsxs4r17cqfa1ncyspbjvkc573lill7rk1r9m0s"; } )]; </ins> prePatch = optionalString stdenv.isDarwin '' substituteInPlace libz/configure 

Related discussion:
text: broke with the new Darwin stdenv changes. See log file here: This is a bit odd because Homebrew doesn't appear to be doing anything special to compile it:
I think we can use llvm 6 here to fix this. It is weird homebrew doesn’t hit this though. I wonder if the SDKs are still on libcxx 6?
Code change:
, qtmacextras , qmake , spacenavSupport ? stdenv.isLinux, libspnav <ins> , wayland , wayland-protocols , qtwayland </ins> }: mkDerivation rec {

Related discussion:
text: The 'select file' dialog works fine, but I cant actually open or edit anything. Steps to reproduce the behavior: Either: via the GUI, then a design or a design via the command line: A edit window with a preview should appear. Please run and paste the result.
Judging by the error message, this might be as simple as compiling with wayland in the deps like ?
Omg it worked! Can I leave it with the maintainers or do you want me to file a PR?
If you submit the PR yourself then you automatically get ownership/credit for your work :-)
Code change:
libsamplerate, cdrdao, cdrtools, <ins> cdparanoia, </ins> dvdplusrwtools, libburn, <ins> libdvdcss, </ins> normalize, sox, transcode,

Related discussion:
text: fails to find libcdparanoia and flac at runtime. This is a regression from , and appears to be more or less the same issue, except for Plasma 6. Steps to reproduce the behavior: to rip a CD with K3b It works, and lists Flac as a supported format. If applicable, add screenshots to help explain your problem. The fix from should still apply in some form? Manually adding flac to and libcdparanoia to works around the problem. also (maintainer for Plasma 5 K3b) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Please test