jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { stdenv, pkgs, lib , libXNVCtrl }: let mangohud_64 = pkgs.callPackage ./default.nix { inherit libXNVCtrl; }; mangohud_32 = pkgs.pkgsi686Linux.callPackage ./default.nix { inherit libXNVCtrl; }; in pkgs.buildEnv rec { name = "mangohud-${mangohud_64.version}"; paths = [ mangohud_32 ] ++ lib.optionals stdenv.is64bit [ mangohud_64 ]; meta = mangohud_64.meta; } </ins>

Related discussion:
text: Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. &rarr;
Still important to me.
Code change:
buildInputs = [ gnupg ]; <del> doCheck = true; </del> <ins> # https://github.com/NixOS/nixpkgs/issues/134445 doCheck = !stdenv.isDarwin && stdenv.isx86_64; </ins> checkInputs = [ expect

Related discussion:
text: blackbox-2.0.0 fails to build with test failures. Steps to reproduce the behavior: -env -i blackbox blackbox builds Please run and paste the result.
Don't really know why this would fail on darwin
fails on aarch64-linux but for a different reason
Code change:
open-meteo = callPackage ../development/python-modules/open-meteo { }; <ins> openai-whisper = callPackage ../development/python-modules/openai-whisper { }; </ins> openant = callPackage ../development/python-modules/openant { }; openapi-schema-validator = callPackage ../development/python-modules/openapi-schema-validator { };

