jiebi/CodeConvo huggingface dataset:
Change:
LCMCR = [ pkgs.gsl ]; BNSP = [ pkgs.gsl ]; scModels = [ pkgs.mpfr.dev ]; <del> multibridge = [ pkgs.mpfr.dev ]; </del> <ins> multibridge = with pkgs; [ pkg-config mpfr.dev ]; </ins> RcppCWB = with pkgs; [ pcre.dev glib.dev ]; redux = [ pkgs.hiredis ]; RmecabKo = [ pkgs.mecab ];

Discussion:
Project description <!-- JASP aims to be a complete statistical package for both Bayesian and Frequentist statistical methods, that is easy to use and familiar to users of SPSS --Metadata homepage URL:https://jasp- source license: agpl3 platforms: window, linux, darwin
PR:
thank you but I had a error when building source
Yes, I get the same error. Unfortunately I could not figure out where the file is supposed to come from. That's why the PR is in draft mode (waiting for someone who knows how to fix the build).
hash = "sha256-h/jFzR5XE+dmETENaBPQ0bCTLJYanpvtJTsMnAwoi9g="; #sha256-h/jFzR5XE+dmETENaBPQ0bCTLJYanpvtJTsMnAwoi9g= sha256-1m0URudMF50pnR7xYuu/d5817ouybaNLTG/h2d1J7rY= fetchSubmodules = true; After changed above, I got error
Change:
platforms = platforms.unix; maintainers = with maintainers; [ babariviere qyliss ]; # ld: symbol(s) not found for architecture x86_64 <del> broken = stdenv.isDarwin; </del> <ins> broken = stdenv.isDarwin && stdenv.isx86_64; </ins> }; }

Discussion:
bear is marked as broken on macOS x86_64 now but it can be built on macOS10.15 as the pkg repo says:
See
Bear for aarch64-darwin re-enabled in
I was trying to install on x86_64-darwin(macOS 11.2), but it kept invoking the old clang-7.0 from nixpkg, how can I force nix-env to compile with the OSX built-int clang-12 or the newest llvm- from nixpkgs? sorry for bothering you with this, I new to nix-env.
You need nixpkgs new enough to include
Change:
<ins> { lib , appimageTools , fetchurl }: appimageTools.wrapType2 rec { pname = "bazecor"; version = "1.3.2"; src = fetchurl { url = "https://github.com/Dygmalab/Bazecor/releases/download/bazecor-${version}/Bazecor-${version}-x64.AppImage"; hash = "sha256-afalUj3EqHX6ctCZgwGRf4kqv9AeVS+PAaBA4iK9jKk="; }; meta = with lib; { description = "Graphical configurator for Dygma Products"; homepage = "https://github.com/Dygmalab/Bazecor"; changelog = "https://github.com/Dygmalab/Bazecor/releases/tag/bazecor-${version}"; license = licenses.gpl3Only; maintainers = with maintainers; [ kashw2 ]; }; } </ins>

Discussion:
Bazecor - Configurator for Dygma keyboards <!-- Describe the project a little: --Bazecor is the graphical configurator for the Dygma Raise and the upcoming Dygma Defy keyboards. Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux, darwin
Change:
hash = "sha256-KA3Bn8skJ2gMmihmwlUmN6jXZmfoYY/f4vqbKwvxwgw="; }; <del> # Patches from ROSA Linux </del> <ins> # Patches from Debian </ins> patches = [ # Disable loading of the missing Animal.dat (fetchpatch { <del> url = "https://abf.io/import/freefilesync/raw/rosa2021.1-11.25-1/ffs_devuan.patch"; sha256 = "sha256-o8T/tBinlhM1I82yXxm0ogZcZf+uri95vTJrca5mcqs="; </del> <ins> url = "https://sources.debian.org/data/main/f/freefilesync/12.0-2/debian/patches/ffs_devuan.patch"; </ins> excludes = [ "FreeFileSync/Source/ffs_paths.cpp" ]; <del> postFetch = '' substituteInPlace $out --replace " for Rosa" "" ''; </del> <ins> hash = "sha256-6pHr5txabMTpGMKP7I5oe1lGAmgb0cPW8ZkPv/WXN74="; </ins> }) # Fix build with GTK 3 (fetchpatch { <del> url = "https://abf.io/import/freefilesync/raw/rosa2021.1-11.25-1/ffs_devuan_gtk3.patch"; sha256 = "sha256-NXt/+BRTcMk8bnjR9Hipv1NzV9YqRJqy0e3RMInoWsA="; postFetch = '' substituteInPlace $out --replace "-isystem/usr/include/gtk-3.0" "" ''; </del> <ins> url = "https://sources.debian.org/data/main/f/freefilesync/12.0-2/debian/patches/ffs_devuan_gtk3.patch"; hash = "sha256-0n58Np4JI3hYK/CRBytkPHl9Jp4xK+IRjgUvoYti/f4="; </ins> }) ]; nativeBuildInputs = [ <del> wrapGAppsHook </del> <ins> copyDesktopItems </ins> pkg-config <ins> wrapGAppsHook unzip </ins> ]; buildInputs = [

