jiebi/CodeConvo huggingface dataset:
Code change:
sha256 = ( if cudaSupport then <del> { x86_64-linux = "sha256-VGNMf5/DgXbgsu1w5J1Pmrukw+7UO31BNU+crKVsX5k="; } </del> <ins> { x86_64-linux = "sha256-vUoAPkYKEnHkV4fw6BI0mCeuP2e8BMCJnVuZMm9LwSA="; } </ins> else { <del> x86_64-linux = "sha256-uOoAyMBLHPX6jzdN43b5wZV5eW0yI8sCDD7BSX2h4oQ="; aarch64-linux = "sha256-+SnGKY9LIT1Qhu/x6Uh7sHRaAEjlc//qyKj1m4t16PA="; </del> <ins> x86_64-linux = "sha256-R1TIIyyyLlDqAlUkuhJhtyTxZMra2q5S/jX0OCInsEQ="; aarch64-linux = "sha256-P5JEmJljN1DeRA0dNkzyosKzRnJH+5SD2aWdV5JsoiY="; </ins> } ).${effectiveStdenv.system} or (throw "jaxlib: unsupported system: ${effectiveStdenv.system}"); };

Related discussion:
text: Build . Because this hash was updated not long ago by , I think the package may still need some refactor? We may also expect to get everything settled. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Huh, weird. When I wrote that hash worked fine. I wonder what changed?
Yes I was wondering about the same thing because I knew you updated that hash not long ago. Does that hash depend on any online resources that may change or on other packages? If not, then this package may have some obscure reproducibility issues. This package is so complex that I cannot see what it is doing there at glances.
Yes, but it is my understanding that its pulling resources that are hash-fixed in bazel-land, so iiuc they shouldn't change unless changes... but then again clearly i have some misunderstanding of the behavior here
builds fine for me on .
Is this issue still reproducible for you?
Yes. I just tested on master branch at commit . The exact same error.
Are you using any overlays? Have you set any nixpkgs flags?
I have a local clone of nixpkgs at , and I ran the command Does it depend on my nixos system config?
iirc it will depend on eg but i'm not sure about the nixos system config. What commit of nixpkgs are you on? Does it reproduce on the latest master?
I don't have . I said I was on , which is the latest.
Latest (at the time of writing) is does building on that commit work for you?
That commit does not build either.
Hi, I'm also having the same issue with same hash mismatch. I tested the build on two different systems. If you happen to have a system in which the build runs fine, would you mind sharing the output of the derivation: so I can diff it? I could also send you mine.
Code change:
sha256 = ( if cudaSupport then <del> { x86_64-linux = "sha256-VGNMf5/DgXbgsu1w5J1Pmrukw+7UO31BNU+crKVsX5k="; } </del> <ins> { x86_64-linux = "sha256-vUoAPkYKEnHkV4fw6BI0mCeuP2e8BMCJnVuZMm9LwSA="; } </ins> else { <del> x86_64-linux = "sha256-uOoAyMBLHPX6jzdN43b5wZV5eW0yI8sCDD7BSX2h4oQ="; aarch64-linux = "sha256-+SnGKY9LIT1Qhu/x6Uh7sHRaAEjlc//qyKj1m4t16PA="; </del> <ins> x86_64-linux = "sha256-R1TIIyyyLlDqAlUkuhJhtyTxZMra2q5S/jX0OCInsEQ="; aarch64-linux = "sha256-P5JEmJljN1DeRA0dNkzyosKzRnJH+5SD2aWdV5JsoiY="; </ins> } ).${effectiveStdenv.system} or (throw "jaxlib: unsupported system: ${effectiveStdenv.system}"); };

