jiebi/CodeConvo huggingface dataset:
Change:
pyobihai = callPackage ../development/python-modules/pyobihai { }; <ins> pyocd = callPackage ../development/python-modules/pyocd { }; </ins> pyocr = callPackage ../development/python-modules/pyocr { tesseract = pkgs.tesseract4; };

Discussion:
Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- I will submit a PR shortly once I am back on my laptop.
I'm sorry this took your time. It should be fixed by
Change:
stdenv.mkDerivation rec { name = "duo-unix-${version}"; <del> version = "1.9.11"; </del> <ins> version = "1.9.19"; </ins> src = fetchurl { url    = "https://dl.duosecurity.com/duo_unix-${version}.tar.gz"; <del> sha256 = "0747avzmzzz1gaisahgjlpxyxxbrn04w1mip90lfj9wp2x6a9jgm"; </del> <ins> sha256 = "02hvayknj0kvdik4mqm9j9isqzxk0f992i9v274s27891xqgj8rd"; </ins> }; buildInputs = [ pam openssl zlib ];

Discussion:
the duosec package in nixpkgs is outdated for a security product -- 1.9.11 (Apr 2014), latest is 1.9.19 its related service also can't be enabled it be great if we could fix this by 16.09 cc
Change:
version = "5.6.16775.0418"; srcs = { x86_64-linux = fetchurl { <del> url = "https://zoom.us/client/${version}/zoom_amd64.deb"; sha256 = "1fmzwxq8jv5k1b2kvg1ij9g6cdp1hladd8vm3cxzd8fywdjcndim"; </del> <ins> url = "https://zoom.us/client/${version}/zoom_x86_64.pkg.tar.xz"; sha256 = "twtxzniojgyLTx6Kda8Ej96uyw2JQB/jIhLdTgTqpCo="; </ins> }; }; <del> dontUnpack = true; </del> libs = lib.makeLibraryPath ([ # $ LD_LIBRARY_PATH=$NIX_LD_LIBRARY_PATH:$PWD ldd zoom | grep 'not found'

Discussion:
Describe the bug On my NixOS 20.09, i decided to install from , then I removed it, and tried to reinstall from . However, now i cannot install it from either channel, I get: I tried collecting garbage, rebooting, and I also did but nothing helps. To Reproduce Steps to reproduce the behavior: me, this fails: Expected behavior Should install Zoom. <!-- Screenshots --Additional context Latest Zoom from stable channel was working until I first installed the version from and then removed it. Notify maintainers Metadata Maintainer information:
This was broken with one of the recent channel updates:
Sorry about that. Fix should work from .
Fixed, thanks.
Change:
<ins> { "version": "0.24.1", "platforms": { "aarch64-linux": { "arch": "linux-arm64", "hash": "sha256-TI/bjGqyEZpGDq1F9MBaDypm5XDTlsw9OGd3lIn7JCI=" }, "x86_64-linux": { "arch": "linux-amd64", "hash": "sha256-bmvje439QYivV96fjnEXblYJnSk8C916OwVeK2n/QR8=" }, "x86_64-darwin": { "arch": "darwin-amd64", "hash": "sha256-24odPFqHWQoGXXXDLxvMDjCRu81Y+I5QOdK/KLdeH5o=" } } } </ins>

Discussion:
Project description Fast, typo tolerant, in-memory fuzzy Search Engine for building delightful search experiences. Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin
Change:
sha256 = sha256; }; <del> # Optimizations break compilation of libseccomp c bindings hardeningDisable = [ "fortify" ]; </del> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ makeWrapper removeReferencesTo go-md2man go libtool

Discussion:
Using go + I am unable to build a simple Go program that makes use of C bindings. The program is a testcase from the Go compiler repository ( ) . The build fails with an error message like this: Another example is geth, the go ethereum client, in version 1.6.1: Switching to clang instead seems to be a workaround for the problem: This last command builds successfully. System: (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: Sandboxing enabled: false
I think this has to do with how Go handles GOROOT. It expects to be able to write to $GOROOT even though it's a read-only path. Could you try the buildCommand in go-ethereum:
Aw, I was wondering how to get rid of that warning. The warning is gone, but it doesn't seem to have helped: I originally ran into this issue when I tried to upgrade that linked Nix expression. Version 1.4.7 of go-ethereum compiles just fine, but 1.6.1 doesn't, because now one of the dependencies makes use of some kind of C bindings. While playing around with it I also switched over to using in the Nix expression, but that also didn't help. Switching to clang helped in the end. That version can be found here: But that's just a workaround and I would assume that other Go packages will at some point also run into this problem when they just use or .
I ran into this problem adding seccomp support to the docker package. It's caused by the -O2 optimization flag which is being by the fortify hardening flag. A possible fix would be to add hardeningDisable = [ "fortify" ]; to the buildGoPackage.
I can't no longer reproduce this on my system so I guess the issue is fixed? I created a PR to get rid of the workarounds:
I can confirm that I also cannot reproduce this anymore on my system. I am closing this - thanks!
Change:
keepass-diff = callPackage ../applications/misc/keepass-diff { }; <del> keeweb = callPackage ../applications/misc/keeweb { }; </del> evolution-data-server-gtk4 = evolution-data-server.override { withGtk3 = false; withGtk4 = true; }; evolution-ews = callPackage ../applications/networking/mailreaders/evolution/evolution-ews { }; evolution = callPackage ../applications/networking/mailreaders/evolution/evolution { };

Discussion:
Keeweb opens an empty window, hangs for a few seconds and then the program simply crashes. Looks like a missing libGL dependency. <details<summaryLog without libGL</summary</detailsSteps to reproduce the behavior: Keeweb from Terminal or .desktop file. Keeweb not crashing. Just an empty window with only an icon and title. Can be started with following Command: <details<summaryUsing this overlay to launch it without having to use the terminal.</summary</details<!-- 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:
let cfg = config.services.xserver.windowManager.fvwm; <del> fvwm = pkgs.fvwm.override { gestures = cfg.gestures; }; </del> <ins> fvwm = pkgs.fvwm.override { enableGestures = cfg.gestures; }; </ins> in {

Discussion:
After switching to 21.05, nixos-rebuild switch --upgrade fails: unpacking channels... building Nix... building the system configuration... error: anonymous function at /nix/store/nkr5k3g0ki69d7c2yn19lxd0fyfpnpsa-nixos-21.05.650./nixos/pkgs/applications/window- called with unexpected argument 'gestures', at /nix/store/nkr5k3g0ki69d7c2yn19lxd0fyfpnpsa-nixos- (use '--show-trace' to show detailed location information) The error seems to be triggered by fvwm in my Here is a stripped down version that still triggers the error on a virtual machine: { config, pkgs, lib, ... }: { imports = [ # Include the results of the hardware scan. ./hardware- ]; # Boot and Kernel # =============== # Use the GRUB 2 boot loader. = true; = 2; = true; = "/dev/disk/by-id/ata-VBOXHARDDISKVB576b20e2-"; # or "nodev" for efi only boot.supportedFilesystems = [ "zfs" ]; boot.extraModprobeConfig = '' options zfs zfsarcmax= ''; networking.hostId = ""; # Localization # ============ # Select internationalisation properties. = "Lat2-Termnus16"; console.keyMap = "de"; i18n = { defaultLocale = "enUS.UTF-8"; }; # Set your time zone. time.timeZone = "Europe/Berlin"; # Enable the X11 windowing system. services.xserver = { enable = true; layout = "de"; xkbModel = "pc105"; xkbVariant = "nodeadkeys"; = true; }; # Packages # ======== environment.systemPackages = with pkgs; [ # should be present when init scripts for users run zsh screen home-manager ]; # User management # =============== users.mutableUsers = true; # Version # ======= # This value determines the NixOS release with which your system is to be # compatible, in order to avoid breaking some software such as database # servers. You should change this only after NixOS release notes say you # should.

system.stateVersion = "20.03"; # Did you read the comment? } To Reproduce Steps to reproduce the behavior: to the channel nixos-21.05 nixos-rebuild switch --upgrade Expected behavior A clear and concise description of what you expected to happen. The system should upgrade. Metadata Please run and paste the result. these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/lp90qhw19dcp79cnlicjg09llgh7dzsz-bash-interactive-4.4-p23-dev copying path '/nix/store/lp90qhw19dcp79cnlicjg09llgh7dzsz-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): channels(bux): nixpkgs:
changed the argument name but forgot to update the nixos module at cc
I have exactly the same problem, is there any workaround? Is it safe to change this manually?
Change:
# wait for reader to be ready machine.wait_for_file("${readyFile}") <del> machine.sleep(1) </del> # send all keys for key in inputs:

Discussion:
The dvorak test is failing. Build Copy of the log Dvorak works, test works, channel progresses. If applicable, add screenshots to help explain your problem. Test has no maintainers. Please run and paste the result.
All keymap tests have been flaky for quite a long time. I don't know why. Restarting them helps, e.g. the build linked above succeeded on the second attempt.
Speaking of blockers here's a current one:
You don't happen to know the rough time frame when they became flaky?
No, I can't recall. Practically it became worse because shortly before 22.11 we to standard jobs, so the number of keymap tests doubled.
Yeah, I can see why this gets a lot more annoying. Is the flakiness exclusively for the -tests or the -ones as well?
Tried to reproduce it via the following (mainly for myself as a reference when switching locations) and didn't get a single failure after several runs: I'm guessing that the build nodes were on high load, so need to employ a different strategy...
We might run smaller amount of them; that should be easy. I don't know why it's useful to run it on so many keymaps.
Or a larger amount with more logging so we can find the cause.
Also not all hardware is equal. Maybe keep track of hostnames?
I've found a fix that runs the test dozens of times without issue on a machine that otherwise reproduces the issue fairly reliably.
Change:
rm "$link" makeWrapper "$target" "$link"  --prefix PATH : "$out/bin:${perl}/bin"  <del> --prefix PERL5LIB : "$PERL5LIB" </del> <ins> --prefix PERL5LIB : "$PERL5LIB"  --set-default TEXMFCNF "$TEXMFCNF" </ins> # avoid using non-nix shebang in $target by calling interpreter if [[ "$(head -c 2 "$target")" = "#!" ]]; then

Discussion:
Describe the bug A behaviour I'm observing on my Nix machines is that dvipng takes a long time to render the image from , about 9 times slower than imagemagick. To Reproduce the packages: a test latex file: the file: the benchmarks: Expected behavior Expect to be as performant as . Additional context This behaviour is observed because in previewing Emacs latex fragments, is the default command used, and I've noticed this to be significantly slower than on other distros. Additional Information Not sure if this is related, but I'm seeing: perhaps dvipng is performing some extra work, making it slow. Any way to make this go away? Metadata system: host os: multi-user?: sandbox: version: channels(jethro): nixpkgs:
I can reproduce this: Do you think you could bring this up with the upstream?
glad to see I'm not the only one, had run a similar benchmark though and he can't reproduce this, so I'm unsure if it's an upstream issue.
Maybe you could run dvipng under "strace -rf" to see if any specific filesystem activity eats up the time?
I'm not too familiar on how to read , but here's the summary:
I think the cited invocation produces a lower-resolution image. The timestamps in the strace output seem to be too low for a 1-second process. Interesting…
This is a result on RHEL7-like system:
From eyeballing the stdout of the command, it seems a lot of time is spent on : I'm not sure how to proceed further with the diagnosis.
Change:
, lib , buildPythonApplication , fetchFromGitHub <del> # python requirements </del> <ins> , fetchpatch # python requirements </ins> , beautifulsoup4 , boto3 , faker

Discussion:
Steps to reproduce the behavior: as my Nix starter template for macOS - uses home-manager and nix-darwin. , which causes some kind of build failure with visidata. (Previously visitdata seemed to be working correctly - however, I recently ran a - and it seems to have been broken for the last week or so). I've uploaded the build logs () as a gist here: 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. I get this error when I try to run this command: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Looking at the build log, that is a failing test from visidata itself, where something is wrong with the number having a different value vs So that should hopefully be fixed upstream
Forwarded the issue upstream:
Well, that's what it looked like at first to my naive eyes (a failing test). However, it didn't make sense because it's Visidata 3.0.2 - which was released back in January 2024. Also, if I look at the Nix visidata package - there's been no changes in 6 months. And I could have sworn visidata was working for me last week or so, before I ran since then...although maybe I'm mistaken...
Could be a floating point number issue. I spoke too soon, seems like it also affects x86_64-linux on Hydra:
Hi Do you, by any chance have set to anything?
Thinking about it, in nixpkgs has switched from to last month. I managed to reproduce the issue locally as well, confirming that something changed between those versions of Python. This failure seems to be happening only with Python 3.12.4. The test suite passes fine with Python 3.11.9 however. The failing tests are: describe-error describe edit-type All failing the same way with the number rounding. The tests are executed in a sandboxed environment with Nix, so user config should not affect those.
That gives me the info to address this!
This is fixed upstream.
Thanks and =).

Quick question for a Nix newbie - if I'm currently using nixpkgs-unstable (default on the I'm using) - but Visidata hasn't cut a new release yet with this fix just yet - and nixpkgs is using 3.0.2 () - is there an easy way to have it build from the visidata develop branch instead? Or is it just a case of waiting for the next visidata release, and then also for the nixpkgs to get updated?
We'll try to update the package here asap, which shouldn't take too long since a new release is currently "in the works" on upstream's side. In the meantime, since the compatibility issue only seems to be within the tests, you can keep using the current stable version, simply skipping the test phase with something like: . You can also override the attribute the same way as above to override the source to use the develop branch if desired.
Change:
--replace 'protected String compilerCommand = "cc";' 'protected String compilerCommand = "${stdenv.cc}/bin/cc";' # prevent cyclical imports caused by identical <include> names substituteInPlace sulong/projects/com.oracle.truffle.llvm.libraries.bitcode/include/stdlib.h  <del> --replace '# include <cstdlib>' '# include "${stdenv.cc.cc}/include/c++/${stdenv.cc.cc.version}/cstdlib"' </del> <ins> --replace '# include <cstdlib>' '# include "${stdenv.cc.cc}/include/c++/${lib.getVersion stdenv.cc.cc}/cstdlib"' </ins> # dragonegg can't seem to compile on nix, so let's not require it substituteInPlace sulong/mx.sulong/suite.py  --replace '"requireDragonegg" : True,' '"requireDragonegg" : False,'

Discussion:
Describe the bug To Reproduce Metadata
In darwin building graalvm results in:
Which version of Nixpkgs is this? Please use the template...
sorry I overlooked the metadata; updated it now;
Change:
{ stdenv, fetchurl, gmp, mpfr, libmpc, zlib, avrbinutils, texinfo }: let <del> version = "5.4.0"; </del> <ins> version = "7.3.0"; </ins> in stdenv.mkDerivation { name = "avr-gcc-${version}"; src = fetchurl { <del> url = "mirror://gcc/releases/gcc-${version}/gcc-${version}.tar.bz2"; sha256 = "0fihlcy5hnksdxk0sn6bvgnyq8gfrgs8m794b1jxwd1dxinzg3b0"; </del> <ins> url = "mirror://gcc/releases/gcc-${version}/gcc-${version}.tar.xz"; sha256 = "0p71bij6bfhzyrs8676a8jmpjsfz392s2rg862sdnsk30jpacb43"; </ins> }; patches = [

Discussion:
A goal of mine for 18.09 is to get rid of some legacy cross compilation stuff. We can now use "crossSystem" to accomplish the same thing. [x] pkgs/development/compilers/arm-frc-linux-gnueabi-gcc/ [ ] pkgs/development/misc/avr/ [ ] pkgs/development/compiler/gcc-arm-embedded/ [ ] pkgs/development/compilers/mentor/ We want to make sure we have easy alternatives for the above. This might include providing aliases if they are needed. Also we might want to have Hydra build toolchains for AVR and ARM embedded.
I another entry: pkgs/development/compilers/mentor/. (Currently holds two old ARM toolchains.)
Change:
stdenv.mkDerivation (finalAttrs: { pname = "juce"; <del> version = "7.0.7"; </del> <ins> version = "7.0.9"; </ins> src = fetchFromGitHub { owner = "juce-framework"; repo = "juce"; rev = finalAttrs.version; <del> hash = "sha256-r+Wf/skPDexm3rsrVBoWrygKvV9HGlCQd7r0iHr9avM="; </del> <ins> hash = "sha256-k8cNTPH9OgOav4dsSLqrd5PlJ1rqO0PLt6Lwmumc2Gg="; </ins> }; patches = [

Discussion:
Package name: juce Latest released version: 7.0.9 Current version on the unstable channel: 7.0.7 Current version on the stable/release channel: 7.0.7 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]:
Change:
<ins> # Remove mimeinfo cache mimeinfoPreFixupPhase() { rm -f $out/share/applications/mimeinfo.cache } preFixupPhases="$preFixupPhases mimeinfoPreFixupPhase" </ins>

Discussion:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .
Change:
<ins> diff --git a/compiler/modulepaths.nim b/compiler/modulepaths.nim index e80ea3fa6..8ecf27a85 100644 --- a/compiler/modulepaths.nim +++ b/compiler/modulepaths.nim @@ -70,6 +70,13 @@ proc checkModuleName*(conf: ConfigRef; n: PNode; doLocalError=true): FileIndex = else: result = fileInfoIdx(conf, fullPath) +proc rot13(result: var string) = +  for i, c in result: +    case c +    of 'a'..'m', 'A'..'M': result[i] = char(c.uint8 + 13) +    of 'n'..'z', 'N'..'Z': result[i] = char(c.uint8 - 13) +    else: discard + proc mangleModuleName*(conf: ConfigRef; path: AbsoluteFile): string = ## Mangle a relative module path to avoid path and symbol collisions. ## @@ -78,9 +85,11 @@ proc mangleModuleName*(conf: ConfigRef; path: AbsoluteFile): string = ## ## Example: ## `foo-#head/../bar` becomes `@foo-@hhead@s..@sbar` -  "@m" & relativeTo(path, conf.projectPath).string.multiReplace( +  result = "@m" & relativeTo(path, conf.projectPath).string.multiReplace( {$os.DirSep: "@s", $os.AltSep: "@s", "#": "@h", "@": "@@", ":": "@c"}) +  rot13(result) proc demangleModuleName*(path: string): string = ## Demangle a relative module path. result = path.multiReplace({"@@": "@", "@h": "#", "@s": "/", "@m": "", "@c": ":"}) +  rot13(result) diff --git a/compiler/msgs.nim b/compiler/msgs.nim index 3f386cc61..054f7f647 100644 --- a/compiler/msgs.nim +++ b/compiler/msgs.nim @@ -659,8 +659,10 @@ proc uniqueModuleName*(conf: ConfigRef; fid: FileIndex): string = for i in 0..<trunc: let c = rel[i] case c -    of 'a'..'z': -      result.add c +    of 'a'..'m': +      result.add char(c.uint8 + 13) +    of 'n'..'z': +      result.add char(c.uint8 - 13) of {os.DirSep, os.AltSep}: result.add 'Z' # because it looks a bit like '/' of '.': </ins>

Discussion:
Nim programs contain a full-path reference to the Nim standard library, which pulls the Nim compiler into the programs' store closure. Steps to reproduce the behavior: nix path-info -rsSh nixpkgs#nimPackages.c2nim less nix path-info -rsSh nixpkgs#nimmm | sort -nk3
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
biber = callPackage ../tools/typesetting/biber { }; <ins> biber-for-tectonic = callPackage ../tools/typesetting/tectonic/biber.nix { }; </ins> biber-ms = callPackage ../tools/typesetting/biber-ms { }; biblatex-check = callPackage ../tools/typesetting/biblatex-check { };

Discussion:
Describe the bug Reproduction  Expected behavior No errors Notify maintainers Metadata Maintainer information:
The version of biber that we ship corresponds to . ships with texlive 2018 (tectonic-typesetting/tectonic-staging). And doesn't yet have a builtin solution for biber tectonic-typesetting/tectonic. You can try overriding biber to version 2.11, which should be compatible. cc as maintainer of
I would also appreciate a fix for this. I tried overriding to version 2.11, but that didn't help (similar version incompatibility), at least not on the current unstable channel or on 20.03 to match with the date of message. The version in the current derivation seems to be 3.3, which dates back to 2016, so it looks like updating would make more sense.
I marked this as stale due to inactivity. &rarr;
I've just encountered this issue too.
Which version of nixpkgs are you using? What is the output of:
Currently biber expects while nixpkgs (as well as texlive) contains . For me the override suggested in works with no issue; e.g. with home-manager: Although this works on my end, I hope this could be upstreamed to nixpkgs itself so that we can make use of the hydra cache with no need to locally rebuild tectonic; cc maintainers: Thank you very much!
Tectonic is tracking this issue in . In general, we sort of rely on Tectonic's bundles to follow texlive releases. That's why we don't embed such hardcoding of the version in Tectonic - since Tectonic could update it's bundle without an update to Tectonic itself, which could fix such an issue if it arises after a Tectonic release. Perhaps also the following Tectonic nixpkgs update will help:
Indeed... Is it then possible to create some package without the dependency, so that we can install the appropriate versions of and separately, without the need to recompile the package? :thinking: Thanks!
You have a point. I was the one who introduced the wrapping of with in ... I tend to think now that it shouldn't be that way, especially with this frequent issue of incompatibility. I pushed that as well to .

Wow nice! Thank you very much!
I have hence created a wrapper so that one can combine the two into a single package, where the -specific biber is renamed to prevent conflict with the texlive biber: I am far from proficient in nix, so the package is created following along with the previous revision of . It can be used e.g. as an override: I don't know whether it's good to upstream this or not. In any case, I think it may be useful to others like me, so it would be good to share this here haha.
Update: I am now trying to upstream a more polished solution via . would you be interested in a review? :pleading_face: The PR will close this issue.
Change:
meta = with stdenv.lib; { description = "Print, scan and fax HP drivers for Linux"; homepage = http://hplipopensource.com/; <ins> downloadPage = https://sourceforge.net/projects/hplip/files/hplip/; </ins> license = if withPlugin then licenses.unfree else with licenses; [ mit bsd2 gpl2Plus ];

Discussion:
Printing with a HP Color LaserJet printer fails due to a crash in the filter when using the driver "hpcups 3.19.1" With the "CUPS+Gutenprint v5.2.14" driver printing works. Try to print anything, a test page would do Please run and paste the results. oops.. let's try again:
I'm having the same problem, and made some observations: hplip 3.18.5 (used in release-18.09) works, even if compiled with pkgs from release-19.03 Here's a bug report with a proposed patch: is probably here: I didn't come around to test any of those patches thoug as I have only very limited access to my HP printer.