jiebi/CodeConvo huggingface dataset:
Code change:
]; configureFlags = [ <del> # TODO(Profpatsch): mupdf support </del> <ins> "--with-mutool-path=${mupdf}/bin/mutool" </ins> "--with-pdftops=pdftops" "--with-pdftops-path=${poppler_utils}/bin/pdftops" "--with-gs-path=${ghostscript}/bin/gs"

Related discussion:
text: Configuration summary shows several incorrect paths: liblouis tables can probably be easily corrected, not sure what to do about cups dom socket and font directory. nixpkgs: cc
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 .
Code change:
odbc = "sha256-T+RIIKzZ9xEg/E72pfs5xqHz2WuIWKx/oRfDrQbw3ms="; }; x86_64-darwin = { <del> basic = "f4335c1d53e8188a3a8cdfb97494ff87c4d0f481309284cf086dc64080a60abd"; sdk = "b46b4b87af593f7cfe447cfb903d1ae5073cec34049143ad8cdc9f3e78b23b27"; sqlplus = "f7565c3cbf898b0a7953fbb0017c5edd9d11d1863781588b7caf3a69937a2e9e"; tools = "b2bc474f98da13efdbc77fd05f559498cd8c08582c5b9038f6a862215de33f2c"; odbc = "f91da40684abaa866aa059eb26b1322f2d527670a1937d678404c991eadeb725"; </del> <ins> basic = "sha256-V+1BmPOhDYPNXdwkcsBY1MOwt4Yka66/a7/HORzBIIc="; sdk = "sha256-D6iuTEQYqmbOh1z5LnKN16ga6vLmjnkm4QK15S/Iukw="; sqlplus = "sha256-08uoiwoKPZmTxLZLYRVp0UbN827FXdhOukeDUXvTCVk="; tools = "sha256-1xFFGZapFq9ogGQ6ePSv4PrXl5qOAgRZWAp4mJ5uxdU="; odbc = "sha256-S6+5P4daK/+nXwoHmOkj4DIkHtwdzO5GOkCCI612bRY="; </ins> }; }.${stdenv.hostPlatform.system} or throwSystem;

Related discussion:
text: Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:
Code change:
./services/hardware/lcd.nix ./services/hardware/lirc.nix ./services/hardware/nvidia-container-toolkit-cdi-generator <ins> ./services/hardware/monado.nix </ins> ./services/hardware/nvidia-optimus.nix ./services/hardware/openrgb.nix ./services/hardware/pcscd.nix

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:
<del> --- qemu-2.10.0-clean/linux-user/syscall.c	2020-03-12 18:47:47.898592169 +0100 +++ qemu-2.10.0/linux-user/syscall.c	2020-03-13 09:13:42.461809699 +0100 @@ -34,6 +34,7 @@ #include <sys/resource.h> #include <sys/swap.h> #include <linux/capability.h> +#include <linux/sockios.h> // https://lkml.org/lkml/2019/6/3/988 #include <sched.h> #include <sys/timex.h> #ifdef __ia64__ @@ -256,7 +257,9 @@ static type name (type1 arg1,type2 arg2, #endif #ifdef __NR_gettid -_syscall0(int, gettid) +// taken from https://patchwork.kernel.org/patch/10862231/ +#define __NR_sys_gettid __NR_gettid +_syscall0(int, sys_gettid) #else /* This is a replacement for the host gettid() and must return a host errno. */ @@ -6219,7 +6222,7 @@ static void *clone_func(void *arg) cpu = ENV_GET_CPU(env); thread_cpu = cpu; ts = (TaskState *)cpu->opaque; -    info->tid = gettid(); +    info->tid = sys_gettid(); task_settid(ts); if (info->child_tidptr) put_user_u32(info->tid, info->child_tidptr); @@ -6363,9 +6366,9 @@ static int do_fork(CPUArchState *env, un mapping.  We can't repeat the spinlock hack used above because the child process gets its own copy of the lock.  */ if (flags & CLONE_CHILD_SETTID) -                put_user_u32(gettid(), child_tidptr); +                put_user_u32(sys_gettid(), child_tidptr); if (flags & CLONE_PARENT_SETTID) -                put_user_u32(gettid(), parent_tidptr); +                put_user_u32(sys_gettid(), parent_tidptr); ts = (TaskState *)cpu->opaque; if (flags & CLONE_SETTLS) cpu_set_tls (env, newtls); @@ -11402,7 +11405,7 @@ abi_long do_syscall(void *cpu_env, int n break; #endif case TARGET_NR_gettid: -        ret = get_errno(gettid()); +        ret = get_errno(sys_gettid()); break; #ifdef TARGET_NR_readahead case TARGET_NR_readahead: </del>