Related discussion:
text: Should be fixed by
Fixed by
Hi everyone, sorry to reactivate this issue but if I check out the current master branch and run , I end up with the same error as above (just with different hashes). Can anyone reproduce this behaviour?
what hashes are you seeing now?
I can rebuild the package just fine...
! These are the hashes I get after running on the current master (). I am puzzled by the fact that this exact commands builds fine for . My expectation would have been that the behaviour should be the same if we are on the same platform (I am on x86_64-linux). Do you have an idea how we can dig deeper into this?
I also just stumbled upon this issue and I do get the exact same hash mismatch as :
Well, my only hypothesis is that the bazel dependencies derivation is nothing more than non-deterministic :'(
Does this still build for you? If it does I can offer to send you an archive of my jaxlib with the changed hash so you can run a diff to find out what is wrong. (Or the other way round ofc)
Yes, I have tried once again right now and it works fine... Sure, Send me what you have :)
Alright, I've updated today and will build against nixpkgs . My machine will probably take some time to completely build it though, so I'll post back once it's done.
I'm getting a similar problem when I'm trying to compile . The commit is from the branch. The commit was the only commit I found after going through multiple issues and threads which worked on my system. I have also observed this issue when compiling (), so the issue of build failures due to bazel hash mismatch isn't just limited to . So, I don't think that this issue has been properly resolved yet.
I'm not sure if this is helpful--or noise!--but I just hit a similar issue with (see below for output, repro, and system info).
Btw we're tracking the hash issues in .
Code change:
# HACK to ensure that we preserve source from bootstrap binutils to not rebuild LLVM normal-src = stdenv.__bootPackages.binutils-unwrapped.src or (fetchurl { url = "mirror://gnu/binutils/${basename}-${version}.tar.bz2"; <del> sha256 = "1l34hn1zkmhr1wcrgf0d4z7r3najxnw3cx2y2fk7v55zjlk3ik7z"; </del> <ins> sha256 = "1rin1f5c7wm4n3piky6xilcrpf2s0n3dd5vqq8irrxkcic3i1w49"; </ins> }); in

Related discussion:
text: Describe the bug is currently in nixpkgs master. It was released in July 2018. was released in October 2019. It contains a few improvements and may also contains fix for some vulnerabilities: Is there a reason to keep the old version in nixpkgs, other than a lack of manpower? I'd be happy to do this work, but I just want to be sure that I was not starting a long, difficult and redundant work. I already tried a "naive" bump of the and but it does not work, mostly because most of the patchs are not valid anymore.
This was solved by cc.
Thank you for continuing this work!
Code change:
touch .${projectName}.d/env/94-appsbase.sh cd .. <del> mkdir -p /var/lib/${projectName}/mnt/{container,final,overlay,session,source} </del> <ins> mkdir -p /var/lib/${projectName}/mnt/session </ins> echo "root:x:0:0:System administrator:/root:/bin/sh" > /etc/passwd echo > /etc/resolv.conf TMPDIR=$(pwd -P) ${projectName} build $out ./img

Related discussion:
text: The derivation is missing the directory to work properly. Steps to reproduce the behavior: A clear and concise description of what you expected to happen. is output without error. This can be fixed by creating the directory manually (). I guess this could be to the derivation. <!-- 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.
NixOS module provides those top-level directories. discussed with one of the main Apptainer developer in . He think it should be easy to specify a directory that will always exist at build time. Regalding this, I'm considering the possibility to put those dilectories under the derivation store path. Not sure if there would be potential problem using a store path as a mount point, but it seems to work without problem.
Could you help me take a look at ?
If you have time, please help me test the PR . It should fundamentally solve this issue. If applied, you no longer need the NixOS module or just to run images. It specifies the LOCALSTATEDIR as , making both Apptainer and Sylabs SingularityCE works without . (The image running still depends on and to run images, which might be the final obstacle to build images as a package without invoking a virtual machine. Other than that, it should not be an issue for most users, as are available on most of the UNIX/UNIX-like systems.)
I removed (the temporary fix for this issue) and ran the following and it seems to work fine: Thank you for this fix!
Glad to hear that! Would you mind ? I've heard that committers tend to merge PRs getting two approvals.
Done!
Code change:
# Check whenever fileSystem is needed for boot.  NOTE: Make sure # pathsNeededForBoot is closed under the parent relationship, i.e. if /a/b/c # is in the list, put /a and /a/b in as well. <del> pathsNeededForBoot = [ "/" "/nix" "/nix/store" "/var" "/var/log" "/var/lib" "/var/lib/nixos" "/etc" ]; </del> <ins> pathsNeededForBoot = [ "/" "/nix" "/nix/store" "/var" "/var/log" "/var/lib" "/var/lib/nixos" "/etc" "/usr" ]; </ins> fsNeededForBoot = fs: fs.neededForBoot || elem fs.mountPoint pathsNeededForBoot; # Check whenever `b` depends on `a` as a fileSystem