Discussion:
For FreeFileSync, add a desktop file to $out/share/applications so that the application can be found in an app launcher. <!-- 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:
zlib ]; <del> # Workaround for libssl.so.10 wanted by TruffleRuby # Resulting TruffleRuby cannot use `openssl` library. autoPatchelfIgnoreMissingDeps = true; </del> nativeBuildInputs = [ unzip perl autoPatchelfHook makeWrapper ]; unpackPhase = ''

Discussion:
Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A 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. Maintainer information:
Change:
# allow us the specify logging directory using env substituteInPlace $out/bin/kafka-run-class.sh  <del> --replace 'LOG_DIR=$base_dir/logs' 'LOG_DIR=$KAFKA_LOG_DIR' </del> <ins> --replace 'LOG_DIR="$base_dir/logs"' 'LOG_DIR="$KAFKA_LOG_DIR"' </ins> for p in $out/bin/*.sh; do wrapProgram $p 

Discussion:
I get this error when trying to use the kafka scripts from the package: $ /nix/store/12ndbm9by7ccsb77lsx4kc9566pk4y6l-apache-kafka-2.10-0.8.2.1/bin/kafka-server- /nix/store/yh8hdd378j1gaaq73gk88ca7gzf590vg-apache-kafka-2.10-0.8.2.1/config/server.properties mkdir: cannot create directory ‘/nix/store/12ndbm9by7ccsb77lsx4kc9566pk4y6l-apache-kafka-2.10-0.8.2.1/bin/../logs’: Read-only file system log4j:ERROR setFile(null,true) call failed. /nix/store/12ndbm9by7ccsb77lsx4kc9566pk4y6l-apache-kafka-2.10-0.8.2.1/bin/../logs/kafka- (No such file or directory) at (Native Method)
Looks like this was fixed in the referenced commit?
This should probably be closed since it appears to be fixed and isn't responding.
Agreed
Change:
extraLoaders = [ librsvg webp-pixbuf-loader <ins> libheif.out </ins> ]; }}" '';

