jiebi/CodeConvo huggingface dataset:
Change:
directx-headers = callPackage ../development/libraries/directx-headers {}; <del> directx-shader-compiler = callPackage ../tools/graphics/directx-shader-compiler {}; </del> <ins> directx-shader-compiler = callPackage ../tools/graphics/directx-shader-compiler { # https://github.com/NixOS/nixpkgs/issues/216294 stdenv = if stdenv.cc.isGNU && stdenv.isi686 then gcc11Stdenv else stdenv; }; </ins> dkimproxy = callPackage ../servers/mail/dkimproxy { };

Discussion:
Similar to Hydra now, I'm having issues with with i686 This is used for x86_64 to get the drivers to run Steam and other older games. Building from as I have for months while I wait for + because I need to turn off the broken build flag. Maybe one day it will get reviewed and merged in and I can go back to unstable. Please run and paste the result.
I bisected it to commit
What is "it"? I'm not sure what you mean or what I should do/try with .
That was just a note that introduced that regression. builds fine before that commit, but does not build with that commit. It would probably build if you revert that commit, but you’d have to rebuild the world, so I can’t recommend that. So, no fix at this point. You can switch to a commit before , if you need a working 32-bit amdvlk. cc
I don't know enough about amdvlk to be able to do anything with this information.
The comment in gpurt doesn't help much: LTO is disabled by default in directx-shader-compiler, and the other cmake option is already set. I noticed that at least in my case is segfaulting when building 32-bit : I don't understand graphic drivers plumbing or what's going on in that build, but thanks to bisect I tried to just build 32-bit directx-shader-compiler with older gcc and it builds now (it also builds gcc11, but it's still better than a failing build). Here's the overlay:
I experience the same problem:
amdvlk is enabled by default if you're using nixos-hardware AMD modules, and figuring that out isn't entirely obvious for newer NixOS users.
Not since
Not sure what exactly you are talking about, but this problem only happens with 32-bit amdvlk. The 64-bit one builds/works just fine.
Steam enables 32bit support here
Overriding the compiler is no longer necessary .
32-bit is broken again now for me.
's overlay is working however
Weird; I tested building without the overlay and that worked for me, and passed as well. Do you have any idea where the difference might come from?

I can’t say I know what the differences are but I can tell you that I pulled the latest unstable into my and when I ran tried to build, and then failed. If we peek Hydra, we can see it’s failing up there too: toastal ไข่ดาว | PGP: 7944 74B7 D236 DAB9 C9EF E7F9 5CCE 6F14 66D4 7C9E
Change:
license     = licenses.ruby; maintainers = with maintainers; [ vrthra manveru marsam ]; platforms   = platforms.all; <ins> knownVulnerabilities = op (lib.versionOlder ver.majMin "3.0") "This Ruby release has reached its end of life. See https://www.ruby-lang.org/en/downloads/branches/."; </ins> }; passthru = rec {

Discussion:
So we'll have an EOL for a few months on 22.11, which isn't ideal, but we really shouldn't go into 23.05 like that. Also, does not support , which is why I noticed this when looking into stuff for
Ruby 2.7 support status ended yesterday.
The default is with the merge of :partyingface: Thanks for taking care of this Now… do we want to mark as EOL e.g. through ?
Change:
idna-ssl ]; <ins> # NOTE: pytest-xdist cannot be added because it is flaky. See https://github.com/NixOS/nixpkgs/issues/230597 for more info. </ins> nativeCheckInputs = [ async_generator freezegun gunicorn pytest-mock <del> pytest-xdist </del> pytestCheckHook re-assert ] ++ lib.optionals (!(stdenv.isDarwin && stdenv.isAarch64)) [

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-bin maintainers cc: python39Packages.aiohttp maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: -
I noticed this too, but I think the tests might just be flaky when running with multiple other Nix builds. I eventually got it working by just letting it build it by itself. I'm guessing the flakyness might be a regression from It's building on master right now:
This issue is also tracking this
cc
pytest-xdist was removed before in and I didn't search the history when doing the change. Lets remove it again and add a comment to not add it back.
closing this since is now merged