Related discussion:
text: systemd seems to use the term split-usr to refer to an attribute of a system, where: is a mount point. is not mounted "at boot". Since systemd v248, support for a split-usr system is deprecated: While don't seem to mention a formal removal of support of split-usr, it seems that . According to : It seems that if is a mount point, this unit calls with on it, regardless of whether it is already mounted — making the assumption that it had already been mounted "at boot". When I installed my first NixOS on my workstation, I made a filesystem for each path under . This let me customize options per directory as I wished, both at install and later on. ZFS's sharing of storage space between filesystems in the same zpool takes the cost out of being "generous" with the number of filesystems. I didn't know that is merely that happens to be generated at boot. I also didn't know that systemd deprecated split-usr. So I did not mark as . The system built successfully and booted successfully. Except for an error in the logs: The failure seems to be due to the attempt to remount using with the option a non-mounted filesystem — . is later successfully mounted along with the rest of the filesystems. Since systemd seems to expect that if is a mount point it would have already been mounted "at boot", I would expect NixOS to: 's to by default, . to build when 's is (that could be ). Understanding this error took around three hours of collaborative debugging with the tremendous help of A workaround is to set for , or to not have a mount point at all. The suggested solution (expected behavior) is with the goal of sparing all future users an investigation of this error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Not sure who to mention. Please ignore if you no longer wish to be involved. If you happen to know who should be mentioned here and is not, please comment mentioning them. Please run and paste the result. Maintainer information:
gentoo notes this in their wiki as well
ping a couple people who might care: and probably others.
Code change:
<ins> import ./make-test-python.nix ({ pkgs, ... }: { name = "monado"; nodes.machine = { pkgs, ... }: { hardware.opengl.enable = true; users.users.alice = { isNormalUser = true; uid = 1000; }; services.monado = { enable = true; defaultRuntime = true; }; # Stop Monado from probing for any hardware systemd.user.services.monado.environment.SIMULATED_ENABLE = "1"; environment.systemPackages = with pkgs; [ openxr-loader ]; }; testScript = { nodes, ... }: let userId = toString nodes.machine.users.users.alice.uid; runtimePath = "/run/user/${userId}"; in '' machine.succeed("loginctl enable-linger alice") machine.wait_for_unit("user@${userId}.service") machine.wait_for_unit("monado.socket", "alice") machine.systemctl("start monado.service", "alice") machine.wait_for_unit("monado.service", "alice") machine.succeed("su -- alice -c env XDG_RUNTIME_DIR=${runtimePath} openxr_runtime_list") ''; }) </ins>

Related discussion:
text: The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- 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]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See
Code change:
--set-rpath "${stdenv.lib.makeLibraryPath buildInputs}"  $out/bin/anydesk <ins> # pangox is not actually necessary (it was only added as a part of gtkglext) patchelf  --remove-needed libpangox-1.0.so.0  $out/bin/anydesk </ins> wrapProgram $out/bin/anydesk  --prefix PATH : ${stdenv.lib.makeBinPath [ lsb-release ]}

Related discussion:
text: Describe the bug Seems like some updates to pango broke a few packages Among the broken ones: ettercap (see ) pangox-compat (which anydesk needs) probably a few more To Reproduce Steps to reproduce the behavior: to build ettercap or anydesk from master will fail to build with some pango-related errors Expected behavior It should work Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): nixpkgs: Maintainer information:
Also remmina is broken But doesn't seem to depend on pango directly, so unsure which dependency actually is broken
Here's an issue for pangox-compat
Lutris is broken too - not an urgent requirement but just making you fine folks aware!
Not sure why Lutris is broken, but Lutris-unwrap is fine.
It's a failure in the dependency chain, in this case .
no longer depends on on its master branch: We should probably switch to that. should not be needed in according to the README in , I suspect it was only there because we did not propagate it until ebassi also suggests switching to HEAD and says we need not worry about ABI changes:
Not having pangox_compat fixed is definitively still an issue. Can this be re-opened?
After , the only program depending on this is anydesk and openmodelica which is broken.
So it breaks anydesk thus either we mark anydesk as broken or we fix that?
Anydesk shouldn't use this deprecated library. Yes, we can mark it as broken.
Code change:
mkdir -p "$doc" export SAGE_DOC="$doc" export SAGE_DOCBUILD_OPTS="--no-pdf-links -k" <ins> '' + stdenv.lib.optionalString (!optimize) '' export SAGE_FAT_BINARY=yes </ins> ''; buildFlags = if (buildDocs) then "doc" else "build";

Related discussion:
text: The recent changes seem to make sage crash when it tries to run some code using openblas (I think). I installed the sage derivation from the latest github repository. In the sage interpreter, run the following sage crashes with the following message: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(okideal): channels(root): nixpkgs:
Procedural: as it is , please specify the CPU model. Looks like the Sage build system had the idea to use somewhere… I.e. the local build could work. I wonder how feasible it is to find where Sage does it — the Sage derivation is allowed to rebuild a lot of dependencies because it is just too much pain to make it use the system versions.
Here is the output of lscpu
From the traceback it presumably crashes here: which is which indeed is an AMD-only instruction (MMX? thought that would be long obsolete by now...)
You were right. A local build works fine. Thanks for the help.
Thanks for your report. do we set to and give up?
This should be fixed by exporting (see ). I'm not quite ready to give up (even though it would probably be the healthier choice :grin:). I'm actually currently experimenting with doing it the "right way" and replacing the sage buildsytem with nix (with a mix of sage and system dependencies).
can you confirm that the latest binary works?
Sorry for the late answer. The binaries from the master branch seem to work. The initial crashes are gone and running gives only unrelated failures. Installing from still gives me the old, faulty binaries though.
Are you sure you updated the channel? What do you mean by "binaries from master"?
I meant that installing from the master branch of the git repository works. I was not aware that there is a difference between nixos-unstable and nixpkgs-unstable. The latter does not seem to include the fix yet. Installing from nixos-unstable works well. Thanks for your help.
Okay, I guess hydra is a bit overwhelmed by all the fixes for the upcoming release. Thanks for reporting.
Code change:
assert stdenv.isLinux; # better than `called with unexpected argument 'enableJavaFX'` mavenJdk.buildMavenPackage rec { pname = "cryptomator"; <del> version = "1.10.1"; </del> <ins> version = "1.11.0"; </ins> src = fetchFromGitHub { owner = "cryptomator"; repo = "cryptomator"; rev = version; <del> hash = "sha256-xhj7RUurBRq9ZIDAlcq7KyYGnLqc+vTjaf2VMNStpVQ"; </del> <ins> hash = "sha256-NMNlDEUpwKUywzhXhxlNX7NiE+6wOov2Yt8nTfbKTNI="; </ins> }; mvnParameters = "-Dmaven.test.skip=true"; <del> mvnHash = "sha256-XAIwKn8wMqILMQbg9wM4kHAaRSGWQaBx9AXQyJuUO5k="; </del> <ins> mvnHash = "sha256-jIHMUj7ZQFu4XAvWUywj4f0PbmLHGtU5VRG0ZuKm3mA="; </ins> preBuild = '' VERSION=${version}

Related discussion:
text: In the vault options, vaults can only be mounted as . Steps to reproduce the behavior: cryptomator to a vault options the tab, the combo box does not contain a FUSE item Vaults can be mounted as FUSE volumes In the console output, cryptomator seems to have access to the fuse3 libs in its PATH: Full console output:
I think this might be related to It seems since they switched to the new fuse integration they only search a predefined number of paths. This is also consistent as the nix build of cryptomator works on non nixos linux.
I have the same issue. Does somebody have some workaraound yet? EDIT: so what I am currently doing, which is really not ideal, is just mounting the webdav directory with rclone, which, well, uses FUSE. so yeah rclone has no problems with using FUSE...
The fix for this is merged but not yet released It's in the 4.0.0 milestone of fuse-nio-adapter. I'm currently using the flapak version of Cryptomator.
thank you for the answer! i don't quite understand what is. Is it a dependency of ? Is there a way to manually fetch this so that it works? I'm gonna try the flatpak version of Cryptomator out, thanks for the hint. I actually tried out appimage, but that didn't change anything.
In the 1.11.0-beta2 release of cryptomator, vaults are able to be mounted as FUSE volumes. So once 1.11.0 is fully released (and the nixpkgs version updated), this issue should be fixed. Until the new version of cryptomator is released, you could create an overlay to use the beta version, like I am doing at the moment. Apart from changing the version and hashes, I also needed to change the jdk used to a jdk21 and overriding it to enable JavaFX:
thank you for your response! i hope i am not rude to ask for your help in achieving this myself. i put the following in my : and i also did the overlay.
Code change:
assert stdenv.isLinux; # better than `called with unexpected argument 'enableJavaFX'` mavenJdk.buildMavenPackage rec { pname = "cryptomator"; <del> version = "1.10.1"; </del> <ins> version = "1.11.0"; </ins> src = fetchFromGitHub { owner = "cryptomator"; repo = "cryptomator"; rev = version; <del> hash = "sha256-xhj7RUurBRq9ZIDAlcq7KyYGnLqc+vTjaf2VMNStpVQ"; </del> <ins> hash = "sha256-NMNlDEUpwKUywzhXhxlNX7NiE+6wOov2Yt8nTfbKTNI="; </ins> }; mvnParameters = "-Dmaven.test.skip=true"; <del> mvnHash = "sha256-XAIwKn8wMqILMQbg9wM4kHAaRSGWQaBx9AXQyJuUO5k="; </del> <ins> mvnHash = "sha256-jIHMUj7ZQFu4XAvWUywj4f0PbmLHGtU5VRG0ZuKm3mA="; </ins> preBuild = '' VERSION=${version}

Related discussion:
text: i get the following error when building: haven't been able to successfully find a solution via search engines...
For overlays, I simply copy the nix files and doing the following overlay: This is quite crude, and there is probably a better way to do it, but it at least avoids any weird errors like the one you are having.
Code change:
++ lib.optionals enableTesseract [ tesseract leptonica ] ++ lib.optional enableTbb tbb ++ lib.optionals enableCuda [ cudatoolkit nvidia-optical-flow-sdk ] <del> ++ lib.optionals stdenv.isDarwin [ bzip2 AVFoundation Cocoa VideoDecodeAcceleration ] </del> <ins> ++ lib.optionals stdenv.isDarwin [ bzip2 AVFoundation Cocoa VideoDecodeAcceleration CoreMedia MediaToolbox ] </ins> ++ lib.optionals enableDocs [ doxygen graphviz-nox ]; propagatedBuildInputs = lib.optional enablePython pythonPackages.numpy;

Related discussion:
text: Describe the issue In the opencv build for mac, why is off by default? What needs to be done to enable it? (either development work, dependencies that aren't yet nixpkgs, or, if possible, how to manually override the argument and simply set to ) To Reproduce See above Expected behavior There may be a good reason it's disabled, so I can't say that I'd expect videoio to be enabled by default. Notify maintainers Metadata Please run and paste the result. Maintainer information:
It was removed here 15 months ago: See this PR: due to apple removing most of QTkit in 10.12 Brew does not use this option. You can use an overlay or a nixpkgs checkout with this patch to build with videoio The following will drop you into a nix-shell with the patched opencv, which you can use for testing. I'm not sure if it builds. FWIW, I get the following build failure which indicates the upstream issue might not be resolved, or we're missing some thing in our derivation.
I was originally attempting to use an overlay. After getting nowhere, I made a , which is what redirected me to the nix build. So if you want to help me close that thread, that'd be awesome cause both me and the person that helped me still don't know how to access/change the from an overlay.
Code change:
src = fetchFromGitHub { owner = "rstudio"; repo = "rstudio"; <del> rev = version; </del> <ins> rev = "v${version}"; </ins> sha256 = "sha256-9c1bNsf8kJjpcZ2cMV/pPNtXQkFOntX29a1cdnXpllE="; };

Related discussion:
text: RStudio () fails to build from nixpkgs master with a 404 on downloading sources. 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. --Please run and paste the result. Maintainer information:
Code change:
patches = [ ./sw_vers_root5.patch <del> (fetchpatch { name = "enable_new_gcc.patch"; url = "https://aur.archlinux.org/cgit/aur.git/plain/enable_new_gcc.patch?h=root5&id=91c50876081a0af36f84ec4f0f9dba869107fa4f"; sha256 = "1rnp0xlw0yqi7mjs4w145njd79i8kkir1qik7zwicdik9axf8ygm"; }) </del> # prevents rootcint from looking in /usr/includes and such ./purify_include_paths_root5.patch

Related discussion:
text: , CVSSv3=8.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc
Code change:
''; postFixup = '' <del> makeWrapper ${electron}/bin/electron $out/bin/${pname}  </del> <ins> makeWrapper ${electron_11}/bin/electron $out/bin/${pname}  </ins> --add-flags $out/share/${pname}/resources/app.asar  --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ stdenv.cc.cc libsecret ]}" '';

Related discussion:
text: Describe the bug After electron 12 came out, adding in home-manager succeeds, but trying to start the app fails mentioning a missing javascript function from an older version of electron. To Reproduce Steps to reproduce the behavior: to home-manager's app from terminal with Expected behavior Expected the application start as it had before. Additional context I was able to get it working locally by providing an overlay to home-manager: I would have created a PR myself, but I'm still new to nix and not sure entirely how to require a different electron version in the package derivation. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(jon): nixpkgs: Maintainer information:
thanks for catching this! Just fixed in the PR above.