Related discussion:
text: Steps to reproduce the behavior: afl <!-- 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]:
If you are planing to open a PR, you don't need to create an issue first.
I wasn't sure, thanks for clarification
Code change:
<ins> { stdenv, fetchurl, unzip }: stdenv.mkDerivation { name = "lmmath-0.903"; src = fetchurl { url = "http://www.gust.org.pl/projects/e-foundry/lm-math/download/lmmath0903otf"; sha256 = "ee96cb14f5c746d6c6b9ecfbdf97dafc2f535be3dd277e15e8ea6fb594995d64"; name = "lmmath-0.903.zip"; }; buildInputs = [unzip]; sourceRoot = "."; installPhase = '' mkdir -p $out/texmf/fonts/opentype mkdir -p $out/share/fonts/opentype cp *.{OTF,otf} $out/texmf/fonts/opentype/lmmath-regular.otf cp *.{OTF,otf} $out/share/fonts/opentype/lmmath-regular.otf ln -s $out/texmf* $out/share/ ''; meta = { description = "Latin Modern font"; }; } </ins>

Related discussion:
text: Describe the bug Thunderbird 78.2.1 is working. master (Thunderbird 78.2.2) has rendering issues (see screenshot). Most buttons do not react to clicks and the menu is also not reacting. To Reproduce Switch to the mentioned commit and rebuild. Expected behavior Normally working thunderbird. Screenshots ! Notify maintainers Metadata
This was also a bug in Ubuntu, it was fixed there with:
Upstream bug appears to be
Btw temporary workaround would be to switch to thunderbird-bin-78 if you are not opposed to binaries
Code change:
<ins> { stdenv, fetchurl, unzip }: stdenv.mkDerivation { name = "lmmath-0.903"; src = fetchurl { url = "http://www.gust.org.pl/projects/e-foundry/lm-math/download/lmmath0903otf"; sha256 = "ee96cb14f5c746d6c6b9ecfbdf97dafc2f535be3dd277e15e8ea6fb594995d64"; name = "lmmath-0.903.zip"; }; buildInputs = [unzip]; sourceRoot = "."; installPhase = '' mkdir -p $out/texmf/fonts/opentype mkdir -p $out/share/fonts/opentype cp *.{OTF,otf} $out/texmf/fonts/opentype/lmmath-regular.otf cp *.{OTF,otf} $out/share/fonts/opentype/lmmath-regular.otf ln -s $out/texmf* $out/share/ ''; meta = { description = "Latin Modern font"; }; } </ins>

Related discussion:
text: Steps to reproduce the behavior: 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
might be fixed by confirmed. closing.
Hello. I'm new to NixOS, and also facing this problem: How can I apply that fix? I just updated my NixOS system flake to latest version: But still getting error during system rebuild:
try and update again, the fix is in unstable now.
Code change:
source $cc_wrapper/nix-support/add-local-cc-cflags-before.sh fi <del> # May need to transform the triple injected by the above. for ((i = 1; i < ${#extraBefore[@]}; i++)); do if [[ "${extraBefore[i]}" = -target ]]; then </del> <ins> for ((i=0; i < ${#extraBefore[@]}; i++));do case "${extraBefore[i]}" in -target) </ins> i=$((i + 1)) # On Darwin only, need to change 'aarch64' to 'arm64'. extraBefore[i]="${extraBefore[i]/aarch64-apple-/arm64-apple-}" # On Darwin, Swift requires the triple to be annotated with a version. # TODO: Assumes macOS. extraBefore[i]="${extraBefore[i]/-apple-darwin/-apple-macosx${MACOSX_DEPLOYMENT_TARGET:-11.0}}" <del> break fi </del> <ins> ;; -march=*) [[ i -gt 0 && ${extraBefore[i-1]} == -Xcc ]] && continue extraBefore=( "${extraBefore[@]:0:i}" -Xcc "${extraBefore[@]:i:${#extraBefore[@]}}" ) i=$((i + 1)) ;; esac </ins> done # As a very special hack, if the arguments are just `-v', then don't