While trying to test , the aiohttp build failed twice for me. It seems there's some flakyness in the tests. I don't have build logs anymore, but it's the aiohttp that's pulled in by (which is necessary to build VM tests).
I'm encountering flakiness with tests especially when running parallel builds and/or with ...
rebuilding with got it to pass...
Closing since it sounds like fixed this. Happy to reopen if I'm mistaken.
Change:
<del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchurl , rpmextract , patchelf

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
, xorg }: let <del> id = "168727396"; </del> <ins> id = "180492850"; </ins> in stdenvNoCC.mkDerivation rec { pname = "multiviewer-for-f1"; <del> version = "1.32.1"; </del> <ins> version = "1.35.2"; </ins> src = fetchurl { url = "https://releases.multiviewer.dev/download/${id}/multiviewer-for-f1_${version}_amd64.deb"; <del> sha256 = "sha256-cnfye5c3+ZYZLjlZ6F4OD90tXhxDbgbNBn98mgmZ+Hs="; </del> <ins> sha256 = "sha256-V1+kMgfbgDS47YNIotmzrh2Hry5pvdQvrzWwuKJY1oM="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: multiviewer-for-f1 Latest released version: 1.35.2 <!-- Search your package here: --- Current version on the unstable channel: 1.32.1 Current version on the stable/release channel: 1.31.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
./virtualisation/parallels-guest.nix ./virtualisation/podman/default.nix ./virtualisation/qemu-guest-agent.nix <del> ./virtualisation/railcar.nix </del> ./virtualisation/spice-usb-redirection.nix ./virtualisation/virtualbox-guest.nix ./virtualisation/virtualbox-host.nix

Discussion:
I was curious about railcar and noted that it's marked as so I decided to give it a try. The first attempt failed at an error over a missing in libseccomp: I gather this is Linux-only and could find at least one other PR that fixed a macOS build of a different project by just removing it as a buildInput () and the cargo build fell over on some issues with caps: Other notes: I looked to see if Hydra was building this for darwin and don't see any builds. I guess hydra is smart enough not to bother with darwin given the libseccomp input. I noticed that ofborg didn't bother with building darwin on the original PR, either. Also, I noticed that oracle has archived the railcar repo. I only see at the moment. They've done some work on the CI earlier this year, at least, which seems to be a good signal? Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(abathur): nixpkgs:
I marked this as stale due to inactivity. &rarr;
Change:
<del> { stdenv, fetchurl, makeWrapper, unzip, autoreconfHook, autoconf-archive , python, libsodium, pkgconfig, popt, glog, xz, json_c, gperf, yacc , flex, pandoc, help2man, callPackage }: assert stdenv.isLinux; let hyperleveldb = callPackage ./hyperleveldb.nix {}; libpo6 = callPackage ./libpo6.nix {}; libe = callPackage ./libe.nix { inherit libpo6; }; busybee = callPackage ./busybee.nix { inherit libpo6 libe; }; replicant = callPackage ./replicant.nix { inherit libpo6 libe busybee hyperleveldb; }; libmacaroons = callPackage ./libmacaroons.nix { }; in stdenv.mkDerivation rec { name = "hyperdex-${version}"; version = "1.5.0"; src = fetchurl { url = "https://github.com/rescrv/HyperDex/archive/releases/${version}.zip"; sha256 = "0l7w3x6c4nslz5ijmj8xys0k1slwi3s4crxmi16ml1x32bqgzhj7"; }; buildInputs = [ autoreconfHook autoconf-archive busybee glog hyperleveldb json_c libe libmacaroons libpo6 pkgconfig popt python replicant unzip gperf yacc flex help2man pandoc ]; meta = with stdenv.lib; { description = "A scalable, searchable key-value store"; homepage = http://hyperdex.org; license = licenses.bsd3; platforms = platforms.linux; }; } </del>

Discussion:
Starting the HyperDex coordinator by running does most of its work by , which must be on . This does not work with the current derivation. This could be fixed either by ensuring replicant is to PATH (would making it a propagated build input be sufficient?) or patching hyperdex to exec replicant by its store path. Install hyperdex, run . It fails. System: 16.03.1242. (Emu) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: 16.03.1242.
Thanks! Upstream hyperdex is not super maintained and in my experience not stable enough to be used in production. I vote for removing it from nixos. are you relying in hyperdex in nixos or is are you just testing? [1]
I was just testing, not relying on it. Removal sounds okay to me. Alternately, I tested and adding to (in addition to ) fixes the problem.
Change:
''; }; <ins> readability-cli = prev.readability-cli.override (oldAttrs: { # Wrap src to fix this build error: # > readability-cli/readable.ts: unsupported interpreter directive "#!/usr/bin/env -S deno..." # # Need to wrap the source, instead of patching in patchPhase, because # buildNodePackage only unpacks sources in the installPhase. src = pkgs.srcOnly { src = oldAttrs.src; name = oldAttrs.name; patchPhase = "chmod a-x readable.ts"; }; nativeBuildInputs = [ pkgs.pkg-config ]; buildInputs = with pkgs; [ pixman cairo pango ]; }); </ins> reveal-md = prev.reveal-md.override ( lib.optionalAttrs (!stdenv.isDarwin) { nativeBuildInputs = [ pkgs.buildPackages.makeWrapper ];

Discussion:
Steps to reproduce the behavior: Seems like it's tied to deno. Also, it builds with yarn2nix just not node2nix. <!-- 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:
(fetchNuGet { pname = "runtime.unix.System.Private.Uri"; version = "4.3.0"; sha256 = "1jx02q6kiwlvfksq1q9qr17fj78y5v6mwsszav4qcz9z25d5g6vk"; }) (fetchNuGet { pname = "runtime.unix.System.Runtime.Extensions"; version = "4.3.0"; sha256 = "0pnxxmm8whx38dp6yvwgmh22smknxmqs5n513fc7m4wxvs1bvi4p"; }) (fetchNuGet { pname = "Sentry"; version = "3.40.0"; sha256 = "1vijf4dfv842y2567sgs4bx51g7jyqsrmg689nj4nbbf44aay99a"; }) <del> (fetchNuGet { pname = "SharpCompress"; version = "0.31.0"; sha256 = "01az7amjkxjbya5rdcqwxzrh2d3kybf1gsd3617rsxvvxadyra1r"; }) </del> (fetchNuGet { pname = "SharpCompress"; version = "0.33.0"; sha256 = "1j94hfjvkygpp97svv75jay0rmnx9ygg86d5syyahl9hayns4ig9"; }) <ins> (fetchNuGet { pname = "SharpCompress"; version = "0.34.1"; sha256 = "0m02yk97fxafdqg6s8408vqcg1a0wll483sj4ff2m0dnxajffkii"; }) </ins> (fetchNuGet { pname = "SharpFNT"; version = "2.0.0"; sha256 = "1bgacgh9hbck0qvji6frbb50sdiqfdng2fvvfgfw8b9qaql91mx0"; }) (fetchNuGet { pname = "SharpGen.Runtime"; version = "2.0.0-beta.13"; sha256 = "1250z6sa9ghf84czlkzvaysb29c0n229z1f0vh5qls89akrkl7h8"; }) (fetchNuGet { pname = "SharpGen.Runtime.COM"; version = "2.0.0-beta.13"; sha256 = "1lmv3jp2g7mgy9j23pd3j0wr3p89qiq8v6c6qxqf688izyni1166"; })

Discussion:
Package name: osu-lazer Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2023.815.0 Current version on the stable/release channel: 2023.511.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR.
Change:
<del> { lib, buildPythonPackage, fetchFromGitHub , django }: </del> <ins> { lib , buildPythonPackage , django , fetchFromGitHub , poetry-core , python , pythonOlder , ua-parser }: </ins> buildPythonPackage rec { pname = "django-sesame"; <del> version = "1.7"; </del> <ins> version = "3.1"; format = "pyproject"; disabled = pythonOlder "3.7"; </ins> src = fetchFromGitHub { owner = "aaugustin"; repo = pname; <del> rev = version; sha256 = "0k8s44zn2jmasp0w064vrx685fn4pbmdfx8qmhkab1hd5ys6pi44"; </del> <ins> rev = "refs/tags/${version}"; hash = "sha256-Pyyhm0th0cNEkM0sd6maCnf4qELsSO82c9CQuqQdn0w="; </ins> }; <del> nativeCheckInputs = [ django ]; </del> <ins> nativeBuildInputs = [ poetry-core ]; nativeCheckInputs = [ django ua-parser ]; pythonImportsCheck = [ "sesame" ]; </ins> checkPhase = '' <del> make test </del> <ins> runHook preCheck ${python.interpreter} -m django test --settings=tests.settings runHook postCheck </ins> ''; meta = with lib; {

Discussion:
Package name: django-sesame Latest released version: 3.1 - <!-- Search your package here: --- Current version on the unstable channel: 1.7 Current version on the stable/release channel: 1.7 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
https://django- The docs for django-sesame ensure compatibility with Django 3.2 and 4.1, which are the versions covered by unstable and the latest stable releases. There is no guarantee that 1.7 would have been compatible with the current Django versions.
Change:
, includeEverything ? true , raylib-games , darwin <ins> , autoPatchelfHook </ins> }: let inherit (darwin.apple_sdk.frameworks) Carbon Cocoa OpenGL;

Discussion:
When using an application built against the raylib library on Linux, audio doesn't work. Steps to reproduce the behavior: When playing the game there should be audio. The game logs the following to the terminal, indicating it was unable to initialize the audio device: I played with a patched version of raylib to confirm that the game does indeed feature audio. The audio patch was removed in <!-- 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]:
Hey Emmanuel, Unfortunately I don't have any time to act as maintainer for Nix at the moment or in the foreseeable future.
OK, no problem The solution is known, but the question is whether anyone else can reproduce this. For what it's worh, I had the same issue with a non-raylib application which uses miniaudio.
Change:
environment.systemPackages = [ x11Fonts ]; <ins> environment.pathsToLink = [ "/share/X11-fonts" ]; </ins> }; }

Discussion:
The documentation for states that setting the option to should cause a directory of fonts to be generated. However, this option is set on my system, but the system does not have a fonts directory: Enable in . Rebuild system. Observe lack of directory.System: (NixOS: , Ubuntu/Fedora: , ...) [twey nixos-version 16.09pre82105. (Flounder) Nix version: (run ) [twey nix-env --version nix-env (Nix) 1.11.2 Nixpkgs version: (run ) [twey nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion "16.09pre82105."
I can reproduce the issue
:+1:, same here, for a loooong time now (sorry for not reporting earlier).
BTW, what's this option good for?
It gives a place to point applications that want to know about fonts (e.g. LuaTeX). On 7 May 2016 11:20, Vladimír Čunát wrote:BTW, what's this option good for? —You are receiving this because you authored the thread.Reply to this email directly or view it on GitHub
I assumed everything uses fontconfig nowadays, but there may be some exceptions...
Could you please write this in (and not in as you said in the issue description)? Do you have the directory now?
I have this in and no directory.
I believe this is fixed by I don't use nor really care about this feature, though, so I have no idea whether linking into really does anything useful ...
Change:
doCheck = true; <ins> mesonCheckFlags = [ # PAM related checks are timing out "--no-suite" "fprintd:TestPamFprintd" ]; </ins> postPatch = '' patchShebangs  po/check-translations.sh 

Discussion:
Steps to reproduce the behavior: . . Also failed in . <!-- 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 was experiencing the same issue regardless of the nixpkgs-branch I'm using for fprintd. I've asked in the matrix channel and came up with this overlay to skip the broken (timeout) test for the moment: ~(currently testing)~
Worked for me after maybe because of some dirty state from previous attempts.
Addressed the pam rule issue with
Having the same error building from this pull request.
How did you apply it? After applying it to my local-checkout of nixpkgs which I use to build my system from and updating flake inputs I was able to import (inputs-definition) as second package-set and set and was able to rebuild without applying above overlay. So this does not solve the issue of timing-out tests but it solves the issue that using the stable-package (which is the same version) wasn't helping either.
With merged, there is no longer a need for using an overlay to apply the workaroud, you may just set
I'm also having the timeout issue, even with the workaround
If you're using the unstable channel, the still seems to be the best option until lands in unstable as otherwise it would require modifying the PAM module in addition to fprintd.
Unfortunately, this still fails with timeout errors
You have to wait til it reaches your channel. See
If you don't want to wait and don't actively use a fingerprint sensor has been working for me without any noticeable drawbacks.
Change:
let pname = "lbry-desktop"; <del> version = "0.53.8"; </del> <ins> version = "0.53.9"; </ins> in appimageTools.wrapAppImage rec { name = "${pname}-${version}";

Discussion:
Package name: lbry Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 0.53.8 Current version on the stable/release channel: 0.53.8 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
"/share/pixmaps" ]; <ins> environment.systemPackages = [ # Empty icon theme that contains index.theme file describing directories # where toolkits should look for icons installed by apps. pkgs.hicolor-icon-theme ]; </ins> # libXcursor looks for cursors in XCURSOR_PATH # it mostly follows the spec for icons # See: https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml Themes

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: install Nixos enabling Gnome An option to Exclude Gnome-Tour package or to exclude some Gnome-shell packages I would like to exclude some useless Gnome-shell packages that if i exclude them will not break my whole system. You can not exclude packages from Gnome-shell with this option and this not work because is required by this <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
This should be resolved in , but it is not part of 22.05, Edit:
How do I do a backport ? Thank you for your fast response.
It works. = with pkgs; [ gnome-tour ];
After doing this commands gnome tour still in my system. Do i need to do something more ? ! Maybe that ballon is not Gnome tour but i think it is.
It works in unstable channel, you need waitting for Backport 22.05 merge.
Thank you
I merged , not sure why the issue is not auto-closed. You should get the fix when the backport reaches the channel you uses, feel free to re-open this if the issue persists.
After waiting for being in Nixos 22.05, Writing this in And executing. That deleted Gnome-tour from my system. Thank you for your support.
Change:
with stdenv.lib; let extraJars = optional mysqlSupport mysql_jdbc; <ins> logback-core = fetchurl { url = "http://central.maven.org/maven2/ch/qos/logback/logback-core/1.2.3/logback-core-1.2.3.jar"; sha256 = "5946d837fe6f960c02a53eda7a6926ecc3c758bbdd69aa453ee429f858217f22"; }; logback-classic = fetchurl { url = "http://central.maven.org/maven2/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar"; sha256 = "fb53f8539e7fcb8f093a56e138112056ec1dc809ebb020b59d8a36a5ebac37e0"; }; slf4j = fetchurl { url = "http://central.maven.org/maven2/org/slf4j/slf4j-api/1.7.25/slf4j-api-1.7.25.jar"; sha256 = "18c4a0095d5c1da6b817592e767bb23d29dd2f560ad74df75ff3961dbde25b79"; }; </ins> in stdenv.mkDerivation rec {

Discussion:
Starting liquibase results in: system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs:
This is fixed in: So the next release should have this. Alternatives seem to be: Manually download the slf4j jar file and include it in the classpath Use an older version (3.5.* seems to work) Include the PR in the derivation. This would mean building liquibase from source. Keep it broken until it's released. I'm a little baffled that nobody actually tried to execute liquibase apparently. What do you suggest? I made a preliminiary PR that fixes the problem.