Discussion:
This is required for HEIF/HEIC support in eog work. Modules are trying to install to gdk-pixbuf prefix, (we are patching it in ) where it works. (That can be fixed using the pkg-config env var.) But the file is not generated/installed so the setup hook cannot pick it up. Originally posted by in
I marked this as stale due to inactivity. &rarr;
Does not look stale to me.
I marked this as stale due to inactivity. &rarr;
Still important to me.
I marked this as stale due to inactivity. &rarr;
will make this possible.
Change:
let pname = "zammad"; <del> version = "5.1.0"; </del> <ins> version = "5.1.1"; </ins> src = applyPatches {

Discussion:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc
Change:
# https://github.com/fabioz/PyDev.Debugger/issues/227 "test_to_server_and_to_client" # AssertionError pydevd_tracing.set_trace_to_threads(tracing_func) == 0 <del> "test_tracing_other_threads" </del> <ins> "test_step_next_step_in_multi_threads" </ins> "test_tracing_basic" <ins> "test_tracing_other_threads" # subprocess.CalledProcessError "test_find_main_thread_id" </ins> ] ++ lib.optionals (pythonAtLeast "3.12") [ "test_case_handled_and_unhandled_exception_generator" "test_case_stop_async_iteration_exception"

Discussion:
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]:
I started with but unfortunately there is more to do.
Change:
buildPythonApplication rec { pname = "nixops"; <del> version = "unstable-2023-10-26"; </del> <ins> version = "unstable-2023-12-17"; </ins> pyproject = true; src = fetchFromGitHub { owner = "NixOS"; repo = "nixops"; <del> rev = "2cfc2cb4fa9ecb89a4274574ff7f63ea61782498"; hash = "sha256-4uvQQkERZFEeRJjMAcyLYJzNvH0rNiiJ+5BDQmD58gI="; </del> <ins> rev = "053668e849bb369973cf265b7e8f38e66ef70138"; hash = "sha256-Kus1Ls1tT8fVGLX0NakRXmjuz5/J/tfqU4TLOkiZqvo="; </ins> }; postPatch = ''

Discussion:
Package name: nixops_unstable Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2023-10-26 Current version on the stable/release channel: 2023-10-26 <!-- 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:
sha256 = "sha256-8VF/CD0Wu2eV6wOpj/M6peKDthFWlcg+1NzzTSIH4S8="; }; <del> patches = [ ./vulkan_icd.patch ]; </del> <ins> patches = [ ./vulkan_icd.patch # Remove next version (fetchpatch { url = "https://github.com/bottlesdevs/Bottles/commit/7cb284f9bac0b71bf632bfc70d94f7a53bc51267.patch"; hash = "sha256-mRF+BtQ0qM7Yvx7SONeH2wc04F87fEyNRlBuyQrzN8Y="; }) ]; </ins> # https://github.com/bottlesdevs/Bottles/wiki/Packaging nativeBuildInputs = [

Discussion:
Bottles gets stuck on the "Starting up" screen showing the "Downloading ~20kb of packages" message. Steps to reproduce the behavior: bottles the error message Bottles would start ! Additionally an earlier update broke the bottles listing screen. It would only let you have the "Library" tab active, but wouldn't let you click over to the "Bottles" listing screen. But you could still start the ".exe" file by double clicking it from a file explorer while having Bottles open in the background Please run and paste the result.
Upstream problem , it was fixed by I'll see if it's better to backport now or to wait for the next version. (Someone already backported it on their own repo, )
About the Library tab, it seems that Bottles depends on for it to work. Looking upstream, the cause seems to be . I'm not knowledgeable on how it should be fixed, though.
So, if I manually add to my , will that fix it?
I'm on the channel. Just should pull in the fixes, right? Once the pull request has been merged?
Yes to both questions. (Though not immediately after the merge, you must wait for to update)
Maybe I'm doing something wrong, but I have the same problem. I've updated the flake and rebuild, and it hangs in the same place. I also , but it didn't help.
It's on , but not on .
Change:
- [isolate](https://github.com/ioi/isolate), a sandbox for securely executing untrusted programs. Available as [security.isolate](#opt-security.isolate.enable). <ins> - [ydotool](https://github.com/ReimuNotMoe/ydotool), a generic command-line automation tool now has a module. Available as [programs.ydotool](#opt-programs.ydotool.enable). </ins> - [private-gpt](https://github.com/zylon-ai/private-gpt), a service to interact with your documents using the power of LLMs, 100% privately, no data leaks. Available as [services.private-gpt](#opt-services.private-gpt.enable). ## Backward Incompatibilities {#sec-release-24.05-incompatibilities}

Discussion:
requires to be running in order to be used otherwise it aborts and crashes (see ). It would make sense to have a NixOS configuration option in order to automatically configure to run. Some NixOS module option (perhaps ) that automatically configures and runs as a systemd service in the background.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
url = "https://github.com/ipmitool/ipmitool/commit/5db314f694f75c575cd7c9ffe9ee57aaf3a88866.patch"; sha256 = "01niwrgajhrdhl441gzmw6v1r1yc3i8kn98db4b6smfn5fwdp1pa"; }) <ins> (fetchpatch { name = "CVE-2020-5208.patch"; url = "https://github.com/ipmitool/ipmitool/commit/e824c23316ae50beb7f7488f2055ac65e8b341f2.patch"; sha256 = "sha256-X7MnoX2fzByRpRY4p33xetT+V2aehlQ/qU+aeaqtTUY="; }) </ins> ]; buildInputs = [ openssl ];

