jiebi/CodeConvo huggingface dataset:
Change:
}; in buildFHSEnv { <del> inherit (package) pname meta; </del> <ins> inherit (package) pname version meta; </ins> runScript = "${package.outPath}/bin/stm32cubemx"; targetPkgs = pkgs: with pkgs; [

Discussion:
Package name: stm32cubemx Latest released version: 6.11.1 <!-- Search your package here: --- Current version on the unstable channel: 6.10.0 Current version on the stable/release channel: 6.9.2 <!-- 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:
passwordDescription = '' The options {option}`hashedPassword`, <del> {option}`password` and {option}`passwordFile` </del> <ins> {option}`password` and {option}`hashedPasswordFile` </ins> controls what password is set for the user. {option}`hashedPassword` overrides both <del> {option}`password` and {option}`passwordFile`. {option}`password` overrides {option}`passwordFile`. </del> <ins> {option}`password` and {option}`hashedPasswordFile`. {option}`password` overrides {option}`hashedPasswordFile`. </ins> If none of these three options are set, no password is assigned to the user, and the user will not be able to do password logins. If the option {option}`users.mutableUsers` is true, the

Discussion:
Password hashes, while less sensitive than unhashed passwords, are secrets. We should therefore have a option in that avoids both placing the hashes in the store world-readable and storing the password unhashed.
This is a common misunderstanding due to the bad naming of these options: → string of plaintext password → string of password hash → file containing password hash So, what you want already exists and it's .
Oh wow, indeed. Thanks! Given that the option is named so confusingly and that its description starts with "The full path to a file that contains the user's password." I think we should keep the issue, pending an option rename and a documentation improvement.
Change:
CacheDirectory = dirs cacheDirs; RuntimeDirectory = dirName; ReadWriteDirectories = lib.mkIf useCustomDir [ cfg.storageDir ]; <del> StateDirectory = dirs (lib.optional (!useCustomDir) libDirs); </del> <ins> StateDirectory = dirs (lib.optionals (!useCustomDir) libDirs); </ins> LogsDirectory = dirName; PrivateTmp = true; ProtectSystem = "strict";

Discussion:
After Zoneminder module partially broke. If you don't set the system won't build. Steps to reproduce the behavior: module. not set option or make it . to build It builds. This happened probably because of a typo: instead of . <!-- 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:
preStart = '' mkdir -p /var/run/slapd chown -R ${cfg.user}:${cfg.group} /var/run/slapd <del> mkdir -p /var/db/openldap chown -R ${cfg.user}:${cfg.group} /var/db/openldap </del> <ins> mkdir -p ${cfg.dataDir} chown -R ${cfg.user}:${cfg.group} ${cfg.dataDir} </ins> ''; <del> serviceConfig.ExecStart = "${openldap}/libexec/slapd -u openldap -g openldap -d 0 -f ${configFile}"; </del> <ins> serviceConfig.ExecStart = "${openldap}/libexec/slapd -u ${cfg.user} -g ${cfg.group} -d 0 -f ${configFile}"; </ins> }; <del> users.extraUsers = optionalAttrs (cfg.user == "openldap") (singleton { name = "openldap"; </del> <ins> users.extraUsers.openldap = { name = cfg.user; </ins> group = cfg.group; uid = config.ids.uids.openldap; <del> }); </del> <ins> }; </ins> <del> users.extraGroups = optionalAttrs (cfg.group == "openldap") (singleton { name = "openldap"; </del> <ins> users.extraGroups.openldap = { name = cfg.group; </ins> gid = config.ids.gids.openldap; <del> }); </del> <ins> }; </ins> }; }