Related discussion:
text: Project description Whisper is a general-purpose speech recognition model. It is trained on a large dataset of diverse audio and is also a multi-task model that can perform multilingual speech recognition as well as speech translation and language identification. Metadata homepage URL: source URL: license: mit platforms: all
PTAL.
Code change:
sha256 = "sha256-BX3kc629FOh5cnD6Sa/69wKdhmhT3Rpz5ZvhnD4MclQ="; }; <ins> patches = [ (fetchpatch { # fix #295002 (segfault on AMD), will be in the release after 0.8.0 name = "fix crash on AMD"; url = "https://github.com/mchehab/rasdaemon/commit/f1ea76375281001cdf4a048c1a4a24d86c6fbe48.patch"; hash = "sha256-1VPDTrAsvZGiGbh52EUdG6tYV/n6wUS0mphOSXzran0="; }) ]; </ins> nativeBuildInputs = [ autoreconfHook pkg-config ]; buildInputs = [

Related discussion:
text: For some reason, rasdaemon doesn't work. dmesg: systemctl: Steps to reproduce the behavior: rasdaemon should work. Unfortunately, ras-mc-ctl doesn't check if the daemon is working so it took me some time to discover that the daemon actually doesn't work. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
perhaps some build-time hardening is messing with it?
Looks like the latest tagged version is broken on AMD because it doesn't include Now I'm running from the latest commit and it works fine
oh, thanks for finding a solution! i'll open a PR with that patch in a few hours unless you beat me to it :)
adds that patch
Code change:
# symlink other core stuff ln -s /host/etc/localtime localtime <ins> ln -s /host/etc/zoneinfo zoneinfo </ins> ln -s /host/etc/machine-id machine-id ln -s /host/etc/os-release os-release

Related discussion:
text: is meant to show the current timezone. It doesn't. (I have some reason to believe that this is connected to Steam game failures, but still working on that. In any case...) Set time.timeZone to anything other than UTC. Rebuild your system. Run The output will be in UTC, with no timezone shown: lists only UTC. System: 17.03pre92039. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 17.03pre92039.
I think this is because of this line: We can patch this to not check prefix, but still wouldn't work. For discoverability of timezones we can add to and look for them in but I'm not sure this is a good idea.
See ,
Code change:
<del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchFromGitHub , nix-update-script , pantheon , pkg-config <del> , vala_0_46 </del> <ins> , vala </ins> , cmake , ninja , gtk3

Related discussion:
text: Describe the bug To Reproduce Steps to reproduce the behavior: Expected behavior no fail Additional context it seem to be fixed upstream, but no new release it made yet Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Code change:
, pycountry , pytestCheckHook , python-dateutil <ins> , python-jose </ins> , pythonOlder , pyyaml , requests

Related discussion:
text: When used through the command line, complains about imports and fails. <!-- 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]:
I've opened but haven't had the time to test it quite yet. If you get around to it before me feel free to merge it
I suggest another fix in
Code change:
{ lib , buildPythonPackage <del> , fetchPypi </del> <ins> , fetchFromGitHub </ins> , selenium <ins> , six </ins> , flask <del> , coverage </del> <ins> , pytestCheckHook </ins> }: buildPythonPackage rec { pname = "splinter"; version = "0.14.0"; <del> src = fetchPypi { inherit pname version; sha256 = "459e39e7a9f7572db6f1cdb5fdc5ccfc6404f021dccb969ee6287be2386a40db"; </del> <ins> src = fetchFromGitHub { owner = "cobrateam"; repo = "splinter"; rev = version; sha256 = "0480bqprv8581cvnc80ls91rz9780wvdnfw99zsw44hvy2yg15a6"; </ins> }; <del> propagatedBuildInputs = [ selenium ]; </del> <ins> propagatedBuildInputs = [ selenium six ]; </ins> <del> checkInputs = [ flask coverage ]; </del> <ins> checkInputs = [ flask pytestCheckHook ]; </ins> <del> # No tests included doCheck = false; </del> <ins> disabledTestPaths = [ "samples" "tests/test_djangoclient.py" "tests/test_flaskclient.py" "tests/test_webdriver.py" "tests/test_webdriver_chrome.py" "tests/test_webdriver_firefox.py" "tests/test_webdriver_remote.py" "tests/test_zopetestbrowser.py" ]; </ins> <del> meta = { </del> <ins> pythonImportsCheck = [ "splinter" ]; meta = with lib; { </ins> description = "Browser abstraction for web acceptance testing"; homepage = "https://github.com/cobrateam/splinter"; <del> license = lib.licenses.bsd3; </del> <ins> license = licenses.bsd3; maintainers = with maintainers; [ dotlambda ]; </ins> }; }

Related discussion:
text: Describe the bug I cannot install anything that depends on splinter (such as searx), as it doesn't seem cached and fails to build To Reproduce Steps to reproduce the behavior: Additional context this was on nixos-unstable ()
Code change:
This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing). <ins> #### HTML Inlining HTML is not allowed. Parts of the documentation gets rendered to various non-HTML formats, such as man pages in the case of NixOS manual. </ins> #### Roles If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``. The references will turn into links when a mapping exists in [`doc/manpage-urls.json`](./manpage-urls.json).

Related discussion:
text: Contributors working on improving the nixpkgs manual would be redirected to the . This section is not up-to-date with all the syntax features supported by , forcing contributors to look for use examples over the whole manual. The same markdown syntax is used to write and generate the NixOS manual. However, this manual does not make any mention of the supported syntax. This makes it hard to contribute to the NixOS manual with relative isolation from the nixpkgs manual. Update in Nixpkgs manual to include reference material and examples on all the syntax features supported by . Link in Nixos manual for completion. [x] remove references to in the . : [x] remove references to in the . [x] add a redirecting to the syntax section in . [x] add reference to lack of support for [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support () () )
Code change:
buggyBiosCDSupport = config.grub.buggyBiosCDSupport or true; }; <del> grub2 = callPackage ../tools/misc/grub/2.0x.nix { libusb = libusb1; }; </del> <ins> grub2 = callPackage ../tools/misc/grub/2.0x.nix { libusb = libusb1; flex = flex_2_5_35; }; </ins> grub2_efi = grub2.override { EFIsupport = true; };

Related discussion:
text: grub fails with nixos-rebuild switch -I nixpkgs=/home/lethal/nixpkgs
The issue title here is highly uninformative, which is why I didn't find this when checking for duplicates. :P
Code change:
# Generate the swapDevices option from the currently activated swap # devices. <del> my @swaps = read_file("/proc/swaps"); shift @swaps; </del> <ins> my @swaps = read_file("/proc/swaps", err_mode => 'carp'); </ins> my @swapDevices; <del> foreach my $swap (@swaps) { $swap =~ /^(S+)s/; next unless -e $1; my $dev = findStableDevPath $1; push @swapDevices, "{ device = "$dev"; }"; </del> <ins> if (@swaps) { shift @swaps; foreach my $swap (@swaps) { $swap =~ /^(S+)s/; next unless -e $1; my $dev = findStableDevPath $1; push @swapDevices, "{ device = "$dev"; }"; } </ins> }

Related discussion:
text: I'm reporting this for a friend of mine who wanted to install NixOS and ran into this issue. I hope that's okay. The problem is: fails if you have in your host's kernel config (which, I think, is reasonable if you're compiling it yourself and don't need swap). I took a cursory look into and saw that it reads from . This fails, apparently, because the file doesn't exist on systems without swap support. Can this be easily fixed by assuming there are no swap devices if the file cannot be found?
I'd say already assume this, but don't handle it gracefully.
Code change:
owner = "xianyi"; repo = "OpenBLAS"; rev = "v${version}"; <del> sha256 = "174id98ga82bhz2v7sy9yj6pqy0h0088p3mkdikip69p9rh3d17b"; </del> <ins> sha256 = "0mk1kjkr96bvvcq2zigzjrs0cnhwsf6gfi0855mp9yifn8lvp20y"; </ins> }; inherit blas64;

Related discussion:
text: Describe the bug On current nixos-unstable Scipy fails to build with a segmentation fault during testing: To Reproduce Steps to reproduce the behavior: the following as Expected behavior Should not segfault during test. Additional context SciPY seems to build just fine on current 20.03 release. Notify maintainers cc , Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(ente): nixpkgs:
Also fails with
Particular stacktrace is:
I believe the fix is contained in: and upstream tracking issue is: and Debian issue:
Opened to bump openblas to a version with that fix
fixes this for me - can you confirm?
builds for me
Works, thanks!
This still affects . Is there a simple fix we can backports (either in nixpkgs, or here locally)?
Backport openblas updates:
Thanks, I’ll try that. Would such a backport be eligible to go to ?
I don't really do backports, but since it fixes something known to be broken I assume it would be fine.
Pull request should target not .
Code change:
cp -R "usr/share" "$out/share" chmod -R g-w "$out" <del> # Wrap the startup command makeBinaryWrapper $out/opt/ArmCord/armcord $out/bin/armcord  </del> <ins> # use makeShellWrapper (instead of the makeBinaryWrapper provided by wrapGAppsHook3) for proper shell variable expansion # see https://github.com/NixOS/nixpkgs/issues/172583 makeShellWrapper $out/opt/ArmCord/armcord $out/bin/armcord  </ins> "''${gappsWrapperArgs[@]}"  --prefix XDG_DATA_DIRS : "${gtk3}/share/gsettings-schemas/${gtk3.name}/"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform=wayland --enable-features=UseOzonePlatform --enable-features=WebRTCPipeWireCapturer }}" 

Related discussion:
text: ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- 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]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.
Code change:
- Type should be appropriate (string related types differs in their merging capabilities, `optionSet` and `string` types are deprecated). - Description, default and example should be provided. - Ensure that option changes are backward compatible. <del> - `mkRenamedOptionModule` and `mkAliasOptionModule` functions provide way to make option changes backward compatible. </del> <ins> - `mkRenamedOptionModuleWith` provides a way to make option changes backward compatible. </ins> - Ensure that removed options are declared with `mkRemovedOptionModule` - Ensure that changes that are not backward compatible are mentioned in release notes. - Ensure that documentations affected by the change is updated.

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
Code change:
<ins> { stdenv, lib, fetchFromGitHub, cmake }: stdenv.mkDerivation rec { pname = "dht"; version = "0.25"; src = fetchFromGitHub { # Use transmission fork from post-0.25-transmission branch owner = "transmission"; repo = pname; rev = "25e12bb39eea3d433602de6390796fec8a8f3620"; sha256 = "fksi8WBQPydgSlISaZMMnxzt4xN7/Hh7aN6QQ+g/L7s="; }; nativeBuildInputs = [ cmake ]; meta = with lib; { description = "BitTorrent DHT library"; homepage = "https://github.com/transmission/dht"; license = licenses.mit; maintainers = with maintainers; [ angustrau ]; platforms = platforms.unix; }; } </ins>

Related discussion:
text: Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:
Code change:
, callPackage , coreutils , curl <ins> , docbook_xsl_ns , docbook5 </ins> , editline , flex , gnutar

Related discussion:
text: Package name: nix23 Latest released version: 2.3.17 (see ) Current version on the unstable channel: 2.3.16 Current version on the stable/release channel: 2.3.16 Notify maintainers Note for maintainers: Please tag this issue in your PR. See for context. The release script apparently doesn't upload source tarballs anymore, so 2.3.17 sources look more like the other ones. There's a bunch of expressions in that might need to be revisited.
Code change:
eternity = callPackage ../games/doom-ports/eternity-engine { }; <del> gzdoom = callPackage ../games/doom-ports/gzdoom { }; </del> odamex = callPackage ../games/doom-ports/odamex { }; prboom-plus = callPackage ../games/doom-ports/prboom-plus { };

Related discussion:
text: I'm trying to use GZDoom, but the Vulkan backend isn't working. No errors, but it will silently fall back to OpenGL. Apparently this is the case if GZDoom can't find the correct Vulkan drivers. I have a Radeon RX 5700 XT, so my GPU definitely supports Vulkan. Steps to reproduce the behavior: basic without any mods <kbdesc</kbdthen <kbd~</kbdAt the end of its loading it should say what renderer it is using This is a screenshot of it running with Vulkan from someone else's system: ! This is a screenshot of what it looks like when it's using OpenGL: ! Note the lines. GZDoom uses Vulkan Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
outputs = [ "out" "dev" ]; <del> preConfigure = '' patchShebangs ./bootstrap ./bootstrap ''; </del> <ins> nativeBuildInputs = [ cmake libtool ]; </ins> depsBuildBuild = [ buildPackages.stdenv.cc ]; <del> nativeBuildInputs = [ automake autoconf libtool which ]; NIX_CFLAGS_LINK = "-pthread"; patches = [ ./cross.patch ]; </del> <ins> patches = [ ./cross.patch ]; </ins> # fails 1 out of 1 tests with # "lt-ImathTest: testBoxAlgo.cpp:892: void {anonymous}::boxMatrixTransform(): Assertion `b21 == b2' failed"

Related discussion:
text: Describe the bug build of OpenEXR fails to find -lImath24 To Reproduce Expected behavior Successful build. Screenshots Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: Maintainer information:
Something seems to be mangling the library names incorrectly? The ilmbase package contains: Notice the periods.
cc.
I lack the hardware to debug this. any ideas?
Repro'd on 10.14
seems to indicate that autoconf-based builds are only supported on linux - we may want to switch this to cmake. Building outside of nix via cmake is working fine for me.
can you give a try?
I can confirm this still builds on at least.
appears to fix this for me (macos 10.14). Reopen if it's still a problem for you.
Code change:
scipy ]; <del> pythonImportsCheck = [ "pymatting" ]; </del> nativeCheckInputs = [ pytestCheckHook ]; <ins> pythonImportsCheck = [ "pymatting" ]; </ins> disabledTests = [ # no access to input data set # see: https://github.com/pymatting/pymatting/blob/master/tests/download_images.py

Related discussion:
text: Steps to reproduce the behavior: python311Packages.pymatting Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
{ spellChecking ? true <del> , stdenv, fetchurl, pkgconfig, gtk2, gtkspell2 ? null , perl, pcre, gmime, gettext, intltool, dbus-glib, libnotify </del> <ins> , stdenv, fetchurl, pkgconfig, gtk3, gtkspell3 ? null , perl, pcre, gmime2, gettext, intltool, itstool, libxml2, dbus-glib, libnotify, gnutls , makeWrapper, gnupg , gnomeSupport ? true, libgnome-keyring3 </ins> }: <del> assert spellChecking -> gtkspell2 != null; </del> <ins> assert spellChecking -> gtkspell3 != null; </ins> <del> let version = "0.139"; in </del> <ins> let version = "0.144"; in </ins> stdenv.mkDerivation { name = "pan-${version}"; src = fetchurl { url = "http://pan.rebelbase.com/download/releases/${version}/source/pan-${version}.tar.bz2"; <del> sha256 = "1fab2i6ngqp66lhls0g7j8d1c1rk75afiqr3r1x2sn3zk47k4pxz"; </del> <ins> sha256 = "0l07y75z8jxhbmfv28slw81gjncs7i89x7fq44zif7xhq5vy7yli"; </ins> }; <del> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ gtk2 perl gmime gettext intltool dbus-glib libnotify ] ++ stdenv.lib.optional spellChecking gtkspell2; </del> <ins> nativeBuildInputs = [ pkgconfig makeWrapper ]; buildInputs = [ gtk3 perl gmime2 gettext intltool itstool libxml2 dbus-glib libnotify gnutls ] ++ stdenv.lib.optional spellChecking gtkspell3 ++ stdenv.lib.optional gnomeSupport libgnome-keyring3; configureFlags = [ "--with-dbus" "--with-gtk3" "--with-gnutls" "--enable-libnotify" ] ++ stdenv.lib.optional spellChecking "--with-gtkspell" ++ stdenv.lib.optional gnomeSupport "--enable-gkr"; postInstall = '' wrapProgram $out/bin/pan --suffix PATH : ${gnupg}/bin ''; </ins> enableParallelBuilding = true;

Related discussion:
text: The pan-0.139 package builds without gpg2, and as a result it produces a segmentation fault: The steps to reproduce happen to be the example from the "Managing Build Environments" section of the Nix guide:
I can reproduce, investigating. Update is available (139 -144) so exploring that as well.
Hi, thanks!
Code change:
}@args: let <del> basicEnv = (callPackage ../bundled-common {}) args; </del> <ins> basicEnv = (callPackage ../bundled-common { inherit ruby; }) args; </ins> cmdArgs = removeAttrs args [ "pname" "postBuild" "gemConfig" "passthru" "gemset" "gemdir" ] // { inherit preferLocalBuild allowSubstitutes; # pass the defaults

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