Discussion:
, CVSSv3=8.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc
Fixed in
Change:
buildPythonApplication rec { name = "vim-vint-${version}"; <del> version = "0.3.18"; </del> <ins> version = "0.3.19"; </ins> src = fetchFromGitHub { owner = "kuniwak"; repo = "vint"; rev = "v${version}"; <del> sha256 = "0qrlimg385sxq4y6vqbanby31inaa1q47w9qcw5knwffbz96whrs"; </del> <ins> sha256 = "0fb0vkmn5fv4mwk6riw08hb3vsh1pivvrfwm90b95yhksq4pfi12"; </ins> }; # For python 3.5 > version > 2.7 , a nested dependency (pythonPackages.hypothesis) fails.

Discussion:
reasoning: last setuptools release is older than 2 years: distribute is actively maintained and a drop-in replacedment for setuptools: distribute works with python3 and builds for us the next step towards pythonPackages32
Distribute will merge into setuptools (soon?), so we should just wait a bit more, probably.
7: Merged Setuptools and Distribute. See for details.

If I understand correctly, adding the following to should stop easy_install from trying to zip eggs, which inevitably leads to the error: "ZIP does not support timestamps before 1980":
As we anyway use --always-unzip, we probably could use that. Though I don't know whether it would actually solve the problem. Apart from that a solution is already in stdenv-updates: The error occurs e.g. for git checkout, where the whole directory is copied into the store and all timestamps set to epoch 0, this is the equivalent to a tarball in the store. For building the package, the directory is copied into a temporary build directory and timestamps where preserved, that is not set to "now". A temporary workaround is used by charon:
Ah ok, that would explain why I noticed the error when using fetchhg.
Can someone check if this is still an issue now that stdenv-updates is merged?
Closing, if problem repeats, open the issue again.
For those coming in from Google on this error, it's very possible there are in fact files that have corrupt touch dates older than 1980. This raises when the of a file in the packaging tree is older than 1980. This even happened for me when zipsafe was set to You can see if you have any of these files with: In my case, there were nodemodules with corrupt dates that I simply needed to exclude through my Also see
I fixed this by invoking . My has a , so I put it in its . I found this workaround in the . Certainly this is a ridiculous thing to have to do as an end user.
your suggestion worked. Many thanks!
There are several closed tickets with this issue, so noting this on a few of them in case it interests someone. Was looking through the and happened to notice this Looks like the default is strict_timestamps=True Could be a reasonable thing to patch I think.
Change:
url = "https://github.com/pixlsus/registry.gimp.org_static/raw/master/registry.gimp.org/files/wavelet-sharpen-0.1.2.tar.gz"; sha256 = "0vql1k67i21g5ivaa1jh56rg427m0icrkpryrhg75nscpirfxxqw"; }; <del> installPhase = "installPlugins src/wavelet-sharpen"; # TODO translations are not copied .. How to do this on nix? </del> <ins> installPhase = "installPlugin src/wavelet-sharpen"; # TODO translations are not copied .. How to do this on nix? </ins> }; lqrPlugin = pluginDerivation rec {

Discussion:
Describe the bug I'm adding gimp like this in 20.09: However the fourier plugin is not being recognized. It should add: Filters/Generic/Forward FFT Filters/Generic/Inverse FFT But these filters are missing. Expected behavior FFT plugin should be recognized by gimp. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
I'm not sure about these specific plugins, but gimp-with-plugins comes with G'MIC, which includes a FFT filter under Filters -G'MIC Qt... -Available Filters -Frequency -Fourier transform
Change:
</varlistentry> <varlistentry> <term> <del> <option>--verbose</option> </term> <listitem> <para> This option enables verbose mode, which currently is just the Bash <command>set</command> <option>-x</option> debug mode. </para> </listitem> </varlistentry> <varlistentry> <term> <option>--xml</option> </del> <ins> <option>--all</option> </ins> </term> <listitem> <para> <del> This option causes the output to be rendered as XML. </del> <ins> Print the values of all options. </ins> </para> </listitem> </varlistentry>