Related discussion:
text: Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…
Code change:
, buildGoModule , runCommandLocal # Native build inputs <ins> , addDriverRunpath </ins> , makeWrapper , pkg-config , util-linux , which # Build inputs , bash <ins> , callPackage </ins> , conmon , coreutils , cryptsetup

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:
, buildGoModule , runCommandLocal # Native build inputs <ins> , addDriverRunpath </ins> , makeWrapper , pkg-config , util-linux , which # Build inputs , bash <ins> , callPackage </ins> , conmon , coreutils , cryptsetup

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:
, buildGoModule , runCommandLocal # Native build inputs <ins> , addDriverRunpath </ins> , makeWrapper , pkg-config , util-linux , which # Build inputs , bash <ins> , callPackage </ins> , conmon , coreutils , cryptsetup

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:
nativeBuildInputs = [ wrapGAppsHook gettext ]; <del> checkInputs = with python3.pkgs; [ pytest pytest_xdist pyflakes pycodestyle polib xvfb_run dbus.daemon glibcLocales ]; </del> <ins> checkInputs = [ gdk-pixbuf ] ++ (with python3.pkgs; [ pytest pytest_xdist polib xvfb_run dbus.daemon glibcLocales ]); </ins> buildInputs = [ gnome3.adwaita-icon-theme libsoup glib glib-networking gtk3 webkitgtk gdk-pixbuf keybinder3 gtksourceview libmodplug libappindicator-gtk3 kakasi gobject-introspection ] ++ (if xineBackend then [ xineLib ] else with gst_all_1;

Related discussion:
text: fails to install on . It worked before the recent update. It fails early on in the check phase. I'm guessing the fact that I have to build it from source at all is because it also fails everywhere else, so there's no cached build to download. Try to install on system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Hmm, the tests worked just fine for me on
Do they work for you now? What's kinda weird is that I never get an error message or anything. You see in the output I posted above, there's just loads of dots. It kind of sits there printing dots for a while and then it looks like it just times out or something.
For what it's worth if I put in the derivation, the resulting player is perfectly functional at least for my purposes. Haven't tested every feature or anything though.
I think it crashes during the test. I will try bisecting.
Bisecting was inconclusive because I ran out of resources when building webkitgtk.
What commands did you run? I have a server with plenty of resources that's just sitting idle at the moment, I could try run it on that.
but I guess it might make more sense to skip the builds where dependencies failed by running something like:
Cool, I've been running this for a while, for what it's worth it's currently narrowed it down to between and .
I'll let you know in the morning when it's finished.
The original bisect command I ran didn't take into account the case where dependencies failed to build, so I had to run it again with a script like the one you suggested. Here's the output of :
FWIW I managed to build it by setting in an overlay. Works for me, but I wouldn't suggest that this is done in the Hydra build of course!
Yeah, we should probably add in the expression if this still occurs.
I get quite a bit further, attempting to build rather than . The entire test suite finishes, then reports three test failures related to icons and GTK / GDK.
Seems like the tests are failing again
I marked this as stale due to inactivity. &rarr;
EDIT: Kindly ignore this comment, didn't notice that I was using the deprecated repository. Hi, I'm encountering the same errors as reported previously. In case anyone else is experiencing the same, I was able to fix them using:
Code change:
+ " -drive if=pflash,format=raw,unit=1,file=$efiVars"); } '' <del> # Create a /boot EFI partition with 60M and arbitrary but fixed GUIDs for reproducibility </del> <ins> # Create a /boot EFI partition with 120M and arbitrary but fixed GUIDs for reproducibility </ins> ${pkgs.gptfdisk}/bin/sgdisk  --set-alignment=1 --new=1:34:2047 --change-name=1:BIOSBootPartition --typecode=1:ef02  --set-alignment=512 --largest-new=2 --change-name=2:EFISystem --typecode=2:ef00 

Related discussion:
text: During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- 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:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in
Code change:
PrivateMounts = true; PrivateUsers = true; MemoryDenyWriteExecute = true; <del> SystemCallFilter = "~@chown @clock @cpu-emulation @debug @keyring @memlock @module @mount @obsolete @privileged @raw-io @reboot @resources @setuid @swap"; </del> <ins> SystemCallFilter = "~@clock @cpu-emulation @debug @keyring @memlock @module @mount @obsolete @raw-io @reboot @resources @setuid @swap"; </ins> SystemCallArchitectures = "native"; RestrictAddressFamilies = "AF_UNIX AF_INET AF_INET6"; };

Related discussion:
text: Describe the bug gitea fails to start due to a too restrictive systemd setup To Reproduce Looks like is a bit too restrictive. :smile:
ping
Removing the blacklist of and gets us past the test, I think, but there's still problems with the socket.
Judging from this error output: it looks like it fails in prescript during in Interestingly enough, there is a right underneath that, in which does not seem to be the issue. This does not look like an issue with Gitea itself, since it fails during the service pre script. Since the and will only be run if the configuration is managed by nix, the tests pass if I set in the test config. (unfortunatly I don't know much about systemd services and especially systemd sanboxing, so I'm not sure if the information from above is useful or not)
Any chance the service is broken too? I recently updated and service failed to start. I haven't dug into it yet... I may have seen something about a database permission issue.
Temporary fix for someone who using bleeding-edge Gitea:
This doesn't solve the issue for me. I get the following output:
Pretty strange. It works for me (). You can try to disable it at all () and if it'll still not work then just change in the same way all other parameters to default values that were introduced in . p.s. probably there's must be something like a mkForceRemove, but I haven't found anything in manual.
Ok the fix is actually working, I just had an own AmbientCapabilities definition in my configuration which didn't play nicely with the new options.