Discussion:
There seems to be even more wrong with openldap as mentioned in When I declare openldap as follows: The service won't start due to: Shouldn't the be linked to /etc? It is not.
Set to something else:
Still not working:
I guess you have to create this directory with proper permissions. And yeah, I wouldn't use /var/run for databases. ;-)
Hmm, looking at the module I would suggest using . This directory is automatically created by systemd service and gets the right permissions.
Change:
patches = [ ./tag-date.patch ./setuptools-distutils-C++.patch <ins> # Use sysconfigdata to find headers. Fixes cross-compilation of extension modules. # https://github.com/pypa/distutils/pull/145 (fetchpatch { url = "https://github.com/pypa/distutils/commit/aed7294b7b0c228cc0666a8b04f2959bf310ab57.patch"; hash = "sha256-/9+TKv0nllBfnj48zcXLrOgyBj52dBIVbrpnIaQ4O84="; stripLen = 2; extraPrefix = "setuptools/_distutils/"; }) </ins> ]; buildPhase = ''

Discussion:
Try to build for . Note, I'm trying staging because is necessary. fails: staging is at :
This was caused by setuptools 60, which now uses bundled distutils. All Python packages with extension modules fail to cross-compile currently, but this will be fixed by . I also noticed that the libbtrfsutil Python bindings are never actually installed, so I also created .
Change:
./services/desktops/profile-sync-daemon.nix ./services/desktops/telepathy.nix ./services/development/hoogle.nix <ins> ./services/editors/emacs.nix </ins> ./services/games/factorio.nix ./services/games/ghost-one.nix ./services/games/minecraft-server.nix

Discussion:
Several users are manually adding a systemd user service to their . It would be better to create a NixOS module so that people don't copy/paste half-baked definitions. What do you think?
/cc
Versions of such a user service can be found at: Please tell me where I can find your version so we merge them all
On a related note, I use an XDG autostart to start the Emacs daemon. This may be preferable for some people because the environment will be set up correctly, though there are of course other ways to achieve this.
Sounds like a great idea to me. Those versions look quite similar to mine. build my emacs with GTK3 enabled. So there would obviously need to be a config option. there be a configuration option for the list of Melpa packages, or would this be handled using and the option? : Tikon's config. Having will result in starting emacs for every user who logs in. For a general NixOS module it would be best to leave empty and let the user enable the service with (or adding a symlink in ). : Damien's config, You probably already know, but setting the variable could be achieved by putting this in your configuration: Other variables such as should already be taken care of by sourcing . note that systemd socket activation for Emacs server was implemented in April and should appear in Emacs 25.2.
Please see PR . thanks for your feedback. I didn't do anything special yet. I have the impression allowing that would just duplicate features. But I really don't know. Any opinion?
Yes, it does overlap a little. I am trying to find out if it's possible to make the configuration of emacs any simpler for newcomers. In this case, I think not.
Change:
installPhase = '' mkdir -p $out/bin cp * $out/bin/ <ins> '' + optionalString stdenv.isLinux '' </ins> wrapProgram $out/bin/pulumi --set LD_LIBRARY_PATH "${stdenv.cc.cc.lib}/lib" ''; <del> buildInputs = optionals stdenv.isLinux [ autoPatchelfHook makeWrapper ]; </del> <ins> nativeBuildInputs = optionals stdenv.isLinux [ autoPatchelfHook makeWrapper ]; </ins> meta = { homepage = "https://pulumi.io/";

Discussion:
Describe the bug The derivation To Reproduce Steps to reproduce the behavior: -env -iA Expected behavior Successful install. Additional context Notify maintainers Metadata Please run and paste the result.
Change:
mkdir -p -m 0755 /run/binfmt ${lib.concatStringsSep "n" (lib.mapAttrsToList activationSnippet config.boot.binfmt.registrations)} ''; <del> systemd.additionalUpstreamSystemUnits = lib.mkIf (config.boot.binfmt.registrations != {}) [ "proc-sys-fs-binfmt_misc.automount" "proc-sys-fs-binfmt_misc.mount" ]; </del> <ins> systemd.additionalUpstreamSystemUnits = lib.mkIf (config.boot.binfmt.registrations != {}) [ "proc-sys-fs-binfmt_misc.automount" "proc-sys-fs-binfmt_misc.mount" "systemd-binfmt.service" ]; </ins> }; }

Discussion:
Describe the bug The indicates a dependency on . However, this unit is not automatically included with the help of . It is therefore listed as : highlights this: Expected behavior Units that are relied upon should be found. Additional context Commit seems to something to do with it. Notify maintainers Metadata Please run and paste the result. Maintainer information:
This has last been touched in I see we set in if , so we could move there as well. After reading a bit on and , is this currently halfway broken? Maybe more of the logic should be moved into …
Can you see if fixes this for you? You might want to reboot, to make sure the mount isn't active. Also, do you use any binfmt stuff?
Yes, it fixes the problem: I do not think so. I am not familiar with binfmt.
Change:
<ins> diff --git a/source/creator/config.d b/source/creator/config.d index 4289703..d8dea4e 100644 --- a/source/creator/config.d +++ b/source/creator/config.d @@ -30,7 +30,7 @@ enum INC_BANNER_ARTIST_PAGE = "https://mastodon.art/@nighteden"; /** URI for bug reports, for unofficial builds this SHOULD be changed. */ -enum INC_BUG_REPORT_URI = "https://github.com/Inochi2D/inochi-creator/issues/new?assignees=&labels=bug&template=bug-report.yml&title=%5BBUG%5D"; +enum INC_BUG_REPORT_URI = "https://github.com/NixOS/nixpkgs/issues/new?assignees=@assignees@&labels=0.kind%3A+bug&projects=&template=bug_report.md&title=inochi-creator:"; /** URI for feature requests, for the most part this doesn't need to be changed </ins>

Discussion:
Project description Open Source Real-time 2D Animation inochi-creator, inochi-session should be packaged as separated packages. There was some debate about Inochi2D in initiated by its author. If you want to package it, read the mentioned issue first. It seems that the debate was settled: the author agrees that nixpkgs can package Inoshi2D under complying their demands. However, no PR packaging Inochi2D was opened after that, so I am opening this issue. Metadata homepage URL: source URL: , license: bsd 2-clause (not including proprietary assets) platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
join-desktop = callPackage ../applications/misc/join-desktop { }; <ins> json-plot = callPackage ../applications/graphics/json-plot {}; </ins> libbitcoin = callPackage ../tools/misc/libbitcoin/libbitcoin.nix { boost = boost175; # fatal error: 'boost/interprocess/detail/posix_time_types_wrk.hpp' file not found };

Discussion:
Project description Dead simple terminal plots from JSON (or CSV) data. Bar charts, line charts, scatter plots, histograms and heatmaps are supported. Written in go. Metadata homepage URL: source URL: license: platforms: Issues At the moment ().
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
still import to me
I marked this as stale due to inactivity. &rarr;
Change:
export QTCOMPOSE=${xorg.libX11}/share/X11/locale export LIBARCHIVE=${libarchive.lib}/lib/libarchive.so # Allows `conda activate` to work properly <del> source ${installationPath}/etc/profile.d/conda.sh </del> <ins> condaSh=${installationPath}/etc/profile.d/conda.sh if [ ! -f $condaSh ]; then conda-install fi source $condaSh </ins> ''; runScript = "bash -l";

Discussion:
I was following the instructions at to run stable-diffusion and when running I got which I found surprising (especially as it's the first progran that I run that get into a FHS). I am not sure what I would expect, maybe recommand to run if the folder doesnt exist ?
You are sure ` has the right shebang?
Same problem here
I had this problem too. Here is a flake that fixes it. I'll create a PR too.
Change:
<ins> { buildPythonPackage , blessed , fetchPypi , lib , mockito , nvidia-ml-py , psutil , pytest-runner , pythonRelaxDepsHook , pytestCheckHook }: buildPythonPackage rec { pname = "gpustat"; version = "1.0.0"; src = fetchPypi { inherit pname version; sha256 = "sha256-WB6P+FjDLJWjIruPA/HZ3D0Xe07LM93L7Sw3PGf04/E="; }; nativeBuildInputs = [ pythonRelaxDepsHook ]; pythonRelaxDeps = [ "nvidia-ml-py" ]; propagatedBuildInputs = [ blessed nvidia-ml-py psutil ]; checkInputs = [ mockito pytestCheckHook ]; pythonImportsCheck = [ "gpustat" ]; meta = with lib; { description = "A simple command-line utility for querying and monitoring GPU status"; homepage = "https://github.com/wookayin/gpustat"; license = licenses.mit; maintainers = with maintainers; [ billhuang ]; }; } </ins>

Discussion:
Project description Ray is a fast and simple framework for building and running distributed applications. It is packaged with RLlib, a scalable reinforcement learning library. The project provides a wheel at , but according to NixOs is by default not compatible. Metadata homepage URL: source URL: license: apache2 platforms: unix, linux
I'm interested in this as well, when I try to use any sort of non-local mode with ray installed in a nix-shell environment via pip, it throws errors launching redis. Even though redis-server exists at the aforemention path. It fails to launch when I attempt to execute redis directly.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I haven't tested, but since manylinux1 is available by default now (), does it work on your machine on the latest unstable?
I still have the issue with redis unfortunately
this seems to work
I see, the s fixed it.
I marked this as stale due to inactivity. &rarr;
Still important to me.
I marked this as stale due to inactivity. &rarr;
In case anyone is still looking for this - it is packaged in python-on-nix
Change:
In an effort to keep the Nixpkgs manual in a consistent style, please follow the conventions below, unless they prevent you from properly documenting something. In that case, please open an issue about the particular documentation convention and tag it with a "needs: documentation" label. <ins> When needed, each convention explain why it exists, so you can make a decision whether to follow it or not based on your particular case. Note that these conventions are about the **structure** of the manual (and its source files), not about the content that goes in it. You, as the writer of documentation, are still in charge of its content. </ins> - Put each sentence in its own line. This makes reviews and suggestions much easier, since GitHub's review system is based on lines.

Discussion:
While working on some documentation on Nixpkgs, I noticed that there doesn't seem to be a convention for showing shell commands and their outputs. prepends to the command prompt, and output as a normal, not-indented line. adds a comment above the command prompt showing what the output is. uses two different code blocks, one with the command, the other with the output. Additionally, there are other code blocks to show expressions and their result inside the nix repl: prepends to the (error) output. And prepends to the output. Note that the proposal below was written just to have some starting proposal, but not much thought has been given to other alternatives yet. My current proposal is to adopt the following convention: For shell commands and outputs, prepend to any lines that are part of the command, and put outputs in their own lines as-is. If the command has line continuations, don't prepend , but add some indentation to keep it from looking like an output. For example: For nix repl expressions, prepend to any lines part of an expression, and put outputs in their own lines as-is. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Talked about this in the docs team meeting, I think this is a good idea! If you make a PR to describe this convention in the I could review/merge it. I guess very generally, the convention is to use the format as you'd see it in the REPL.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
There are no functional changes, however this may require updating some configurations to use correct types for all attributes. </para> </listitem> <ins> <listitem> <para> The <literal>fontconfig</literal> module stopped generating fontconfig 2.10.x config and cache. Fontconfig 2.10.x was removed from Nixpkgs - it hasn't been used in any nixpkgs package anymore. </para> </listitem> </ins> </itemizedlist> </section> </section>

Discussion:
, CVSSv3=7.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
See also:
PR for unstable: PR for 20.03:
This is still an issue.
oops, sorry
We only use config files. We could probably just delete everything but from the derivation, or remove it from top-level.
Yeah, but we still ship the fontconfig binary in nixpkgs. Is there any reason we still need to provide config files parse-able by 2.10.x fontconfig implementations?
I doubt there is much of a reason these days, nobody will be running programs compiled against fontconfig 2.10. I just do not want to remove it now so that possible breakage caused by is not mixed with potential downfall from removing the unversioned path.
is a new attempt to address this.
Change:
hash = "sha256-zvoN+8Sx6qpVg2JeRLOIH1ehfl3tFTv7r5wQZ44Qsbc="; }; <ins> patches = lib.optionals withOpenCL [ (substituteAll { src = ./opencl.patch; ocl_icd = ocl-icd; }) ]; </ins> postPatch = '' sed -ri -e ' s!^(#defines+CFG_[A-Z]+_NAMEs+).*/!1"'"$out"'/etc/john/!

Discussion:
Project description Is it possible to add OpenCL support to ? Details can be found by link below: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I tried but I'm getting a weird linker error: I have no idea what causes it. Looking at the source, it looks perfectly fine.
CC
Worked around it with . PR:
Change:
<del> { lib, stdenv, fetchFromGitHub, fetchpatch, pkg-config, libtool </del> <ins> { lib, stdenv, fetchFromGitHub, pkg-config, libtool </ins> , bzip2, zlib, libX11, libXext, libXt, fontconfig, freetype, ghostscript, libjpeg, djvulibre , lcms2, openexr, libpng, librsvg, libtiff, libxml2, openjpeg, libwebp, fftw, libheif, libde265 , ApplicationServices

Discussion:
, CVSSv3=7.8 (nixos-unstable) CVSSv3=7.8 (nixos-unstable) CVSSv3=6.1 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) CVSSv3=3.3 (nixos-unstable) Scanned versions: nixos-unstable: .
See also:

CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) CVSSv3=9.1 (nixos-unstable) CVSSv3=8.8 (nixos-unstable) CVSSv3=8.8 (nixos-unstable) CVSSv3=8.8 (nixos-unstable) CVSSv3=8.8 (nixos-unstable) CVSSv3=8.8 (nixos-unstable) CVSSv3=7.8 (nixos-unstable) CVSSv3=7.8 (nixos-unstable) CVSSv3=7.8 (nixos-unstable) CVSSv3=7.8 (nixos-unstable) CVSSv3=7.8 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.1 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.

5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) CVSSv3=5.5 (nixos-unstable) Scanned versions: nixos-unstable: .
Change:
<ins> { stdenv, libXScrnSaver, makeWrapper, fetchurl, wrapGAppsHook, gtk3, unzip, atomEnv, libuuid, at-spi2-atk, at-spi2-core}: version: hashes: let name = "electron-${version}"; meta = with stdenv.lib; { description = "Cross platform desktop application shell"; homepage = https://github.com/electron/electron; license = licenses.mit; maintainers = with maintainers; [ travisbhartwell manveru ]; platforms = [ "x86_64-darwin" "x86_64-linux" "i686-linux" "armv7l-linux" "aarch64-linux" ]; }; fetcher = vers: tag: hash: fetchurl { url = "https://github.com/electron/electron/releases/download/v${vers}/electron-v${vers}-${tag}.zip"; sha256 = hash; }; tags = { i686-linux = "linux-ia32"; x86_64-linux = "linux-x64"; armv7l-linux = "linux-armv7l"; aarch64-linux = "linux-arm64"; x86_64-darwin = "darwin-x64"; }; get = as: platform: as.${platform.system} or "Unsupported system: ${platform.system}"; common = platform: { inherit name version meta; src = fetcher version (get tags platform) (get hashes platform); }; linux = { buildInputs = [ gtk3 ]; nativeBuildInputs = [ unzip makeWrapper wrapGAppsHook ]; dontWrapGApps = true; # electron is in lib, we need to wrap it manually buildCommand = '' mkdir -p $out/lib/electron $out/bin unzip -d $out/lib/electron $src ln -s $out/lib/electron/electron $out/bin fixupPhase patchelf  --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${atomEnv.libPath}:${stdenv.lib.makeLibraryPath [ libuuid at-spi2-atk at-spi2-core ]}:$out/lib/electron"  $out/lib/electron/electron wrapProgram $out/lib/electron/electron  --prefix LD_PRELOAD : ${stdenv.lib.makeLibraryPath [ libXScrnSaver ]}/libXss.so.1  "''${gappsWrapperArgs[@]}" ''; }; darwin = { buildInputs = [ unzip ]; buildCommand = '' mkdir -p $out/Applications unzip $src mv Electron.app $out/Applications mkdir -p $out/bin ln -s $out/Applications/Electron.app/Contents/MacOs/Electron $out/bin/electron ''; }; in stdenv.mkDerivation ( (common stdenv.hostPlatform) // (if stdenv.isDarwin then darwin else linux) ) </ins>

Discussion:
Describe the bug ^ what is says. They're several months out of date. Here are the currently supported versions: cc