Discussion:
We can currently display a NixOS module option type using, for example: . It seems to me that, to maximize usability, should display this string. Also, the should display this information. Perhaps it should be toggleable, though, since options involving submodule types could be quite large. EDIT: Apparently the field is currently for any submodule type. It would be nice to either pretty-print the whole type or output some kind of structured data there. Run . There is no indication of the type of this option other than the default/example values. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc
This was fixed in .
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 .
Change:
license     = licenses.lgpl21; maintainers = with maintainers; [ lluchs ]; platforms   = [ "x86_64-linux" ]; <del> broken = true; </del> }; }

Discussion:
I try to install vivaldi-ffmpeg-codecs, it tries to build it — Just try to install vivaldi-ffmpeg-codecs. there was the same thing in previous 18.03.
I found that was removed in . Here it is in the : And the helpful thread:
I tried bluntly update the chromium source where codecs stored. But it failed:
That patch is marked .
Let's call submitter:
I tried bluntly update the chromium source where codecs stored. This is the right approach, but you'll also have to remove the old patches and check whether you need any newer . The patches used by the are usually a good starting point.
So unless I'm mistaken, shouldn't we just build chromium & provide a vivaldi output? The chromium build is huge & we don't want Hydra to have to do it multiple times. What's the intended use of ffmpeg-vivaldi-codecs? I think we can disable libcxx building with in args, though.
As i can see, there are some license issues (?) with something like h264. So we build in on "client" side from sources (probably it's x264)... I don't know exactly...
Providing a Vivaldi output from chromium (as suggests) is difficult because chromium moves at a different speed than Vivaldi, so the resulting library may not fit properly. I don't know how often this happens, but it looks like upstream ffmpeg changes their ABI fairly often. The build actually isn't that much of an issue. The only difficulty is having to download and extract the full chromium tarball, the compile times are short as we only need . What's the intended use of ffmpeg-vivaldi-codecs? Vivaldi (the company) cannot distribute certain codecs in ffmpeg in their packages, so we have to compile that separately.
Change:
license     = licenses.lgpl21; maintainers = with maintainers; [ lluchs ]; platforms   = [ "x86_64-linux" ]; <del> broken = true; </del> }; }

Discussion:
This probably isn't a strictly NixOS issue, but nevertheless should be mentioned. The hash for vivaldi-stable2.1.1337.51-1 has changed. The old one in nixpkgs is 08x6abyz65vx4ycj8ys8sib9z1adb8ybmnrqjck69b30kbz78rj2, while nix-env reports 00rxp6rardxjg17g2b28y2rj8szqlainp4ga6c58z981zkxvdlls. to unstable channels. -env -i vivaldi system: host os: multi-user?: sandbox: version: channels(void): channels(root): nixpkgs:
unfortunately, sometimes software projects update different package sources with different sha256sums on their website, which will then error during build, until it gets fixed again Can you add a Pull Request, updating the hash in
Change:
palettable = callPackage ../development/python-modules/palettable { }; <del> pam = callPackage ../development/python-modules/pam { inherit (pkgs) pam; }; </del> <ins> # Alias. Added 2020-09-07. pam = self.python-pam; </ins> pamela = callPackage ../development/python-modules/pamela { };

Discussion:
Describe the bug , which provides the "pam" namespace to everything in python-packages. This is fine, except this also broke the definition of , which packages the same library at the same version. To Reproduce Steps to reproduce the behavior: build result/lib/python3.8/site- points at a non-existent SO in the "pam" Python package Expected behavior Only one, working definition of this Python package. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
The problem is that the python-pam probably is referencing the pam python package from the current scope, which I solved in my package by inheriting from the parent scope. The reason why pam was created in the first place is because I got confused because of the name and I imagine the reason it was named python-pam by the original author is to solve the inherit issue in another way, namely renaming it. I'd be in favour of the name "pam" because that's how the module is being called (unless both modules do have differences, then we need both)
I'm not particularly fussed about which one "wins", just that we should probably only have one of them. I agree that "pam" is probably a better name - it's just a little unergonomic to use in the tree.
Thanks for reporting. See