jiebi/CodeConvo huggingface dataset:
Code change:
owner = "named-data"; repo = lib.toUpper pname; rev = "NFD-${version}"; <del> sha256 = "1l9bchj8c68r6qw4vr1kc96jgxl0vpqa2vjkvy1xmhz92sivr6gi"; </del> <ins> sha256 = "sha256-8Zm8oxbpw9qD31NuofDdgPYnTWIz5E04NhkZhiRkK9E="; </ins> fetchSubmodules = true; };

Related discussion:
text: The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.
Code change:
{ stdenv, lib, fetchurl, iptables-legacy, libuuid, openssl, pkg-config <del> , which, iproute2, gnused, coreutils, gawk, makeWrapper </del> <ins> , which, iproute2, gnused, coreutils, gnugrep, gawk, makeWrapper </ins> , nixosTests <ins> , firewall ? "iptables", nftables, libmnl, libnftnl </ins> }: let <del> scriptBinEnv = lib.makeBinPath [ which iproute2 iptables-legacy gnused coreutils gawk ]; </del> <ins> scriptBinEnv = lib.makeBinPath { iptables = [ # needed for dirname in ip{,6}tables_*.sh coreutils # used in miniupnpd_functions.sh: which iproute2 iptables-legacy gnused gnugrep gawk ]; nftables = [ # needed for dirname in nft_*.sh & cat in nft_init.sh coreutils # used in miniupnpd_functions.sh: which nftables ]; }.${firewall}; </ins> in stdenv.mkDerivation rec { pname = "miniupnpd";

Related discussion:
text: We already have in , but only with iptables support. It would be nice to have the nftables version available as well.
Being worked on in , I'm trying to test myself but couldn't make it to work yet.
I think the PR is ready now, testing welcome!
Maybe add an option for will be better?
Code change:
fastapi-mail = callPackage ../development/python-modules/fastapi-mail { }; <ins> fast-histogram = callPackage ../development/python-modules/fast-histogram { }; </ins> fastavro = callPackage ../development/python-modules/fastavro { }; fastbencode = callPackage ../development/python-modules/fastbencode { };

Related discussion:
text: Project description Glue is a python project to link visualizations of scientific datasets across many files. Click on the image for a quick demo: ! Metadata homepage URL: source URL: license: BSD Linux, BSD
Code change:
{ lib , buildPythonPackage , fetchPypi <del> # build-system , setuptools , plux # dependencies , cachetools , click , cryptography </del> , dill , dnslib , dnspython <del> , psutil , python-dotenv , pyyaml </del> <ins> , plux , pyaes , python-jose </ins> , requests <del> , rich , semver , stevedore , tailer </del> <ins> , tabulate </ins> # Sensitive downstream dependencies , localstack

Related discussion:
text: Steps to reproduce the behavior: localstack (from unstable) (version 3.2.0) localstack 2.3.0 works and so does (tagged because you bumped the version) (the channel is slightly messed up. I am using 23.11 but with flakes) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The new version requires too many dependencies to package up in a reasonable time frame and even includes circular ones. contains a revert to 3.0.0 which builds for me and shows the usage. Can you take a look if that works for you?
Sorry for the delay! Yes, the revert works well for me! Thank you!
Code change:
license = lib.licenses.agpl3Plus; maintainers = with lib.maintainers; [ arturcygan ]; platforms = lib.platforms.unix; <ins> mainProgram = "echidna-test"; </ins> }

Related discussion:
text: <!-- 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: 1.7.3 desired version: 2.0.2 <!-- 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.
waiting for 0.50.0 release of
I fixed echidna.
Lovely. Thanks you so much for you effort.
Code change:
buildKernel = any (n: n == configFile) [ "kernel" "all" ]; buildUser = any (n: n == configFile) [ "user" "all" ]; <ins> # remove this patch at the next ZFS release (> 2.0.1) reapplyPathSanitizerPatch = fetchpatch { url = "https://github.com/openzfs/zfs/commit/03f036cbccdd8699f5fe8540ef317595a35bceb8.patch"; sha256 = "c157bbb6551a4e720c3faba005e1b72e4692d304c6ff5e0e685691bd47197dca"; }; </ins> common = { version , sha256 , extraPatches ? []

Related discussion:
text: Describe the bug When booting with ZFS legacy mountpoints like this: the boot fails as described in this post: To Reproduce I guess this is difficult if not anyone is having this issue with legacy mountpoints, but it seems that in the linked discourse post, I'm not the only one with this issue. But I've tested it just on this commit: where it fails, and on this (just one commit before): And there everything works. Expected behavior Mounting of legacy ZFS mountpoints succeeds while booting. Notify maintainers <!-- Metadata Please run and paste the result. Maintainer information: --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Can you check if this is fixed by ?
I tried with this overlay: Not sure if that's the way to do it, but it didn't work.
it should probably be
Thanks I tried that, and it didn't work. Not sure how to confirm the patch got applied properly though.
if you have the log output, you will have something like:
Guys, just to report, I'm in the latest zen with ZFS 2.0.1-1 with encryption, unstable channel and I'm not having any problems.
I've just found time to test this, thanks for the research. The patch did indeed fix the issue for me! (I've checked the log output for the application of the patch). For the sake of completeness the overlay I've applied (needed a slightly different sha256 sum for me):
Could you make a PR adding the patch to zfs?
Code change:
<itemizedlist> <listitem> <para> <ins> The Mailman NixOS module (<literal>services.mailman</literal>) has a new option <xref linkend="opt-services.mailman.enablePostfix" />, defaulting to true, that controls integration with Postfix. </para> <para> If this option is disabled, default MTA config becomes not set and you should set the options in <literal>services.mailman.settings.mta</literal> according to the desired configuration as described in <link xlink:href="https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html">Mailman documentation</link>. </para> </listitem> <listitem> <para> </ins> The default-version of <literal>nextcloud</literal> is <package>nextcloud20</package>. Please note that it's <emphasis>not</emphasis> possible to upgrade <literal>nextcloud</literal> across multiple major versions! This means that it's e.g. not possible to upgrade

Related discussion:
text: Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.
Code change:
qtWrapperArgs = let libpath = with xorg; <del> lib.makeLibraryPath [ </del> <ins> lib.makeLibraryPath ([ </ins> libX11 libXext libXcursor

Related discussion:
text: A clear and concise description of what the bug is. Prism Launcher doesn't allow enabling Feral GameMode or MangoHud under the "Performance" tab because it can't find it. Steps to reproduce the behavior: GameMode ( ) MangoHud ( ) Prism Launcher ( ) new instance in Prism Launcher instance and go to "Performance" tab A clear and concise description of what you expected to happen. GameMode and MangoHud should be able to be enabled when installed. If applicable, add screenshots to help explain your problem. ! ! Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
Addressed here -
Code change:
++ lib.optional enableSqlite sqlite; dontWrapQtApps = true; <ins> dontWrapGApps = true; </ins> configureFlags = [ "--enable-shared" ] ++ lib.optional sdlClient "--enable-client=sdl"

Related discussion:
text: should provide a QT client to freeciv, which is probably named if I had to guess. Steps to reproduce the behavior: only gtk client installed (see below) A executable. If applicable, add screenshots to help explain your problem. ! -( does not exist) ! The installed is indeed a gtk client. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (You were the last person to commit, so I choose you :) ) (I don't believe the listed maintainer exists). Please run and paste the result. Maintainer information:
Code change:
<del> { lib, stdenv, fetchzip, jdk11 }: </del> <ins> { lib, stdenv, fetchzip, jdk11, wrapGAppsHook }: </ins> stdenv.mkDerivation rec { pname = "igv";

Related discussion:
text: The IGV package freezes and crashed when a file dialog should open (open file, save as, etc.). Steps to reproduce the behavior: igv: igv "File" -"Load from File.." application crashes The file dialog should open and allow me to open a file. If I open igv through the terminal, then this error is shown: This error is the same as previously reported issues for other application, e.g. I'll shortly open a PR with the same fix. I'll rather do that in the PR with the fix. Please run and paste the result. NA
Code change:
default = [ "aes" "aes_generic" "blowfish" "twofish" "serpent" "cbc" "xts" "lrw" "sha1" "sha256" "sha512" <ins> "af_alg" "algif_skcipher" </ins> (if pkgs.stdenv.hostPlatform.system == "x86_64-linux" then "aes_x86_64" else "aes_i586") ];

Related discussion:
text: See:
I've been using cryptsetup with an SSD and without kernel crypto to run my entire NixOS and didn't noted any performance issues, but I agree that my patch was a temporary workaround, so enabling the crypto module would be a better solution.
The option also breaks the feature of that can be used when installing nixos to reason about the speed of disk encryption
The NixOS test works with and the kernel userapace crypto API enabled in on at least 19.03. was updated to 2.0.6 in the meantime, maybe the bug was fixed? Haven't noticed anything in release notes. This API shouldn't in fact be need for LUKS, only for tcrypt and the benchmark. Did you also run the test or did you just notice that on your local machine? Do you have any non-standard config concerning the initrd?
Hmm, even with the test succeeds. We need more information.
I haven't ran any tests, I just tested it in my work laptop and in a VM used to isolate the issue. I used a non-standard initrd config only for debugging, but after finding the problem I used the standard one. The only strange thing I did was to have a LUKS2 encrypted volume, which isn't very common (or at least it wasn't at the moment I experienced the issue). In a few days I will try to boot my system both with and without kernel crypto to check whether it is necessary or not.
I can confirm that I still have problems booting my system when kernel crypto is enabled. I put this in my , in an updated unstable NixOS: With this configuration, my system boots. If I uncomment the line, it doesn't because it fails to unencrypt my root partition. I'm using LVM inside a LUKS2 partition.
Here is the result of using when mounting my LUKS2 volume with kernel crypto enabled. The last image is the most important. Sorry for pasting screenshots, I didn't have a flash drive to copy the logs. ! ! ! ! !
Thank you very much for your detailed analysis. :+1: Oh, LUKS2! Seems the userspace API is indeed needed for LUKS2 but not LUKS1. I'll try to adapt the test and fix this issue. There are probably just some modules missing.
Code change:
default = [ "aes" "aes_generic" "blowfish" "twofish" "serpent" "cbc" "xts" "lrw" "sha1" "sha256" "sha512" <ins> "af_alg" "algif_skcipher" </ins> (if pkgs.stdenv.hostPlatform.system == "x86_64-linux" then "aes_x86_64" else "aes_i586") ];

Related discussion:
text: Commit introduced to the configuration of . This causes to no longer work, with the following message: Run , where is a truecrypt volume. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The issue for re-enabling kernel_crypto is
It also breaks
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 . on the on .
still important to me
I marked this as stale due to inactivity. &rarr;
are you sure this is still an issue? This seems to have been solved by . e.g. cryptsetup benchmark works just fine on my machine.
I did not check and do not care anymore. Thanks!
Code change:
libxcrypt lttng-ust_2_12 musl <ins> ]++ lib.optionals (stdenv.isLinux && stdenv.isAarch64) [ expat libxml2 xz </ins> ]; }).overrideAttrs (attrs: { postInstall = (attrs.postInstall or "") + lib.optionalString (stdenv.isLinux) '' (

Related discussion:
text: Steps to reproduce the behavior: for n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --built from nixpkgs master () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
buildInputs = lib.optionals (lib.versionOlder cudaVersion "11.4") [cudatoolkit] ++ lib.optionals (lib.versionAtLeast cudaVersion "11.4") [ <del> libcublas </del> <ins> libcublas.dev libcublas.lib libcublas.static </ins> cuda_cudart ] ++ lib.optionals (lib.versionAtLeast cudaVersion "12.0") [cuda_cccl];

Related discussion:
text: singularity cannot use nvidia gpu because it does not access 'nvidia-container-cli' Steps to reproduce the behavior: return result of ! This is because the path is not listed in , as also in a. It is caused by neither the option nor . I tried to handle it with override, but since it was called in , I think it is impossible to handle. Also, I created a conf file in as shown in the singularity docs, but it was not read. <!-- 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.
Thank you for reporting and sorry for the trouble. I'll look at the SingularityCE documentation again. (Those configuration options has been deprecated by Apptainer.) Also, I created a conf file in /usr/local/etc/singularity/ as shown in the singularity docs, but it was not read.  shold be what you are looking for. The overriden package can be assigned to . (If you would like to bypass all the overriding done by the module and directly specify the package to install for some special reason, you can assign it to .)
Thanks for the reply. I followed your advice and tried the override and was able to use the GPU. Here is the code This is simply adding a process to append the nvidia-docker path to the I mentioned earlier that when conf was entered in , it was not reflected, and the same is true for '/etc/singularity'. I referred to .
At least we have confirmed that in works and the path is replaced by , but the product does not seem to be recognizable.
Does setting the to make ldconfig search in help? This is modified from the configuration proposed by (). There's also (probably) related to this topic.
Adding the path of to works well. This once removed from consideration. Next we have a patched version of ldconfig. This does not append the path of to the config. The result was an error that could not be found, and it could not be started.
Oh, I already forgot about this issue. Absolutely coincidentally, but maybe efforts such as might open up a way to implement this hack more reliably.
Code change:
buildInputs = lib.optionals (lib.versionOlder cudaVersion "11.4") [cudatoolkit] ++ lib.optionals (lib.versionAtLeast cudaVersion "11.4") [ <del> libcublas </del> <ins> libcublas.dev libcublas.lib libcublas.static </ins> cuda_cudart ] ++ lib.optionals (lib.versionAtLeast cudaVersion "12.0") [cuda_cccl];

Related discussion:
text: Meanwhile, in my config I'm still abusing You probably already have guessed, but singularity in nixpkgs is configured to read this config from the package-specific directory, rather than from the global . You could in principle override this behaviour, but there maybe isn't much value in supporting that
I tried to enable the use of external sysconfdir (), but have encountered issue trying to specify a directory under with the NixOS module ().
Have you tried to apply both at the same time?
The SingularityCE Admin Guide says If the value of nvidia-container-cli path is empty, SingularityCE will look for the binary on $PATH at runtime. It should work as long as is found in the run-time , even when is not set. As nvidia-container-cli is alredy included in the PATH-prefixing wrapper, we shouldn't have to set the .
Update: I found a bug in the prefixed PATH of the wrapper introduced in . The prefixing should be specified as (in Bash) I forgot to add , causing the trailing to be missing.
The statement in the SingularityCE Admin Guide turns out to be wrong / irrelevant. The source code clearly states that nvidia-container-cli will only be read from the configuration.
(we need to patch nvidia-container-cli, for many reasons )
Eh, actually, closed semi-automatically. Apptainer with is fixed (on NixOS), but not with . The fix doesn't concern singularity-ce either, unfortunately. Shouldn't be hard to make this work with singularity too, but I'm out of bandwidth
Hi folks, I've been trying to get apptainer to run this (which I've done previously successfully with a slight ldconfig hack -- that doesn't work anymore -- on NixOS 22.11), that will make use of the machine's Tesla V100 to do some simulation stuff. The machine is running NixOS 23.11. Using the workaround from 9th of May post further up, I was able to get past the ldconfig issue, but now I'm getting an error saying the driver and CUDA are not in sync.
Code change:
buildInputs = lib.optionals (lib.versionOlder cudaVersion "11.4") [cudatoolkit] ++ lib.optionals (lib.versionAtLeast cudaVersion "11.4") [ <del> libcublas </del> <ins> libcublas.dev libcublas.lib libcublas.static </ins> cuda_cudart ] ++ lib.optionals (lib.versionAtLeast cudaVersion "12.0") [cuda_cccl];

Related discussion:
text: Before I start posting any details (I don't want to re-open this issue, but I'm also not sure if I'm just doing something wrong) I was wondering if the current implementation of singularity/apptainer on NixOS is expected to work, and I'm just being an idiot, or if there are known breaking issues? I've seen the other issues about singularity/apptainer here, but I'm not knowledgeable enough to make a judgement call if they are responsible for my problem or not. Thanks very much in advance!
(If I understood the message correctly) That usually means you need a reboot, and you should experience the same issue outside the container
No, the reboot didn't help either. For some reason, though, after upgrading to 24.05, everything "just works[tm]" again. So, whatever the issue was, thanks for fixing it (probably)! :)
Thanks to Nixpkgs 24.05 includes GPU-related changes/fixes to the package and the module.
Well more like thanks to ShamrockLee
Code change:
CMakeLists.txt ''; <del> postInstall = '' cp -r ${desktopItem}/share/applications $out/share ln -sf $out/bin/dolphin-emu $out/bin/dolphin-emu-master '' + lib.optionalString stdenv.hostPlatform.isLinux '' </del> <ins> postInstall = lib.optionalString stdenv.hostPlatform.isLinux '' </ins> install -D $src/Data/51-usb-device.rules $out/etc/udev/rules.d/51-usb-device.rules '';

Related discussion:
text: The derivation of creates a different .desktop file from the "official" one that has a different name. This is probably done in order to differentiate the two versions of in case someone installs both of them, but the problem is that while it creates a new one, it doesn't delete the "official" one. Also, the new .desktop file should also set , otherwise games don't launch in Wayland. (Though maybe it should be a wrapper instead) (And, unrelated, but why and not ?) The same also applies to PATH: there are both and (which is a link made by the derivation to in the folder). For consistency, there should be made a , otherwise if both dolphins are installed, one overwrites the other in PATH. Steps to reproduce the behavior: dolphinEmuMaster; an app launcher; are both the original "Dolphin Emulator" and the new "Dolphin Emulator (master)" that open the same app (the master one doesn't set `QTQPAPLATFORM=xcb). PATH there are both and (which is a link). There should only be the "Dolphin Emulator (master)" desktop file, and in PATH there should be only (and instead of ). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --